cancel
Showing results for 
Search instead for 
Did you mean: 

Shutdown oracle before BC

Shutdown oracle before BC

Hi,

I'm working on a script that will shutdown oracle before doing a bussiness copy.
(We have to be absolutely sure that oracle is down after running the script)

What I had in mind is the following:


-- Start Timer
alter system checkpoint; -- writes dirty buffer to datafiles + updates controlfile
shutdown immediate; -- kill and rollback ongoing transactions +
shutdown database

If Timeout then
shutdown abort; -- Kills everything here and now (No rollback of ongoing transactions)
startup restrict; -- Recover database and starup in restricted mode (only SYSDBA:s allowed)
shutdown normal; -- Wait for all users to logout (Nobody is connected as we are in restriced mode) and then shutdown database cleanly.

end if;

Should this work?

Anyone already having a similar script? :-)

Any other hints or tricks?

Thanks in advance,

Michael
9 REPLIES
Steven E. Protter
Exalted Contributor

Re: Shutdown oracle before BC

Shalom Michael,

Yes it will work.

You can use dbshut as well, if you modify its shutdown from shutdown to shutdown immediate.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Jakes Louw
Trusted Contributor

Re: Shutdown oracle before BC

Looks good to me too, and a company I worked for, with HUGE business-critical DBs, used that method for all BCV splits. Many DRP tests showed that the DB was consistent every time.
(In'Shallah!)
Trying is the first step to failure - Homer Simpson
Ninad_1
Honored Contributor

Re: Shutdown oracle before BC

Just a small suggestion.
Have a script which will logout all applications users using the database before shutting down the database.
I remember we used to kill all client connections - processes showing LOCAL=NO as well.

Regards,
Ninad
Bill Thorsteinson
Honored Contributor

Re: Shutdown oracle before BC

Have you considered hot backups. This
requires the database be in archive log
mode, which you want on any critical database
anyway.

For each tablespace,
- Mark the tablespace as being backed up,
- Copy the tablespace,
- Unmark the tablespace

Save a copy of the control file to trace.
Take a timestamp, wait two seconds, and
force a logfile switch.
Save any logfiles from the start of the
backup until after the forced logfile
switch.

Recovery is:
- Restore files to a new location.
- Modify the backed up control file to
reflect the new locations.
- Startup the database and recover until
the time of the timestamp.
- Shutdown the database and rename it.
- Restart resetting logs.
Jakes Louw
Trusted Contributor

Re: Shutdown oracle before BC

Doing the split while the DB is in backup mode is fine, except.....recovery depends on the availability of the archive logs. In a disaster, you don't want to have wonder where they are. I suggest that if a warm backup is done, that a cold backup is done once a week, to provide a minimum restore point.
Trying is the first step to failure - Homer Simpson

Re: Shutdown oracle before BC

We have considered hot backups...but according to our DBA running in archive log mode would slow the application noticeably...
(business warehouse application)

Thanks for all answers!

//Michael
Yogeeraj_1
Honored Contributor

Re: Shutdown oracle before BC

hi Michael,

being in noarchivelog mode -- is a 100% surefire way to LOSE data

Archiving is very CPU deintensive -- it involves copying a file from one disk to
another disk. You need sufficient devices to avoid contention here.

consider this:
You want to make it so that when LGWR is writing to a device, ARCH is *not* reading that device. So, you would have log group 1 on dev1 (mirrored to dev3). Log group 2 on dev2 (mirrored to dev4). Log group 3 on dev1/dev3, log group 4 on dev2/dev4 and so
on.

Well, LGWR writes to dev1/dev3. Arch is reading dev2/dev4 and writing to dev5. Arch finishes and waits. LGWR not writes to dev2/dev4, Arch reads dev1/dev3 and writes to dev5. No contention, there you go -- smooth operation, no degradation.

think well, in some cases noarchivelog is indeed essential... but can you afford to make this compromise?

kind regards
yogeeraj
No person was ever honoured for what he received. Honour has been the reward for what he gave (clavin coolidge)

Re: Shutdown oracle before BC

Thanks for your opinion on the archivelog issue...
(I'll forward it to the DBA)

Unfortunatly I'm just the consultant setting up the bussiness copy :-)

I've tried to convince my customer to switch to archivelog mode and
the least I can say is that's been very controversial...

//Michael

Re: Shutdown oracle before BC

Got sufficiant information...