Collaborate 2014 Networking Opportunity Events

Where I can keep track of the special events (note: these are not “parties” as so many people are misled to believe) at Collaborate (April 7-11, 2014 – Las Vegas, Nevada).

To attend one of these events:

  1. You’re registered as an Collaborate Attendee.
  2. You’re either a prospect, customer, or goodwill contact for the host.
  3. You visit the host’s booth at Collaborate in order to pick up whatever is required for entry.
  4. Do not just show up at the event and attempt to “crash” it – just spend your time at a regular #C14LV reception the same evening and you’ll still get plenty of party time.
Feel free to post your own additions in the comments. 
Advertisements

R12.1.3 Patch Warnings during AutoPatch – Fixed

If you’ve been bothered by these warning messages that come up during every AutoPatch (adpatch) session in Oracle e-Business Release 12.1.x:

AutoPatch warning:
Product Data File
/ptcharmk/apps/apps_st/appl/admin/zfaprod.txt
does not exist for product “zfa”.
This product is registered in the database but the
above file does not exist in APPL_TOP. The product
will be ignored without error.

AutoPatch warning:
Product Data File
/ptcharmk/apps/apps_st/appl/admin/zsaprod.txt
does not exist for product “zsa”.
This product is registered in the database but the
above file does not exist in APPL_TOP. The product
will be ignored without error.

AutoPatch warning:
Product Data File
/ptcharmk/apps/apps_st/appl/admin/jtsprod.txt
does not exist for product “jts”.
This product is registered in the database but the
above file does not exist in APPL_TOP. The product
will be ignored without error.

AutoPatch warning:
Territory Data File
/ptcharmk/apps/apps_st/appl/admin/zfaterr.txt
does not exist for product “zfa”.
This product is registered in the database but the
above file does not exist in APPL_TOP. The product
will be ignored without error.

AutoPatch warning:
Territory Data File
/ptcharmk/apps/apps_st/appl/admin/zsaterr.txt
does not exist for product “zsa”.
This product is registered in the database but the
above file does not exist in APPL_TOP. The product
will be ignored without error.
AutoPatch warning:
Territory Data File
/ptcharmk/apps/apps_st/appl/admin/jtsterr.txt
does not exist for product “jts”.
This product is registered in the database but the
above file does not exist in APPL_TOP. The product
will be ignored without error.

Simply Create the following text files. The contents should be respectively:

$APPL_TOP/admin/jtsprod.txt
%%% Single-product product data file format 12.0.A
jts 875
END_OF_PRODUCT_ABBREVIATIONS -999
875 jts JTS APP
No No No No
Yes Yes
875 JTS JTS
0
1.0.0 1.0.0
none
none
none
none
END_OF_PRODUCTS
Release 12.0.0
12.0.0
R120 R120_ additional-this-mpl
JTS 12.0.0
END_OF_RELEASE 0.0.0

$APPL_TOP/admin/jtsterr.txt (or substitute your own NLS_LANG and NLS_CHARACTERSET settings localized for your instance)
%%% Single-product territory data file format 12.0.A
R120
0 usaeng US AMERICAN EN US American_English
appltape.txt appltape.txt AL32UTF8
Yes Standard Data_Group
none
none
none
none
none
c jts Oracle_CRM_Self_Service_Admin
END_OF_PRODUCT_NAMES
END_OF_LANGUAGE_INFO

$APPL_TOP/admin/zsaprod.txt
%%% Single-product product data file format 12.0.A
zsa 506
END_OF_PRODUCT_ABBREVIATIONS -999
506 zsa ZSA APP
No No No No
Yes Yes
506 ZSA ZSA
0
1.0.0 1.0.0
none
none
none
none
END_OF_PRODUCTS
Release 12.0.0
12.0.0
R120 R120_ additional-this-mpl
ZSA 12.0.0
END_OF_RELEASE 0.0.0

$APPL_TOP/admin/zsaterr.txt
%%% Single-product territory data file format 12.0.A
R120
0 usaeng US AMERICAN EN US American_English
appltape.txt appltape.txt AL32UTF8
Yes Standard Data_Group
none
none
none
none
none
c zsa Oracle_Sales_Analyzer
END_OF_PRODUCT_NAMES
END_OF_LANGUAGE_INFO

$APPL_TOP/admin/zfaprod.txt
%%% Single-product product data file format 12.0.A
zfa 505
END_OF_PRODUCT_ABBREVIATIONS -999
505 zfa ZFA APP
No No No No
Yes Yes
505 ZFA ZFA
0
1.0.0 1.0.0
none
none
none
none
END_OF_PRODUCTS
Release 12.0.0
12.0.0
R120 R120_ additional-this-mpl
ZFA 12.0.0
END_OF_RELEASE 0.0.0

$APPL_TOP/admin/zfaterr.txt
%%% Single-product territory data file format 12.0.A
R120
0 usaeng US AMERICAN EN US American_English
appltape.txt appltape.txt AL32UTF8
Yes Standard Data_Group
none
none
none
none
none
c zfa Oracle_Financial_Analyzer
END_OF_PRODUCT_NAMES
END_OF_LANGUAGE_INFO

Repeat the following dummy file creations for each product you’re registering above:

Create directory $APPL_TOP/zfa/12.0.0/admin

Create directory $APPL_TOP/zfa/12.0.0/admin/driver

Create directory $APPL_TOP/zfa/12.0.0/admin/sql

Create file $APPL_TOP/zfa/12.0.0/admin/driver/zfafile.drv with following contents:
# Dummy xxadfile.drv

Create file $APPL_TOP/zfa/12.0.0/sql/ZFANLINS.sql with following contents:
commit;
exit;

Create file $APPL_TOP/zfa/12.0.0/admin/sql/ZFANLADD.sql with following contents:
commit;
exit;

 

That’s it – no more warnings during AutoPatch. (they are all legacy products anyway)

How to migrate EM12c R3 OMS and repository to a new host

Very useful, even if you’re moving parts of OEM 12c from one host to another, or modifying the filesystem mounts.

Pardy DBA

(EDIT 20130917: If you simply need to change the IP address of your OEM server, please review MOS note 1562029.1.  The procedure in that note may allow you to change your OEM server’s IP address without following the lengthy process I describe below.)

In order to save power in our data center, I need to migrate my EM12c R3 environment from the host where it currently runs to a new host.  I have a simple configuration, with a single OMS, no load balancer, and the repository database runs on the same host as EM12c R3 itself.  I also have BI Publisher installed and integrated with EM12c, and a few third party plugins as I’ve detailed elsewhere on this blog.  If you use an OS other than Linux x86-64 I suggest you research thoroughly as this procedure may or may not apply to your environment.  Further, if you have a multi-OMS…

View original post 3,770 more words

2014-03 Shinnyo-en Buddhism Podcast – Na

2014-03 Shinnyo-en Buddhism Podcast – Namu/Eza/Spiritual Awakening http://ow.ly/2EXoiC

2014-03 Shinnyo-en Buddhism Podcast – Namu/Eza/Spiritual Awakening

2014-03 Shinnyo-en Buddhism Podcast – Namu/Eza/Spiritual Awakening

  • Namu – What is it and Why do we say it?
  • Eza/Elevation Training – What is it? Why do we participate in it?

Subscribe to this Podcast (RSS) or iTunes or via Flipboard

Namu (Japanese, 南無, lit. devotion) from the Sanskrit word “namas” or “namo”, which means resigning one’s soul to something.

So when we chant (the core chant):

“Namu Shinnyo…” it means, “Devotion to the Truth.”

“Namu Shinnyo Ichinyo…” meaning, “Devotion to The Truth and Oneness.”

“Namu Shinnyo Ichinyo Dai-hatsu…” meaning, “Devotion to The Truth and Oneness with Greatness.”

“Namu Shinnyo Ichinyo Dai-hatsu Nehan…” meaning, “Devotion to The Truth and Oneness with the Great Nirvana/Heaven.”

And finally, “Namu Shinnyo Ichinyo Dai-hatsu Nehan Kyo,” meaning, “Devotion to The Truth and Oneness with The Great Nirvana/Heaven Sutra.”

Eza (Japanese, 会座, lit. seated meeting) – part of Shinnyo-en which bridges the world of esoteric buddhism with the lay follower practice is the creation of what I would describe as an “enlightenment preschool” of sorts.  Eza, in the traditional esoteric sense, is the monastic practice of extended deep meditation and prayer, usually in an isolated environment (for example, a cave deep inside a mountain) for months or years of individual reflection and contemplation.

In an earlier podcast, I covered the topic of Shinnyo guided mediation, or Sesshin training. Well, just as missionary school is the training grounds for priests (or Dharma Teachers), Eza is the training process for those endeavoring to become spiritual guides for Sesshin training. Please note that these two disciplines, dharma teachers and spiritual guides, are complementary, but not co-dependent roles. That is there are dharma teachers who are not spiritual guides, and vice-versa.  And through dedication and perseverance, you can achieve both in a single lifetime.

Eza, as practiced in Shinnyo-en,  involves a gradual awakening of the heart and spirit towards a seeking of pure truth. You can view the process of enlightenment as gradually increasing your awareness beyond the five primary senses (sight, sound, smell, taste, and touch), to self-awareness, and finally beyond awareness of the self, to awareness of others and everything. It is awareness without judgement nor critique. Enlightenment embraces the development of yourself into a mirror of your surroundings, void of coloration and filtering, and yet, able to reflect the innate goodness present within each and every living being.

