当前位置: 首页 >> 技术文章 >> 实战课堂:为什么更换存储之后一切正常但RAC集群启动不了?(下)
实战课堂:为什么更换存储之后一切正常但RAC集群启动不了?(下)
发布时间:2018-06-14 发布人:数据和云 40

数据库中有一个隐藏参数 _controlfile_enqueue_timeout 默认为900s,该参数的意思是在数据库的 Open 阶段,锁定控制文件读取相关的数据文件并打开的允许超时时间,如果超过了900s阈值则认为数据库超时,会抛出异常,中断操作。


在此之前,我们估算了打开所有数据文件需要至少1092秒,这里在参数文件将该参数修改为9000s后,重新执行启动流程,最终成功打开了数据库的第二节点。

Fri Dec 16 12:52:22 2016

ALTER SYSTEM SET _controlfile_enqueue_timeout=9000 SCOPE=SPFILE;

Fri Dec 16 12:52:22 2016

Shutting down instance (abort)

License high water mark = 5

USER (ospid: 18936): terminating the instance

Instance terminated by USER, pid = 18936

Fri Dec 16 12:52:30 2016

Instance shutdown complete

Fri Dec 16 12:52:34 2016

Starting ORACLE instance (normal)

Fri Dec 16 12:52:47 2016

Fri Dec 16 12:56:39 2016

Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE)

Lost write protection disabled

Completed: ALTER DATABASE   MOUNT

Fri Dec 16 12:57:19 2016

alter database open

Fri Dec 16 13:15:42 2016

GTX0 started with pid=92, OS id=26326 

replication_dependency_tracking turned off (no async multimaster replication found)

Starting background process QMNC

Fri Dec 16 13:15:43 2016

QMNC started with pid=93, OS id=26332 

Completed: alter database open

从日志中,也清晰的看到,从12:57发起 alter database open 到最后完成open,耗时18分钟后,数据库成功open,数据库恢复正常。


这个案例给我们的警示是:

  • 在可能的情况下,任何变更都应该进行 1:1 真实测试,最大可能发现隐患;

  • 事关存储的变更,必须做好存储的读写I/O基准测试;


这个案例的后续是,分析新存储的I/O性能为何出现衰减,导致启动超时。这和存储的规划、磁盘划分、缓存配置等有关,数据库的案例到此就处理完成了。