Re: Snapshot standby problems?

From: Don Seiler <don_at_seiler.us>
Date: Tue, 14 Apr 2015 12:30:40 -0500
Message-ID: <CAHJZqBC5YyGJ=v98X6M=Zj3Q96EOVTidQSkcOJbW7JCC4XdNig_at_mail.gmail.com>



Andrew,

Some rules of thumb I do when converting to physical and back:

  1. Connect to dgmgrl from the primary environment.
  2. Connect as sys with the sys password. I tried connecting as "/" but when you do that, dgmgrl can't do remote restarts (which are needed when converting to physical).
  3. Make sure all the TNS and listener setups are right. You need static listener entries to do the restarts as well.

Hope that helps!

Don.

On Wed, Apr 8, 2015 at 1:41 AM, Kim Berg Hansen <kibeha_at_gmail.com> wrote:

> Hi, Andrew
>
> 11.2.0.3 in general I don't know of major issues with converting from
> physical to snapshot and back.
> We have done it on HP-UX Itanium and are doing it now on Oracle Linux. AIX *specific
> *issues I can't tell you if there are any ;-)
>
> We are using Cloud Control scheduled jobs to convert to snapshot standby
> every morning at 5 AM and then convert back to physical every evening at 11
> PM.
> That way during the day we use the snapshot standby for internal education
> and for testing on a complete copy of production database, and whatever we
> happen to destroy during the day is rolled back in the evening, redo
> applied during the night, and next morning a fresh copy is ready - works
> fine :-)
>
> The CC scheduled jobs call OS scripts for the two conversions:
>
> The OS script for converting to snapshot standby in the morning does:
>
> 1. emctl call to start blackout for the instance.
> 2. dgmgrl call to convert to snapshot standby.
> 3. sqlplus call to execute a script that updates some data to
> "TESTING" that makes it clear to the application user that it is the test
> database, disable some database scheduled jobs that only makes sense in
> production, and so on.
> 4. emctl call to stop blackout.
>
> The blackout probably shouldn't be necessary, but we had a minor issue
> with alerts for the instance happening during conversion. We think that
> might be fixed if we patch the Cloud Control agents (we are using CC
> version 12.1.0.2.0) but for now the workaround with setting a blackout is
> fine for us.
>
> The OS script for converting back to physical standby in the evening does:
>
> 1. emctl call to start blackout for the instance.
> 2. dgmgrl call to convert to physical standby.
> 3. emctl call to stop blackout.
>
> This has been working fine for years now, and it has helped us a lot to be
> able to try out things in the snapshot standby without worrying too much,
> as we know anything we do will be gone the next day.
>
> Teaching new users in application running on the snapshot standby is also
> great, as we can let them create orders and perform invoicing as much as
> they need to understand the application without worrying about whether they
> break anything or not.
>
> And on several occasions it has been very helpful as debug tool as well.
> When a user calls and state the application just made such and such error,
> we can often reproduce the error by performing the exact steps the user did
> on the snapshot standby, as the data there is just as they were in
> production at 5 AM in the morning.
>
>
> So apart from perhaps a minor issue of some misleading "instance down"
> alerts from Cloud Control, I'd say go for it :-)
>
>
>
> Regards
>
>
> Kim Berg Hansen
>
> http://dspsd.blogspot.com
> kibeha_at_gmail.com
> _at_kibeha
>
>
> On Wed, Apr 8, 2015 at 4:06 AM, Andrew Kerber <andrew.kerber_at_gmail.com>
> wrote:
>
>> Are there any issues with converting a physical standby to a snapshot
>> standby and back in 11.2.0.3 on AIX? I'm getting ready to do some work
>> with this, but thought I would check for any known problems first. I will
>> be doing the conversion through dgmgrl at least initially.
>>
>> Sent from my iPad--
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>

-- 
Don Seiler
http://www.seiler.us

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Apr 14 2015 - 19:30:40 CEST

Original text of this message