Re: Turning Off Archive Logging for Dev, Test Systems

From: joel garry <>
Date: Mon, 7 Apr 2008 11:13:40 -0700 (PDT)
Message-ID: <>

On Apr 7, 7:42 am, "" <> wrote:
> On Apr 7, 10:24 am, Cristian Cudizio <>
> wrote:
> > On Apr 7, 4:15 pm, ""
> > <> wrote:
> > > Hi,
> > > We are running a few SAP/Ora9i/10g Windows systems in which point-in-
> > > time
> > > recovery is not needed. (Some of these systems can easily be rebuilt,
> > > and
> > > others can be restored from a regular cold backup). The systems are
> > > combined
> > > OLTP/DS.
> > > Thus, I am thinking of turning off archive logging for these systems.
> > > What
> > > are some of the other drawbacks to turning off archive logging?
> > > Thanks,
> > > BASIS Consultant
> > If you want REAL test it is better that your test environment is equal
> > to production system.
> > Performance can be slightly different.
> > The problem are archived logs, but you can schedule an rman script
> > that regularly deletes
> > archived logs
> > Regards,
> >  Cristian Cudizio
> >http://oracledb.wordpress.com
> Hi,
> Thanks for the quick reply. We are developing software, not
> replicating our production
> environment (In which case you are correct, and I would leave archive
> logging
> on). I should have specified so in the original question.
> Thanks

This is how I generally do it. For my systems, the RMAN backup has not been the quickest restore. If there were an alter schema name command it might be different, but I have a real problem with using the same schema name in production and development for my systems. YMMV. But in any event, you are analysing it correctly - does the reality meet the backup and restore requirements? Your developers are your users, what will be lost in a wipeout? What's more likely, hardware problems or fumblefingers?

I'm currently upgrading 250 custom programs, I rcp them every day with cron or more frequently as necessary, using a (diff filedate type of ) script. The db with multiple schemata can be upgraded/refreshed at any time (app, OS and Oracle versions). The last one will be the production upgrade. Whether I use archiving or not depends, the app upgrade generates about 125G of arcs for a 100G db, so when I have a window to worry about, noarchive. There are several savepoints in the upgrade that require a backup when doing it for real, no need to PITR in between those. I've also been testing performance and backups, so of course those require archivelog. Then there's a standby... no value stressing the production network unless necessary.

So, it depends.


-- is bogus.
"If something hasn't broken on your helicopter, it's about to."  What
I always think, looking through my glass moonroof at those newby
pilots showing off in their Vietnam-era helicopters over the 5
Received on Mon Apr 07 2008 - 13:13:40 CDT

Original text of this message