RE: Hot Backup Theory Revisited:
- From: "Khedr, Waleed" <Waleed.Khedr@xxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 25 Jun 2004 01:51:17 -0400
I think it's better copying the control file to a trace file, creating new
control file for the cloned DB using the trace file, and doing recover until
cancel.
Waleed
-----Original Message-----
From: Hodgkinson, Stephen [mailto:Stephen.Hodgkinson@xxxxxxxxxx]
Sent: Thu 6/24/2004 10:34 PM
To: 'oracle-l@xxxxxxxxxxxxx'
Cc:
Subject: RE: Hot Backup Theory Revisited:
Mark,
Thanks for you help.
The log file has definitely been switched.
I am deliberately using 'ALTER SYSTEM ARCHIVE LOG CURRENT' because the
script will wait to it completes before continuing.
(what I heave read on metalink)
I do create a backup controfile just left it out of the example. I do
recover using it.
Yes it is short hand typing, just trying to get the idea across
I do use Log serail numbers - didn't really meant to say time.
Thanks again,
I guess the conclusion is it should never require archive logs before
the
first begin backup otherwise other people would have experienced this
problem also - next time it happens I will investigate it fully
Thanks, Stephen.
-----Original Message-----
From: Mark W. Farnham [mailto:mwf@xxxxxxxx]
Sent: Thursday, 24 June 2004 11:30
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Hot Backup Theory Revested:
Are you checking that the log file has in fact switched before you
begin
backup?
-- I am not confident of my memory whether archive log current is
synchronous or asynchronus at various releases. Further, if you use two
different sessions that would not save you anyway.
Appropriate DBA paranoia dictates that you spin/wait on the log serial
number in question until the database reports that its status is
archived.
Call this step 1a
Definitely make sure you're waiting for the archive of the archive from
step
3.
Are you using disk systems that defer writes? If I recall correctly,
the
archive log current pushes a checkpoint (can't hurt to add one and wait
for
it to complete before the start of begin backup - if it is extraneous
it
will have very little to do), but if your disk cacheing does not
actually
push the writes, then you could be reading stale blocks via the OS
(naughty
OS!). The equivalent of sync;sync;sync for your disk subsystem between
steps
1a and step 2 should take care of that. (NFS or SAN involved here?)
You mentioned TIME in your copyarchlogs. Far better to use the log
serial
numbers. Depending on how and where time is computed, it can vary, but
the
serial numbers are reliable.
Where do you create backup controlfiles to be used with the minimal
backup
set? Are you telling recovery that you are using a backup controlfile?
In your step 2, I'm assuming that is just short hand typing, but I hope
you
really mean:
For each tablespace
begin backup of tablespace
copy each file that is a component of the tablespace
end backup of the tablespace
loop
or begin backup for all tablespaces
copy all database files for all tablespaces
end backup for all tablespaces
(a little less good if you're trying to minimize whole block redo
generation)
Since v6.0.36 I have never witnessed a failure to recover from a
properly
constructed hot backup set, so your 5% failure rate seems extremely
high.
Far and away the leading cause of broken recoveries that I have
witnessed is
from reloading the online redo logs from the time of the backup over
the top
of the current online redo logs. So make step one of your recovery
getting
an online copy of the current online redo logs, just in case something
does
go wrong.
Okay, that's all I can think of off the top of my head. I hope one of
these
thoughts leads you to a solution.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Hodgkinson, Stephen
Sent: Thursday, June 24, 2004 4:47 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: FW: Hot Backup Theory Revested:
> Can somebody give me there opinion on the below - either yes this can
> happen or no this is impossible you must have a mistake elsewhere.
>
> /****************************************************
>
> I have an automated script that backups my database, ftp's it to a
> test server and rebuild it each night.
>
> This process works 95 % of the time.
>
> Occasionally the restore of the database fails as it asks for an
> archive log before the backup process began.
>
> My backup is something like this:
>
> 1) ALTER SYSTEM ARCHIVE LOG CURRENT
> 2) Start Begin and End Backups and copies of all tablespaces.
> 3) ALTER SYSTEM ARCHIVE LOG CURRENT
> 4) CopyArchivedRedoLogs (From the time of step1 to tep 4)
>
> So my question is do you ever require the archive logs that are
> generated before the first begin backup e.g. Maybe for a long running
> transaction that spans redo logs.
>
> I tried executing step 1) four times but I Didn't really expect it
to
> help - and it didn't
>
> Please don't suggest using RMAN - we will use it soon.
>
> I known you generally would want all you archive logs and we do have
> this it is just an automation issue I am trying to resolve.
>
> If you believe what I am suggesting is impossible please let me known
> and the next time it happens I will investigate it 100 % rather than
> just manually ftp over the old archive log.
>
> Thanks in advance.
>
>
>
************** IMPORTANT MESSAGE **************
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. If you are not the intended
recipient
please advise the sender by return email, do not use or disclose the
contents, and delete the message and any attachments from your system.
Unless specifically indicated, this email does not constitute formal
advice
or commitment by the sender or the Commonwealth Bank of Australia (ABN
48
123 123 124) or its subsidiaries. We can be contacted through our web
site:
www.commbank.com.au
**************************************************
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
<https://access0.fidelity.com/,DanaInfo=www.orafaq.com+>
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
<https://access0.fidelity.com/archives/oracle-l/,DanaInfo=www.freelists.org+>
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
<https://access0.fidelity.com/help/fom-serve/cache/1.html,DanaInfo=www.freelists.org+>
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
<https://access0.fidelity.com/,DanaInfo=www.orafaq.com+>
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
<https://access0.fidelity.com/archives/oracle-l/,DanaInfo=www.freelists.org+>
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
<https://access0.fidelity.com/help/fom-serve/cache/1.html,DanaInfo=www.freelists.org+>
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
<https://access0.fidelity.com/,DanaInfo=www.orafaq.com+>
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
<https://access0.fidelity.com/archives/oracle-l/,DanaInfo=www.freelists.org+>
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
<https://access0.fidelity.com/help/fom-serve/cache/1.html,DanaInfo=www.freelists.org+>
-----------------------------------------------------------------
-- Binary/unsupported file stripped by Ecartis --
-- Type: application/ms-tnef
-- File: winmail.dat
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
