Re: Post-Install: Oracle v9.2.0 on Mandrake9.2

php newbie wrote:

> I have installed Oracle a few times in the past few days, each time
> following different guidelines (puschitz, dizwell, Oracle's own).
> Each time, I end up with the same post-install state.
>
> The user oracle can start up, shut down, and connect to the database.
> Any other user can not, despite their having no differences, other
> than user names. I will appreciate any help to resolve this.
>
> I am including as much information as possible in the hopes that
> someone will see what is going on:
>
> OS: Mandrake 9.2
> Oracle: Oracle 9.2.0.1.0
> RAM: 1GB
>
> users: oracle, test
> user oracle's groups: oinstall, dba, oracle
> user test's groups: test, oracle
> Global DB Name: db_lx92
> SID: lx92

Use the Unix "id" command to see what group memberships are currently in effect.
Under many if not all Unices, you have to re-login (or "newgrp") after editing /etc/groups for it take effect.

As mentioned previously, membership in the "dba" group is not necessary simply to connect. Only for startup/shutdown.

> $ printenv |grep ORA

[...]

Which Unix user is running this session? "test"? What is the PATH variable setting?

[...]

> -rwsr-sr-x 1 oracle oinstall 44946785 May 13 2002 oracle*
> -rwxr-xr-x 1 oracle oinstall 0 May 2 2002 oracleO*

It's very odd that "oracleO" file is zero bytes.... it should usually be an exact copy of the "oracle" file (something that should happen automatically via the install).

Also, it is normal for the group ownership to be "dba". When you installed and it prompted you for SYSOPER and SYSDBA group, what did you provide? "dba" or "oinstall" ? "dba" is not a magic name, just traditional. You group "oracle" seems to be completely irrelevant here.
>
> $ cd ../lib
> $ pwd
> /u01/app/oracle/9i/lib
> $ ls -l libodm*
> lrwxrwxrwx 1 oracle oinstall 11 Jan 31 21:55 libodm9.so ->
> libodmd9.s
> o*
> -rwsr-sr-x 1 oracle oinstall 6747 Apr 26 2002 libodmd9.so*
>

It's not normal for any of the files in the "lib" directory to have "s" (suid)permissions. The "s" only applies to executable files, which these are not. Not sure that's a problem, but how did this happen? I have never seen this happen after numerous installs under Solaris, HP-UX, and Red Hat Linux.

I believe the "odm" refers to the Oracle Data Minining component. Maybe try a simpler install without all the "extras" first (are you installing Standard Edition or Enterprise Edition?)

> << HERE ARE THE CONTENTS OF OF RELEVANT CONFIG FILES AND ERROR MSGS>>
> << listener.ora, sqlnet.ora, tnsnames.ora, /etc/sysctl.conf >>
> << sqlnet.log >>
> << install errors that were not fixed following various suggestions >>
[...]
>

Not sure, but your install errors seem pretty serious to me (i.e. need to be fixed). You didn't include any info on what a successful login as user "oracle" looks like. Can this user connect using both the "beq" and "tcp" protocols?
Does "lsnrctl status" output show anything unusual?

### $ cat /etc/sysctl.conf

Much better to run this command:

        sysctl -a | grep kernel

to see what settings are currently in effect (but I don't think this is the most likely problem).

Can the "root" user connect?

HTH, it's pretty hard to be more specific without being there to see what's happening. If you can possibly find a working installation somewhere to compare against, that would be the best way to track down the problems.

-Mark Bole Received on Thu Feb 05 2004 - 09:44:19 CST