11 Copyright © 2006, Oracle. All rights reserved. Checkpoint and Redo Tuning.

11Copyright © 2006, Oracle. All rights reserved.

Checkpoint and Redo Tuning

11-2 Copyright © 2006, Oracle. All rights reserved.

Objectives

After completing this lesson, you should be able to do the following:

• Diagnose checkpoint and redo issues

• Implement Fast Start MTTR Target

• Monitor the performance impact of Fast Start MTTR Target

• Tune the redo chain

• Size the redo log file

• Size the redo log buffer


Checkpoint and Redo

• Checkpoint:– Transfers changed data to disk– Makes buffer space available for more data blocks– Controls mean time to recover (MTTR)

• Redo:– Recovers committed data not on disk– Provides uncommitted data for rollback operation– Provides source data for complete recovery


Spfile

Temp

Data file

Undo

Oracle Database Architecture

PMON SMON RECO MMON

MMNL

PSP0

MMAN DBWn LGWR CKPT

CJQ0

S000

D000QMNC

QnnnFMON

ARCnCTWR

RVWR

Fixedsize

Largepool

Javapool

Streamspool

Defaultbuffercache

Keepbuffercache

Recyclebuffercache

nKbuffer

caches

Redolog

buffer

ASHbuffer

Sortextentpool

Globalcontext

pool

SGA

Flashbackbuffer

Instance

Flashbacklogs

Redo logfiles

Archivelog files

Controlfiles

SYSTEM

SYSAUXChangetracking

file

Passwordfile

Sharedpool


Checkpoint Architecture

The checkpoint architecture provides:

• Checkpoint position: A starting position in the redo logs to begin recovery

• Checkpoint target: A calculated position in the redo logs where the checkpoint position should be

• An estimated mean time to recover

• A high-performance incremental checkpoint

• A full checkpoint when required


Database Writer (DBWn) Process

DBWn writes when one of the following events occurs:

• Checkpoint

• Dirty buffers’ threshold

• No free buffers

• Timeout

• RAC ping request

• Tablespace OFFLINE• Tablespace READ ONLY• Table DROP or TRUNCATE• Tablespace BEGIN BACKUP

SGA

Databasebuffer cache

Data files

DatabaseWriter

(DBWn)

Background Information


Checkpoint (CKPT) Process

Responsible for:

• Signaling DBWn at checkpoints

• Updating data file headers withcheckpoint information

• Updating control files withcheckpoint information

DatabaseWriter

(DBWn)

Checkpoint(CKPT)

SGA

Databasebuffer cache


Redo Architecture

Redo is designed for minimum performance impact.

• Server processes write to the redo log buffer:– Circular buffer – Memory-to-memory writes – Small fast writes

• LGWR writes log buffer blocks to log files:– Circular files– Memory-to-disk write– Full blocks if possible

• ARCn copies log files to archive log files:– Disk-to-disk writes– Multiple archiver processes can be started.


Database buffer cache

Redo log

buffer

Shared pool Library cache

Data dictionary cache

User global area

The Redo Log Buffer

SQL> UPDATE employees

2 SET salary=salary*1.1

3 WHERE employee_id=736;

Serverprocess

LGWR

Control files

ARCn

Archivedlog files

Redo log files

Data files


Redo Log Files and LogWriter

Redo log files:

• Record changes to the database

• Should be multiplexed to protect against loss

LogWriter writes:

• At commit

• When one-third full

• Every three seconds

• Before DBWn writesGroup 3

LogWriter

(LGWR)

Group 1 Group 2

Redo log buffer

SGA

Redo log files


Archiver (ARCn)

• Is an optional background process

• Automatically archives online redo log files when ARCHIVELOG mode is set for the database

• Preserves the record of all changes made to the database

LogWriter(LGWR)

Archiver(ARCn)

Redo log buffer

SGA


Incremental Checkpointing

c1Checkpoint

position

c2 c3 c4 c5Tail of

redo thread

Redo stream

Checkpointqueue

Target RBA

b3 b4

t2

t1

FAST_START_MTTR_TARGET=T

t1 + t2 < T

b1 b2

Incremental checkpoint


Incremental Checkpoint and Log File Size

• The maximum checkpoint lag is:

90%*(SUM(log_sizei) – MAX(log_sizei))

• Checkpoint lag is designed to prevent log switch from blocking.

• A few small log files can result in excess checkpoint writes.

Currenttail

Target checkpoint

9,000blocks

Log file#1:10,000 blocks

Log file#2:10,000 blocks


Adjusting the Checkpoint Rate

The checkpoint rate is determined by the most aggressive of:

• FAST_START_MTTR_TARGET parameter (only on Enterprise Edition)

• Size of the smallest redo log file

• LOG_CHECKPOINT_TIMEOUT parameter (overrides FAST_START_MTTR_TARGET if set)

• LOG_CHECKPOINT_INTERVAL parameter (overrides FAST_START_MTTR_TARGET if set)


Redo Logfile Size Advisor

• This advisor determines theoptimal size of youronline redo logs:– No additional

checkpoint writesbeyond those caused by FAST_START_MTTR_TARGET.

• FAST_START_MTTR_TARGET must be set.

This column shows the redo log file size (in megabytes) that is considered as minimal.

Description

OPTIMAL_LOGFILE_SIZEColumn name

V$INSTANCE_RECOVERYView name


Impact of the Checkpoint Rate

