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."