数据库中有一个隐藏参数 _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性能为何出现衰减，导致启动超时。这和存储的规划、磁盘划分、缓存配置等有关，数据库的案例到此就处理完成了。