SELECT c.value-nc.valueFROM V$SYSSTAT c, V$SYSSTAT ncWHERE c.name = 'physical writes' AND nc.name = 'physical writes non checkpoint';

Statistic Total -------------------------- ------------------ physical writes 47,308 physical writes non checkpoint 44,674

From the V$ views:

From the Statspack report:


Automatic Checkpoint Tuning

• There is no longer a continuous manual tuning effort.

• Automatic checkpoint tuning is the best-effort checkpointing, without much overhead.

• It reduces average recovery time by making use of unused bandwidth.

• Automatic checkpoint tuning is enabled when FAST_START_MTTR_TARGET is not explicitly set to zero.


ADDM Report: Checkpoints


ADDM Report: Redo Logs


Statspack and AWR Reports

Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait CallEvent Waits Time (s) (ms) Time----------------------- ------- ----------- ------ ------CPU time 551 56.8log file parallel write 3,899 201 52 20.7log file sync 823 58 71 6.0latch: redo copy 635 44 70 4.6latch: redo allocation 1,109 42 38 4.4

Checkpoint and redo show certain symptoms:

• Alert log shows log switch not complete

• I/O symptoms caused by excessive checkpoints

• Log switches per hour > 4

• log file and latch:redo in Top Timed Events


Check Parameters

Parameter Name Begin value---------------------------- -----------fast_start_mttr_target 25

Review checkpoint parameters for reasonable values:

SQL> SELECT mttr_target_for_estimate, 2> estd_total_ios, estd_total_io_factor 3> FROM V$MTTR_TARGET_ADVICE ORDER BY 1

MTTR_TARGET_FOR_ESTIMATE ESTD_TOTAL_IOS ESTD_TOTAL_IO_FACTOR------------------------ -------------- -------------------- 20 2436690 1.0739 22 2330674 1.0272 25 2268973 1 37 2204817 .9717 62 2181841 .9616

Use V$MTTR_TARGET_ADVICE for optimum value:


Check the Redo Log Size

Review the current size of the redo log files:

Check alert log for log switch rate:


Redo Log Chain Tuning

Redo tuning starts with the slowest part.

• Reduce the amount of redo generated.

• Check archive logging (waits for archiving needed).

• Check the redo log file size and log switch rate.

• Check the checkpoint parameters.

• Look for log space requests.

• The Redo Buffer Allocation Retries value should be near 0 and should be less than 1% of redo entries.


Reducing Redo Operations

Ways to avoid logging bulk operations in the redo log:

• Direct Path loading without archiving does not generate redo.

• Direct Path loading with archiving can use NOLOGGING mode.

• Direct Load INSERT can use NOLOGGING mode.

• Some SQL statements can use NOLOGGING mode.


Increasing the Performance of Archiving

• Share the archiving work during a temporary increase in workload:

• Increase the number of archiver processes with LOG_ARCHIVE_MAX_PROCESSES.

• Multiplex the redo log files, and add more members.

• Change the number of archive destinations:

– LOG_ARCHIVE_DEST_n

ALTER SYSTEM ARCHIVE LOG ALL

TO <log_archive_dest>


Diagnostic Tools

V$ARCHIVE_DEST

V$ARCHIVED_LOG

V$ARCHIVE_PROCESSES

LOG_ARCHIVE_DEST_n

Archivedlogs

LOG_ARCHIVE_DEST_STATE_n


LGWR

Redo Log Groups and Members

Group 2 Group 3Group 1Disk 1

Disk 2

Member

Member

Member

Member

Member

Member


Online Redo Log File Configuration

• Size redo log files to minimize contention.

• Provide enough groups to prevent waiting.

• Store redo log files on separate, fast devices.

• Monitor the redo log file configuration with:

– V$LOGFILE– V$LOG– V$LOG_HISTORY


Monitoring Online Redo Log File I/O


Sizing the Redo Log Buffer

The size of the redo log buffer is determined by:

• LOG_BUFFER parameter

• Remaining space in the fixed area granule

Default value: Either 2 MB or 128 KB the value of CPU_COUNT, whichever is greater


Archivedlog filesRedo log files

Diagnosing Redo Log Buffer Inefficiency

SQL> UPDATE employees

2 SET salary=salary*1.1


Serverprocess

LGRW

ARCH

Serverprocess

SQL> DELETE FROM employees



Diagnosing Log Buffer Problems

V$SESSION_WAIT

Log Buffer Space event

V$SYSSTAT

Redo Buffer Allocation Retries

Redo Entries

Redo log buffer


Log Space Request Waits:Further Investigation

Possible reasons for log space request waits:

• There is disk I/O contention on redo log files.

• LGWR is waiting on DBWn to complete the checkpointing of the required redo log file.

• LGWR is waiting on ARCn to complete archiving of the required redo log file.

• Log buffer is too small.


Practice Overview: Diagnose Checkpoints and Redo

This practice covers the following topics:


• Resize log files

• Adjust the checkpoint parameters


Summary

In this lesson, you should have learned how to:


• Implement Fast Start MTTR Target

• Monitor the performance impact of Fast Start MTTR Target

• Implement multiple database writers

• Tune the redo chain

• Size the redo log file

• Size the redo log buffer

11 Copyright © 2006, Oracle. All rights reserved. Checkpoint and Redo Tuning.

Documents

Transcript of 11 Copyright © 2006, Oracle. All rights reserved. Checkpoint and Redo Tuning.