Re: script problem solved, but I still don't understand ....

Ed Stevens <nospam_at_noway.nohow> wrote in message news:<88fvm0hh1qdmdaen6m3i1ha2umm0lgoh8u_at_4ax.com>...
> On 14 Oct 2004 16:28:58 -0700, joel-garry_at_home.com (Joel Garry) wrote:
>
> >Ed Stevens <nospam_at_noway.nohow> wrote in message news:<dr5tm0p1v8gf3nt2iarmfege20dt06iepm_at_4ax.com>...
> >>
> >> And still leaves me with the fundamental question of how I was able to
> >> get a good connect -- *not* a 'connected to an idle instance' -- then
> >> have the first DML statement result in a ORA-01034: ORACLE not
> >> available.
> >
> >I'm frustrated as heck right now because I've done this same thing and
> >can't remember the answer.
> >
> >But it might be something like being logged on as root rather than the
> >oracle user, so you can connect, because that just means running
> >sqlplus, but when you try to actually do anything you get the 1034
> >because the shared memory area is owned by oracle:dba (or whatever)
> >and root is explicitly enjoined from doing certain things in Oracle,
> >even if it is in the dba group.
> >
> >I also have a vague memory of something like this when I forgot the -
> >in the su - oracle, where the oracle .profile had the proper
> >environment call and the sysadmin had tried to run oracle things as
> >root, so the environment was partly set up under cron.
> >
> >jg
>
> Showing the limits of my unix knowledge ...

Mine is becoming more limited, result of setting and forgetting. :-O

>
> So, if a job is submitted by cron, is it being submitted by root or by
> the user that owns the crontab from which the job was scheduled? I
> assumed that it was run by the owner of the crontab. In fact I'm
> pretty certain that if I 'ps -ef | grep oracle' I will see processes
> that were the result of being scheduled in oracle's crontab.

Sorry, I've seen so many places that just run everything from root crontab with su -, I'd forgotten about the normal way to do it, allowing users to have their own crontab.

>
> Are you saying that if I were to log on as root (which I can't do) and
> $ORACLE_SID were null, I could still issue a 'sqlplus "/ as sysdba" '
> and get 'connected' ? If so, and in the case of my original
> problem, what the heck did sqlplus think it was connected to?

No, you'd probably get an ORA-12547 TNS lost contact error. Sorry, I still can't remember exactly how to get into your situation, and I don't have a test box I can futz with enough to replicate it. But I suspect the answer lies in who is in the dba group in /etc/group, together with who is defined with that in /etc/passwd, together with the ownership of the shared memory area, along with the environment variables, and perhaps something in tnsnames.ora. Try doing env >> somefile throughout the whole process (you can put it before and after your command in crontab, separated by ;), maybe an ORACLE_SID or TWO_TASK will show up... maybe from an old /etc/profile.

Of course, if you run the script just when someone else shuts down Oracle, that could do it.

This probably doesn't have anything to do with it, but is interesting anyways: http://metalink.oracle.com/metalink/plsql/ml2_documents.showFrameDocument?p_database_id=NOT&p_id=166409.1

I notice I don't get any "Connected." message when I run a script from the ksh command line, perhaps you are connecting to something in the script to get that? I'm wondering if you are doing something like accidentally connecting somewhere else than you think you are, or doing something to disconnect. Maybe you even have sqlplus aliased?

jg

--
@home.com is bogus.
Grid model in flames:  http://catless.ncl.ac.uk/Risks/23.56.html#subj8