回滚段问题?谢谢

dcc123

1.如何查库里的大回滚段?

2.ORA-1628: max # extents  reached for rollback segment
达到MAXEXTENTS参数设置的极限
是否必须重建?


谢谢

zergduan

undo管理？还是手动管理？

zergduan

手动管理的话，rollback segment 有个MAXEXTENTS 存储参数，你可以  ALTER ROLLBACK SEGMENT XXX STORAGE ( MAXEXTENTS XXX)修改一下，如果是自动管理的undo，我就不知道如何办了，我曾经遇到过相同的问题在undo的情况下，我只能重建了一个undo切换过去就好了~

烟囱

如果是手动管理的话,默认的maxentents都是一个十分巨大的数,怎么会达到最大限度呢?

magic007

不需要重建，修改回滚段的maxextents即可
注意检查你的回滚段的optimal size大小。如果该参数没设置，可能会导致回滚段无限制增大，最终导致你的RBS表空间非常大。

zergduan

原帖由 magic007 于 2008-2-19 20:43 发表
不需要重建，修改回滚段的maxextents即可
注意检查你的回滚段的optimal size大小。如果该参数没设置，可能会导致回滚段无限制增大，最终导致你的RBS表空间非常大。

如果用的是undo，maxextents能改么？

mcseman

这是一个Undo管理的问题。如果你用的是10g，就比较简单（但是要想详细理解起来你会晕菜，还好设成自动管理会省去很多的烦恼。。。。）

设置成自动管理回滚段。然后考虑Undo_retention这个初始化变量的设置吧。。。。。


#========================================================

Undo_retention Oracle 9i 开始出现新的初始化参数．Oracle 9i 的 Undo 管理特性使得 Ora-1555 错误大大减少, 但是 Undo_retention 的设置仍然会个别的时候出现问题．

Oracle 10g 有自动Automatic Undo Retention Tuning 这个特性．设置的 undo_retention 参数只是一个指导值, Oracle 会自动调整 Undo (会跨过 undo_retention 设定的时间) 来保证不会出现 Ora-1555 错误. 通过查询　V$UNDOSTAT 的 tuned_undoretention 字段可以得到 Oracle 根据事务量(如果是文件不可扩展，则会考虑剩余空间)采样后的自作主张的 retenton 时间. 这样对于一个 事务量分布不均匀的数据库来说, 就会引发潜在的问题--在批处理的时候可能 Undo 会用光. 而且这个状态将一直持续, 不会释放.

10g 中, 如果数据文件的属性是 autoextensible , 则 undo_retention 参数必须设置. 如果 undo 表空间的文件属性是不可扩展的, 则　undo_retention 将不会起到什么作用(修正的办法是把该 Undo 表空间属性设置为GUARANTEE ).

通过如下命令(undotbs01 是undo 表空间名字)：

ALTER TABLESPACE undotbs01 RETENTION GUARANTEE;然后可以查询 DBA_tablespaces 的 retention 列. undo 表空间的属性和普通表空间的属性是不一样的．


千万小心这个Retenion gurantee，会弄得你莫名其妙。仔细研究吧。。。。。呵呵！


二、Automatic Undo Retention

1.base
  1) 9i引入了aum，10g进一步优化了一下，可以自动调整undo_retention参数，该参数默认900秒。当把该参数设置为0或空时，10g自动调整undo_retention参数，并以900秒为最小值。当把该参数设置为非0值时，10g同样自动调整undo_retention，但以设置值为最小值。

  2) AUM启动时，AUR功能自动启动，并且不能禁用。它主要是为了longest-running query。

2.Undo Advisor
  1) Undo Advisor是10g的一个新特性：数据库会自动分析undo的使用情况，给出undo空间大小的建议，从而支持longest-running query .
   
3.removed parameters
  1) 10g为了简化undo配置，去掉了几个参数，如下：max_rollback_segments、undo_suppress_errors、row_locking、serializable、transaction_auditing

4.rentention guarantee
  1) 10g自动调整retention主要为了long-running query，防止snap too old错误，但非常heavy的查询也保证不了，监于这种情况，10g引入了rentention guarantee机制

  2) 该机制保证指定的undo retention内一定会保持undo可用

  3) 在创建undo tablespace时，可以用 retention guarantee子句来启动该机制，或者使用alter tablespace ... retention guarantee也可以启用

  4) 同理，可以使用retention noguarantee子句来停止该机制。

  5) 使用dba_tablespaces，可以查看undo tablespace 的retention guarantee机制是否启用
  SQL> SELECT tablespace_name, contents, retention  FROM dba_tablespaces;

  TABLESPACE_NAME                CONTENTS  RETENTION
  ------------------------------ --------- -----------
  SYSTEM                         PERMANENT NOT APPLY
  UNDOTBS1                       UNDO      NOGUARANTEE
  SYSAUX                         PERMANENT NOT APPLY
  TEMP                           TEMPORARY NOT APPLY
  USERS                          PERMANENT NOT APPLY
  EXAMPLE                        PERMANENT NOT APPLY



-----------------------------------------------------------------------   



今天dblink导入数据资料的时候才发现，10g  Undo_retention=900 , 和原来的 10800 差很多。 设置的 undo_retention 参数只是一个指导值, Oracle 会自动调整 Undo (会跨过 undo_retention 设定的时间) 来保证不会出现 Ora-1555 错误.  这句话不是太理解。
自动调整undo ,是指undo_retention 时间，还是调整undo tbs ?

magic007

原帖由 zergduan 于 2008-2-19 23:26 发表

如果用的是undo，maxextents能改么？

如果用的undo，不能改。你唯一能做的就是把UNDO表空间增大。

zergduan

原帖由 magic007 于 2008-2-20 10:24 发表


如果用的undo，不能改。你唯一能做的就是把UNDO表空间增大。

扩大undo一样会报错的，这个错误不是空间不足，而是其中一个回滚段的最大extent数达到参数设置的最大值，所以不能分配下一个extent.
并不是因为空间不够无法扩展。
所以我能想到的办法只有，新建一个undo,切换过去

shiri512003

简单的方法
查查你数据库版本的
create tablespace语法
看看关于max extents 的说法，是否可以更改
by the way，
看看alter tablespace语法，有没有更改extents的项
如果没有的话
就只有重建了