学习笔记-redo构成、生成及优化

Oracle Redo

redo的构成：
1）redo header：
Redo Header 主要记录了Redo基本概要信息，例如数据库名称、控制文件序列号及日志Thread号等信息

2）redo recorder：
Redo Reord又被称为日志记录条目，记录了更加细致的数据库更改操作。Redo Record由日志记录头（Redo Record Header）、更改矢量（Change Vector）两部分组成。

Redo Record Header：
记录位于每个Redo Record头部，记录了Redo Record信息概要

REDO RECORD - Thread:1 RBA: 0x000007.00000004.0178 LEN: 0x0240 VLD: 0x01 CON_UID: 1
SCN: 0x00000000001ad861 SUBSCN: 1 02/09/2020 22:55:38

Change Vector:
Redo Record包含了一个到多个更改矢量。一个Change Vector记录了一个数据块的一次更改。

它由Change Vector header、Change Vector Body组成，其中change Vector header如下：

CHANGE #3 CON_ID:1 TYP:2 CLS:1 AFN:1 DBA:0x004000e1 OBJ:15 SCN:0x0000000000160cb9 SEQ:1 OP:11.5 ENC:0 RBL:0 FLG:0x0000
其中，
CLS为block类型，与x$bh.class保持一致。CLS为1，则表示数据块的操作
OP表示数据库操作码，用于记录数据库的操作类型。OP的特点：
数据库的任何更改操作(OP)都会被记录在redo中；
数据库更改操作(OP)包含Layer Code和Sub Code，中间使用"."分开。上面例子中的11.5表示的就是update一行数据；
Oracle包含多种类型的更改操作。

Change Vector body：

KTB Redo
op: 0x11 ver: 0x01
compat bit: 4 (post-11) padding: 1
op: F xid: 0x0000.049.0000001d uba: 0x00400217.002c.0e
Block cleanout record, scn: 0x00000000001ad861 ver: 0x01 opt: 0x02 bigscn: Y compact: Y spare: 00000000, entries follow…
itli: 1 flg: (opt=2 whr=1) scn: 0x0000000000160cb9
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x004000e1 hdba: 0x004000e0
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 1 ckix: 88
ncol: 17 nnew: 5 size: 0
col 1: [19] 5f 53 59 53 53 4d 55 31 5f 37 36 32 30 38 39 36 32 33 24
col 5: [ 5] c4 02 42 5d 25
col 7: [ 3] c2 07 54
col 8: [ 3] c2 03 22
col 10: [ 2] c1 03

3）Change Vector和ITL事务槽的关系
当事务开始时，系统在回滚段头的事务表中分配一个ITL事务槽，在Change Ventor中以OP(5.2)表明事务开始；
当事务提交后，Change Venctor中以OP(5.4)代表事务结束；

事务XID(Transaction ID)用于唯一标识事务；
UBA(Undo Block Address)记录了事务相关的Undo Record的存储位置；
ITL为XID与UBA组合，描述了事务的详细信息，即ITL=XID+UBA，其中：

XID组成结构：
USN（Undo Segment Number）：事务所在的Undo Segment ID
TX TABLE SLOT(Undo Segemnt Header Transation Table Slot):回滚段头事务表中的事务Slot号；
WRAP(Sequence Number):事务序列号

UBA组成结构：
Undo Block DBA(Data Block Address):事务相关的Undo Block物理地址；
Sequence Number:Undo Block中的序列号
Record Number:Undo Block中的记录索引号(Rec#)

我们可以从redolog的dump中看到ITL
itl: xid: 0x0000.049.0000001d uba: 0x00400217.002c.0e

Redo一般会在什么情况下产生：
1.DML事务
当数据库触发DML事务(索引行)的时候，可以在dump redo一般会有以下顺序的操作(OP为5.2表示事务开始，OP为5.4表示事务结束)：
索引行插入数据：OP(5.2)+OP(11.2)+OP(10.2)+OP(5.4)
索引行更新数据：OP(5.2)+OP(11.5)+OP(10.18)+OP(5.4)
索引行删除数据：OP(5.2)+OP(11.3)+OP(10.4)+OP(5.4)

但是有以下几点需要注意：
1）DML中的null不会影响索引；
2）更新索引键数据时候，索引也会相应更新；
3）当索引创建较多的时候，索引行DML更新可能会影响到多个索引键的DML更新，因此会产生大量的redo，从而影响数据库性能。因此，在满足性能需求的情况下，应当经可能少的创建索引；
而这也是为什么在频繁更新的表上索引创建多了，会由于维护索引而使数据库更新效率变低。

2.Block cleanout
当事务提交后，ITL标志会立即被清除。但是，当事务体提交后，如果数据块的ITL没有及时被清除，则会产生delayed block cleanout。
同时，我们需要直到Block Cleanout可以由select语句产生，所以select查询也可能产生redo。

3.Block write
DBWR进程将Block Buffer写入磁盘操作（Block Write）会被记录在redo中，而数据库恢复操作也会引发Block Write，即数据库恢复会记录大量的redo日志。

4.热备(Hot Backup)
当数据库进行热备(Hot Backup)操作时，热备信息也会记录在Redo中。

5.数据直接路径加载
当进行数据直接路径加载时，直接路径加载信息还是会记录到redo中。但是直接路径加载产生的redo更少。

6.Nologging
Nologging记录模式可以减少redo产生，但是使用nologging有以下风险：
1）该方式创建的数据库对象不可恢复；
2）数据库对象被设置为nologging模式后，必须立即备份数据库对象；
3）使用nologging特定的操作后，建议将数据库对象的日志记录模式恢复为logging模式，即
alter database[tablespace] <tablespace_name> force logging;
4)使用nologging操作创建索引时候，可以加快索引的创建速度。

Nologging使用级别：
1）对象级(database/tablespace/table等)的使用：
create/alter table[index] table_name[index_name] parallel nologging;

2)SQL语句级：
insert /+nologging append/ into table_name select * from xxxx;

可以通过set autot traceonly方式验证该方式是否可以达到redo量的减少。

Redo优化：
首先，我们需要知道Redo的产生，主要是由DML事务引起的，而DML事务相关的数据库操作主要可以分为以下几点：
1）数据块更改；
2）回滚段数据镜像更新；
3）数据库内部信息更新（数据字典表的更新）

因此，我们可以考虑下述措施
1）减少索引更新操作；
2）减少大表(键)更新操作；
3）使用direct load加载数据；
4）使用nologging进行特定操作；
5）使用临时表；
6）使用外部表；
7）批量化处理DML业务程序；
8）减少select for update显示锁定
9）减少表记录的数量规模(利用分区路由架构分区裁剪特性)，例如使用分区、分表、分库等策略；
10）减少不必要的DML操作可以减少redo产生，例如改写、整合SQL、优化逻辑