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!


Norman Dunbar
Dunbar IT Consultants Ltd

Registered address:
Thorpe House
61 Richardshaw Lane
West Yorkshire
United Kingdom
LS28 7EL

Company Number: 05132767

Other related posts: