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

joel-garry_at_home.com (Joel Garry) wrote in message news:<91884734.0410141528.4a58b52f_at_posting.google.com>...
> 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

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 Received on Fri Oct 15 2004 - 13:05:08 CDT