Physical Standby Setup-SINGLE NODE

In today’s article, we will talk about Physical Standby Setup-SINGLE NODE.

1. We query the status of the listener to see which services are running in the primary database.

2.

3. We query the contents of the Listener.ORA file.

4.We query the contents of the SQLNET.ORA file to see which naming methods are in the primary database.

5. We query which services are registered in the TNSNAMES.ORA file.

6.We add the TNSNAMES method to the SQLNET.ORA file. We use NETMGR for this.

a. By connecting to the server from the terminal, switching to the Oracle user and running netmgr.

b. We check the “Profile” settings.

c. We extract the EZCONNECT method in the “Selected Methods” section.

The reason why HOSTNAME is not added directly is because the order of Methods is wanted to be made as TNSNAMES-HOSTNAME-EZCONNECT. Otherwise, as we will see below, no method would be active.

ç. First we add HOSTNAME and then EZCONNECT to “Selected Methods” .

d. Save the changes made in the “File” section and exit.

e. We check whether the change is reflected in the SQLNET.ORA file.

7. Services are added to the TNSNAMES.ORA file that will enable Clients to automatically connect to Standby when Physical Standby and Primary cannot be accessed. We use NETMGR for this.

a. By connecting to the server from the terminal, switch to the Oracle user and run netmgr.

b. In the window that opens, with the Service Naming tab active, click the Create button with the “+” sign.

In our configuration, the Service Naming field will not be that much service. There will be only 1 service. It seems too much here because it was made for testing purposes.

c. We write “standby” in the Net Service Naming field.

ç. We choose “TCP/IP” as the network protocol.

d. As Hostname, we write “prod.tivibulab.local”, which is the Hostname of the Primary database, and “1521” as the Port.

The hostname is learned as follows.

e. Select “standby” as Service Name and “Dedicated Server” as Connection Type.

f. With Finish, we complete the service creation process

g. The service is configured. Click on the Advanced button.

ğ. We write “32767” in the Session Data Unit field. This value increases the network throughput. Normally, this value is 64KB for 12cR1, but we enter 32767 because NETMGR does not support this value. It will then be edited manually.

h. Send and Receive Buffer Sizes are set for the network throughput. We make this adjustment accordingly.

This value is compared to 10 MB. Whichever is greater is entered.

Let’s calculate.

Network Bandwidth= 1 Gbit/s
Latency=0.288 ms [This value can be seen by pinging the Primary Far SYNC instance, where it sends the Redos from the Primary]

TCP Socket Buffer size= 1,000,000* (1/8) * 0.288*(1/1000)s * 3 = 108 bytes

Therefore, the value of 10MB=10*1024*1024=10485760 bytes is written to the “Show Advanced” section of each 2 Adress Configuration section.

In our configuration, there will be only one Address in the “Address Configuration” field. Here, there are 2 for testing purposes.

ı. We write “prmy” in the Net Service Naming field.

i. Settings are saved by clicking “Save” in the “File” section.

j.We choose “TCP/IP” as the network protocol.

k. As Hostname, we write “prod.tivibulab.local”, which is the Hostname of the Primary database, and “1521” as the Port.

l. We choose “prmy” as Service Name and “Dedicated Server” as Connection Type.

m. With Finish, we complete the service creation process.

n. The service is configured. Click on the Advanced button.

o. We write “32767” in the Session Data Unit field. This value increases the network throughput. Normally, this value is 64KB recommended for 12cR1, but 32767 is entered because NETMGR does not support this value. It will then be edited manually.

ö.The database that will be primary in the role change is added to the Address Configuration field. We do this with the + sign.

p. As the hostname, we write the Target Standby database information of Switchover and Failover. We write “standby.tivibulab.local” as the Hostname and “1521” as the Port.

r. Send and Receive Buffer Sizes are set for the network throughput. We make this adjustment accordingly.

TCP Socket Buffer size=BDP*3=network bandwidth*latency*3

This value is compared to 10MB. Whichever is greater is entered.

Let’s calculate.

Network Bandwidth= 1 Gbit/s
Latency=0.288 ms [This value can be seen by pinging the Primary Far SYNC instance where it sends the Redos from the Primary]

 

TCP Socket Buffer size= 1,000,000* (1/8) * 0.288*(1/1000)s * 3 = 108 bytes

Therefore, we write the value of 10MB=10*1024*1024=10485760 bytes in the “Show Advanced” section of each 2 Adress Configuration section.

s. Similarly, the SDU_UNIT and SEND-RECV_BUF_SIZE parameters of the PROD service are edited.

ş. We save it by clicking “Save” in the “File” section of the settings.

t. We change the SDU value to “65535”. For this, open the TNSNAMES.ORA file with the vi text editor and run the following command.

u. We check whether the change is reflected in the TNSNAMES.ORA file.

8. Copy the TNSNAMES.ORA file to the Standby database.

9.we check if the file goes to the Standby database.

1. Copy the SQLNET.ORA file to the Standby database.

