While running adcfgclone.pl as oracle user, the session just hangs without giving any error in the log file. The issue was that it wasn’t able to connect to the database as:
sqlplus "/as sysdbaa
This can be occur due to improper shutdown of the database. While in the course of a database shutdown, if any of the oracle process is not completed killed and it holds a large shared memory segment, such issues can occur which would prevent from normal database operation.
ipcs -m | grep <oracle user>
eg:
ipcs -m | grep oracle
key shmid owner perms bytes nattch status
0x732xx675 65788 oracle 690 56788997 0
ipcrm -m < shmid>
eg:
ipcrm -m 65788
This would free up the memory held.
This resolved the issue.
sqlplus "/as sysdbaa
This can be occur due to improper shutdown of the database. While in the course of a database shutdown, if any of the oracle process is not completed killed and it holds a large shared memory segment, such issues can occur which would prevent from normal database operation.
So next time when an instance tries to start it is not able to grab a large chunk of memory to get started.
This can be checked as follows:
After the database has been shut down , there shouldn’t be any processes running as oracle on the server level:
This can be checked as follows:
After the database has been shut down , there shouldn’t be any processes running as oracle on the server level:
ipcs -m | grep <oracle user>
eg:
ipcs -m | grep oracle
key shmid owner perms bytes nattch status
0x732xx675 65788 oracle 690 56788997 0
Here in the above example, a single oracle process holds 56788997 bytes of shared memory, even after shutdown. If the database instance is started, then we would expect abnormal behaviors on the database side, like the login issue that we are discussing now.
This can cleaned as mentioned below:
ipcrm -m < shmid>
eg:
ipcrm -m 65788
This would free up the memory held.
This resolved the issue.
Comments
Post a Comment