dbua in 11.2 is now dependent on oracle restart config
Date: Sun, 16 Oct 2011 03:53:20 -0700 (PDT)
Message-ID: <7dd60ac2-7133-4cf1-8947-666386dc159c_at_h5g2000vbf.googlegroups.com>
I have been testing for a while with 11.2 in a standalone server environment. ( This means no RAC no cluster but does include the grid infrastructure in 1 home ( to support ASM ) and database software in a 2nd different home ).
I had been testing using 11.2.0.2 patched up ( via patchset update ) to 11.2.0.2.3.
With the recent 11.2.0.3 availability I decided to go ahead and start testing using 11.2.0.3 versus latest patch set updates to 11.2.0.2.
For my system ( and really most anyones system I recommend considering this option ) I had ripped out all possibility of Oracle restart bringing up things on its own. I don't want any kind of software trying to restart things after a server reboot. Maybe you still have disk problems or disk controller problems or unstable os configuration or who knows what?
So on my systems that are going to run 11.2 I am going to disable all the Oracle restart stuff. That's just the way I am going to roll.
To do that you run commands like ( as root I think ) crsctl disable has and then as grid owner srvctl disable asm and srvctl disable listener and etc. Piece by piece you make sure that all the components are turned off.
I found out during the 11.2.0.3 upgrade process ( yes I put that into different oracle homes aka out of place upgrades and then ripped out eventually the old obsolete oracle homes don't get me started on that one ) that disabling the oracle restart configuration creates issues for dbua.
At some point dbua tries to figure out if the database getting upgraded uses asm ( that part worked ) then dbua tries to see if asm is running ( maybe to check that asm has already been upgraded ??? ) eventually.
Sure looks like dbua does the equivalent of "srvctl status asm" ...
If you have disable restart config for asm the srvctl status asm says asm is not running. Even though it is running.
The dbua apparently also mis interprets the response of it's check for asm running. It will tell you that you need to run asmca to upgrade asm ( instead of telling you that it's check to see if asm was running seemed to return that it is not running ). Since you already upgraded asm as part of the grid infrastructure upgrade that gets confusing.
To actually get the dbua to upgrade you have to ( grumble grumble ) reenable restart for asm ( srvctl enable asm ) so that the check being run by dbua works. Then you can later disable it again ...
Dang there is some pretty darn complicated pieces parts of 11.2 in a grid infrastructure standalone server environment that we DBAs are going to have to learn to deal with and get around if we don't want the oracle software to start making bad mistakes for us.
I thought that I was pretty much done with srvctl after getting rid of RAC but ... no it's back! Received on Sun Oct 16 2011 - 05:53:20 CDT