RE: ASM and archivelogs - what if....
Date: Tue, 5 Feb 2013 09:09:37 -0600
Message-ID: <F05D8DF1FB25F44085DB74CB916678E885711A5E69_at_NADCWPMSGCMS10.hca.corpad.net>
Great points - we do backup the archivelogs as part of the RMAN nightly backup so I wasn't clear on that. Your points about incremental archivelog backups is exactly what I was considering implementing.
We use SAN replication for the database storage to a Sungard DR site and have regular DR tests to verify we can bring those up.
Thanks for the ideas - gives some credence to what I was thinking.
Chris
From: alanbort_at_gmail.com [mailto:alanbort_at_gmail.com] On Behalf Of Guillermo Alan Bort
Sent: Tuesday, February 05, 2013 9:04 AM
To: Taylor Christopher - Nashville
Cc: oracle-l_at_freelists.org
Subject: Re: ASM and archivelogs - what if....
Chris,
A good backup policy will include an archivelog backup immediately after the full backup (that is why RMAN has the backup database plus archivelog feature), and frequent archivelog-only backups. Ideally you would back up the entire database at night and then take archivelog backups every couple of hours. I usually have two scripts for archivelog backups, one that runs every hour or two, depending on the customer data loss requirements and then another one that runs every five minutes and checks how much free space there is in the FRA, if it reaches a certain threshold, then it executes an archivelog backup. In some systems I set up an alert when the "every 5 mintues" script has to run a backup because it means something went wrong (either the transactional load increased for valid reasons or it didn't... if it didn't I need to find out why).
Furthermore, if you have a storage issue bad enough to corrupt the ASM headers, you may loose any cooked filesystems as well (they are not *that* different) and you would have to restore from a tape backup, hence having the archivelogs available on tape is a must.
That being said, if the data loss requirements allow for less than one hour, it is usually a critical system, so the uptime requirements will be equally restrictive, in this scenario the best option is Dataguard.
I'm not a fan of having a secondary archive dest (except for DG) since it increases the chance of impacting the database. The approach I'd take there would be to generate archivelogs to the FRA and then back them up to a filesystem if the tapes are too busy during the day.
Alan.-
On Tue, Feb 5, 2013 at 10:23 AM, <Christopher.Taylor2_at_parallon.net<mailto:Christopher.Taylor2_at_parallon.net>> wrote:
Env:
10.2.0.4 RAC 3 Nodes RHEL 5.6 64-bit
10.2.0.4 ASM 3 Nodes RHEL 5.6 64-bit
We have our archivelogs stored solely in a diskgroup managed by the ASM instance. We don't write the archivelogs to a cooked filesystem.
Nightly we take an RMAN backup and verification to a cooked filesystem.
I'm curious if I have a potential problem area with this setup in that I ask the question:
"What happens if I lose my ASM information - such as ASM disk header corruption or a severe SAN problem that corrupts the disk data?"
I can imagine a scenario where I would have my last backup but not have any current archivelogs to do a restore. How can I prepare for such a potentiality (fully understanding that it is unlikely but still possible)?
Should I just write a secondary archivelog location to a cooked filesystem and have the same tape backup pickup the archivelogs?
"Prepare for the worst, always hope for the best"
Chris Taylor
Oracle DBA
Parallon IT&S
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Tue Feb 05 2013 - 16:09:37 CET