Since spiritual elevation is part of the esoteric practice, or put simply, the part of the buddhist practice that comes with experience, knowledge, education and self-development, there is no “Step 1, 2, 3 and presto, you’re elevated!” kind of project plan. Some people progress very quickly, and others can take decades. But as with most things in life, it is the journey itself that brings the most fulfillment and reward, not the goal. And philosophically, since attachment is one of the things we seek to lessen (and please, do be aware that the definition of “attachment” for the purposes of Buddhism is often misinterpreted, because of the original translation from sanskrit was a closest-matching definition, and not an exact matching word), ultimately it is the freedom from being goal-centric and more process-centric that begins to eliminate the worry and stress over whether we get there, or not.

For now, I will relay what I have been taught by the many who came before me:  Have gratitude in your heart for the opportunity to train each day. Be determined to succeed no matter what direction your path takes, and how many obstacles are presented to you (because you are prepared for them, even if you think you aren’t.) And focus your energies, thoughts, and spirit on becoming one with all that flows around you. Through your daily practice, eventually your perspective will have changed. And one day, when you were always looking up at the skies above you, you will find yourself among the same very clouds and sky, ready to take the next step in your path.

Hou-Ren-Sou: A Recipe for Japanese (Over) Communication

And it works: Hou-Ren-Sou: Communicate X 3.

Voyager of the Flattening World

The Japanese word “hou-ren-sou” means spinach. Spinach is a vegetable you find at the authentic Japanese restaurant, as in “ohitashi” or boiled and chilled spinach with soy sauce and in “goma-ae” or spinach with sweet sesame paste. This “hou-ren-sou” is, however, a special term in the business management context and nothing to do with those delicious dishes. The three syllables of the word, “hou,” “ren,” and “sou” are abbreviation of the three management keywords regarding the Japanese style communication at the workplace. Almost all the Japanese freshmen are repeatedly taught, during on- and off-the-job training, the importance of the “hou-ren-sou.” Let’s see its recipe in more detail.

View original post 388 more words

ORA-06512 ‘DBSNMP.BSLN_INTERNAL’

Periodic Stats Gathering Fails in 11gR2 Oracle Database – found in alert.log: ORA-06512: at “DBSNMP.BSLN_INTERNAL”, line 2073

The Fix:

SQL> @?/rdbms/admin/catnsnmp.sql

SQL> @?/rdbms/admin/catsnmp.sql

Dbhk's Blog

Symptoms

1.  BSLN_MAINTAIN_STATS_JOB failed at every SUNDAY

2.  Alert messages got the following

Errors in file /opt/oracle/diag/rdbms/vstbpro/vstbpro1/trace/vstbpro1_j000_7796.trc:
ORA-12012: error on auto execute of job 11762
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at “DBSNMP.BSLN_INTERNAL”, line 2073

3. Details of the trace file

Trace file /opt/oracle/diag/rdbms/vstbpro/vstbpro1/trace/vstbpro1_j000_7796.trc
Oracle Database 11g Release 11.1.0.7.0 – 64bit Production
With the Real Application Clusters option
ORACLE_HOME = /opt/oracle/product/11g
System name:    SunOS
Node name:      wvpdb09
Release:        5.10
Version:        Generic_138888-01
Machine:        sun4u
Instance name: vstbpro1
Redo thread mounted by this instance: 1
Oracle process number: 73
Unix process pid: 7796, image: oracle@wvpdb09 (J000)

*** 2010-04-11 15:00:04.639
*** SESSION ID:(1041.32020) 2010-04-11 15:00:04.639
*** CLIENT ID:() 2010-04-11 15:00:04.639
*** SERVICE NAME:(SYS$USERS) 2010-04-11 15:00:04.639
*** MODULE NAME:(DBMS_SCHEDULER) 2010-04-11 15:00:04.639
*** ACTION NAME:(BSLN_MAINTAIN_STATS_JOB) 2010-04-11 15:00:04.639

ORA-12012: error on auto execute of job 11762
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at “DBSNMP.BSLN_INTERNAL”, line 2073
ORA-06512: at line 1

Cause

Table DBSNMP.BSLN_BASELINES contains…

View original post 35 more words

Existing OEM 12c Agent Fails Startup and Resecure on Hostname Change

Had an issue where the hostname (on Oracle Enterprise Linux 5.9 – OEL 64-bit) happened to have an incorrect hostname and alias when I had already installed the OEM 12c (12.1.0.3) Agent. Thus the OMS repository targets were all named incorrectly, even though the Agent was secured and registered. (This was a new database host).

