Well that title was a bit of a mouthful, but what this posting is concerned with, is how you go about testing a failover in a Dataguard environment when you are running in Maximum Performance mode and sending your redo data via LGWR ASYNC. Testing a switchover in this environment is fine and this can be done without incurring any data loss, but how do you go about testing a failover?
Performing a failover while running in Maximum Performance mode will incur data loss, this loss may be acceptable when faced with a real life disaster but may be unacceptable in a testing scenario. The size of data loss window in this type of environment can be minimised by using LGWR with ASYNC to ship the redo data, and this may provide a useful combination of minimal impact on your production instance with only a small data loss window.
As I see it, there are really 2 options here on how to test a failover while you are running in Maximum Performance mode and ensure you have no data loss:
In this scenario, you announce a service outage, and prior to performing the failover, you ensure all applications accessing the database are switched off. Note you can leave read-only applications up and running while performing the failover.
You will need a method of resyncing your original primary to failback. Of course this is something you will want to have tested in the event of a real failover anyway.
This has a bit of an obvious drawback in that how the applications that perform writes behave in a failover scenario are not really being exercised.
An alternative scenario is:
This option involves activating the standby read-write and essentially running with 2 primary databases. Of course in this scenario you do not allow the end users into the standby, but you can run read-write applications against the standby for testing purposes.
This scenario has the added attraction of the lowest impact on the original primary and indeed you may even get away without any downtime for your end users.
I think it is fair to say that the first option is the more rigorous testing, while the second option is less intrusive. For sure it is important to test your business continuity strategy, but while running in a maximum performance your options for testing a failover can be limited.