Hi,

I will continue to tell Oracle Dataguard Architecture in this post.

 

Oracle Dataguard Architecture 

 

Read second article before this article.

 

Oracle Dataguard ( Standby ) Architecture -2

 

 

Physical Standby Architecture

 

1.Maximum Performance: This mode is the default mode for the first installation in Dataguard. In this mode, ASYNC (Asynchronous) Dataguard method is used because the performance of the Primary database is very important.

That is, LGWR process sends commit information to the user without waiting for confirmation of the Redo data sent from the standby database.

 

2.Maximum Availability: Dataguard provides zero data loss in this mode. The configuration that provides zero data loss is SYNC (Synchronous) Dataguard configuration, as I mentioned above. In this mode, Commit information is not sent without being applied to Standby when the user send a commit for a transaction.

If there is any communication problem between the Primary database and the Standby database, dataguard waits for a certain time. If the communication problem is not solved within this period, LGWR process interrupts the connection with the LNS process and returns commit information to the user. The parameter that the database specifies for a certain period of time is the NET_TIMEOUT parameter. This parameter allows the database to be hanged.

 

3.Maximum Protection: This mode is like the Maximum Availability feature I described above and uses SYNC Dataguard configuration. There is only one difference between them and the NET_TIMEOUT parameter is not used in this mode, ie the LGWR process will wait for the information from the LNS process that the Redo data has been applied to Standby, If it is not applied then Commit information is not sent to the user.

In this mode, the primary database will consistently wait for information from Standby so dataguard may be hang after a period of time. To prevent this situation, usually create more than one standby database. It is enough that  has been applied to any database. In this method it is important for Primary to use more than one Standby because the possibility of Hang is reduced.

 

let’s look at the parameters that the Oracle database for Dataguard has to offer. The parameters and functions common to both primary and Standby are as follows.

 

 

• DB_UNIQUE_NAME: Each database should be unique, so each database separates from its db_unique_name parameter with each other. So Primary and Standby database have different and db_unique_name in the Dataguard Configuration. The DB_NAME parameter should be the same for both database (Primary and Standby ), but DB_UNIQUE_NAME must be different.
• LOG_ARCHIVE_CONFIG: This is the parameter that specifies the DB_UNIQUE_NAME of the databases selected for the Dataguard configuration. First, the primary database DB_UNIQUE_NAME is written, then standby databases are written.For Example log_archive_config = ‘dg_config = (DEVECI, DEVECIDG)’
• LOG_ARCHIVE_MAX_PROCESSES: This is one of the important parameters for Dataguard configuration. As it is understood by its name, it determines the maximum number of ARCH processes that the database can use.By default, this parameter’s value is 2 in the first installation, ie 2 ARCH processes are active and one of these processes is archiving Online Redolog files which are only filled and assigned for this. Therefore, two ARCH processes in the initial installation are inadequate for our database.The reason for the inadequacy of the ARCH process is the Archiving of both the filled online Redo logs and the Redo Gap between the Primary and the Standby. The maximum value of this parameter is 30, but I don’t suggest you use this much as long as you don’t need it. I usually update the number of this parameter to 4 in the first installation, then monitor the database and change it if needed.

 

There are many other parameters that are used for dataguard except for the parameters I described above. Some of them are only used for the Standby database, some of them are only Primary and the important ones and functions are as follows.

 

• LOG_ARCHIVE_DEST_n: This parameter is an important parameter used for the Primary and standby database. It is a parameter required to send Redo data from the primary database to the Standby (s). The value n is 0 to 31 for this parameter. The parameter log_archive_dest_1 shows the location of the Archive logs of the Primary database, and the  Log_archive_dest_2 are configured for the first Standby. If you used 2 Standby database, then you should use Log_archive_dest_3 parameter.
• DB_FILE_NAME_CONVERT: An important parameter used on the standby side. On the standby side, If the location of the Datafiles on the Primary side is different then it can convert if it is different. This parameter is especially important when switchover operation is required.
• LOG_FILE_NAME_CONVERT: This is the parameter that is the same as the parameter above, only those made for Datafiles above are made for Online Redolog files with this parameter.
• FAL_SERVER: This parameter is an important parameter for dataguard. FAL stands for Fetch Archive Log. As the name suggests, when Redo GAP is occurred between Primary and Standby, we determine which Server to take the archive logs by this parameter.

 

I will show you how to install dataguard step by step in the next post.

Oracle DataGuard Physical Standby Installation Step by Step Using RMAN -1

 

 

 

 

Do you want to learn Oracle Database for Beginners, then read the following articles.

Oracle Tutorial | Oracle Database Tutorials for Beginners ( Junior Oracle DBA )