Re: Backup setup sane?
Date: Fri, 16 Oct 2009 21:08:06 +0200
Message-ID: <7jrukmF33ob38U1_at_mid.individual.net>
On 10/16/2009 06:52 PM, joel garry wrote:
> On Oct 16, 1:39 am, Robert Klemme <shortcut..._at_googlemail.com> wrote:
>
>> I set these non default settings >> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 10 DAYS;
>
> I can't remember why, but every time I investigate it it becomes
> obvious this should be much longer.
It would be interesting to learn why. :-) As far as I understood the recovery window RMAN will keep all the files that it needs to recover to any point in time within the window so there should not be a problem (unless you want to recover to a point in time outside the window :-)).
> Something like, if you are
> keeping the information in the control file, then you are going to
> have to tell RMAN about what is actually available on disk with cross
> reference and delete obsolete commands and the like.
That was the exact intention of my scripts.
> So if you are
> going to make things on disk appear and disappear "behind RMAN's back"
> it is much easier with a longer retention policy.
I did not even plan to go near that option. As little as I understand about RMAN yet, one thing seems to be clear: it wants to control the whole process of storing backups and erasing stuff and as soon as you start doing things "behind its back" you need to be extra cautious.
Having said that I once worked with a 10 something DB (also on Linux) where backups were done via a storage manager (not sure, could have been Tivoli) and roughly once in a month RMAN got stuck and the backup did not finish. I finally created a trap in EM that sent me an email when the backup took longer than a few hours. I then needed to log into the system and manually kill RMAN. That kind of shock my confidence in storage manager integrations - although it is a nice idea in theory because you do not have to store backups locally before sending them off to storage plus RMAN always knows where things are. Well, in theory anyway...
> There are some
> things you can do with catalogs to tell RMAN about things that you
> can't do with nocatalog, though off the top of my head I can't recall
> what they are, and there are version dependencies.
Maybe I'll look into using a catalog as next learning step. I wanted to keep things simple initially. And those scripts are surprisingly simple indeed - I hope that they do what I expect them to do. :-)
> At least retention policy even hurts the RMAN book authors head:
> http://www.freelists.org/post/oracle-l/RMAN-retention-policy,1
Well, the presented scheme is exactly what I would have expected. With incremental backups it is obvious that you need the newest full backup before the incremental that you need to recover to the earliest day in the window.
Thanks for commenting!
Kind regards
robert
-- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/Received on Fri Oct 16 2009 - 14:08:06 CDT