RAC node startup failed -- ASM cannot connect

A rac problem occurs recently, and a node cannot be started. After analysis, the solution is as follows. In the 11.2.0.3RAC environment, if one node instance fails to start, the following error is displayed: [oracle @ exadbmel04 ~] $ C

A rac problem occurs recently, and a node cannot be started. After analysis, the solution is as follows. In the 11.2.0.3RAC environment, if one node instance fails to start, the following error is displayed: [oracle @ exadbmel04 ~] $ C

A rac problem occurs recently, and a node cannot be started. After analysis, the solution is as follows.

The same error occurs when SQL plus is enabled.

View resources. We can see that the ASM instance is normal, including diskgroup, but the instance exadbmel04 is not started.

Locate the problem point by querying ORA-27300 errors.

The problem is that the permission of the file $ GI_HOME/bin/oracle is incorrect. The correct permission should be "-rwsr-s -- x". Correct the permission and solve the problem.

Start instance, Hong Kong server, normal start

Use sqlplus to verify that the database is accessible

Possible problems,

1. manually modify the permissions of the file,

2. If the apply patch fails, the file permission will be changed to-rwxr-xr-x During the apply patch process. After the apply patch is completed, it will be modified back, however, if the apply patch fails, the permission of the file remains in the wrong state and needs to be manually modified.

Finally, the "S" in the $ GI_HOME/bin/oracle File Permission is analyzed. This permission problem is clear and oracle's problem is explained. Query Linux permissions on an American server.

The Linux permission model has two specialized spaces, Hong Kong Space, called "suid" and "sgid ". When an executable program is set
When the "suid" is specified, it indicates that the executable file owner runs, rather than the person who starts the program.
Now, back to the executable file, we can
It belongs to the root user:

. This indicates that for this special program,
Set the user to execute (
With full superuser access), rather than representing the user running it. Because of user access
The permission is run, so the/etc/passwd file can be modified without any problem.

Suid/sgid warning description

We can see how suid works, and sgid works in the same way. It allows the program to inherit group ownership of the program
Is the program ownership of the current user.

Reference a post of ITPUB, which contains related questions and Analysis

? Mod = viewthread & tid = 1622940.

The reason for the problem is that the permissions of oracle programs under $ ORACLE_HOME/bin/oracle and $ GI_HOME/bin/oracle are set in this way, and their groups are different, therefore, in the actual connection process, you need to call each other's oracle program to apply for the SGA memory zone.

We can see that the following groups are different. If you need to use the application of the other party and use the group of the application, the only way is to use the "S" permission.

This article is from the blog "Little Dog's nest" and will not be reposted!