startup fails after migration of Oracle DB 8i to 9i on Alpha 7.3-2

[Guinaudeau]

We are migrating an Oracle DB on a VMS 7.3-2 Alpha system from 8.1.7 to 9.2.0. Migration apparently ran OK, but we cannot start
the DB since then. Audit indicates a failure "SETPRV missing privilege", although i eventually set /DEFPRIV=ALL/PRIV=ALL for the Oracle account including BYPASS for test purpose.

We red lot of release notes, metalink notes and our check-list was hopefully exhaustive enough. Quotas, PQL_M, CPU level (our AXP = EV6 462MHz), FW, ODS-5 format for the product tree, installation from CD-ROM using its own JRE 1.3.1. PAGEFILE.SYS, SYSGEN esp PQL_M* ...

We had initially some confusions between both env 8i/9i or misses in the logical name settings, partly because we did
not use the OFA standards under 8i. We repaired this, lognames and bequeath listener start are OK.

After the migration itself, we cannot start the Oracle DB.

Alert log indicates the SGA allocation then the non-default parameter values and nothing afterwards. No trace file is generated by Oracle anywhere.

On the SQL session :

APOLLO/ORAOMV920[GASLZ]> sqlplus "sys/change_on_install as sysdba"

SQL*Plus: Release 9.2.0.2.0 - Production on Fri Jan 6 02:14:36 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup
ORA-03113: end-of-file on communication channel
SQL> exit


Audit results in :

%%%%%%%%%%% OPCOM 6-JAN-2006 03:41:50.66 %%%%%%%%%%%
Message from user AUDIT$SERVER on APOLLO
Security alarm (SECURITY) on APOLLO, system id: 4119
Auditable event: Privilege failure
Event information: SETPRV not used to enable temporary privilege not authorized to process (SET PROCESS/PRIVILEGE, $SETPRV)
Event time: 6-JAN-2006 03:41:50.66
PID: 0000029D
Process name: ORA_GASLZB4498
Username: ORAOMV920
Process owner: [ORAOMV920]
Image name: APOLLO$DKC500:[ORACLE.ORA_920.][BIN]ORACLE.EXE
New privileges: ALTPRI,SETPRV,EXQUOTA,BYPASS
Old privileges: CMKRNL,SYSNAM,GRPNAM,IMPERSONATE,LOG_IO,GROUP,PRMCEB,
PRMMBX,TMPMBX,WORLD,OPER,NETMBX,PRMGBL,SYSGBL,PFNMAP,
SYSPRV,SYSLCK,SHARE
Privileges missing: SETPRV
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)

also i set /DEFPRIV=ALL/PRIV=ALL for the Oracle account, i ever catch
this failure SETPRV missing privilege failure.

any ideas ???

[Robert_Boyd]

The problem here appears to be with the username ORAOMV920 not ORACLE. The process running under ORAOMV920 must have SETPRV enabled. Either this process is not getting SETPRV enabled when it is started because the ORACLE start code for it fails to do so, or the authorized privileges need to be adjusted to include SETPRV.

Robert

[Guinaudeau]

Robert,

the privilege SETPRV is both authorized and default privilege by the account ORAOMV920.

Should the account name be the same as the owner / user name ? We have [ORAOMVN] for the account and [ORAOMV920] for the owner/user. I have choosen the user name then remarked that account name are max 8 chars long.

Would it be that troublesome ?

Louis

[Marc Van den Broeck]

Can you do a show ORAOMV920 in authorize please and show us the output?

Rgds
Marc

[Wim Van den Wyngaert]

Have no to test it but is the oracle.exe installed with privs but not enough privs ?

Wim

[Guinaudeau]

Robert,

sorry : your answer does worth probably more than 4 points

i am testing the following, but i am pretty sure about my trouble.

see attachement. that's not trivial to understand anyway on the first snapshot, but i assume i catched the error because you suggested me the right ideas, looking at user/owner/account names. it was a confusing situation and i did not catch the confusion at the first look. But why does it happen is nevertheless unclear.

i am not enough experienced with SYSUAF / security , and may be i should have user=owner=account in my case. anyway, that has been the source of confusion.

i could not set

actually, the audit failure said :

Username: ORAOMV920
Process owner: [ORAOMV920]

but it was the important data : account = ORAOMVN.

question :

what about this ? is this a bug or a feature ? is this Oracle or VMS ?

i am in the process to change the user account strategy, that is, i discuss with a colleague ... and let you know. just your idea has opened my mind to a potential error.

