修改db_files后遇ORA-01105 ORA-01174 解决
人间岁月戏白头
于 2018-04-20 15:49:49 发布
1781
收藏 2
分类专栏： Oracle RAC Oracle 数据库运维 Oracle 参数设置
版权
Oracle RAC
同时被 3 个专栏收录
26 篇文章1 订阅
订阅专栏
Oracle
70 篇文章1 订阅
订阅专栏
数据库运维
36 篇文章1 订阅
订阅专栏
修改db_files后遇ORA-01105 ORA-01174 解决
增加数据文件时遇
ORA-00059: maximum number of DB_FILES exceeded
查看db_files
SQL> show parameter db_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_files integer 200
查看数据库已添加的数据文件数量，发现达到了200个，需要修改db_files参数，大于200.
修改db_files
SQL> show parameter db_files;
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_files integer 200
SQL> alter system set db_files=300 scope=spfile sid='*';
System altered.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
重新启动
SQL> startup
ORACLE instance started.
Total System Global Area 2.6523E+10 bytes
Fixed Size 2219288 bytes
Variable Size 2.0737E+10 bytes
Database Buffers 5704253440 bytes
Redo Buffers 80158720 bytes
ORA-01105: mount is incompatible with mounts by other instances
ORA-01174: DB_FILES is 300 buts needs to be 200 to be compatible
原因是RAC的节点db_files 参数不一致
在其中一个节点的sqlplus 里只执行shutdown /startup，只是对改节点的instane起作用，不能分别重启实例，需要整个重启数据库
.用srvctl 重启数据库
[oracle@whdata1 ~]$ srvctl stop database -d PROD
[oracle@whdata1 ~]$ srvctl start database -d PROD
[oracle@whdata1 ~]$ sqlplus / as sysdba;
SQL*Plus: Release 11.2.0.4.0 Production on Fri Apr 20 15:27:39 2018
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL>
分别在两个节点查看，DB_FILES已修改。
SQL> show parameter db_files;
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_files integer 200
————————————————
版权声明：本文为CSDN博主「人间岁月戏白头」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/DBDeep/article/details/80019833