资料来源 ：
http://warehouse.itpub.net/post/777/482693
有几个问题
1. 从资料中可以看出，如果sessions 参数值大于等于46， 那么所有的undo segments 都被online , 而每5个session 大约对应一个undo segment .
那么当undo tablespace 被建立，然后在数据库刚刚开启的时候，假设sesssions=200, 整个undo tablespace 会被分成约 40 个undo segments ?
都是online 的 ？
2. undo segment 什么情况下offline ? undo segments 中包内含的所有事务被提交或回滚之后 ？
3. 当我们使用AUM，并设置了undo_retention以后， undo块就存在四种状态。
Active：表示正在使用该undo的事务还没有提交或回滚。
Inactive：表示该undo上没有活动的事务，该状态的undo可以被其他事务覆盖。
Expired：表示该undo持续inactive的时间超过undo_retention所指定的时间。
Freed：表示该undo块内容是空的，从来没有被使用过。
当活动的事务使用undo segment时，在AUM下，事务可以在不同的undo segment之间动态交换undo空间(也就是extents),当一个执行的事务需要更多的undo空间
时，首先会重用当前undo segment里的可用空间，如果不足，则按照下面步骤获取所需要的extent :
a. 获取undo表空间中可用的，空的extents;
b. 获取其他undo segment里的expired状态的extents;
c. 如果undo数据文件启用了自动扩展，则文件自动扩展；
d. 如果undo文件都没有启用自动扩展，则获取其他undo segment中inactive的；
e. 如果以上步骤均无法获得可用空间时，报空间不足的错误消息.
expired 不是指undo block吗 ？ expired 状态的extents 是所有block都是超过undo_retention 的extents ?
When the undo tablespace is created, a number of undo segments are created. These are named using the _SYSSMU$ algorithm. Because of the new name, some commands (alter system dump undo header) require that the undo segment name be enclosed in double quotes.
The number of undo segments created and brought online is a function of the SESSIONS parameter. The algorithm is roughly 1 undo segment for each 5 sessions. All undo segments are placed online when the sessions parameter is set to 46 or greater. The lower limit was not tested, as the minimum value for the
sessions parameter in the test database was 16, which was derived from the minimum number of processes (10) for the database. These are sized according
to the autoallocate algorithm for locally managed tablespaces. The basic algorithm is that the first 16 extents are 64k in size. The subsequent allocation method is the next 63 extents of 1m, the next 120 extents of 8m and all additional extents at 64m.
The first block of the first undo extent is reserved as the header and not indicated in the data dictionary views. As with Oracle 8, the second block of the undo segment is not used initially and may or may not be allocated at a later time. This is one of those anomalies that has no consistent pattern
and is therefore hard to explain.
当undo表空间被创建时，很多的undo segments被创建，这些segments以_SYSSMU$规则来命名。 因为新的名称，一些命令比如alert system dump undo header 需要在
undo segment的名称上加注双引号。
Undo segment创建和在线数量是由参数SESSIONS决定的，粗略算法为每5个session对应一个undo segment, 当sessions参数设置为46或更大时所有的undo segments都处于
online状态。 下限没有被测试过，因为在测试数据库中sessions参数最小值是16，这个值来自于数据库中参数processes的最小值10，这些大小是参考本地管理表空间(LMT)自动分配算法而来。 基本算法是： 前16个extents大小为64K, 随后63个extents是每个1M, 然后120个extents是每个8M, 再后面的extents大小都是64M不变。
第一个undo extent的第一个block保留作为头部，没有在数据字典中标示出来，与Oracle8 一样，undo segment的第二个block最初没有被使用，后面一段时间也许被分配，也许
不会，这是异常现象之一，没有统一的模式，因此很难解释。
http://warehouse.itpub.net/post/777/482693
有几个问题
1. 从资料中可以看出，如果sessions 参数值大于等于46， 那么所有的undo segments 都被online , 而每5个session 大约对应一个undo segment .
那么当undo tablespace 被建立，然后在数据库刚刚开启的时候，假设sesssions=200, 整个undo tablespace 会被分成约 40 个undo segments ?
都是online 的 ？
2. undo segment 什么情况下offline ? undo segments 中包内含的所有事务被提交或回滚之后 ？
3. 当我们使用AUM，并设置了undo_retention以后， undo块就存在四种状态。
Active：表示正在使用该undo的事务还没有提交或回滚。
Inactive：表示该undo上没有活动的事务，该状态的undo可以被其他事务覆盖。
Expired：表示该undo持续inactive的时间超过undo_retention所指定的时间。
Freed：表示该undo块内容是空的，从来没有被使用过。
当活动的事务使用undo segment时，在AUM下，事务可以在不同的undo segment之间动态交换undo空间(也就是extents),当一个执行的事务需要更多的undo空间
时，首先会重用当前undo segment里的可用空间，如果不足，则按照下面步骤获取所需要的extent :
a. 获取undo表空间中可用的，空的extents;
b. 获取其他undo segment里的expired状态的extents;
c. 如果undo数据文件启用了自动扩展，则文件自动扩展；
d. 如果undo文件都没有启用自动扩展，则获取其他undo segment中inactive的；
e. 如果以上步骤均无法获得可用空间时，报空间不足的错误消息.
expired 不是指undo block吗 ？ expired 状态的extents 是所有block都是超过undo_retention 的extents ?
When the undo tablespace is created, a number of undo segments are created. These are named using the _SYSSMU$ algorithm. Because of the new name, some commands (alter system dump undo header) require that the undo segment name be enclosed in double quotes.
The number of undo segments created and brought online is a function of the SESSIONS parameter. The algorithm is roughly 1 undo segment for each 5 sessions. All undo segments are placed online when the sessions parameter is set to 46 or greater. The lower limit was not tested, as the minimum value for the
sessions parameter in the test database was 16, which was derived from the minimum number of processes (10) for the database. These are sized according
to the autoallocate algorithm for locally managed tablespaces. The basic algorithm is that the first 16 extents are 64k in size. The subsequent allocation method is the next 63 extents of 1m, the next 120 extents of 8m and all additional extents at 64m.
The first block of the first undo extent is reserved as the header and not indicated in the data dictionary views. As with Oracle 8, the second block of the undo segment is not used initially and may or may not be allocated at a later time. This is one of those anomalies that has no consistent pattern
and is therefore hard to explain.
当undo表空间被创建时，很多的undo segments被创建，这些segments以_SYSSMU$规则来命名。 因为新的名称，一些命令比如alert system dump undo header 需要在
undo segment的名称上加注双引号。
Undo segment创建和在线数量是由参数SESSIONS决定的，粗略算法为每5个session对应一个undo segment, 当sessions参数设置为46或更大时所有的undo segments都处于
online状态。 下限没有被测试过，因为在测试数据库中sessions参数最小值是16，这个值来自于数据库中参数processes的最小值10，这些大小是参考本地管理表空间(LMT)自动分配算法而来。 基本算法是： 前16个extents大小为64K, 随后63个extents是每个1M, 然后120个extents是每个8M, 再后面的extents大小都是64M不变。
第一个undo extent的第一个block保留作为头部，没有在数据字典中标示出来，与Oracle8 一样，undo segment的第二个block最初没有被使用，后面一段时间也许被分配，也许
不会，这是异常现象之一，没有统一的模式，因此很难解释。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-697020/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/35489/viewspace-697020/
200
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
