Friday , December 2 2022

Upgrade With Physical Standby

The database upgrade stages with almost zero interruption from the current Data Guard configuration Single Node Primary and Physical Standby are as follows.

1. We set up a Physical Standby database.

2. We are preparing Primary and Standby databases for Upgrade. For this, the first thing to do is to activate the Flashback database in both databases.

Flashback database must be activated in Primary. Because the main flashback before starting one of the steps, upgrade, will be returned.

In the standby database, the reason for commissioning is to return to the guarantee restore point that we will create our system in case of possible failure.

a. We are querying whether the Flashback Database feature is enabled.

b. We activate Flashback Database in primary database.

c. We activate Flashback Database in standby database.

d. We are questioning whether Flashback Database is activated in databases.

3. We define Restore Points in Primary and Standby databases.

a. We are making identification in the primary database.

b. We are making identification in the standby database.
4. The Physical Standby database is converted to a Logical Standby database. The only difference in the conversion process is that the “KEEP IDENTITY” statement will be used.

This means that although Physical Standby is converted to Logical, it is temporary, so it should not forget its ID (DB_NAME and DB_ID) and will be converted back to Physical.

a. We create a LogMiner dictionary in the primary database so that SQL Apply can correctly interpret the transactional changes.

b. Redo Apply is stopped in the standby database and the instance is put into MOUNT mode.

c. The Physical Standby database is converted to Logical.

This command just waits without any feedback at this stage. The reason is that it searches for LogMiner Dictionary in logs. For this reason, LogMiner Dictionary is created again in the Primary database.

As soon as the PL/SQL Procedure is completed, the conversion command to Logical is also completed.

d. The conversion process is concluded by opening the database.

e. We pass to the controls.

f. By creating a table in the primary database, we check whether it is reflected in the Standby database.

5. Automatic deletion of Foreign Archive Logs is disabled, in case of need during the upgrade.

6. Preparations before Upgrade are completed in the Logical Standby database.

a. Sending logs to Logical Standby is prevented.

b. By stopping SQL Apply, a guaranteed restore point is defined.

c. We are creating some tables to see that the transactions coming during the upgrade are processed to Logical Standby after the SQL Apply is started after the Upgrade.

d. We create the paths where the new version will be installed.

7. 12cR1’s Software is installed on Logical Standby.

8. Go to 12cR1’s ORACLE_HOME/bin directory and run DBUA.

9. We question whether the upgrade has taken place.

10. The log flow from the Primary database to Standby is provided again and it is questioned whether the Standby database is SYNC with the Primary.

a. Log flow of Primary to Standby is started.

b. SQL Apply starts on the standby database.

c. We check whether the tables created in Primary during the upgrade are formed in Standby.

d. The Primary’s Standby and SYNC are checked.

11. We question whether the logs go from Primary to Standby without any problems.

a. Existing Log sequence numbers are queried.

b. Log Switch operation is performed in Primary.

c. We are checking whether the logs go to Standby.

12. Logical Standby, which is passed to 12cR1 with Switchover, is made Primary and Standby is made in Primary, which is 11gR2.

a. We question the compatibility of Primary with Switchover.

b. Primary database is converted to Standby.

c. We question the suitability of Logical Standby to Primary.

d. Converted to Logical Standby Primary.

e. We pass to the controls.

f. Tables are created in the new Primary.

13. The new Logical Standby database is flashbacked to the Restore Point taken before the Upgrade. The reason for this operation is to initially bring the database to the moment of the Physical Standby database before it is pulled to Logical.

Thus, when I complete the conversion from Logical to Physical, the old Primary database will be a Physical Standby that came before the Upgrade.

a. We get the original Primary database MOUNT mod.

b. Restore Point’s information is learned.

c. We are doing a flashback to Restore Point.


14. In the original Primary database, the paths where 12cR1 will be loaded are created.

15. 12cR1’s Software is installed in the original Primary database.

16. We are editing some files as there is no 12cR1 database in the Original Primary database yet.

a. There are no files like LISTENER, TNSNAMES. We copy such files to new paths.

b. It is organized according to Bash Profile 12cR1.

c. Bash Profile is enabled to be active. We check if the change has taken place.

17. In the new Software location, we connect to the database and MOUNT.


18. It turns out that the error is related to the control file locations. The control file location is reduced to one and the problem is solved by changing its name.

19. The original database is now converted to Physical Standby.

20. The database is closed and taken to the MOUNT step.

21. We are checking whether the database has passed to Physical Standby.

22. It is ensured that the logs come from Primary to Standby and Redo Apply is started.


There are some points to check when redos are not sent. These are, respectively,


a. We check the TNSNAMES.ORA file in Primary.

b. It is understood that there is no Standby and the Standby database is added to TNSNAMES.

c. Good versions of these files are sent to the Standby database.

d. On the standby side, we update the LISTENER.ORA file.

e. Listener STOP is START.

f. With all these operations, the logs were sent to Standby successfully and there were no errors left in the logs. We check whether the logs go to the standby side.

23. Redo Apply is started and with this process, 12cR1 Upgrade in Standby database is completed.


24. The standby database is opened and it is seen whether the tables have come or not.

25. We check if the upgrade is running smoothly in both databases.





Starting the recovery just by typing “disconnect” came in 12c. This is proof that we have passed to healthy 12c.

26. Compatible parameters of databases are increased.

a. We DROP Restore Point in Standby.

b. We change the Compatible parameter.

c. We close and open the database.

d. We check for changes.

e. We are querying the Restore Points in Primary.

f. Restore Points in Primary are DROPed.

g. We change the Compatible parameter.

h. By closing the database, the parameter is activated.

I. We check for changes.

27. Summary of All Our Work



Author: Onur ARDAHANLI


Leave a Reply

Your email address will not be published. Required fields are marked *