On 14 Oct 2004 16:28:58 -0700, joel-garry@home.com (Joel Garry) wrote:

>Ed Stevens <nospam@noway.nohow> wrote in message news:<dr5tm0p1v8gf3nt2iarmfege20dt06iepm@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 ...

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.

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?

joel-garry@home.com (Joel Garry) wrote in message news:<91884734.0410141528.4a58b52f@posting.google. com>...
> Ed Stevens <nospam@noway.nohow> wrote in message news:<dr5tm0p1v8gf3nt2iarmfege20dt06iepm@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

I am running Solaris 8 and I cannot get this behaviour no matter what
I do; either I'm told it's an idle instance or I'm connected, even as
'root'.

I know that cron jobs only get the default environment from
/etc/profile unless it's specifically set in the script. I set
ORACLE_SID and exported it, not exported it, and still was able to
connect to my instance through SQL*Plus, so I can't understand why
exporting the variable in the script should make a difference.
Undoubtedly it does, as you've already stated.

This is truly a strange situation.

David Fitzjarrell

Ed Stevens <nospam@noway.nohow> wrote in message news:<88fvm0hh1qdmdaen6m3i1ha2umm0lgoh8u@4ax.com>. ..
> On 14 Oct 2004 16:28:58 -0700, joel-garry@home.com (Joel Garry) wrote:
>
> >Ed Stevens <nospam@noway.nohow> wrote in message news:<dr5tm0p1v8gf3nt2iarmfege20dt06iepm@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/... 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