How to screw up DBUA inadvertently.
- From: Norman Dunbar <oracle@xxxxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 21 Jun 2012 09:43:43 +0100
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
