This topic is discussed in ITPUB. Link: www.itpub.netthread-1838538-1-1.html 1. What is IMU? What is the main role of IMU, that is, to solve what problems? IMU --- InMemoryUndo, new 10g feature, the database will open up an independent memory area in the sharedpool to store Undo information, each new transaction will
This topic is discussed in ITPUB. Link: http://www.itpub.net/thread-1838538-1-1.html 1. What is IMU? What is the main role of IMU, that is, to solve what problems? IMU --- In Memory Undo, new 10g feature, the database will open up an independent Memory area In the shared pool to store Undo information, each new transaction will
This topic is discussed in ITPUB, link: http://www.itpub.net/thread-1838538-1-1.html
1. What is IMU? What is the main role of IMU, that is, to solve what problems?
IMU ---> In Memory Undo, new 10 Gb feature, the database will open up an independent Memory area In the shared pool to store Undo information,
Each new transaction is allocated an IMU buffer (private). A buffer contains many nodes, and a node is equivalent to a block (rollback block ).
IMU features:
IMU, as its name implies, is the undo in the memory. now, every time you change the data block, Oracle does not need to change this undo block (and no corresponding redo is generated ), instead, the undo information is cached in IMU. Only when the final commit or flush IMU is used, the undo information is updated to the undo block in batches and a redo is generated. It can avoid read/write operations in Buffer Cache before Undo information, further reduce Redo generation, and greatly reduce previous undo segment operations. Data in IMU can also be written into rollback segments after being saved, sorted, and shrunk. Such writing improves the performance of sequential and batch writing.
IMU main functions:
Reduce CR blocks --> when constructing CR blocks, you do not need to obtain undo record from the undo block as before. Instead, you can use the information in the private IMU area of the Shared Pool to construct the cr block, this reduces the cbc latch competition in buffer caceh.
Reduce the number of redo log entries --> it is no longer a redo records statement for each DML statement, but the generation of a redo records -- redo record for each transaction will be uploaded to the log buffer, and LATCH will be applied.
Reduce LATCH --> first, because the number of REDO records is reduced. Second, replace redo allocation latch and redo copy latch with an IMU latch, which also reduces LATCH contention.
Number of imu latch in the query system-that is, the number of Private redo strand area.
Internal table corresponding to the IMU private REDO partition: x $ kcrfstrand internal table corresponding to the imu undo partition: x $ ktifp
BYS @ bys3> select count (name) from v $ latch_children where lower (name) like 'in mem % ';
COUNT (NAME)
-----------
84
BYS @ bys3> select count (*), name from v $ latch_children where lower (name) like 'in mem % 'group by name;
COUNT (*) NAME
--------------------------------------------------------------------------
84 In memory undo latch
The following statement can be used to query the imu latch retrieval status.
Select name, gets from v $ latch_children where lower (name) like 'in mem % ';
2. In which scenarios will IMU features not be used? (IMU is enabled for ORACLE 10 Gb by default)
IMU is not supported in the RAC environment.
When flashback database is enabled, secondary logs are enabled. At this time, IMU cannot be used.
The transaction is too large-it is said that the Private redo strand area size of each IMU Buffer is about 64 KB (the 64-bit Oracle version is KB), and large transactions cannot be used. For example, if a transaction has an UPDATE, the REDO private region is used up. Other DML statements of this transaction will automatically use the non-IMU mode.
If the Shared Pool is too small, ORACLE automatically does not use IMU.
When imu latch cannot be obtained, non-IMU mode is automatically used.
3. How do I manually disable and enable IMU mode?
By default, the IMU feature is enabled for 10g and 11g. The statement for enabling and disabling is as follows: -- it is best to restart the modification to make it take effect, or switch the REDO log at least once.
Alter system set "_ in_memory_undo" = false;
Alter system set "_ in_memory_undo" = true; -- disable IMU and use this statement to use IMU again.
4. How does one UPDATE a statement process from step 1 to Step 9? Perform DUMP Analysis on REDO logs in IMU mode (as shown in REDO format in IMU mode ). The UPDATE statement corresponds to Step 1 to Step 9: Step 1: store the changed data to PGA
Step 2: copy the old data in the buffer cache to the private IMU buffer in the sharing pool.
Step 3: store the modified data in PGA to private redo-only available in IMU.
Step 4: modify data in the buffre cache
After submitting:
Step 5: Copy and modify the pre-value from IMU to build a CR block in buffer cache ----- SMON will do this even if it is not submitted every 3 seconds
Step 6: Step 4 modify the redo log generated by data in the buffre cache and write it to log buffe
Step 7: Step 5: Construct CR blocks and write the generated redo logs into log buffe
Step 8: log buffer written by lgwr to redo log file
Step 9: dbwr write dirty data into the data file5.UPDATE operation dump redo content experiment record:
INSERT and DELETE statements. For details, see: Click to open the link.
REDO RECORD-Thread: 1 RBA: 0x000141. 00000027.0010 LEN: 0x031c VLD: 0x0d
SCN: 0x0000.00719188 SUBSCN: 1 01/07/2014 20:27:05
(Lwn rba: 0x000141. 00000027.0010 LEN: 0002 NST: 0001 SCN: 0x0000.00719187)
#### A redo record: a RECORD header + change vector (a CV is an operation)
The above is the log header, Thread: 1 Thread number, RAC will have 1, 2 and so on
RBA: 0x000141. 00000027.0010 converts hexadecimal to decimal values: log file number, log block number, and N bytes in the block.
VLD: 0x0d Log Type -- this is used in the IMU mode; if it is not IMU, it is: VLD: 0x05
SCN: 0x0000.00719188 SUBSCN: 1 01/07/2014 20:27:05 ----
BYS @ bys3> select scn_to_timestamp (to_number ('000000', 'xxxxxxxx') from dual;
SCN_TO_TIMESTAMP (TO_NUMBER ('201312', 'xxxxxxxxxx '))
---------------------------------------------------------------------------
07-JAN-14 08.272135.000000000 PM
-- It is the SCN number generated when the REDO entry is generated. The converted value is in decimal format and the timestamp is 08.27.05. The insert statement is completed at 20:27:00 BYS @ bys3> commit; -- This is the same as the SCN when CHANGE #4 is submitted five seconds after the insert statement is completed.
(Lwn rba: 0x000141. 00000027.0010 LEN: 0002 NST: 0001 SCN: 0x0000.00719187)
The SCN: 0x0000.00719187 in parentheses is 1 SCN less than the previous line: SCN: 0x0000.00719187.
####
CHANGE #1TYP: 2 CLS: 1 AFN: 4 DBA: 0x0108fd OBJ: 22327 SCN: 0x0000. 007164a1 SEQ: 1 OP: 11.5 ENC: 0 RBL: 0
##### AFN: 4: The operation is performed in file 4-dba_data_files.file_id; OBJ: 22327 -- The OBJECT_ID of the object to be operated. OP: 11.5-some versions are OP: 11.19 -- Update operations
KTB Redo
Op: 0x11 ver: 0x01
Compat bit: 4 (post-11) padding: 1
Op: F xid: 0x0005. 002.00000edc uba: 0x00c041cd. 02ea. 01
Block cleanout record, scn: 0x0000. 0071917c ver: 0x01 opt: 0x02, entries follow...
Itli: 1 flg: 2 scn: 0x0000. 007164a1
KDO Op code: URP row dependencies Disabled -- URP = update row piece. Sometimes it will be: KDO Op code: 21 row dependencies Disabled
Xtype: XA flags: 0x00000000 bdba: 0x00000fd hdba: 0x00000fa
Itli: 2 ispac: 0 maxfr: 4858
Tabn: 0 slot: 8 (0x8) flag: 0x2c lock: 2 ckix: 0
Ncol: 3 nnew: 1 size: 2
--
Ncol: 3 nnew: 1 indicates that the operated table has three columns and one column is operated., Size: 2
-- The length of column characters is increased by 2: database minus chedan --- According to the logs of multiple updates and DUMP, the size value here should be: the value in the current CHANGE minus the other ..
Col 1: [8] 64 61 74 61 62 61 73 65 -- set dname = 'database' -- col 1: [8], second column, 8 characters
BYS @ bys3> select dump ('database', 16), dump ('dataoracle', 16) from dual;
DUMP ('database', 16) DUMP ('dataoracle', 16)
---------------------------------------------------------------------------------
Typ = 96 Len = 8: 64, 61, Typ = 96 Len = 10: 64, 61, 6f, 63, 6c, 65
#########################
CHANGE #2TYP: 0 CLS: 25 AFN: 3 DBA: 0x00c000c0 OBJ: 4294967295 SCN: 0x0000.00719153 SEQ: 1
OP: 5.2ENC: 0 RBL: 0
Ktudh redo: slt: 0x0002 sqn: 0x00000edc flg: 0x000a siz: 164 fbi: 0
Uba: 0x00c041cd. 02ea. 01 pxid: 0x0000. 000.00000000
####################### Transaction information
TYP: 0 common block, CLS: 25 class greater than 16 is the UNDO block-increment. AFN: 3 absolute File No. dba_data_files.file_id -- is the UNDO file No.
DBA: 0x00c000c0 data block in memory address
OBJ: 4294967295 -- decimal, convert to hexadecimal format: FFFFFFFF
SCN: 0x0000.00719153 to hexadecimal can be compared with the operation
OP: 5.2-> operation code writes transaction information to the transaction table in the UNDO field header-start of the transaction
Uba: 0x00c041cd. 02ea. 01 UNDO block address
#######################
CHANGE #3TYP: 0 CLS: 1 AFN: 4 DBA: 0x0108fdobj: 22327 SCN: 0x0000.00719188 SEQ: 1OP: 11.5 ENC: 0 RBL: 0
KTB Redo -- Resolution with CHANGE #1
Op: 0x02 ver: 0x01
Compat bit: 4 (post-11) padding: 1
Op: C uba: 0x00c041cd. 02ea. 02
KDO Op code: URP row dependencies Disabled --- UNDO ROW PIECE
Xtype: XA flags: 0x00000000 bdba: 0x00000fd hdba: 0x00000fa
Itli: 2 ispac: 0 maxfr: 4858
Tabn: 0 slot: 9 (0x9) flag: 0x2c lock: 2 ckix: 0
Ncol: 3 nnew: 1 size: 6
Col 1: [10] 64 61 74 61 6f 72 61 63 6c 65 -- 2nd columns, 10 characters -- number of characters in this operation
BYS @ bys3> select dump ('database', 16), dump ('dataoracle', 16) from dual;
DUMP ('database', 16) DUMP ('dataoracle', 16)
---------------------------------------------------------------------------------
Typ = 96 Len = 8: 64, 61, Typ = 96 Len = 10: 64, 61, 6f, 63, 6c, 65
###########################
CHANGE #4TYP: 0 CLS: 25
AFN: 3DBA: 0x000c000c0 OBJ: 4294967295
SCN: 0x0000.00719188SEQ: 1
OP: 5.4ENC: 0 RBL: 0
Ktucm redo: slt: 0x0002 sqn: 0x00000edc srt: 0 sta: 9 flg: 0x2 ktucf redo: uba: 0x00c041cd. 02ea. 02 ext: 15 spc: 7890 fbi: 0
###### OP: 5.4 indicates that the operation is submitted. AFN: 3 corresponds to the UNDO file. slt: 0x0002 modifies the transaction slot of the UNDO file. uba: 0x00c041cd. 02ea. 02
CHANGE #5TYP: 1 CLS: 26 AFN: 3 DBA: 0x00c041cd OBJ: 4294967295 SCN: 0x0000. 0071917c SEQ: 1 OP: 5.1 ENC: 0 RBL: 0
Ktudb redo: siz: 164 spc: 0 flg: 0x000a seq: 0x02ea rec: 0x01
### OP: 5.1 -- put the data pre-modification value into UNDO -- AFN: 3 -- operate in the UNDO file, and the UNDO file number is 3 .. CLS: 26 -- 1 bigger than CHANGE #2, increasing in sequence haha
Xid: 0x0005. 002.00000edc
Ktubl redo: slt: 2 rci: 0 opc: 11.1 [objn: 22327 objd: 22327 tsn: 4]
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c041cc. 02ea. 04
Prev ctl max cmt scn: 0x0000. 00718dff prev tx cmt scn: 0x0000. 00718e4e
Txn start scn: 0x0000.00000000 logon user: 32 prev brb: 12599753 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
Op: 0x04 ver: 0x01
Compat bit: 4 (post-11) padding: 1
Op: L itl: xid: 0x0009. 004.00000ebc uba: 0x00c037d5. 0249.08
Flg: C --- lkc: 0 scn: 0x0000. 0070 cfea
KDO Op code: URP row dependencies Disabled ----- UNDO ROW PIECE
Xtype: XA flags: 0x00000000 bdba: 0x00000fd hdba: 0x00000fa
Itli: 2 ispac: 0 maxfr: 4858
Tabn: 0 slot: 8 (0x8) flag: 0x2c lock: 0 ckix: 0
Ncol: 3 nnew: 1 size:-2 ---- the length of the column is reduced by 2: chedan minus database --- According to the logs of multiple updates and DUMP, the size value here should be: the value in the current CHANGE minus the other
Col 1: [6] 63 68 65 64 61 6e ---- the original value is chedan, the second column, 6 Characters
BYS @ bys3> select dump ('didance', 16), dump ('test', 16) from dual;
DUMP ('mongoshake, 16) DUMP ('test', 16)
--------------------------------------------------------
Typ = 96 Len = 6: 63,68, 65,64, 61, 6e Typ = 96 Len = 4: 74,65, 73,74
CHANGE #6 TYP: 0 CLS: 26 AFN: 3 DBA: 0x00c041cd OBJ: 4294967295 SCN: 0x0000.00719188 SEQ: 1
OP: 5.1ENC: 0 RBL: 0 -- resolve the same as above
Ktudb redo: siz: 92 spc: 7984 flg: 0x0022 seq: 0x02ea rec: 0x02
Xid: 0x0005. 002.00000edc
Ktubu redo: slt: 2 rci: 1 opc: 11.1 objn: 22327 objd: 22327 tsn: 4
Undo type: Regular undo Undo type: Last buffer split: No
Tablespace Undo: No
Zero x 00000000
KDO undo record:
KTB Redo
Op: 0x02 ver: 0x01
Compat bit: 4 (post-11) padding: 1
Op: C uba: 0x00c041cd. 02ea. 01
KDO Op code: URP row dependencies Disabled ----- UNDO ROW PIECE
Xtype: XA flags: 0x00000000 bdba: 0x00000fd hdba: 0x00000fa
Itli: 2 ispac: 0 maxfr: 4858
Tabn: 0 slot: 9 (0x9) flag: 0x2c lock: 0 ckix: 0
Ncol: 3 nnew: 1 size:-6-the length of the column is reduced by 2: test minus database --- According to the logs of multiple updates and DUMP, the size value here should be: the value in the current CHANGE minus the other
Col 1: [4] 74 65 73 74 -- this operation, second column, 4 characters
BYS @ bys3> select dump ('didance', 16), dump ('test', 16) from dual;
DUMP ('mongoshake, 16) DUMP ('test', 16)
--------------------------------------------------------
Typ = 96 Len = 6: 63,68, 65,64, 61, 6e Typ = 96 Len = 4: 74,65, 73,74
######################################## ######## Verify the SMON Process
Tutorial steps: -- this experiment is incorrect. It should not be a dmup redo log, because at that time the redo log file has not been written from log buffe, you can consider using -- I have not done it yet.
| Event 10500-Trace SMON Process |
Trace the SMON Process |
Event = "10500 trace name context forever, level 1" D |
12:12:04 BYS @ bys3> select. group #,. sequence #,. archived,. status, B. type, B. member from v $ log a, v $ logfile B where. group # = B. group #;
GROUP # SEQUENCE # ARC STATUS TYPE MEMBER
----------------------------------------------------------------------------
1 334 no current online/u01/oradata/bys3/redo01.log
2 332 yes active online/u01/oradata/bys3/redo02.log
3 333 yes active online/u01/oradata/bys3/redo03.log
Elapsed: 00:00:00. 03
12:12:09 BYS @ bys3> select * from dept;
DEPTNO DNAME LOC
-------------------------------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
40 OPERATIONS BOSTON
11 database
22 dataoracle sh
Elapsed: 00:00:00. 01
12:12:24 BYS @ bys3> update dept set dname = 'mysql' where deptno = 11;
1 row updated.
Elapsed: 00:00:00. 01
12:12:29 BYS @ bys3> --- the UPDATE statement is completed at: 12: 12: 29. Only UPDATE statements are used. do not submit the UPDATE statement. Go to dump redo logfile immediately.
DUMP: event = "10500 trace name context forever, level 1"