i have also forgotten to grant ORA_DBA to ORACLE, but it is not the user we actuallay use.

thanks

louis

[Wim Van den Wyngaert]

Your uaf seems ok to me. Don't bother about the account field.

Could you post the output of
$ mc install list/fu APOLLO$DKC500:[ORACLE.ORA_920.][BIN]ORACLE.EXE

Wim

[Wim Van den Wyngaert]

Just to be sure :
. did you re-login after modif of the sysuaf
. do you redirect sysuaf to another sysuaf (sh log sysuaf/tab=*)

Wim

[Guinaudeau]

sorry, i thought on friday i had found the trouble and the correct solution was around this SYSUAF trouble. it is not so obvious, at least i did not catch something. we have some other departments in our company using Oracle9i under Alpha 7.3-2 and i will
check tomorrow morning with them (they can remotely connect our systems) what might go wrong, 4 eyes better than two.

Wim :

>>> did you re-login after modif of the sysuaf

yes

>>> do you redirect sysuaf to another sysuaf (sh log sysuaf/tab=*)

APOLLO/ORAOMV9[GASLZ]> sh log sysuaf
"SYSUAF" = "CLU_DAT:SYSUAF.DAT" (LNM$SYSTEM_TABLE)

so redirected to one file. in normal case, we have separate system
drives for each node, but one CLU_DAT directory common for nodes in
our environment, so one SYSUAF for every nodes in our cluster of
test machines.

>>> Have no to test it but is the oracle.exe installed with privs but not enough privs ?

i did not understand you at first reply : assume you expected following output to check this, but it is unclear what privs you mean :

APOLLO/ORAOMV9[GASLZ]> install list/full apollo$dkc500:[oracle.ora_920.bin]oracle

DISK$ORA920:.EXE
ORACLE;1 Open Hdr Shared
Entry access count = 1
Current / Maximum shared = 1 / 1
Global section count = 1

else, additional informations :

i observed "bizarr" phenomenon with the fact that account was ORAOMVN, and that ORAOMVN user exists, as one can see here :

APOLLO/ORAOMV920[GASLZ]> mc authorize show [30,*] /brief
Owner Username UIC Account Privs Pri Directory

ORAOMVN ORACLE [30,1] ORAOMVN All 4 DISK$OMVN_ORA1:[ORACLE]
ORAOMVN ORAOMVN [30,11] ORAOMVN All 4 DISK$OMVN_ORA2:[ORACLE]
ORAOMV920 ORAOMV920 [30,14] ORAOMVN All 4 DISK$ORA920:[ORACLE]

i had this audit alarm "SETPRV failure" first with these entries. i changed
account name so that was :

ORAOMV920 ORAOMV920 [30,14] ORAOMV9 All 4 DISK$ORA920:[ORACLE]

then audit alarm "SETPRV failure" vanished. that does mean : there should have been something in Oracle code which is confused when account name is the name of another user ...

i discussed with colleagues and anyway will from now have :

user=owner=account

last question for now :

did someone use an HW like our :

System Type AlphaServer DS10 466 MHz, 462 MHz
CPU Type EV6 Pass 2.3 (21264)

PAL Code 1.98-83 ; Console Vers V6.7-1

i might upgrade the FW to the last one, if it sounds safer. just, did someone
experience with EV6 462MHz ? i red the Oracle note 222553.1 and it should be ok, but ...

louis

[Jan van den Ende]

Louis,


then audit alarm "SETPRV failure" vanished. that does mean : there should have been something in Oracle code which is confused when account name is the name of another user ...

i discussed with colleagues and anyway will from now have :

user=owner=account



I am not so sure if the last line is such a good idea, especially with respect to your observation that Oracle code CAN get confused.

As long as ALL usernames, UICs, and account names are unique, each username and each acount name will by default also be the name of an UIC-valued IDENTIFIER. Trying to enter a duplicate value (either the name or the value) silently is accepted, without creating the extra identifier.

But another type of identifier, (Numeric-valued) can be granted to UIC-value idents.
_IF_ the code checks for identifiers-held (good VMS usance!), then confusing your identifiers might well confuse the code!

So, please keep your account names as well as usernames unique, also from one another, and maintain exactly ONE accountname per UIC-group. This is: set ACCOUNT for every username in the same UIC group to the same value, and have a separate name for each UIC group.

Hope this helps,

Proost.

Have one on me.

jpe