由读一致性分析undo - 数据库编程

325 txn start scn: scn: 0x0000.006658a2 logon user: 91 prev brb: 12594708 prev bcl: 0 KDO undo record: KTB Redo op: 0x03 ver: 0x01 compat bit: 4 (post-11) padding: 1 op: Z Array Update of 1 rows: tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 191 ncol: 2 nnew: 1 size: 0 KDO Op code: 21 row dependencies Disabled xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x01001bae hdba: 0x01001baa itli: 2 ispac: 0 maxfr: 4858 vect = 3 col 1: [ 1] 61 End dump data blocks tsn: 2 file#: 3 minblk 11799 maxblk 11799

所以通过undo读取了61（代表a)
我们查看数据文件3是什么文件类型：
select * from dba_data_files where file_id=3;

是undo数据文件。

SQL> show parameter undo;


NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1

默认的是undotbs1表空间，可以创建很多undo表空间，但是一个实例只用一个undo表空间。
undo表空间是有undo segments 组成，查看有多少undo段：
select * from dba_rollback_segs;

注意上面的owner列，如果是public，则该实例创建的undo段可以被数据库其他实例使用，但是sys表示的是私有undo段，只可以被该undo段创建者使用。
注意到undo段的状态了没，现在默认的undo表空间是undotbs1,所以该undo段都是在线，undo_w表空间的undo段都是离线。
我们可以通过修改参数undo_tablespace设置默认undo表空间。
oracle对于处于online的undo段进行监视,通过视图v$rollstat查看：

上面总共有11条，usn是undo段编号
一个事务使用一个undo段
下面执行一个事物：
SQL> update t set name='c' where id=1;

已更新 1 行。

select * from v$transaction;

注意XIDUSN列表示的是undo段编号，此时该事务使用的是10号undo段
查看10号undo段：
select * from v$rollstat;

XACTS列表示的是该10号undo段上具有活动的事务数量
此时修改默认undo表空间：
SQL> alter system set undo_tablespace=undo_w;

系统已更改。


SQL> show parameter undo;


NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDO_W

此时查看undo段状态：

select * from dba_rollback_segs;

undotbs1里的undo段除了10号，其他的都处于offline，因为它任被使用，事务结束后，自动变为offline
通过查看视图：
select * from v$rollstat;

发现10号undo段状态是pending offline（pending在等待…期间)
会疑问，每个回滚段段上到底可以被几个事务使用呢？

SQL> show parameter roll


NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_parallel_rollback string LOW
rollback_segments string
transactions_per_rollback_segment integer 5

可以被５个事务使用，但是这是在ｕｎｄｏ表空间没有自动管理之前，自从ｕｎｄｏ表空间自动管理后，该parameter不起作用。
一个undo段只能被一个事务使用，若undo被事务用完后，则oracle background process smon 自动创建undo段.
如果一个回滚段被多个事务使用的话，undo段头会有等待，影响并发性，我们可以通过视图V$WAITSTAT查看等待事件：
select * from v$waitstat;

可以通过执行多个事务，模拟smon自动创建undo段，自行模拟试验。（smon创建的undo段不会因为事务结束而回收）
下面看一下一个很重要的参数：undo_retention单位是秒（表示的是事务提交以后，放在undo里的数据保留的时间）

SQL> show parameter undo;


NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDO_W
SQL> show parameter roll

很有名的oracle一个错误：ORA-01555（快照太旧）
实际情况下查询发生在修改之前，比较少。
出现这个错的可能情况：
undo表空间太小
查询数据的时间过长（sql查询性能差）
undo_rentention太小
我们通过视图dba_tablespaces,引出一个参数：
SELECT TABLESPACE_NAME,RETENTION FROM DBA_TABLESPACES;

retention这列，undo表空间缺省的是NOGUARANTEE,但是我们可以修改这个参数，强制保留。
SQL> alter tablespace undotbs1 retention GUARANTEE;

表空间已更改。

一定会保留900秒。
当让可以改undo_rentention

SQL> alter system set undo_retention=1200;

系统已更改。
上面列出的出现ORA-01

由读一致性分析undo(二)