Shutdown oracle before BC

[Michael Kalisz]

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

[Steven E. Protter]

Shalom Michael,

Yes it will work.

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

SEP

[Jakes Louw]

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!)

[Ninad_1]

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]

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]

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.

[Michael Kalisz]

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]

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

[Michael Kalisz]

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

[Michael Kalisz]

Got sufficiant information...