In the $AGENT_HOME/sysman/log/emagent.nohup log was the following:

— EMState agent
—– Sat Mar 1 10:42:22 2014::10437::Auto tuning the agent at time Sat Mar 1
10:42:22 2014 —–
—– Sat Mar 1 10:42:23 2014::10437::Finished auto tuning the agent at time Sat Mar 1 10:42:23 2014 —–
—– Sat Mar 1 10:42:23 2014::10437::Launching the JVM with following options: -Xmx128M -server -Djava.security.egd=file:///dev/./urandom -Dsun.lang.ClassLoader.allowArraySyntax=true -XX:+UseLinuxPosixThreadCPUClocks -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseCompressedOops —–
—– Sat Mar 1 10:42:23 2014::10491::Time elapsed between Launch of Watchdog process and execing EMAgent is 2 secs —–
—– Sat Mar 1 10:42:23 2014::10437::Agent Launched with PID 10491 at time Sat Mar 1 10:42:23 2014 —–
2014-03-01 10:42:23,962 [1:main] WARN – Missing filename for log handler ‘wsm’
2014-03-01 10:42:23,971 [1:main] WARN – Missing filename for log handler ‘opss’
2014-03-01 10:42:23,972 [1:main] WARN – Missing filename for log handler ‘opsscfg’
OMS decided to shutdown the agent because of the following reason sent from OMS: EM_PLUGIN_MISMATCH_AND_AGENT_NOT_YET_MANAGED
—– Sat Mar 1 10:42:37 2014::10437::Checking status of EMAgent : 10491 —–
—– Sat Mar 1 10:42:37 2014::10437::EMAgent exited at Sat Mar 1 10:42:37 2014 with return value 0. —–
—– Sat Mar 1 10:42:37 2014::10437::EMAgent was shutdown normally. —–

./emctl secure agent

./emctl start agent

Resulted in the same repeating failures.

Removed the Target Host and Agent from OEM 12c OMS

(Target -> Hosts -> (select host) -> [Remove], and then,

Setup -> Manage Cloud Control -> Agents -> (click on Agent:(port)

Agent Menu (upper-left dropdown) -> Target Setup -> Remove Target)

Re-deployed using the faster method of silent Agent deployment (Bobby Curtis has this covered on http://dbasolved.com/2013/04/10/install-oem-agents-silently-in-any-environment )

Everything ready to proceed again.

When Your Oracle DataGuarded Database is Crashed (unintentionall)

It happens:  You have a 4-node DataGuarded Oracle 11gR2 database and your System Administrators need to take the boxes down for maintenance. But they don’t know that it’s protected under DataGuard, with Fast-start failover enabled (which automatically performs (via DG Observer) the switchover from Primary to Standby, switches roles, reconfigures listeners, and tries to keep everything 99.99995% available.)  So they use good old:

sqlplus “/ as sysdba”

SQL> shutdown immediate;

Database closed.

And now you need to start it back up.  But when your admins get to their familiar old prompt it burps out:

SQL> startup

Error: ORA-16825: multiple errors or warnings, including fast-start failover-related errors or warnings, detected for the database

Now there are a number of blogs which will walk you through the tedious steps of recovering this condition manually via DGMGRL and multiple control file and standby redo log restores to all the targets. But it was 1:00A local time and I didn’t want to spend the rest of the night crawling through these trying to get this beast back on its feet.

So, I returned to the never-ending exploratory world of what is contained in Oracle Enterprise Manager 12cR3 (12.1.0.3.0)  And (tada sound), OEM can handle it all for you relatively automatically.

To get your Primary DB back on-line (to avoid the complaints from the users who have been disconnected)

DGMGRL> connect SYS/<pwd>@<primaryDGDBtarget>

DGMGRL> disable fast_start failover force;

SQL> startup

Database opened.

Now that the Primary is back open and accessible, return to OEM OMS and visit:

Targets -> Database -> (your Primary DB)

Availability -> Data Guard Administration

There’s a text link at the bottom which reads

Additional Administration:

Verify Configuration

That’s your ticket back to green-arrows and healthy DG in 90% of the situations.  It will perform health-checks throughout your configuration, re-created standby redo logs, re-sychronizing disconnected standby databases, shipping archive logs whereever they are needed, repairing disrupted communications, restoring fast-start failover observers, and whatever else you have.

The other alternative is to simply Remove the existing failed Standby database (select, then [Remove] the existing standby database; then visit its host and delete the existing datafiles, redo, archive and tempfiles (you do not have to touch the TNSNAMES or Listener configurations – that will be re-created for you); then use [Add Standby Database] on the same screen to restore functionality (this is good as an if-all-else-fails, so this method of recovery).

Happy Guarding Data!