RE: Hot Backup Theory Revested:
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 24 Jun 2004 09:30:00 -0400
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
----------------------------------------------------------------
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
-----------------------------------------------------------------
----------------------------------------------------------------
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:
