Re: ORA-27123 when migrating (9.0.1 to 9.2.0.3)

g8rb8 <member36724_at_dbforums.com> wrote in message news:<3278393.1061689206_at_dbforums.com>...
> Hello-
>
>
>
> I am in the midst of migrating an instance from 9.0.1 on Sun Sparc 5.8
> to 9.2.0.3.
>
>
>
> This instance(TEST) was running on this server at 9.0.1 prior to the
> upgrade without a problem. The new version of Oracle was installed an a
> couple of instances upgraded via the Export/import method. Another DBA
> performed these tasks.
>
>
>
> No problems were reported by users testing the self service applications
> nor the Internet Native Applications, but I do not know how much testing
> has taken place.
>
>
>
> At this point, I have taken over the server, and I chose to migrate the
> instance, via the STARTUP MIGRATE command. Everything appeared fine, I
> followed up with the catalog upgrade script u0900010.sql and then
> upgraded the other components with the cmpdbmig.sql script. After
> restarting, I ran utlrp.
>
>
>
> Everything ran fine without errors.
>
>
>
> I then edited the init.ora and removed the _system_trig_enabled
> parameter. Restarted, created a spfile from the pfile, and changed and
> bounced the listener.
>
>
>
> Everything still appeared fine. All processes are up, all system
> objects are valid. Oracle can log in as system, or '/ as sysdba'
> just fine.
>
>
>
> When I went to my normal UNIX userid for the application I administer, I
> got a ora-27123 - when attempting to login via sqlplus as system, or any
> other administrative user.
>
>
>
> I checked the previously created instances, and got the same error. I
> then shut down the spare instances to free up the segments, and that
> didn't help.
>
>
>
> Has anyone seen this behavior before and can send me some hints?
>
>
>
> Thanks much! g8r

Some things to check:

Be sure the SGA hasn't been modified to be too big for your memory segments. Try a startup nomount. Double check the O install guide settings of shmmax, etc. See the metalink notes on memory management for unix.

Do an ipcs to be sure you are not using up more segments, like from a previously running instance (ie, shutdown all instances and do an ipcs|grep oracle to be sure nothing is using up memory).

Be sure $ORACLE_HOME/bin/oracle has the correct protection, and you are logged in as someone in the dba group.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/tue/business/news_1b26virus.html