| TWO_TASK preventing Oracle instance from restarting [message #64585] |
Thu, 10 February 2005 14:17  |
Jeff Langr
Messages: 3
Registered: February 2005
|
Junior Member |
|
|
Disclaimer: I'm not a DBA, I have only a passing knowledge of Oracle.
I'm working with Oracle version 8.1.7.4.16 under Solaris 8.
We are having problems with getting intermedia to index files under Solaris. This is reported as Oracle/IFS bug 1579125. The workaround says to create a TNS alias, then set TWO_TASK to this alias (the rationale is that the indexing process, which is kicked off by Oracle, needs to go through the listener in order to function properly). I ensured that we had an entry with the tns name ORAIWS in the tnsnames.ora file. I can do a tnsping against oraiws and get a positive response.
Our application, which uses Oracle, was running fine. I modified the .profile and added the lines:
TWO_TASK=oraiws
export TWO_TASK
I also verified that the LD_LIBRARY_PATH contains what look to be proper values:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/oracle/u01/product/817/lib:/opt/oracle/u01/product/817/ctx/lib
After making the change, I stopped and restarted both the Oracle instance and the listener.
Upon attempting to log in via SQLPlus, I get:
ERROR:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
SVR4 Error: 2: No such file or directory
I presume this means that the database instance hasn't restarted. It doesn't look like all the Oracle processes are there if I do a ps.
If I take out the definition of TWO_TASK from the .profile, all works fine; I can log into the database using SQLPlus.
What am I missing? I searched on "TWO_TASK" and "shared memory realm" and tried any suggestions I found, with no luck.
Many thanks,
Jeff
|
|
|
|
|
|
|
|
| Re: TWO_TASK preventing Oracle instance from restarting [message #64597 is a reply to message #64595] |
Fri, 11 February 2005 14:03  |
Jeff Langr
Messages: 3
Registered: February 2005
|
Junior Member |
|
|
Greetings Mahesh,
Thanks for the response. Didn't seem to work, but I did figure this out.
The oracle install (? or someone's install) apparently sets up two startup scripts, S96dbora and S96lsnrora, that go in /etc/rc2.d. I'm not sure why these are numbered the same, but apparently the Oracle instance is starting before the listener. I renumbered S96dbora to S97dbora. Dumb. Once I ran the commands in the scripts manually, it was pretty obvious what the problem was.
Also, since you're going through the listener, apparently you can't use the internal login to do a startup. I changed the script to login using "sys as sysdba" (after doing a sqlplus /nolog) and it appeared to work fine.
regards,
Jeff
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
