我和我的团队在 Google 上(以及在 Binged 上)拼命寻找这个问题的答案,所以希望 SF 上的 Oracle 专家能够知道答案。
一周前,我们服务器所在的大楼停电了。整个服务器在数据库导出过程中瘫痪。当我们将服务器恢复在线时,我们注意到一个新进程 SMON 在数据库实例上疯狂运行。以下是 OEM 中“热门活动”的屏幕截图。
Oracle 企业管理器http://www.myviewstate.net/images/oem.png
我们让它继续运行了一段时间,但过了一天我们开始担心。检查日志后,我们注意到它似乎陷入了无限循环。以下是日志文件的一部分:
Fri Aug 14 14:43:58 2009
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
SMON: about to recover undo segment 12
SMON: mark undo segment 12 as available
以下是我迄今为止采取的步骤(其中大多数是我根据在网上找到的东西尝试的),但都没有奏效。
- 重启数据库实例
- 将用户表空间脱机,然后重新联机,然后重新启动数据库实例
- 创建了一个新的 REDO 表空间,停止数据库实例,将 spfile 指向新的表空间,然后重新启动实例
请记住,我是一名开发人员,几乎没有 Oracle 经验,更不用说 DBA 经验了。
有什么建议么?
答案1
您的数据库正在循环,因为它尝试执行恢复并将撤消段重新联机以恢复数据库。由于您不是 dba,我会立即在线联系 oracle 支持,并告诉他们您需要大量帮助,并且您不是 dba。他们很可能让您启动数据库并禁用恢复管理器,该管理器正在通过 smon 循环尝试清理撤消段。过去必须进行撤消段清理,因此最好在 oracle 支持的帮助下完成。许多步骤都需要一些事件和下划线参数来禁用/启用隐藏的 oracle mojo。我不建议您尝试自己找到的或发布的任何东西,而无需了解其含义以及如何恢复/退出您的尝试。目标是恢复您的数据库,而不是使情况变得更糟。尽快通过电话联系 oracle 支持。
答案2
Oracle 9i 及以上版本使用特殊的 UNDO 表空间和 REDO 日志来管理其事务。
REDO 存储已执行语句的日志,而 UNDO 存储受这些语句影响的数据库块的前后映像。
做了一些深入研究...如果您有权访问 Oracle Metalink(其支持站点),请查找 Bug ID 3418428 这似乎是您的问题。我无法在此处重现此信息,因为我认为它违反了 Oracles 支持协议。
问题的主要内容是,自动撤销管理会根据需要在 UNDO 表空间中动态创建 ROLLBACK 段。创建的段的数量和大小取决于数据库的负载。
在数据库崩溃之前,它已经创建并联机了超过默认数量的 ROLLBACK 段。
崩溃后,数据库尚未使崩溃前的所有 ROLLBACK 段联机。
我认为,如果有足够的时间,10g 可能能够从中恢复;9i 的问题更多。数据库是否对连接开放并有响应?
除此之外,您可能还会陷入 Oracle 恢复的迷茫之中。我建议寻求一些帮助,因为在尝试恢复时很容易完全搞砸 Oracle。
答案3
您没有提到这是 Oracle 的哪个版本...Metalink 上 10.2.0.4 版本存在此问题 (821743.1)。您的系统是否执行分布式事务?可能存在未提交的两阶段提交事务,该事务“卡住了”。查询视图 dba_2pc_pending:
从 dba_2pc_pending 中选择 local_tran_id、global_tran_id、状态;
如果那里有记录没有消失,则需要强制回滚它们。在这方面要非常小心……@Geoff 的建议很好,可能应该咨询 Oracle 支持,这就是您要付钱的原因。崩溃后的这种症状可能表明数据库中存在一些损坏。这种情况很少见,但有可能。Oracle 应该是“防损坏的”,但最好的计划和所有这一切……
答案4
解释前滚/打开/后滚这里
广义上讲,重做日志的应用将更改推回到数据库。最后,任何已应用但未提交的更改都必须回滚。它会读取 UNDO 来撤消更改。
如果遇到撤销,则意味着存在未提交的更改,需要回滚。它不会是导出(因为那应该是纯选择)。查看 v$transaction 中的 USED_UREC。应该有一行(可能更多)具有非零值,当应用撤销记录来删除未提交的更改时,该行(希望)应该会下降。