PH failing to connect to Oracle

[Rich `Lego-Man' Jesse - 7633]

I wrote:

RJ> We're running PH 733D3 on HP/UX 10.20 to access an Oracle 7.3.4.3.0 db on t
RJ> same machine.  The OPEN in the DATABASE is specified as
RJ> "ORACLE@$MYSCHEMA/$MYPASSWORD" (uses SQL*Net).  The symbols MYSCHEMA and
RJ> MYPASSWORD are defined in all users' .profiles (we use POSIX and Korn shell
RJ> 
RJ> While this works fine 99% of the time, occasionally we'll get a QUIZ or QTP
RJ> failing with:
RJ> 
RJ>     Data access error.
RJ>        File:  ORACLE@$MYSCHEMA/$MYPASSWORD
RJ>     
RJ>     Action Taken: Run terminated.
RJ>     -----------------------------------------------------------------------
RJ>     DMS-E-GENERAL, A general exception has occurred during operation 'attach
RJ>     database'.
RJ>        File:  ORACLE@$MYSCHEMA/$MYPASSWORD
RJ>     -----------------------------------------------------------------------
RJ>     ORA-01034: ORACLE not available
RJ>        File:  ORACLE@$MYSCHEMA/$MYPASSWORD
RJ> 
RJ> Huh?  Oracle certainly is available, and at the time this usually happens,
RJ> there are very few people on the system, may or may not have backups runnin
RJ> not a huge system load, etc.  In other words, I can't find any similarities
RJ> between the times that this has happened.  There are also no pertinent erro
RJ> in the Oracle database and the local sqlnet.log file has no entries for thi
RJ> particular event.
RJ> 
RJ> Since this doesn't happen with any other app accessing the Oracle database,
RJ> guessing that it may be a problem with our PowerHouse programs or dictionar
RJ> setup, etc.

Doh!  After a little group therapy here, we realized that our production
database will disallow *new* sessions for about 3 seconds every morning while
we startup our test instance of Oracle on the same box as our production
instance.  This is due to a "feature" of Oracle that will not allow our test
instance to be started if the file $ORACLE_HOME/dbs/sgadefPRODUCTIONSID.dbf is
present, since our test instance is a copy of the production one.  So, to get
around it, we rename the above file for the duration of the Oracle CREATE
CONTROLFILE statement -- about 3 seconds.

And since the procedure that has been aborting occasionally can potentially run
dozens of QTP, QUIZ, and QUICK programs iteravely, each of which require a
*new* connection to our production instance, it has been the one point of
failure during the time of the startup of our test instance.  <whew!>

Rich Jesse                              Programmer/Analyst (/DBA/SysAdmin/etc.)
rjesse@qtiworld.com                     Quad/Tech International, Sussex, WI USA
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.