In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-30 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >
Share
Shulou(Shulou.com)06/01 Report--
Yesterday, a colleague consulted, he patched a node of the rac cluster, the database could not start after restart, at first glance the situation seems to be disk group can not mount error: ORA17503, careful investigation found that db_files parameter changes caused the database to start error ORA01174 and could not start.
1. Description of the problem
Oracle rac 11.2.0.4 is patched and restarted. The database instance cannot be started. The startup error data disk group is not mounted as shown in the following figure:
2. Problem analysis
The grid of cluster node racdb1 executes crsctl stat res -t -init, checks the cluster resource process status, and finds that it is normal:
The grid of cluster node racdb1 executes crsctl stat res -t to check the cluster resource status and finds that the database instance of racdb1 is not mounted:
View the startup status of node racdb1 instance as started:
Oracle user sys login database execution alter database mount error ORA000205:
Check the alarm log of node racdb1 instance. The alarm log prompt is consistent with the error mentioned in 1: disk group data is not mounted.
The grid user of node racdb1 logs into the asm management console, checks the disk group status, and finds that the data disk group status is normal:
Grid user of node racdb1 checks the control file in asm console and finds that the control file can be seen:
This eliminates the possibility that the ASM diskgroup is not mounted, causing the racdb1 instance to fail to mount.
The oracle user of node racdb1 first executes shutdown abort to shut down the current instance:
The grid user of node racdb1 uses srvctl tool to start the instance and reports error ORA01174:
The reason why the racdb1 instance of node racdb1 cannot be started is located as follows: the database may be patched. The patch set modifies the database parameter DB_FILES of the racdb1 instance. After the database is restarted, the cluster check finds that the DB_FILES parameters of the two node instances are inconsistent, which causes the racdb1 instance of node racdb1 to fail to start.
3. Problem solving
Oracle user on node racdb1 logs in to the database, closes the instance, and boots to nomount state:
Node racdb1 Instance racdb1 Modify DB_FILES parameter to 500:
Because DB_FILES is a static parameter of the database, it needs to be restarted. After closing the node racdb1 instance racdb1, start the database to the open state:
Postscript: Check the alarm logs of 2 nodes afterwards. Except for the alarm log of node racdb1, the DB_FILES parameter is finally manually modified to set it to 500.
No one else was found to manually order it to be modified to 200, thus confirming that it was caused by patching.
This problem is solved!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.