During a test run of an upgrade with the DBUA, everything was peachy..did some tests, and some other thingies..Multiple terminals open like anyone not working on Windows does..Started the DBUA 12c just fine…found out: hey, you need to have extra space in the ASM to accommodate the upgrade..so I added some disks, but needed to reboot the testmachine, since, as you know it…NOTHING works as advertised, and Murphy’s law just loves to make itself count..
Long story short: after the reboot, started the DBUA again, and got hit with:
ORA-01031: Insufficient privileges; DBUA cannot continue..
..Huh? What? Who?WHY!?…Although Oracle claims the DBUA tells you every step, I just didn’t see it, except a dialog box where I could watch DBUA quit on me..
secret? Check the log file located in the ORACLE 12c BASE..Mind the 12c part..
Since we are trying to upgrade an 11G database to 12c, we have multiple versions of the oracle software…*hint* This is a clue on what went wrong…
This log showed us the actual part where things went wrong…After the screen where the database to be upgraded was selected, the DBUA creates a temporary database instance..and the bailout was on the starting up of this instance. Even when trying the instance startup (the files where located in the $ORACLE_HOME) it bails with exact this message..
Then we went on-line and looked up the normal answers and made things even worse, by setting/adding the parameter SQLNET.AUTHENTICATION_SERVICES = (NTS) in the sqlnet.ora file..This resulted in a total “I’m REALLY not going to start” Oracle HAS stack..nothing would start anymore, since ASM didn’t get on-line anymore..*sigh*. The new error was: “ORA-01017: invalid username/password”. So to put this mildly: DON’T SET THAT PARAMETER IN SQLNET.ORA (yet?). Perhaps later. Just…not now..trust me.
We shouldn’t attempt things like this while it’s getting late…since when we rebooted, and logged in, we set the ORACLE_HOME to the 12c version…of ASM! We accidentally set the GRID HOME of Oracle 12c..And this causes the bailout…
So: after cleaning the SQLNET.ora file, and setting the ORACLE_HOME to the DATABASE 12c home, and making sure the PATH setting was correct..we could start the dbua…and it was able to startup the temp instance:
[pool-1-thread-1] [ 2017-02-04 17:09:02.890 CET ] [OsUtilsBase.getBaseFromOrabase:659] oraBaseUtility /oracle/12c/base/db/bin/orabase [pool-1-thread-1] [ 2017-02-04 17:09:02.890 CET ] [OsUtilsBase.getBaseFromOrabase:668] cmds: /oracle/12c/base/db/bin/orabase [pool-1-thread-1] [ 2017-02-04 17:09:02.890 CET ] [OsUtilsBase.getBaseFromOrabase:672] envs: ORACLE_HOME=/oracle/12c/base/db [pool-1-thread-1] [ 2017-02-04 17:09:02.895 CET ] [OsUtilsBase.getBaseFromOrabase:682] baseLocation from orabase /oracle/12c/base [pool-1-thread-1] [ 2017-02-04 17:09:02.895 CET ] [OsUtilsBase.getBaseFromOrabase:707] orabaseLocation= /oracle/12c/base [pool-1-thread-1] [ 2017-02-04 17:09:02.895 CET ] [SQLEngine.getEnvParams:602] Default NLS_LANG: AMERICAN_AMERICA.AL32UTF8 [pool-1-thread-1] [ 2017-02-04 17:09:02.895 CET ] [SQLEngine.getEnvParams:612] NLS_LANG: AMERICAN_AMERICA.AL32UTF8 [pool-1-thread-1] [ 2017-02-04 17:09:02.896 CET ] [SQLEngine.initialize:358] Execing SQLPLUS/SVRMGR process... [pool-1-thread-1] [ 2017-02-04 17:09:02.897 CET ] [SQLEngine.initialize:395] m_bReaderStarted: false [pool-1-thread-1] [ 2017-02-04 17:09:02.897 CET ] [SQLEngine.initialize:399] Starting Reader Thread... [pool-1-thread-1] [ 2017-02-04 17:09:03.934 CET ] [OracleHome.initOptionsStopOnError:1370] executing: startup nomount pfile='/oracle/12c/base/db/dbs/initDBUA0902805.ora' [pool-1-thread-1] [ 2017-02-04 17:09:16.656 CET ] [OracleHome.initOptionsStopOnError:1372] DB Options instance startup successful
and onwards with the upgrade to 12c..
p.s.: yes, this was a nice exercise to stay vigilant, but what can I say? I’m only human..(and a lot more wiser now this went wrong in a test environment, rather than production 🙂 )