浅析undo表空间的管理方式

最新推荐文章于 2020-07-15 00:35:33 发布

csv84695

最新推荐文章于 2020-07-15 00:35:33 发布

阅读量373

点赞数

文章标签：运维数据库

这几天，没怎么总结一些知识。

一、什么是undo

1）还原数据

当某个进程更改了数据库中的数据时，Oracle DB 会保存旧值（还原数据）。按数据修改前的原样存储数据。如果捕获了还原数据，则可以回退未提交的数据。还原数据用于支持读取一致性和闪回查询。还原还可用于“倒回”（闪回）事务处理和表。

在读取一致性查询中，提供与查询开始时的数据一致的结果。如果要成功完成读取一致性查询，原始信息必须仍作为还原信息存在。如果原始数据不再可用，则会收到“快照太旧”错误。只要保留了还原信息，Oracle DB 就能通过重建数据来满足读取一致性查询的要求。

闪回查询有目的地查找过去某个时间存在的某个版本的数据。只要过去那个时间的还原信息仍存在，闪回查询就能成功完成。闪回事务处理使用还原功能来创建补偿事务处理，以便回退事务处理及其相关事务处理。使用闪回表功能可将表恢复到特定的时间点。

还原数据也可用于从失败的事务处理中进行恢复。如果在用户决定提交或回退事务处理之前用户会话异常结束（可能因为网络错误或客户机故障），就会导致事务处理失败。当实例崩溃或发出 SHUTDOWN ABORT 命令时，事务处理也可能会失败。

2）事务处理和还原数据

事务处理开始时就会分配还原段。在事务处理的整个过程中，更改数据时，原始（更改之前）值会被复制到还原段。通过选中 V$TRANSACTION 动态性能视图，可以查看哪些事务处理被分配到哪些还原段。

还原段是为了支持事务处理，由实例自动创建的专用段。像所有段一样，还原段由区组成，区又由数据块组成。还原段根据需要可自动增长和收缩，它充当所分配的事务处理的循环存储缓冲区。

事务处理会填充其还原段中的区，直至完成了事务处理或占用了所有空间为止。如果填充完区之后还需要更多的空间，事务处理则获取段中下一个区的空间。占用了所有区之后，事务处理会自动转回到第一个区或请求为还原段分配新区。

3）还原数据与重做数据

还原数据和重做数据初看很相似，但是二者的作用却截然不同。如果需要还原更改，则需要还原数据，而且为了保持读取一致性和执行回退，也需要还原数据。在因某种原因而丢失了更改时，如果需要再次执行更改，则需要用到重做数据。还原块更改也可以写入重做日志。

提交过程需要验证在事务处理中所做的更改是否已写入重做日志文件。这个重做日志文件会永久保存在磁盘上，而不是保存在内存中。此外，重做日志文件通常被多路复用。因此，磁盘上有重做数据的多个副本。虽然更改可能尚未写入实际存储表块的数据文件，但只要写入到持久重做日志，就足以确保数据库的一致性。

假设在已提交的更改反映到数据文件中之前刚好发生断电。因为事务处理已提交，所有这种情况不会导致问题。当系统再次启动时，就能够前滚断电时尚未反映到数据文件中的任何重做记录。

总结下来Oracle使用undo做以下作用：

回滚活动事务
恢复被终止的事务
提供读一致性
恢复逻辑损坏

二、 UNDO_MANAGEMENT
  UNDO_MANAGEMENT：这个参数确定了Undo空间的管理方式。该参数是个静态参数（不可以动态修改）。如果设置为MANUAL，则使用rollback-managed undo (RMU)管理模式；如果设置为AUTO，则使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式 ps：Oracle是强烈建议使用Automatic Undo Management(AUM)

三、 Automatic UNDO Retention
  Automatic UNDO Retention是10g的新特性，在10g和之后的版本的数据库，这个特性是默认启用的。
在Oracle Database 10g中当自动undo管理被启用，总是存在一个当前的undo retention，Oracle Database尝试至少保留旧的undo信息到该时间。数据库收集使用情况统计信息，基于这些统计信息和UNDO表空间大小来调整   undo retention的时间。
Oracle Database基于undo表空间大小和系统活动自动调整undo retention，通过设置UNDO_RETENTION初始化参数指定undo retention的最小值。

查看Oracle自动调整UNDO RETENTION的值可以通过以下查询获得：
SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TUNED_UNDORETENTION FROM V$UNDOSTAT;

针对自动扩展的UNDO表空间，系统至少保留UNDO到参数指定的时间，自动调整UNDO RETENTION以满足查询对UNDO的要求，这可能导致UNDO急剧扩张，可以考虑不设置UNDO RETENTION值。
针对固定的UNDO表空间，系统根据最大可能的undo retention进行自动调整，参考基于UNDO表空间大小和使用历史进行调整，这将忽略UNDO_RETENTION,除非表空间启用了RETENTION GUARANTEE。
  自动调整undo retention不支持LOB，因为不能在undo表空间中存储任何有关LOBs事务的UNDO信息。
  可以通过设置_undo_autotune=FALSE显示的关闭Automatic UNDO Retention功能。

四、TUNED_UNDORETENTION
  当使用的UNDO表空间非自动增长，tuned_undoretention是基于UNDO表空间大小的使用率计算出来的，在一些情况下，特别是较大的UNDO表空间时，这将计算出较大的值。
  为了解决此行为，设置以下的实例参数：
“_smu_debug_mode=33554432” ---->参见本博客文章（undo表空间使用率过高分析）

PS:设置该参数，TUNED_UNDORETENTION就不基于undo表空间大小的使用率计算，代替的是设置(MAXQUERYLEN +300)和UNDO_RETENTION的最大值。

