How to screw up DBUA inadvertently.
Date: Thu, 21 Jun 2012 09:43:43 +0100
Message-ID: <4FE2DEBF.9070905_at_dunbar-it.co.uk>
It was my own fault, but in case it proves even slightly useful....
I was upgrading from 11202 to 11203 Enterprise using the DB Upgrade Assistant utility. When I said "go do it" it went off, chugged for a bit, then barfed. Told me that the database wasn't running. I checked, it was.
Cutting a long story short, I checked the indicated logfile and discovered that it had connected to the database but then got a couple of errors telling it that "oracle not available". Hmm.
Turns out that I'd added a couple of SQL statements to glogin.sql:
alter session set nls_date_format = 'dd/mm/yyyy hh24:mi:ss';
Being one of them. This works perfectly while the database(s) are open but, if a database is shut, and you login as sysdba to start it, you still get glogin.sql executing, and because the database is down, the above SQL fails.
DBUA picked up the failure and refused to carry on.
Removing the SQL statement(s) from glogin fixed the problem.
The moral to this tale is simple, don't put SQL in glogin.sql (or login.sql) if you ever shut down your databases!
Cheers,
Norm.
--
Norman Dunbar
Dunbar IT Consultants Ltd
Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL
Company Number: 05132767
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jun 21 2012 - 03:43:43 CDT