Another suggestion (and I'm not an Oracle DBA, so YMMV): we wind
up putting our Oracle dbs into a "backup" state (via a separate
cron job, since ADSM presched won't wait), and then using a
postschedule after the ADSM backup to bring 'em back "live" -
this means that the databases stay accessible. Or so they tell
me.
Pat Wilson
paw AT dartmouth DOT edu
> One minor suggestion : Use 'shutdown immediate' to stop oracle database
> in these scripts. This way oracle will terminate all active connections,
> perform required rollback and stop the database. Or else, you will have
> to wait until last user signs off from oracle...
> HTH
>
> > -----Original Message-----
> > From: Kells Kearney [SMTP:kells AT winterland.mainland.ab DOT ca]
> > Sent: Friday, January 22, 1999 11:19 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: ADSM/Oracle Startup/Shutdown on DEC UNIX client
> >
> > "Kerssen, Larry" wrote:
> >
> > > I'm attempting to use the PostSchedulecmd & PreSchedulecmd to invoke
> > an
> > > Oracle start & stop for the ADSM incremental backup. I know the
> > ADSM
> > > scheduler invokes the command because I can place a write statement
> > in the
> > > command script and it works. It appears I am having a permissions
> > problem
> > > with the Oracle commands. Does anyone know how I can verify this
> > and if so,
> > > fix it? I'm assuming the ADSM scheduler is running as "root" user.
> > I also
> > > don't know how to tell on DEC UNIX what userid the ADSM scheduler is
> > using.
> > > The client is on a DEC UNIX client running ADSM 3.1.05. My ADSM
> > server is
> > > running on MVS (3.1.01). I invoke the pre & post commands from an
> > option
> > > assigned to the client node, in the ADSM server. I've also tried
> > the pre &
> > > post commands in the client options file, with the same results.
> >
> > You definitely have a permissions problem. All of the Oracle
> > instances I've
> > seen
> > will NOT let a root user access the database (a security feature, I
> > think :).
> > In order
> > to run the svrmgrl script to shut down Oracle, it needs to run as
> > either your
> > Unix oracle
> > account, or another account in the Unix dba group.
> >
> > Something like
> >
> > #!/bin/sh
> > # Oracle shutdown script
> > su - oracle -c svrmgrl <<EOM
> > connect internal
> > shutdown
> > EOM
> >
> > # End of script
> >
> > should do the trick. You can test this on a test instance, but be
> > careful
> > about the
> > difference between 'su' and 'su -' if you decide to set the ORACLE_SID
> > and
> > ORACLE_HOME environment variables, and pass them onto your script.
> >
> > To do that, try
> >
> > #!/bin/sh
> > # Shut down a non-default Oracle instance
> > ORACLE_HOME=/app/oracle/.... # Your setup here
> > ORACLE_SID=test # Your Oracle SID here
> > export ORACLE_HOME ORACLE_SID
> >
> > su oracle -c svrmgrl <<EOM
> > connect internal
> > shutdown
> > EOM
> >
> > # End of script
> >
> > If you can get your scripts to work using a root login, and then
> > cron, the
> > script
> > wil work using ADSM.
> >
> >
> > kells
> >
> > "Any coincidence of opinion, real or imagined, between myself and
> > Mainland
> > Information Systems Ltd is exactly that."
|