Section 16.6. Managing the Archived Redo Logs


16.6. Managing the Archived Redo Logs

How common is the question, "Should I have archiving turned on?" Yes, yes, a thousand times yes! When in doubt, archive it out! Here's what is possible only if archiving is enabled:

  • Recovery up to the point of failure

  • Recovery from a backup that is a month or more oldif all the archived redo logs since then are available

  • Performance of a complete backup of the database without even shutting it down

The existence of archive logs does all this without adding significant overhead to the entire process. The only difference between having archiving on or off is whether or not Oracle copies the current redo log out to disk when it "switches" from one redo log to the next. That's because even with archiving off, it still logs every transaction in the online redo logs. This means that the only overhead associated with archiving is the overhead associated with copying the online file to the archive location, which is why there may be only a 1 to 3 percent performance hit in an environment with many transactionsif there is one at all. Feel free to experiment, but it is very difficult to justify turning off archiving on any production database.

Remember that the archived redo log destination must not fill up. This causes the production database to stop operating.


In my opinion, there are only two environments in which turning off archiving is acceptable. The first is an environment in which the data does not matter. What type of environment would that be? The only one is a true test environment that is using fake data or data restored from production volumes. No structure changes are being made to this database, and any changes made to the data are discarded. This database does not need archiving and probably doesn't even need to be backed up at all. (Did I just write that?) It should be mentioned, though, that if you're benchmarking a database that will go into production, backup and archiving should be running because testing the application without archiving running does not give realistic results. Tests with archiving running are more realisticeven if all the archive logs are deleted as soon as they are made.

Development databases do not fall into this category because, although the data in a development database may be unimportant, the structure of the database often is highly important. If archiving is off, a DBA cannot restore any development work that he has done since the last backup. That creates the opportunity to lose hours or even days worth of work, just so a development database can be 1 to 3 percent faster. That is a big risk for such a small gain.

The second type of database that doesn't need archive logs is a completely read-only database or a "partially read-only" database where an archive log restore would be slower than a reload of the original data. The emergence of the data warehouse has created this scenario. There are now some databases that have completely read-only tablespaces and never have data loaded into them. This type of database can be backed up once and then left alone until it changes again.

A partially read-only database is one that stays read only for long periods of time and is updated by a batch process that runs nightly, weekly, or even as needed. The idea is that, instead of saving hundreds of redo logs, the database would be restored from a backup that was taken before the load. The DBA then could redo the load. There are two choices in this scenario. The first is to turn off archiving, making sure that there is a good cold backup after each database load. If the load aborted or a disk crashed after the load but before the next backup, you can simply load the older backup and then redo the load. The cold backup costs some downtime, but having archiving off speeds up the loads somewhat. The other option would be to turn on archiving. That allows taking a hot backup anytime and creates the option of using the redo logs to reload the data instead of doing an actual data reload. This method allows for greater backup flexibility. However, depending on the database and the type of data, an archive log restore could take longer than a reload of the original dataespecially if it is a multithreaded load. It is a tradeoff of performance for recoverability. Test both ways to see which one works best for you.




Backup & Recovery
Backup & Recovery: Inexpensive Backup Solutions for Open Systems
ISBN: 0596102461
EAN: 2147483647
Year: 2006
Pages: 237

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net