Normally, you should never have users in the OSDBA group (normally "dba") at the OS level. So, this should not, normally, be a concern.
I presume that the database instance startup is done by the clusterware and not manually or through some other script. Does the startup report errors (1031) ?
Hemant K Chitale
I never allow below authentication mode :
"sqlplus / as sysdba" without password .
Hopefully you understand my query .
Why is that? The only ones that can issue that command and obtain access to the database without a password are those people that have access to the database server and are in the 'dba' group. The number of people with this access should be very, very limited. In every shop I've worked in, only the DBA's have this access. They know how and when to connect as SYSDBA and understand the implications. The only other people who have this access are SysAdmins who have administrative access to the server. But I can count on two fingers the number of SysAdmins I've worked with that knew they had this type of access. Most SysAdmins do not know they can access the database this way.
I once worked in a large facility that had two different DBA teams on different sides of the building. The other side had one of their DBAs resign for another job elsewhere. And another DBA was on vacation. The only other DBA available there was pretty green and wasn't much help yet (he later turned out to be very good at his job). There was a problem with the Oracle database and they called me in to help resolve the issue. No one knew the SYSTEM password or any other DBA account's password. I asked if they had a SysAdmin available who had root access to the server. They did. The SysAdmin signed into the server as root. I was able to issue "su - oracle" and had access to the oracle user. I was then able to "sqlplus / as sysdba" without knowing any password and then "alter user system identified by newpass;". We now had a password to get into the database. The SysAdmin then closed his root window. The whole point of this is that should people become unavailable (resignation, vacation, sick, etc) there is still a way to obtain administrative access to the database in an emergency. That access isn't open to just anyone. It is still strictly controlled. I needed someone who had root access before I could proceed.