RE: Testing for Upgrade using Dataguard Standby

What Tim wrote should work.  

IF you have plenty of disk, it is possible that the safe way to this is the very old safe way, having nothing to do with fancy schmancy tools:  

1. Stop apply and shutdown your standby.
2. Cold clone your standby to a different area of disk, including the controlfiles and everything.
3. startup rename the clone to the point in time you have. Hint: avoid having that be during a massive uncommitted transaction that will need to be rolled back.
4. do whatever you want to the renamed database and then shut it down and drop it.
5. start up and resume apply on the standby, which has had nothing done to it except the shutdown.

You actually CAN leave the clone up and running, which was the old way to do a frozen point in time DSS database for queries before Oracle engineered read-write on the standby.  

As John wrote, if this is your only standby, yas want to be very careful.  

IF you are expert in technology that does snapshots quite apart from the Oracle control files and online redo logs, such as Delphix, then you don’t have to copy the entire thing and the snapshot product takes care of keeping the changes.  

Again, my suggestion is dinosaur technology from before Oracle had dataguard.  

It may also be possible for you to do this as “split mirrors” if your underlying disk management supports splitting off a plex. That is a highly hardware/os/volume manager question, and if anyone goes “oops” regarding which plex is which vintage, hilarity ensues. Sequent’s SVM could do many plexes, for example. Using that for a “hot backup” with triplex and alternating which plex you split off to be backed up (in that day often to a tape farm) unmolested by i/o on the other two “live” plexes required coordination of when you entered and ended “hot backup” and switched log files in order to get a startable backup onto your backup media.  

Doing it “cold” with the database down, shouldn’t be a problem, but again that depends on the volume manager software. IF you’re using ASM to manage your volumes you might be operating without a volume manager.  

Finally, if you’re doing a full clone of that shut down standby, that can become a question of how fast can I copy and verify even if you do have appropriate space.  

good luck, and you probably want to work it out Tim’s way. Now if you have multiple standbys, just burn one, right? Make sure it is completely unhooked and not accidentally considered a read-write open dataguard, or hilarity will ensue.  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of John Thomas Sent: Wednesday, March 24, 2021 10:09 AM To: Andrew Kerber
Cc: Tim Gorman; ORACLE-L
Subject: Re: Testing for Upgrade using Dataguard Standby  

Partly depends on your environment doesn't it?  

If it's your only standby for production and something goes wrong during the test, how will you recover the standby and is the impact on production acceptable? (Do you have to take production offline if you have no standby active?)  

If it's not your only standby, the answer may be different.

Regards,  

John Thomas    

On Wed, 24 Mar 2021 at 13:39, Andrew Kerber <andrew.kerber_at_gmail.com> wrote:

Hi Tim-

Yes, I have used a snapshot standby before. However, I have not used it to test a db version upgrade in the past, and I am concerned there are additional steps I need to be concerned with after testing the upgrade is complete, and I revert back to the previous version.  

As far as I can tell, after testing is complete and I want to revert back to the 11.2.0.4 version and put it back in redo apply, I just shut down the db, startup mount from the 11g home, and tell it to convert to a physical standby. Are there any additional steps due to the upgrade process, such as backing up the control file before the upgrade?        

On Tue, Mar 23, 2021 at 8:16 PM Tim Gorman <tim.evdbt_at_gmail.com> wrote:

This is known as a "snapshot standby" and here are some step-by-step instructions against which you can compare...

https://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/prod/ha/dataguard/usingsnapshot/usingsnapshot.htm

On 3/23/2021 12:54 PM, Andrew Kerber wrote:

For reasons too numerous to list, it is necessary for us to do some upgrade validation testing on our existing dataguard standby of production. This is an upgrade from 11.2.0.4 to the latest 19c version. These are the steps I can see as needed for the process of validation and testing:  

1. Install and patch the 19c software to the most recent version.
2. Create a guaranteed restore point on the standby database.
3. Open the standby database read-write.
4. Run DBUA to upgrade the snapshot standby to 19c.
5. Run testing as required
6. Shutdown standby
7. startup mount the standby from the 11g home and revert to the guaranteed restore point.
8. Resume the redo apply on the standby.

Am I missing a step here? Will there be a problem with the control files when I flash the database back to the restore point after an upgrade? I would think there would not be a problem since oracle should be designed to handle this, but I have tried an upgrade of a snapshot standby before, though I have done other destructive testing of course.

-- 

Andrew W. Kerber



'If at first you dont succeed, dont take up skydiving.'



 



-- 

Andrew W. Kerber



'If at first you dont succeed, dont take up skydiving.'







--
http://www.freelists.org/webpage/oracle-l