DST Patch in Active Standby Environment

Different software components (operating systems, databases, etc.) are updating our clocks automatically when our country changes the clock (when daylight saving starts or ends). In order to do that, the system has to know the date for the daylight saving. This is the DST information.

Countries, however, keep changing their decision about daylight saving. Some cancel it completely, some just change the start/end date. Because of this we have to keep the DST configuration up to date. To be honest, we usually don’t, but if you use the TIMESTAMP WITH TIMEZONE datatype and your, or your client’s, country is one of those who changed their DST, you will find out that the time you see in the system is not the correct one. When this happens, we install a DST patch in the database so it will have the correct information and show the correct time.

DST patch installation

In my case, my environment is 11.2.0.4 (with latest PSU), with ASM and active standby.
DST patch installation is quite simple. It requires a downtime (and it’s important to know it’s not a rolling upgrade for RAC). You install the patch with OPatch, then run the upg_tzv_check.sql script and finally the upg_tzv_apply.sql (which will restart the database twice). This is all documented in the patch README. What is not mentioned anywhere is what to do with the standby database.
Standard (standby first) patching goes like this:

1. Install the patch using OPatch on the standby
2. Install the patch using OPatch on the primary
3. Run any scripts on the primary (as they applied automatically to the standby through the log apply)

But here, I had a bad feeling. The fact that the README doesn’t state that this is a “standby-first” patch, and the fact that standby is not mentioned anywhere in MOS, got me thinking about what could go wrong. So I opened an SR and the engineer in the SR said that I should just install it (standby first, then primary, like any other regular patch). We scheduled the patch and I got everything ready.

The problem

After I patched both servers and executed the SQL scripts I noticed that the standby is not being synchronized:

1. DGMGRL showed that the redo apply is down
2. The drc<ORACLE_SID> file showed “Redo Apply is running without USING CURRENT LOGFILE option while DelayMins=0”
3. Then I saw this in the alert log: “ORA-10485: Real-Time Query cannot be enabled while applying migration redo”

When I checked it, I realized that the DST patch starts the database in upgrade mode, but redo logs that were generated while the database is in upgrade mode cannot be applied to an active standby database.
Then I found MOS note 1618485.1, which explains how to overcome this:

1. Disable DG broker
   
2. Shutdown the database
3. Start the database in MOUNT
4. Execute “alter database recover managed standby database disconnect;”
5. Verify the the archives were applied and the standby is synchronized
6. Start the database in OPEN and enable DG broker

What I didn’t test (and I might, as I have a few more environments that I need to patch) is to use DGMGRL to disable the active standby and convert it to regular standby before the patch and check if it will work without any problem. If I do that I’ll update this post.

Update

In the next patch installation, I tried something else. Before starting the entire process I disabled the real time apply (stopped the apply, shutdown the database and started it in MOUNT and started the apply). Only then I installed the patch. After the patch was installed, I made sure the standby was completely synchronized and enables the real time apply. It worked and this proves that the problem was applying the migration log only when real time apply was active. If it is a regular standby (in MOUNT) there is not problem installing patches on the primary that require STARTUP UPGRADE.