Oracle9i新特性:Undo Space管理
控制Undo空间的初始化参数是什么? 2
可以使用多个Undo表空间么? 4
如何在SMU或者AMU模式下监视Undo空间的使用? 6
如何减少回滚段的竞争? 10
总结 11
在Oracle 9i 之前,Oracle使用回滚段来管理Undo,即事务的读一致性是通过回滚段来保证的。在Oracle 9i 中,已经可以有两种解决方法来维护事务的读一致性,即使用自Oracle 6以来就一直使用的回滚段,或者是使用Undo Tablespace来进行的自动重做管理(system-managed undo (SMU) 或者automatically managed undo (AMU)),但是这两种方法不能同时使用。
当一个事务开始的时候会被分配一个回滚段来存储数据修改前(事务开始前)的前印象。通常,ORACLE DBA 不得不花很多时间和精力来考虑undo 空间的设计和使用:
• 在数据库中设置足够多数量的回滚段是非常重要的。太少的回滚段会导致新事物尝试写回滚段时的等待。太多的回滚段也许对于提高不了事务的并发处理却浪费了大量空间。
• 回滚段的大小要适当。如果回滚段太小,并且有长时间运行的事务或者大事务就会需要更多的空间。回滚段就会扩张到表空间中剩余的自由空间中。如果回滚段需要的(扩张的)空间比表空间中的可用空间多,这个事务就会失败。
• 回滚段的extents应该设置为合适的尺寸。理想情况下,一个事务应该正好在一个回滚段的extents中。如果一个事务比这个extents大,这个事务就会从一个extent环装延伸到同一个回滚段中的下一个extents。过多的环绕就会导致性能的降低喝内部空间的使用问题。
在Oracle 9i 以前,回滚段不得不通过DBA手工管理。关于回滚段尺寸和数量的不恰当地选择都会对系统和并发事务有重大的性能影响。在Oracle 9i 允许使用两种方法管理回滚段:
• 手工方式。这种方式就是我们通常说的rollback-managed undo (RMU)。它是通过把UNDO_MANAGEMENT 参数设置为 MANUAL。手工方式本质上和Oracle 9i 以前的回滚段管理是一样的。
• 自动管理。这种方式就是我们通常说的system-managed undo (SMU) 或者automatically managed undo (AMU)。它是通过把UNDO_MANAGEMENT 参数设置为 AUTO。使用这种方式,Oracle可以自己管理Undo 空间的使用,它自己考虑 Undo 空间的使用,Undo Blocks的竞争和维护读一致性。使用这种方式,Oracle 允许DBA 给Undo 空间分配一个单独的Undo 表空间,Undo Segments就会自动的创建在在Undo表空间中,并且这些Undo Segments的创建,删除等工作全部由Oracle来维护。
Oracle 9i允许DBA把Oracle 9i数据库配置为RMU or SMU模式,但是即便是使用SMU模式,DBA也还是要考虑UNDO 表空间的大小。此外所有的Undo Segments在Undo 表空间中具有相同的尺寸,对于混合型事务的应用,这种设置是很难的。比如说,有些应用中,有一些长时间运行的事务和改变大量数据的事务运行,同时还有其他一些小事务(生命周期很短的事务)不需要改变很多数据。
控制Undo空间的初始化参数是什么?
• UNDO_MANAGEMENT:这个参数确定了Undo空间的管理方式。该参数是个静态参数(不可以动态修改)。如果设置为MANUAL,则使用rollback-managed undo (RMU)管理模式;如果设置为AUTO,则使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式。在Oracle 9i数据库中,AUTO是缺省值。
• UNDO_TABLESPACE:只有使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式的时候才需要设置这个参数。它指定了SMU或者AMU所使用的Undo表空间(该表空间必须是已经创建的表空间)。这个设置可以通过ALTER SYSTEM命令动态改变。如果忽略设置这个参数,那么数据库中的第一个Undo表空间就会被使用,如果没有可用的Undo表空间,SYSTEM 回滚段就会被使用。
创建Undo Tablespace:
SQL> CREATE UNDO TABLESPACE UNDO_TEST
2 DATAFILE 'E:\TEST_TEST.ora' SIZE 10M
3 AUTOEXTEND ON NEXT 2M MAXSIZE 700M
4 /
表空间已创建。
SQL>
• UNDO_RETENTION:只有使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式的时候才需要设置这个参数。它指定了在重做表空间中保持重做的时间,这个设置可以通过ALTER SYSTEM命令动态改变,缺省是5分钟(300秒)。保留重做主要有两个目的,一个是为冗长查询保留非活动的(inactive)的正在被使用的数据,另一个是支持显示当前数据前一种状态的查询,即Oracle 9i中“Flashback Query”新特性。例如,如果设置UNDO_RETENTION = 300(缺省值),那么Oracle将进最大可能将重做保留5分钟,即短语5分钟的查询不会报ORA-01555错误。
• UNDO_SUPPRESS_ERROR:当使用SMU管理模式时,你不能运行RMU管理模式的管理命令,比如说把一个回滚段联机或者脱机等等。这个参数决定了当使用SMU管理模式时,如果发出RMU管理模式的管理命令是否产生错误信息。这个设置可以通过ALTER SYSTEM命令动态改变,缺省值是FALSE,即不禁止错误信息。例如:
C:\>sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.1.0 - Production on 星期日 6月 29 10:10:04 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 93395628 bytes
Fixed Size 453292 bytes
Variable Size 67108864 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL> show parameter UNDO_SUPPRESS_ERRORS
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_suppress_errors boolean FALSE
SQL> show parameter UNDO_MANAGEMENT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
SQL> show parameter UNDO_TABLESPACE
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace string UNDOTBS1
SQL> ALTER ROLLBACK SEGMENT SYSTEM OFFLINE;
ALTER ROLLBACK SEGMENT SYSTEM OFFLINE
*
ERROR 位于第 1 行:
ORA-30019: 自动撤消模式中的回退段操作非法
SQL> ALTER SYSTEM SET UNDO_SUPPRESS_ERRORS=TRUE;
系统已更改。
SQL> SHOW PARAMETER UNDO_SUPPRESS_ERRORS
NAME TYPE VALUE
------------------------------------ ----------- ----------
undo_suppress_errors boolean TRUE
SQL> ALTER ROLLBACK SEGMENT SYSTEM OFFLINE;
回退段已变更。
SQL>
可以使用多个Undo表空间么?
Undo表空间只在SMU或者AMU模式有用,即UNDO_MANAGEMENT = AUTO。在Oracle 9i中你可以使用CREATE UNDO TABLESPACE命令创建多个Undo表空间,然而在数据正常运行的时候只有一个Undo表空间是当前被使用的Undo表空间,这个参数就确定了哪个Undo表空间是当前活动的Undo Tablespace:
C:\>sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.1.0 - Production on 星期日 6月 29 10:10:04 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 93395628 bytes
Fixed Size 453292 bytes
Variable Size 67108864 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL> show parameter UNDO_MANAGEMENT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
SQL> show parameter UNDO_TABLESPACE
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace string UNDOTBS1
SQL> select TABLESPACE_NAME,STATUS
2 from dba_tablespaces
3 where TABLESPACE_NAME like 'UNDO%';
TABLESPACE_NAME STATUS
------------------------------ ---------
UNDOTBS1 ONLINE
UNDOTBS2 ONLINE
SQL> alter system set UNDO_TABLESPACE=UNDOTBS2;
系统已更改。
SQL> show parameter UNDO_TABLESPACE
NAME TYPE VALUE
------------------------------------ ----------- --------------
undo_tablespace string UNDOTBS2
SQL>
如何在SMU或者AMU模式下监视Undo空间的使用?
• 在Oracle 9i 中,V$UNDOSTAT视图可以被用来确定Undo空间的使用情况。下面的查询用来确定事务在Undo空间中执行的时间:
例如:
select TO_CHAR(MIN(Begin_Time),'DD-MON-YYYY HH24:MI:SS')
"Begin Time",
TO_CHAR(MAX(End_Time),'DD-MON-YYYY HH24:MI:SS')
"End Time",
SUM(Undoblks) "Total Undo Blocks Used",
SUM(Txncount) "Total Num Trans Executed",
MAX(Maxquerylen) "Longest Query(in secs)",
MAX(Maxconcurrency) "Highest Concurrent Transaction Count",
SUM(Ssolderrcnt),
SUM(Nospaceerrcnt)
from V$UNDOSTAT;
SQL> select TO_CHAR(MIN(Begin_Time),'DD-MON-YYYY HH24:MI:SS')
2 "Begin Time",
3 TO_CHAR(MAX(End_Time),'DD-MON-YYYY HH24:MI:SS')
4 "End Time",
5 SUM(Undoblks) "Total Undo Blocks Used",
6 SUM(Txncount) "Total Num Trans Executed",
7 MAX(Maxquerylen) "Longest Query(in secs)",
8 MAX(Maxconcurrency) "Highest Concurrent Transaction",
9 SUM(Ssolderrcnt),
10 SUM(Nospaceerrcnt)
11 from V$UNDOSTAT;
Begin Time End Time Total Undo Blocks Used Total Num Trans Executed Longest Query(in secs) Highest Concurrent Transaction SUM(SSOLDERRCNT) SUM(NOSPACEERRCNT)
--------------------- --------------------- ---------------------- ------------------------ ---------------------- ------------------------------ ---------------- ------------------
29-6月 -2003 10:18:05 29-6月 -2003 12:47:26 13 160 4 1 0 0
SQL>
• V$WAITSTAT视图可以被用来确定每个回滚段数据块的等待情况:
SELECT class, count
FROM V$WAITSTAT
WHERE class LIKE '%undo%'
AND COUNT > 0;
SQL> SELECT class, count
2 FROM V$WAITSTAT
3 WHERE class LIKE '%undo%'
4 AND COUNT > 0;
CLASS COUNT
------------------ ----------
SQL>
• V$SYSSTAT视图可以确定总的数据请求的数量:
SELECT SUM(value) "DATA REQUESTS"
FROM V$SYSSTAT
WHERE name IN ('db block gets', 'consistent gets');
SQL> SELECT SUM(value) "DATA REQUESTS"
2 FROM V$SYSSTAT
3 WHERE name IN ('db block gets', 'consistent gets');
DATA REQUESTS
-------------
110019
SQL>
• DBA_ROLLBACK_SEGS视图可以确定回滚段的存储信息和状态等等信息:
SELECT segment_name, owner, tablespace_name, status,
initial_extent, next_extent,
min_extents, max_extents, pct_increase
FROM DBA_ROLLBACK_SEGS;
SQL> SELECT segment_name, owner, tablespace_name, status,
2 initial_extent, next_extent,
3 min_extents, max_extents, pct_increase
4 FROM DBA_ROLLBACK_SEGS;
SEGMENT_NAME OWNER TABLESPACE_NAME STATUS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
------------------------------ ------ ------------------------------ ---------------- -------------- ----------- ----------- ----------- ------------
SYSTEM SYS SYSTEM ONLINE 114688 1 32765
_SYSSMU1$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU2$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU3$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU4$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU5$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU6$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU7$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU8$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU9$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU10$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU11$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU12$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU13$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU14$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU15$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU16$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU17$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU18$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU19$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
SEGMENT_NAME OWNER TABLESPACE_NAME STATUS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
------------------------------ ------ ------------------------------ ---------------- -------------- ----------- ----------- ----------- ------------
_SYSSMU20$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
21 rows selected
SQL>
• V$TRANSACTION视图可以确定每个事务使用Undo空间的数量:
SELECT MAX(used_ublk)
FROM V$TRANSACTION;
如何减少回滚段的竞争?
通常运行在RMU模式下的数据库会给DBA带来更多关于回滚段竞争的问题,为了减少回滚段的竞争,通常考虑下面的策略:
• 增加回滚段的数量
• 把储参数NEXT和INITIAL设置为同样的值
• 把储参数MIN_EXTENTS设置为至少20的值
• 把储参数OPTIMAL设置为INITIAL x MIN_EXTENTS
• 再会滚段表空间中确保有很多可用空间
当数据库运行在SMU或者AMU模式下时,Undo segment的竞争由Oracle来管理。然而,这并不意味着DBA可以完全不用计划Undo空间的使用了,因为:
• 在同一时间,只有一个活动的Undo表空间
• 在一个Undo Tablespace中所有的Undo Segment具有相同的尺寸
• 这个Undo Segment的尺寸也许并不适合每个事务
• 当Undo Tablespace Online/Offline时,该Undo空间中的所有Undo Segment就是Online/Offline的
• Oracle 管理着Undo Segments ,并且它们始终占据着空间(不释放)
• 虽然Oracle管理 Undo Segments的竞争,但是也仍然存在一些问题,比如说使用extends时的收缩和循环问题。如果Undo Segments的尺寸不合适的话,这些问题仍然会导致性能问题。
• Sessions参数的设置影响了创建Undo Segments的数量和尺寸
使用SMU或者AMU时,为了提高性能和避免(减少)Undo Segments相关的问题,Oracle DBA可以考虑:
• 确定Undo空间的使用,事务的混合性程度,数据库实例加载的次数,并且给SESSIONS参数设置为一个合适的值
• 创建多个不同尺寸的Undo Tablespace来迎合不同类型的事务:
UndoSpace = UR * UPS + overhead
其中:
? UndoSpace 是undo blocks的块数;
? UR 是 UNDO_RETENTION的值,即秒数
? UPS 是每秒钟处理的undo blocks(事务率,transaction rate),你可以在事务稳定时通过查询V$UNDOSTAT视图得到事务率的值。
? overhead是一些小的的媒体数据,如 transaction tables,bitmaps等等。Overhead的的值也可以通过查询V$UNDOSTAT视图得到。
举个例子,假设UNDO_RETENTION 设置为2小时(7200秒),事务率(UPS)是每秒钟200个UNDO blocks,数据块大小为4KB,那么需要的空间是: (7200* 200 * 4K)= 5.8GB。
• 根据需要,动态改变UNDO_TABLESPACE参数,以便使用最合适的Undo空间来处理事务
• 监视V$UNDOSTAT视图,以便知道Oracle是如何管理Undo空间的使用的;当性能问题发生时,考虑是否需要调整合适的Undo Tablespace,或者重新创建一个更合适尺寸的Undo Tablespace。
总结
将Oracle 9i数据库运行在RMU还是SMU模式下,Oracle DBA最终丢要考虑数据库的性能影响;这两种模式的都可能会因为不恰当地设计导致性能问题。
控制Undo空间的初始化参数是什么? 2
可以使用多个Undo表空间么? 4
如何在SMU或者AMU模式下监视Undo空间的使用? 6
如何减少回滚段的竞争? 10
总结 11
在Oracle 9i 之前,Oracle使用回滚段来管理Undo,即事务的读一致性是通过回滚段来保证的。在Oracle 9i 中,已经可以有两种解决方法来维护事务的读一致性,即使用自Oracle 6以来就一直使用的回滚段,或者是使用Undo Tablespace来进行的自动重做管理(system-managed undo (SMU) 或者automatically managed undo (AMU)),但是这两种方法不能同时使用。
当一个事务开始的时候会被分配一个回滚段来存储数据修改前(事务开始前)的前印象。通常,ORACLE DBA 不得不花很多时间和精力来考虑undo 空间的设计和使用:
• 在数据库中设置足够多数量的回滚段是非常重要的。太少的回滚段会导致新事物尝试写回滚段时的等待。太多的回滚段也许对于提高不了事务的并发处理却浪费了大量空间。
• 回滚段的大小要适当。如果回滚段太小,并且有长时间运行的事务或者大事务就会需要更多的空间。回滚段就会扩张到表空间中剩余的自由空间中。如果回滚段需要的(扩张的)空间比表空间中的可用空间多,这个事务就会失败。
• 回滚段的extents应该设置为合适的尺寸。理想情况下,一个事务应该正好在一个回滚段的extents中。如果一个事务比这个extents大,这个事务就会从一个extent环装延伸到同一个回滚段中的下一个extents。过多的环绕就会导致性能的降低喝内部空间的使用问题。
在Oracle 9i 以前,回滚段不得不通过DBA手工管理。关于回滚段尺寸和数量的不恰当地选择都会对系统和并发事务有重大的性能影响。在Oracle 9i 允许使用两种方法管理回滚段:
• 手工方式。这种方式就是我们通常说的rollback-managed undo (RMU)。它是通过把UNDO_MANAGEMENT 参数设置为 MANUAL。手工方式本质上和Oracle 9i 以前的回滚段管理是一样的。
• 自动管理。这种方式就是我们通常说的system-managed undo (SMU) 或者automatically managed undo (AMU)。它是通过把UNDO_MANAGEMENT 参数设置为 AUTO。使用这种方式,Oracle可以自己管理Undo 空间的使用,它自己考虑 Undo 空间的使用,Undo Blocks的竞争和维护读一致性。使用这种方式,Oracle 允许DBA 给Undo 空间分配一个单独的Undo 表空间,Undo Segments就会自动的创建在在Undo表空间中,并且这些Undo Segments的创建,删除等工作全部由Oracle来维护。
Oracle 9i允许DBA把Oracle 9i数据库配置为RMU or SMU模式,但是即便是使用SMU模式,DBA也还是要考虑UNDO 表空间的大小。此外所有的Undo Segments在Undo 表空间中具有相同的尺寸,对于混合型事务的应用,这种设置是很难的。比如说,有些应用中,有一些长时间运行的事务和改变大量数据的事务运行,同时还有其他一些小事务(生命周期很短的事务)不需要改变很多数据。
控制Undo空间的初始化参数是什么?
• UNDO_MANAGEMENT:这个参数确定了Undo空间的管理方式。该参数是个静态参数(不可以动态修改)。如果设置为MANUAL,则使用rollback-managed undo (RMU)管理模式;如果设置为AUTO,则使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式。在Oracle 9i数据库中,AUTO是缺省值。
• UNDO_TABLESPACE:只有使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式的时候才需要设置这个参数。它指定了SMU或者AMU所使用的Undo表空间(该表空间必须是已经创建的表空间)。这个设置可以通过ALTER SYSTEM命令动态改变。如果忽略设置这个参数,那么数据库中的第一个Undo表空间就会被使用,如果没有可用的Undo表空间,SYSTEM 回滚段就会被使用。
创建Undo Tablespace:
SQL> CREATE UNDO TABLESPACE UNDO_TEST
2 DATAFILE 'E:\TEST_TEST.ora' SIZE 10M
3 AUTOEXTEND ON NEXT 2M MAXSIZE 700M
4 /
表空间已创建。
SQL>
• UNDO_RETENTION:只有使用system-managed undo (SMU) 或者automatically managed undo (AMU)管理模式的时候才需要设置这个参数。它指定了在重做表空间中保持重做的时间,这个设置可以通过ALTER SYSTEM命令动态改变,缺省是5分钟(300秒)。保留重做主要有两个目的,一个是为冗长查询保留非活动的(inactive)的正在被使用的数据,另一个是支持显示当前数据前一种状态的查询,即Oracle 9i中“Flashback Query”新特性。例如,如果设置UNDO_RETENTION = 300(缺省值),那么Oracle将进最大可能将重做保留5分钟,即短语5分钟的查询不会报ORA-01555错误。
• UNDO_SUPPRESS_ERROR:当使用SMU管理模式时,你不能运行RMU管理模式的管理命令,比如说把一个回滚段联机或者脱机等等。这个参数决定了当使用SMU管理模式时,如果发出RMU管理模式的管理命令是否产生错误信息。这个设置可以通过ALTER SYSTEM命令动态改变,缺省值是FALSE,即不禁止错误信息。例如:
C:\>sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.1.0 - Production on 星期日 6月 29 10:10:04 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 93395628 bytes
Fixed Size 453292 bytes
Variable Size 67108864 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL> show parameter UNDO_SUPPRESS_ERRORS
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_suppress_errors boolean FALSE
SQL> show parameter UNDO_MANAGEMENT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
SQL> show parameter UNDO_TABLESPACE
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace string UNDOTBS1
SQL> ALTER ROLLBACK SEGMENT SYSTEM OFFLINE;
ALTER ROLLBACK SEGMENT SYSTEM OFFLINE
*
ERROR 位于第 1 行:
ORA-30019: 自动撤消模式中的回退段操作非法
SQL> ALTER SYSTEM SET UNDO_SUPPRESS_ERRORS=TRUE;
系统已更改。
SQL> SHOW PARAMETER UNDO_SUPPRESS_ERRORS
NAME TYPE VALUE
------------------------------------ ----------- ----------
undo_suppress_errors boolean TRUE
SQL> ALTER ROLLBACK SEGMENT SYSTEM OFFLINE;
回退段已变更。
SQL>
可以使用多个Undo表空间么?
Undo表空间只在SMU或者AMU模式有用,即UNDO_MANAGEMENT = AUTO。在Oracle 9i中你可以使用CREATE UNDO TABLESPACE命令创建多个Undo表空间,然而在数据正常运行的时候只有一个Undo表空间是当前被使用的Undo表空间,这个参数就确定了哪个Undo表空间是当前活动的Undo Tablespace:
C:\>sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.1.0 - Production on 星期日 6月 29 10:10:04 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 93395628 bytes
Fixed Size 453292 bytes
Variable Size 67108864 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL> show parameter UNDO_MANAGEMENT
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
SQL> show parameter UNDO_TABLESPACE
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace string UNDOTBS1
SQL> select TABLESPACE_NAME,STATUS
2 from dba_tablespaces
3 where TABLESPACE_NAME like 'UNDO%';
TABLESPACE_NAME STATUS
------------------------------ ---------
UNDOTBS1 ONLINE
UNDOTBS2 ONLINE
SQL> alter system set UNDO_TABLESPACE=UNDOTBS2;
系统已更改。
SQL> show parameter UNDO_TABLESPACE
NAME TYPE VALUE
------------------------------------ ----------- --------------
undo_tablespace string UNDOTBS2
SQL>
如何在SMU或者AMU模式下监视Undo空间的使用?
• 在Oracle 9i 中,V$UNDOSTAT视图可以被用来确定Undo空间的使用情况。下面的查询用来确定事务在Undo空间中执行的时间:
例如:
select TO_CHAR(MIN(Begin_Time),'DD-MON-YYYY HH24:MI:SS')
"Begin Time",
TO_CHAR(MAX(End_Time),'DD-MON-YYYY HH24:MI:SS')
"End Time",
SUM(Undoblks) "Total Undo Blocks Used",
SUM(Txncount) "Total Num Trans Executed",
MAX(Maxquerylen) "Longest Query(in secs)",
MAX(Maxconcurrency) "Highest Concurrent Transaction Count",
SUM(Ssolderrcnt),
SUM(Nospaceerrcnt)
from V$UNDOSTAT;
SQL> select TO_CHAR(MIN(Begin_Time),'DD-MON-YYYY HH24:MI:SS')
2 "Begin Time",
3 TO_CHAR(MAX(End_Time),'DD-MON-YYYY HH24:MI:SS')
4 "End Time",
5 SUM(Undoblks) "Total Undo Blocks Used",
6 SUM(Txncount) "Total Num Trans Executed",
7 MAX(Maxquerylen) "Longest Query(in secs)",
8 MAX(Maxconcurrency) "Highest Concurrent Transaction",
9 SUM(Ssolderrcnt),
10 SUM(Nospaceerrcnt)
11 from V$UNDOSTAT;
Begin Time End Time Total Undo Blocks Used Total Num Trans Executed Longest Query(in secs) Highest Concurrent Transaction SUM(SSOLDERRCNT) SUM(NOSPACEERRCNT)
--------------------- --------------------- ---------------------- ------------------------ ---------------------- ------------------------------ ---------------- ------------------
29-6月 -2003 10:18:05 29-6月 -2003 12:47:26 13 160 4 1 0 0
SQL>
• V$WAITSTAT视图可以被用来确定每个回滚段数据块的等待情况:
SELECT class, count
FROM V$WAITSTAT
WHERE class LIKE '%undo%'
AND COUNT > 0;
SQL> SELECT class, count
2 FROM V$WAITSTAT
3 WHERE class LIKE '%undo%'
4 AND COUNT > 0;
CLASS COUNT
------------------ ----------
SQL>
• V$SYSSTAT视图可以确定总的数据请求的数量:
SELECT SUM(value) "DATA REQUESTS"
FROM V$SYSSTAT
WHERE name IN ('db block gets', 'consistent gets');
SQL> SELECT SUM(value) "DATA REQUESTS"
2 FROM V$SYSSTAT
3 WHERE name IN ('db block gets', 'consistent gets');
DATA REQUESTS
-------------
110019
SQL>
• DBA_ROLLBACK_SEGS视图可以确定回滚段的存储信息和状态等等信息:
SELECT segment_name, owner, tablespace_name, status,
initial_extent, next_extent,
min_extents, max_extents, pct_increase
FROM DBA_ROLLBACK_SEGS;
SQL> SELECT segment_name, owner, tablespace_name, status,
2 initial_extent, next_extent,
3 min_extents, max_extents, pct_increase
4 FROM DBA_ROLLBACK_SEGS;
SEGMENT_NAME OWNER TABLESPACE_NAME STATUS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
------------------------------ ------ ------------------------------ ---------------- -------------- ----------- ----------- ----------- ------------
SYSTEM SYS SYSTEM ONLINE 114688 1 32765
_SYSSMU1$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU2$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU3$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU4$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU5$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU6$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU7$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU8$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU9$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU10$ PUBLIC UNDOTBS1 OFFLINE 131072 2 32765
_SYSSMU11$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU12$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU13$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU14$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU15$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU16$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU17$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU18$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
_SYSSMU19$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
SEGMENT_NAME OWNER TABLESPACE_NAME STATUS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE
------------------------------ ------ ------------------------------ ---------------- -------------- ----------- ----------- ----------- ------------
_SYSSMU20$ PUBLIC UNDOTBS2 ONLINE 131072 2 32765
21 rows selected
SQL>
• V$TRANSACTION视图可以确定每个事务使用Undo空间的数量:
SELECT MAX(used_ublk)
FROM V$TRANSACTION;
如何减少回滚段的竞争?
通常运行在RMU模式下的数据库会给DBA带来更多关于回滚段竞争的问题,为了减少回滚段的竞争,通常考虑下面的策略:
• 增加回滚段的数量
• 把储参数NEXT和INITIAL设置为同样的值
• 把储参数MIN_EXTENTS设置为至少20的值
• 把储参数OPTIMAL设置为INITIAL x MIN_EXTENTS
• 再会滚段表空间中确保有很多可用空间
当数据库运行在SMU或者AMU模式下时,Undo segment的竞争由Oracle来管理。然而,这并不意味着DBA可以完全不用计划Undo空间的使用了,因为:
• 在同一时间,只有一个活动的Undo表空间
• 在一个Undo Tablespace中所有的Undo Segment具有相同的尺寸
• 这个Undo Segment的尺寸也许并不适合每个事务
• 当Undo Tablespace Online/Offline时,该Undo空间中的所有Undo Segment就是Online/Offline的
• Oracle 管理着Undo Segments ,并且它们始终占据着空间(不释放)
• 虽然Oracle管理 Undo Segments的竞争,但是也仍然存在一些问题,比如说使用extends时的收缩和循环问题。如果Undo Segments的尺寸不合适的话,这些问题仍然会导致性能问题。
• Sessions参数的设置影响了创建Undo Segments的数量和尺寸
使用SMU或者AMU时,为了提高性能和避免(减少)Undo Segments相关的问题,Oracle DBA可以考虑:
• 确定Undo空间的使用,事务的混合性程度,数据库实例加载的次数,并且给SESSIONS参数设置为一个合适的值
• 创建多个不同尺寸的Undo Tablespace来迎合不同类型的事务:
UndoSpace = UR * UPS + overhead
其中:
? UndoSpace 是undo blocks的块数;
? UR 是 UNDO_RETENTION的值,即秒数
? UPS 是每秒钟处理的undo blocks(事务率,transaction rate),你可以在事务稳定时通过查询V$UNDOSTAT视图得到事务率的值。
? overhead是一些小的的媒体数据,如 transaction tables,bitmaps等等。Overhead的的值也可以通过查询V$UNDOSTAT视图得到。
举个例子,假设UNDO_RETENTION 设置为2小时(7200秒),事务率(UPS)是每秒钟200个UNDO blocks,数据块大小为4KB,那么需要的空间是: (7200* 200 * 4K)= 5.8GB。
• 根据需要,动态改变UNDO_TABLESPACE参数,以便使用最合适的Undo空间来处理事务
• 监视V$UNDOSTAT视图,以便知道Oracle是如何管理Undo空间的使用的;当性能问题发生时,考虑是否需要调整合适的Undo Tablespace,或者重新创建一个更合适尺寸的Undo Tablespace。
总结
将Oracle 9i数据库运行在RMU还是SMU模式下,Oracle DBA最终丢要考虑数据库的性能影响;这两种模式的都可能会因为不恰当地设计导致性能问题。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/20709695/viewspace-707963/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/20709695/viewspace-707963/