为什么回滚段在没有任务的时候，几乎被完全占用？

ada_jia

一直无法解决的问题？！

/u1/app/oracle/ora73/oradata/ora73/rbs01.dbf
/u1/app/oracle/ora73/oradata/ora73/rbs02.dbf
/u1/app/oracle/ora73/oradata/ora73/rbs03.dbf

在没有任务的时候，三个RBS的回滚文件，占用率都在97%左右。

用清理回滚段语句
alter rollback segment rb01 shrink;
alter rollback segment rb02 shrink;
alter rollback segment rb03 shrink;

后占用率变为96%，93%，92% 左右。


在oracle dba studio 里查看，例程->;未解决事务下，又很多几年前的
事务。强制回滚报ora 00600错！

请各位大虾，帮忙分析一下原因。

ada_jia

ora 00600 的 arguments 是 [18104][0][0][][][][][]

txfy

开个新回滚段，把旧的全offline,再重新online看看,或者alter rollback segment rb01 shrink to xxxm?可以吗?

ada_jia

alter rollback segment rb01 shrink to xxxm 试过 ，没用什么大用。

让回滚段占用率由99%变成93%。

rollingpig

restart your oracle ？

bigbeng

我有同样的问题，REBOOT都不行

ada_jia

我有两台机器有这种问题，其中一台用offline .online .再清空后问题就
解决了。另一台还是不行。

会不会是另一台的数据量比较大，又一直没做彻底的清理的原因呢？？

还想请问一下，造成这种现象的原因是什么？

binary

请问每一个rbs的使用情况是怎样看的？

rollingpig

查了metalink
说是

FAILED DISTRIBUTED TRANSACTIONS  

Before you begin, make note of the local transaction ID, <local_tran_id>;, from  the error message reported.

1. Determine if you can attempt a commit or rollback of this
transaction.  You can do the following select to help determine what
action to take:

SQL>; select state, tran_comment, advice from dba_2pc_pending


   where local_tran_id = '<local_tran_id>;';

  Review the TRAN_COMMENT column as this could give more information  as to the origin of the transaction or what type of transaction it was.  Review the ADVICE column as well.  Many applications prescribe advice  about whether to force commit or force rollback the distributed  transaction upon failure.  2. Commit or rollback the transaction.
To commit:

   SQL>; commit force '<local_tran_id>;';
   To rollback:

   SQL>; rollback force '<local_tran_id>;';
WARNING: Step 3 (purge_lost_db_entry) and Step 4 should ONLY be used  when the other database is lost or has been recreated.   Any other use may leave the other database in an unrecoverable or  inconsistent state.  3. If your are using release  7.3.x or greater and you need to execute  purge_lost_db_entry from the suggestions above
execute the following command in either Server Manager or SQL*Plus:
   SQL>; execute sys.dbms_transaction.purge_lost_db_entry('<local_tran_id>;');
  SQL>; COMMIT;   NOTE:  You must run above procedure as sys (since package is owned by sys),

you must have execute privileges, or have DBA privileges   4. If running a release below 7.3 but were suggested to execute  purge_lost_db_entry :
  Connect to Server Manager or SQL*Plus and execute the following
  commands:

SQL>; connect sys/<password>;

SQL>; set transaction use rollback segment system;

SQL>; delete from dba_2pc_pending where



local_tran_id = '<local_tran_id>;';

SQL>; delete from pending_sessions$ where



local_tran_id = '<local_tran_id>;';

SQL>; delete from pending_sub_sessions$ where



local_tran_id = '<local_tran_id>;';

SQL>; COMMIT;
  Solution Explanation:
=====================
The above steps work ONLY after verifying that the other database the Distributed Transaction is dependent on is no longer available.  The steps above will allow these transactions to be deleted and no longer cause RECO to keep giving you the error messages stated in the problem.

gototop

重建好了。