2. We check if the file is in the Standby database.

3. Edit the LISTENER.ORA file.

a. We set it for the Default LISTENER network throughput. We edit the SEND and RECV_BUFSIZE as stated above.

b. The change is saved.

The reason for this error is that this value cannot be set as 10485760 in NETMGR. Therefore, the value 65535 is set. Then we open the file from the vi text editor and edit it.

c. Click on “Database Services” and add Static listener. This is because RMAN and Broker can open the database when the database is closed.

ç. As the first service, we add the Primary database.

d. We add the second database from the “Add Database” tab.

e.The second database’s name has a format. This format is <instance_name>_DGMGRL_<domain_name>. It is added in accordance with this format.

f. Changes made are saved in the “File” section.

g. We check the correctness of the changes in the LISTENER.ORA file.

ğ.We optimize the BUF_SIZE parameters. We open the file with vi and make the necessary adjustments.

h.We’ll check if there’s any change.

I. By RELOAD the Listener, we ensure the permanence of the changes.

i. We check the status of the Listener to see if the services have started.

j. Similar arrangements are made in the standby database. But there is no LISTENER.ORA because there is no database installed in Standby yet. We can also see this when checked from NETMGR.

k.A listener named LISTENER is created.

l. After the Listener is created, we initialize the Listener for the persistence of the changes. The RELOAD command will give an error because there is no LISTENER running here, so it cannot be STOPed. Therefore, the START command is executed.

4. Since I don’t want the database to start automatically when the server with the standby database reboots, I make the necessary adjustments in /etc/oratab.

5. We check if the change is reflected.

6. It is ensured that everything is logged in the primary database.

7. We learn the number of Online Redo Logs in the primary database.

8. Standby Log Files are created in the primary database. The reason why this was created in Primary is to be ready before the role change processes.

The reason for creating one more than the number of Online Redo Logs is that the Log Switch process in the Primary database is not kept waiting due to the slowness that will occur due to Network or other reasons, because the Redo’s go late to the Standby side.

9. We check whether the Standby Log Files are created.

10. We set where the archives to be created in the primary database will be saved.

11. We set the parameter to send the archives to the specified location. Although this parameter is already ENABLE in Default, we set it again for discipline.

12.We set the number of archive processes.

13. We specify which databases the Data Guard Environment will consist of.

14. We ensure that datafiles and online redo logs to be added to the Primary are automatically added to the Standby side.

15. Necessary directories are created on the standby side.

16. In order for the standby database to be duplicated with RMAN, it must be in the NOMOUNT step.

2 parameters are required to bring a database to NOMOUNT. One of them is DB_NAME and the other is DB_DOMAIN.

With a PFILE with these parameters, the database can be brought to NOMOUNT. Other parameters take their default values in memory.

We do not use the DB_DOMAIN parameter. If we were to use it, we would run the following command.

17. Copy the Primary’s Password file to the Standby side.

18. We NOMOUNT by connecting to the standby database.

19. On the standby side, we connect to RMAN as TARGET as Primary database and as Standby database as AUXILIARY.

20. Primary database is DUPLICATED

The cause of the error is that the Primary database is not in Archive mode.

21. We put the Standby databases in archive mode in order to prepare for Primary and Role change operations.

a. We query the archive mode states of the databases.

b. The size of the archive area is set to a suitable value according to our disk size.

c. We’ll check if the change has taken place.

ç.We put databases in archive mode.

d. We’ll check if they switch to archive mode.

e.We initialize the primary database.

f. Since some of the RMAN command was running, the database was switched to MOUNT mode and SPFILE was created. Therefore, the database is closed and the SPFILE file is deleted, and then we move on to the NOMOUNT step.

22. We restart the RMAN command.

23. We query the status of the standby database.

24. We check the mode of the database.

25. We ensure that the Archive Redo Logs go to the Standby database.

26. The installation process of our standby database is completed. Now we get to the controls.

a. We learn the current log sequence number.

b. We check whether the logs go to Standby by performing the Log Switch operation.

27. Logs go to Standby successfully, but we check if they are being applied.

MANAGED

It means Archive Apply, not Real Time. In other words, as the logs come to the Standby side, the apply process will take place.

28. Since I want Standby to be active very quickly in the event of a disaster, I activate the Real-Time Apply feature.

29. By creating a table, it is checked whether it is formed on the standby side.

The reason for this error is that the Database is not in OPEN mode. That is, Active Data Guard is not ENABLE.

30. Considering that we have a license, the database is transferred to Active Data Guard.

a. We stop the Log Apply process.

b. We open the database.

c. We query the instance’s status.

ç. We query the role with the database’s open mode.

d. We query Recovery Mode.

e. We start Real Time Apply.

f. We are checking if Real Time Apply has started.

g. We check whether the table created in Article 37 is formed on the Standby side.

31. I want to take backups from standby side. For this reason, we make the necessary parameter adjustments so that Incremental Backups can be taken faster and without tiring the system.