When you start to work with 10g, you will notice some "new" behavior that you didn't expect.
After install on a unix environment you aren't able to run sqlplus, tnsping from sthat server if you aren't the user or if you don't belong to DBA group.
It looks like that Oracle is not able to get the securirity right.
Their solution is close it for everybody (as in the big, bad world) and your save.
Now you, as a DBA, has to open it for the normal (non DBA) users and now YOU are responsable!
That's an easy solution of Mr. Oracle.
You need to run $ORACLE_HOME/install/changePerm.sh to lift the restrictions.
Note some directories are kep to restrictive, you need to execute in the ORACLE_HOME:
$ chmod O+rx lib lib2 ldap ldap/admin srvm/lib32
(Or better: Checkout Metalink note 363721.1 and download patch 5087548.)
Another effect is that the CONNECT role is changed (is more restrictive in 10g).
Restoring the role CONNECT of 10gR2 as it was in 9i:
SQL> @$ORACLE_HOME/rdbms/admin/rstrconn.sql
After install on a unix environment you aren't able to run sqlplus, tnsping from sthat server if you aren't the user or if you don't belong to DBA group.
It looks like that Oracle is not able to get the securirity right.
Their solution is close it for everybody (as in the big, bad world) and your save.
Now you, as a DBA, has to open it for the normal (non DBA) users and now YOU are responsable!
That's an easy solution of Mr. Oracle.
You need to run $ORACLE_HOME/install/changePerm.sh to lift the restrictions.
Note some directories are kep to restrictive, you need to execute in the ORACLE_HOME:
$ chmod O+rx lib lib2 ldap ldap/admin srvm/lib32
(Or better: Checkout Metalink note 363721.1 and download patch 5087548.)
Another effect is that the CONNECT role is changed (is more restrictive in 10g).
Restoring the role CONNECT of 10gR2 as it was in 9i:
SQL> @$ORACLE_HOME/rdbms/admin/rstrconn.sql
Posts
