We all have horror stories about "That one time, when we restored and recovered the database, and the CIO was calling out managers every few minutes, reminding them the company is at a stand-still...this is costing us $XXX,XXX per minute!!!!!" Now imagine after a few hours in to your restore you have to say, "We hit a bug. We have to open an SR, get a patch and start over." Discovering you can't successfully restore/recover when the heat is on due to a bug would make a great horror movie...nothing is more scary. Luckily I hit this bug during a restore test...so I had some time to deal with it...but I thought I should let everybody know about it.
I know a lot of people are still running 12.1.0.2. The Jan and Apr 2019 PSU (the two latest PSU's) introduce a bug (25107334) that cause you to be unable to open the database. I hit this 3 hours into a restore:
ORA-65108: invalid use of a cursor belonging to another container
The work around is that you manually put the $SEED database into read-only mode. Simple enough...but if you're restoring/recovering a database, that's not a option. There's now a patch (25107334), that solves the issue. While waiting for MOS to come up with a solution, I used a 19.3 home to restore the database, and it worked fine...so that's an optional work-around too.
As people migrate to 19.3, there are earlier bugs that prevent 12.1 from working with a 19.3 GI...those bugs are fixed in these PSU's...so patching 12.1.0.2 needs to be part of the 19.3 upgrade plan, and this patch needs to be part of the 12.1.0.2 patch.
Hopefully this will be part of future PSU/proactive patch bundles...and we can keep the nightmares in the movies!
/*+ UPDATE */
The July PSU is out (12.1.0.2.190716) and per (1924126.1), 25107334 is fixed in that PSU.
I know a lot of people are still running 12.1.0.2. The Jan and Apr 2019 PSU (the two latest PSU's) introduce a bug (25107334) that cause you to be unable to open the database. I hit this 3 hours into a restore:
ORA-65108: invalid use of a cursor belonging to another container
The work around is that you manually put the $SEED database into read-only mode. Simple enough...but if you're restoring/recovering a database, that's not a option. There's now a patch (25107334), that solves the issue. While waiting for MOS to come up with a solution, I used a 19.3 home to restore the database, and it worked fine...so that's an optional work-around too.
As people migrate to 19.3, there are earlier bugs that prevent 12.1 from working with a 19.3 GI...those bugs are fixed in these PSU's...so patching 12.1.0.2 needs to be part of the 19.3 upgrade plan, and this patch needs to be part of the 12.1.0.2 patch.
Hopefully this will be part of future PSU/proactive patch bundles...and we can keep the nightmares in the movies!
/*+ UPDATE */
The July PSU is out (12.1.0.2.190716) and per (1924126.1), 25107334 is fixed in that PSU.
No comments:
Post a Comment