RE: How to prevent Oracle Restart/SIHA/OHAS from attempting to open database needing recovery

…You’ve forgotten more than a lot of folks ever knew…  

By the way, the “old school” way to prevent automatic opens of all varieties (particularly roll your own standby recovery databases before Oracle implemented a product to do what some of us were already doing), was to rename the online redo logs to NOT what they were supposed to be.  

For me, backing up the online redo logs (not on the backup tapes), was always the first step of any attempt of a complete recovery, since in the event of a crash disk corruption of tablespace files the online redo logs *might* contain committed transactions that need to be applied.  

Probably reading your own slides is at least understandable. If you find yourself awake out of the bedroom in the middle of the night and can’t remember why you got up, visit the restroom.  

Thanks for the chuckle,  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman Sent: Thursday, June 08, 2023 2:47 PM
To: Ross Ohnesorg
Cc: ORACLE-L
Subject: Re: How to prevent Oracle Restart/SIHA/OHAS from attempting to open database needing recovery  

Ross,

Thank you so much for your response!

This is a real face-palm.

I used the referenced material on behalf of a vendor called Teleran back in 2007 to automate the startup, shutdown, and status checking of the Teleran iSight product into the grid infrastructure for RAC, and did a presentation on the topic at the RMOUG Training Days conference in Feb 2008. I still have the PPTs!

Then, I resurrected similar functionality using the same features (HERE <https://community.delphix.com/communities/communityhome/digestviewer/viewthread?GroupId=97&MessageKey=5b8e83ea-bcb1-40d5-8efe-18adaf5a583d&CommunityKey=4e2d7f5c-8842-432b-86ec-1bd8b6f628d7&tab=digestviewer> ) while I was working for Delphix about 4 years ago in 2019.

I can understand forgetting about it all if all this were 15 years in the past, but forgetting stuff I blogged publicly about 4 years ago is pretty hard to admit. I mean, I frequently joke about forgetting what I've had for breakfast, but this is coming close to no longer being a joke.

Oh well.

Thank you so much for bringing this all back to the foreground!

Have a wonderful day!

-Tim

On 6/8/2023 10:13 AM, Ross Ohnesorg wrote:

Not sure if I have my full posting privileges right now or not, but the old “action scripts” might be applicable here. We used them years ago on a similar setup. I think ours was a full CRS 11.2 cluster with single instance databases. A quick google search didn’t find the Oracle hosted version of this white paper, but here’s somebody else hosting it,

https://levipereira.files.wordpress.com/2012/05/si-db-failover-11g-134623.pdf  

You might be able to add logic there to do a startup mount, check for recovery, and then open the database. I don’t know if this would work with Oracle Restart instead of the full CRS stack.  

Thanks,

Ross    

From: oracle-l-bounce_at_freelists.org <mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org> on behalf of Tim Gorman <mailto:tim.evdbt_at_gmail.com> <tim.evdbt_at_gmail.com> Date: Thursday, June 8, 2023 at 9:26 AM
To: ORACLE-L <mailto:oracle-l_at_freelists.org> <oracle-l_at_freelists.org> Subject: How to prevent Oracle Restart/SIHA/OHAS from attempting to open database needing recovery

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Friends and colleagues,

I have a customer using Oracle Restart (i.e. single-instance installation of Oracle Grid Infrastructure, a.k.a. SIHA, a.k.a. OHAS) for access to Oracle ASM.

They have a situation where they are restoring the entire VM from storage-level snapshots, including the Oracle database which was in "backup mode" at the time of the snapshot, and Oracle Restart is attempting to automatically open the database (which needs roll-forward recovery).

This automatic restart makes sense under normal conditions, when the database is not in need of media recovery. However, when the database is in need of media recovery, then automatically opening the database eliminates any possibility of performing roll-forward media recovery.

We can use srvctl to set startoptions from open to mount, and that will solve the problem when roll-forward media recovery is needed, but it leaves the database in unusable mount mode when the automatic restart is expected to automatically open the database.

So, Oracle Restart apparently does either STARTUP OPEN or STARTUP MOUNT blindly, instead of perhaps first MOUNTing the database, then checking if media recovery is needed before an OPEN is attempted, which would be the intelligent thing to do, and not difficult to automate into srvctl.

Has anyone resolved this problem?

Thanks!

-Tim
--

https://urldefense.com/v3/__http://www.freelists.org/webpage/oracle-l__;!!N4fOi5Mv!cm5uEXrwOZkvOVWa5EQU8wRVtXZ4p9_d84wlZVcC22mJVaw646ylOSuIMA04g23raFOZTWnAGoSrbCrsbIUfhA$ <https://urldefense.com/v3/__http:/www.freelists.org/webpage/oracle-l__;!!N4fOi5Mv!cm5uEXrwOZkvOVWa5EQU8wRVtXZ4p9_d84wlZVcC22mJVaw646ylOSuIMA04g23raFOZTWnAGoSrbCrsbIUfhA$>  

--

http://www.freelists.org/webpage/oracle-l Received on Thu Jun 08 2023 - 22:21:20 CEST