Redo (Redo) and undo (Undo) is an important characteristic of the oracle to ensure recoverability and revocation of the transaction.
6.1 Redo the role of
In the database, Redo functions primarily through three components: Redo Log Buffer, LGWR background process and Redo Log File (in archive mode, Redo Log File to end up as an archive log files).
6.2 Redo content
Change vector: a representation of a block of data within the database once the changes made.
Redo record: usually consists of a set of changes to the composition of the vector, is a collection of change vector, representing a database changes, constitute the minimum recovery unit database changes.
Assuming issues an update statement: update emp set sal-4000 where empno = 7788;
(1) Check whether there empno = 7788 recorded in the buffer cache, and if not then read into the buffer cache;
(2) a respective groove in the dispensing transaction rollback transaction rollback table space, this operation requires redo record information;
(3) is read from the rollback or create sal = 3000 until the mirror is in the buffer cache, redo information that needs to be generated and recorded in the redo log buffer;
(4) modified sal = 4000, which is update data update, requires credited redo log buffer;
(5) When a user submits, to submit records information redo log buffer, and marking the transaction in rollback inactive (inactive).
6.3 produce much redo
(1) using the function autotrace sql * plus
776 redo size
(2) by v $ mystat inquiry
Records information about the current session of
col name for a30
select a.name,ab.value from v$statname a,v$mystat b where a.statistic#=b.statistic# and a.name='redo size';
(3) by v $ sysstat inquiry
For the generation amount of database global redo, you can query through the v $ sysstat view
col value for 9999999
select name,value from v$sysstat where name ='redo size';
Obtained from this view is the log generation amount accumulated since the start of the database instance, the log generation amount can be estimated according to Example daily start time.
select startup_time form v$instance;
Archive log data volume, v $ archived_log, you can turn the estimated daily and periodic active database and decide space allocation and other issues.
6.4 Redo write trigger conditions
6.4.1 every 3 seconds timeout (the Timeout)
LGWR to perform write operations, log file parallel write wait event will occur.
Enabling 10046 events can be clearly seen from the LGWR trace log these events.
6.4.2 threshold is reached
redo log buffer1/3 满
redo log buffer dirty data having 1MB
That is, LGWR will trigger when min (1M, 1/3 log buffer size), this time the log buffer size is the log block to be measured.
log buffer is set to 3MB?
6.4.3 User submitted
Before the transaction returns a success flag, you must wait for LGWR to complete writing, notify the LGWR process to write to log file sync event and begin hibernation timeout is 1 second.
Note: The author does not require synchronization redo know recursive call (recursive call) in the corresponding need to return to the user, and therefore only need to synchronize the recursive call to return to the last commit operation before the user calls RBA.
There is a variable for the SGA record log block number redo threads need to synchronize. If multiple submissions before the wake LGWR occurred, this variable recorded the highest log block number, all redo before this will be written to disk. This is sometimes called the group submitted (Group Commit).
6.4.4 written before DBWn
6.5 Redo Log Buffer size settings
Generally 3MB is a more reasonable adjustment beginning, when the log buffer space wait time and appear more significant, consider increasing the log buffer to reduce competition.
6.6 Commit to do what
Submit to complete, this means that the oracle has been written before the point in time redo redo log file.
State of 6.7 log
select * from v$log;
The most common states are: current, active, inactive, unused
（1）current
Currently, activities are being used, crash recovery is necessary
（2）active
Non-current, complete archive may or may not complete the archive, it will be used when restoring the crash.
active status means that the checkpoint has not been completed, if the log file reaches the recycling of the file again, the database will be at a standstill waiting, this time in the alert file, you can see the following records:
Thread 1 cannot allocate new log,sequence 7239
Checkpoint not complete
Current log# 5 seq# 7238 mem#0:/opt/oracle/oradata/hsmk/redo05.log
When this problem occurs, the database can be viewed from the inside through the v $ session_wait, the view displays database current session which is in kind of waiting.
Checkpoint not complete embodies the waiting time log file switch (checkpoint incomplete) in the database;
Cause checkpoint imcomplete may have several reasons:
① the log file is too small, too frequent switching;
② log group is too small, can not meet the needs of normal transaction volumes;
③ log files disk I / bottlenecks O, leading to write slow;
④ Since the data file disk I / O bottlenecks, DBWR to write is too slow;
⑤ Due to the huge transaction volumes, DBWR load is too high, overwhelmed.
For different reasons, we can begin to solve the problem from different angles:
① appropriate to increase the log file size;
② appropriately increase the number of log group;
③ using faster disk log file is stored (e.g., use a higher speed disk: instead of using RAID10 RAID5, etc.);
④ improve disk I / O performance;
⑤ using multiple DBWR process or use asynchronous I / O and so on.
This is a serious kind of waiting, it means that the database can not produce a log of all database modification operations will be fully suspended.
（3）inactive
Log inactive inactive log, which is no longer required in the instance recovery, but the recovery in the medium may be used. inactive status may not log archiving. If the database archiving startup mode, until the archive is not complete, the log file is also not allowed to be covered, this time will be an active process in log file switch (archived needed) to wait in.
Log archiving is complete, it can be judged according to v $ log of archived field.
This condition is usually caused by abnormal by the database, possibly because I / O is slow, possibly because of excessive transaction, in exceptional cases, it may be damaged because the log. The problem can be found by checking the alert log file.
（4）unused
unused means that the log has never been written to, such a log may be just added to the database, or is reset after resetlogs. After being used, the status is modified.
Block size of 6.8 log
512bytes
6.9 log file size
In general, in the actual environment generated, the log switch time control in about half an hour;
For a typical operating system, the maximum size of the log file is 2GB, in a very busy business systems, due to the limited size of the log, the log can control in about 10 minutes has been doing pretty well.
6.10 Why redo generated during hot standby more than normal
This is because during hot backup, oracle to solve the problem of split block, block data needs to be recorded before the mirror line where changes in the log file, not just modify the information.
In the hot standby state, the data changes, oracle mirrored data needs to be recorded before the block of the entire change in the log.
select * from redo_size;
6.11 Can not generate redo
6.11.1 nologging impact on the database
nologging can be greatly reduced so that the generated log, but logs necessary (such as modifications to the dictionary tables) will be recorded.
You can use nologging environment is very limited, and in some operations, you can increase nologging words:
① when creating an index or index rebuilding;
② By / * + append * / prompt, direct insert operation or batch path sql * loader direct path loading transactions;
When you create a data table ③CTAS way;
④ large object LOB operation;
⑤ Some alter table operations, such as move, split, etc.
Create a view to facilitate the query redo log
create or replace view redo_size
as
select value from v $ mystat in $ statName where the $ mystat.statistic # = # statname.statistic in $ and in $ statname.name = 'redo size';
For a database of influence 6.11.2 disable_logging
In addition to the above normal operation, oracle there is an internal parameter, the database can log off, or to achieve some special needs testing purposes, the parameter can be set dynamically alter system set "_disable_logging" = true;
6.11.3 force logging mode
When used as a backup, or disaster recovery dataguard high availability database means, the log usually becomes indispensable, as for the database may be forced log mode. In this mode, all operations are logged.
6.12 redo failure recovery
6.12.1 lost inactive log failure recovery group
By clear reconstruction of the log set to resume
! rm /op/oracle/oradata/redo02.log
alter system switch logfile;
startup
atartup mount;
select * from v$log;
select * from v$logfile;
It noted that, since the log group 2 has been lost, the handover process in the log, the database Crash, so that the state becomes the Invalidated group 3 log, the log file status redo03.log becomes stale (stale usually occurs after a failed operation, after a successful operation the next state will return to normal)
You can start the database after clearing the log group:
alter database clear logfile group 2;
If the database is in archive mode, and the group did not complete the archive log is required to force removal:
alter database clear unarchived logfile group 2;
6.12.2 recover lost or current activity log files
Oracle data submitted by the success of the log file will not necessarily lose, but in the failure, the user may lose the current log file. This in turn divided into two cases, the database normal or abnormal shut off.
(1) When the current log loss, normal shutdown database
Before closing the database, oracle will perform a full check points, the current log can no longer needed in the instance recovery.
(2) when the current loss log database shuts
In this case, usually need to restore data from backup files, archive log files by applying a deduction forward until the last good log file, and then start the database recovery can be accomplished through resetlogs, lost data is corrupted log file data.
When the database is not backed up, oracle provides a means for mandatory internal database is open, ignoring issues such as consistency. After opening the database, oralce recommended data export exp, and then re-building a database, and then import the data imp, complete disaster recovery.
Forced to start the database using an implicit parameter:
alter system set "_allow_resetlogs_corruption"= true spfile;
shutdown immediate;
startup mount;
recover database using backup controlfile until cancel;
alter database open resetlogs;
shutdown immediate;
startup
6.13 Diagnostic Case I: to restore the database by clear log
See from the log, the database can not be archived, archiving path error
select * from v$archive_dest;
show parameter log_archive_dest;
Since multiple archiving unsuccessful, resulting in the database archive logs flag is not error, so that the same can not follow the normal log archive.
select * from v$log;
Can be seen in a number of others to restart the handover process, the log group 2 and group sequence # 3 logs have been the promotion, only log group of sequence # 1 is still 202, group 1 because the log is not current log group, so the contents of the log can be eliminated by a clear way, so that the log normal state.
alter database clear unarchived logfile group 1;
Note that since the log is not archived, so hot before the backup for recovery will not cross this gap, oracle database backup is recommended to re-wide, from the alert log you can also see the prompt.
Follow-up work is needed to back up the database.
6.14 Diagnostic Case II: excessive activation of diagnostic log group
Problem Description: The corresponding slow application request has been unable to return
At this time landing database check and found that in addition to current redo log groups are in active state
If the logs are in the active state, then obviously dbwr writing has been unable to keep up with the checkpoint log switch trigger. Then check the busy west dbwr.
ps -ef | grep ora_
dbwr process number is 2266, the top command to look at:
top
No. 2266 can see the process consumes much cpu, obviously not busy, then it is possible bottlenecks on IO, use iostat 'tools plus check io situation. "
iostat -xn 3
You can see the write speed (kw / s) only about 500KB, while the write speed of the disk is usually to 10MB / s, presumably damaged disk. After replacing the disk, the system gradually returned to normal.
Chapter 6 Ends