05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

102<br />

CHAPTER 3 ■ FILES<br />

when <strong>Oracle</strong> goes to reuse it. “Will we keep a copy of that redo or should <strong>Oracle</strong> just overwrite<br />

it, losing it forever?” is an important question to answer. Unless you keep this file, you cannot<br />

recover data from a backup to the current point in time.<br />

Say you take a backup once a week on Saturday. Now, on Friday afternoon, after you have<br />

generated hundreds of redo logs over the week, your hard disk fails. If you have not been running<br />

in ARCHIVELOG mode, the only choices you have right now are as follows:<br />

• Drop the tablespace(s) associated with the failed disk. Any tablespace that had a file<br />

on that disk must be dropped, including the contents of that tablespace. If the SYSTEM<br />

tablespace (<strong>Oracle</strong>’s data dictionary) is affected, you cannot do this.<br />

• Restore last Saturday’s data <strong>and</strong> lose all of the work you did that week.<br />

Neither option is very appealing. Both imply that you lose data. If you had been executing<br />

in ARCHIVELOG mode, on the other h<strong>and</strong>, you simply would have found another disk. You would<br />

have restored the affected files from Saturday’s backup onto it. Lastly, you would have applied<br />

the archived redo logs <strong>and</strong>, ultimately, the online redo logs to them (in effect replaying the<br />

week’s worth of transactions in fast-forward mode). You lose nothing. The data is restored to<br />

the point in time of the failure.<br />

People frequently tell me they don’t need ARCHIVELOG mode for their production systems.<br />

I have yet to meet anyone who was correct in that statement. I believe that a system is not a<br />

production system unless it is in ARCHIVELOG mode. A database that is not in ARCHIVELOG mode<br />

will, some day, lose data. It is inevitable; you will lose data if your database is not in ARCHIVELOG<br />

mode.<br />

“We are using RAID-5, so we are totally protected” is a common excuse. I’ve seen cases<br />

where, due to a manufacturing error, all disks in a RAID set froze, all at about the same time.<br />

I’ve seen cases where the hardware controller introduced corruption into the data files, so<br />

they safely protected corrupt data with their RAID devices. RAID also does not do anything to<br />

protect you from operator error, one of the most common causes of data loss.<br />

“If we had the backups from before the hardware or operator error <strong>and</strong> the archives were<br />

not affected, we could have recovered.” The bottom line is that there is no excuse for not being<br />

in ARCHIVELOG mode on a system where the data is of any value. Performance is no excuse;<br />

properly configured archiving adds little to no overhead. This <strong>and</strong> the fact that a “fast system”<br />

that “loses data” is useless would make it so that even if archiving added 100 percent overhead,<br />

you would need to do it. A feature is overhead if you can remove it <strong>and</strong> lose nothing<br />

important; overhead is like icing on the cake. Preserving your data, <strong>and</strong> making sure you<br />

don’t lose you data isn’t overhead—it’s the DBA’s primary job!<br />

Only a test or development system should execute in NOARCHIVELOG mode. Don’t let anyone<br />

talk you out of being in ARCHIVELOG mode. You spent a long time developing your<br />

application, so you want people to trust it. Losing their data will not instill confidence in<br />

your system.<br />

■Note There are some cases in which a large DW could justify being in NOARCHIVELOG mode if it made<br />

judicious use of READ ONLY tablespaces <strong>and</strong> was willing to fully rebuild any READ WRITE tablespace that<br />

suffered a failure by reloading the data.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!