05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 3 ■ FILES 101<br />

So, at the point in time when this message appeared, processing was suspended in the<br />

database while DBWn hurriedly finished its checkpoint. <strong>Oracle</strong> gave all the processing power it<br />

could to DBWn at that point in the hope it would finish faster.<br />

This is a message you never want to see in a nicely tuned database instance. If you do<br />

see it, you know for a fact that you have introduced artificial, unnecessary waits for your end<br />

users. This can always be avoided. The goal (<strong>and</strong> this is for the DBA, not the developer necessarily)<br />

is to have enough online redo log files allocated so that you never attempt to reuse a<br />

log file before the checkpoint initiated by it completes. If you see this message frequently, it<br />

means a DBA has not allocated sufficient online redo logs for the application, or that DBWn<br />

needs to be tuned to work more efficiently.<br />

Different applications will generate different amounts of redo log. A Decision Support<br />

System (DSS, query only) or DW system will naturally generate significantly less online redo<br />

log than an OLTP (transaction processing) system would, day to day. A system that does a lot<br />

of image manipulation in Binary Large Objects (BLOBs) in the database may generate radically<br />

more redo than a simple order-entry system. An order-entry system with 100 users will<br />

probably generate a tenth the amount of redo 1,000 users would generate. There is no “right”<br />

size for your redo logs, although you do want to ensure they are large enough for your unique<br />

workload.<br />

You must take many things into consideration when setting both the size of <strong>and</strong> the number<br />

of online redo logs. Many of them are beyond the scope of this particular book, but I’ll list<br />

some of them to give you an idea:<br />

• Peak workloads: You would like your system to not have to wait for checkpoint notcomplete<br />

messages, to not get bottlenecked during your peak processing. You will be<br />

sizing your redo logs not for “average” hourly throughput, but rather for your peak processing.<br />

If you generate 24GB of log per day, but 10GB of that log is generated between<br />

9:00 am <strong>and</strong> 11:00 am, you’ll want to size your redo logs large enough to carry you<br />

through that two-hour peak. Sizing them for an average of 1GB per hour would probably<br />

not be sufficient.<br />

• Lots of users modifying the same blocks: Here you might want large redo log files. Since<br />

everyone is modifying the same blocks, you would like to update them as many times<br />

as possible before writing them out to disk. Each log switch will fire a checkpoint, so<br />

you would like to switch logs infrequently. This may, however, affect your recovery time.<br />

• Mean time to recover: If you must ensure that a recovery takes as little time as possible,<br />

you may be swayed toward smaller redo log files, even if the previous point is true. It<br />

will take less time to process one or two small redo log files than a gargantuan one<br />

upon recovery. The overall system will run slower than it absolutely could day to day<br />

perhaps (due to excessive checkpointing), but the amount of time spent in recovery<br />

will be shorter. There are other database parameters that may also be used to reduce<br />

this recovery time, as an alternative to the use of small redo log files.<br />

Archived Redo Log<br />

The <strong>Oracle</strong> database can run in one of two modes: ARCHIVELOG mode <strong>and</strong> NOARCHIVELOG<br />

mode. The difference between these two modes is simply what happens to a redo log file

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

Saved successfully!

Ooh no, something went wrong!