Re: ASM and archivelogs - what if....

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Tue, 5 Feb 2013 09:18:53 -0600
Message-ID: <CAJvnOJYwohxqA70fpGE=VVjE6XfBYG-rdXynT+fs7mtN6MT4wg_at_mail.gmail.com>



I do like having a second archivelog destination, especially to something like Datadomain. By using datadomain, or other backup solutions that can be mounted to look like a disk drive as a secondary or tertiary archivelog destination you in effect back up the archivelog immediately on generation. You can minimize any possible problems on the db by setting the min_succeeded_Destinations parameter to 1, so that it wont complain unless both archivelog destinations have problems. Frequent backups of the archivelogs are of course a necessity on any busy system, but as was noted backing up to a regular file system in addition to ASM has its own risks,

FYI, I do not work for or get any payments from whoever makes Datadomain (EMC I think).

On Tue, Feb 5, 2013 at 9:04 AM, Guillermo Alan Bort <cicciuxdba_at_gmail.com>wrote:

> 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> 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-l
>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'


--
http://www.freelists.org/webpage/oracle-l
Received on Tue Feb 05 2013 - 16:18:53 CET

Original text of this message