五、UNDO表空间数据文件自动扩展
如果UNDO表空间是一个自动扩展的表空间，那么很有可能UNDO表空间状态为EXPIRED的EXTENT不会被使用（这是为了减少报ORA-01555错误的几率），这将导致UNDO表空间变得很大；如果将UNDO表空间设置为非自动扩展，那么状   态为EXPIRED的EXTENT就能被利用，这样可以一定程度控制UNDO表空间的大小，但这样会增加ORA-01555报错和UNDO空间不足报错的风险。合理的非自动扩展的UNDO表空间大小，以及合理的UNDO_RETENTION设置可以确保稳定的   UNDO空间使用。

最后，来讲下V$UNDOSTAT视图的使用，非常重要！

SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TO_CHAR(END_TIME, 'MM/DD/YYYY HH24:MI:SS') END_TIME,
UNDOTSN, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY AS "MAXCON",
MAXQUERYLEN, TUNED_UNDORETENTION
FROM v$UNDOSTAT;

以下为该视图的字段说明：

Column	Datatype	Description
`BEGIN_TIME`	`DATE`	Identifies the beginning of the time interval
`END_TIME`	`DATE`	Identifies the end of the time interval
`UNDOTSN`	`NUMBER`	Represents the last active undo tablespace in the duration of time. The tablespace ID of the active undo tablespace is returned in this column. If more than one undo tablespace was active in that period, the active undo tablespace that was active at the end of the period is reported.
`UNDOBLKS`	`NUMBER`	Represents the total number of undo blocks consumed. You can use this column to obtain the consumption rate of undo blocks, and thereby estimate the size of the undo tablespace needed to handle the workload on your system.
`TXNCOUNT`	`NUMBER`	Identifies the total number of transactions executed within the period
`MAXQUERYLEN`	`NUMBER`	Identifies the length of the longest query (in seconds) executed in the instance during the period. You can use this statistic to estimate the proper setting of the `UNDO_RETENTION`initialization parameter. The length of a query is measured from the cursor open time to the last fetch/execute time of the cursor. Only the length of those cursors that have been fetched/executed during the period are reflected in the view.
`MAXQUERYID`	`VARCHAR2(13)`	SQL identifier of the longest running SQL statement in the period
`MAXCONCURRENCY`	`NUMBER`	Identifies the highest number of transactions executed concurrently within the period
`UNXPSTEALCNT`	`NUMBER`	Number of attempts to obtain undo space by stealing unexpired extents from other transactions
`UNXPBLKRELCNT`	`NUMBER`	Number of unexpired blocks removed from certain undo segments so they can be used by other transactions
`UNXPBLKREUCNT`	`NUMBER`	Number of unexpired undo blocks reused by transactions
`EXPSTEALCNT`	`NUMBER`	Number of attempts to steal expired undo blocks from other undo segments
`EXPBLKRELCNT`	`NUMBER`	Number of expired undo blocks stolen from other undo segments
`EXPBLKREUCNT`	`NUMBER`	Number of expired undo blocks reused within the same undo segments
`SSOLDERRCNT`	`NUMBER`	Identifies the number of times the error `ORA-01555` occurred. You can use this statistic to decide whether or not the `UNDO_RETENTION`initialization parameter is set properly given the size of the undo tablespace. Increasing the value of `UNDO_RETENTION` can reduce the occurrence of this error.
`NOSPACEERRCNT`	`NUMBER`	Identifies the number of times space was requested in the undo tablespace and there was no free space available. That is, all of the space in the undo tablespace was in use by active transactions. The corrective action is to add more space to the undo tablespace.
`ACTIVEBLKS`	`NUMBER`	Total number of blocks in the active extents of the undo tablespace for the instance at the sampled time in the period
`UNEXPIREDBLKS`	`NUMBER`	Total number of blocks in the unexpired extents of the undo tablespace for the instance at the sampled time in the period
`EXPIREDBLKS`	`NUMBER`	Total number of blocks in the expired extents of the undo tablespace for the instance at the sampled time in the period
`TUNED_UNDORETENTION`	`NUMBER`	Amount of time (in seconds) for which undo will not be recycled from the time it was committed. At any point in time, the latest value of`TUNED_UNDORETENTION` is used to determine whether data committed at a particular time in the past can be recycled.

附上几个常用的UNDO表空间监控脚本：

1）查看undo中事务的extent状态
SELECT DISTINCT STATUS, SUM(BYTES), COUNT(*)
FROM DBA_UNDO_EXTENTS GROUP BY STATUS;

ACTIVE - Undo Extent is Active, 说明正在被事务所使用
EXPIRED - Undo Extent is expired，及超过undo的保留时间，可以被覆盖掉
UNEXPIRED -

2）查看事务的回滚状态
SELECT A.SID, A.USERNAME, B.XIDUSN, B.USED_UREC, B.USED_UBLK
FROM V$SESSION A, V$TRANSACTION B
WHERE A.SADDR=B.SES_ADDR;

3）查看undo表空间的空余大小
SELECT SUM(BYTES) FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='&UNDOTBS';

4）查看当前undo表空间extent的使用状况
SELECT DISTINCT STATUS, SUM(BYTES), COUNT(*)
FROM DBA_UNDO_EXTENTS GROUP BY STATUS;

5）查看当前事务的undo使用状况
SELECT XIDUSN, XIDSLOT, XIDSQN, USED_UBLK FROM V$TRANSACTION WHERE STATUS='ACTIVE' ;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30430420/viewspace-1813697/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30430420/viewspace-1813697/