"Go" Oracle 11g Dataguard parameter details

Transferred from: https://www.jb51.net/article/52269.htm

This article mainly introduces the Oracle 11g Dataguard parameters in detail, including the independent parameters, the main library parameters, the library parameters detailed description, the need for friends can refer to.

Note: This article is translated from Oracle Data Guard 11g Handbook Page 78–page 88

As far as Data Guard (DG) is concerned, we only focus on the following three types of parameters:

1. Parameters independent of database roles
2. Parameters when the database role is primary
3. Parameters when the database role is standby

Although DG has a very large number of configuration parameters, we actually use only a few of them, and because now many of the DG features are integrated into the code, the recent DG version of many configuration parameters have been deprecated. It is important to note that the parameters related to the TNS NAMES,LISTENER,SRL (Standby Redo log) file need to be configured in all databases in order to facilitate the role conversion of the database (roles transition). So now let's take a look at these parameters:

I. Parameters unrelated to the role

db_unique_name This parameter defines a unique name for the database. Because the db_name parameter needs to meet the conditions that are consistent with the physical standby database (physical standby) name and the logical standby database (logical standby) name, So in 10g This parameter is introduced to differentiate each database role in the DG configuration. This parameter needs to be configured in all databases and must be restarted for the database to take effect. If you do not configure this parameter, the db_name parameter is used by default, which means that we do not need to close the production library to complete the configuration of the standby database, which we can configure later.

The code is as follows: Db_unique_name= ' Matrix '

log_archive_config This parameter defines the list of db_unique_name parameter values that are available in the DG configuration. When used in conjunction with the db_unique_name values of the target parameters (discussed later), DG uses them to implement security checks for the connection between the two databases. As long as you do not specify the send and receive properties, this parameter is dynamic, and the two properties are left over by the old parameter remote_archive_enable and are no longer needed, so don't use it anymore.

In practice, you only need to add a unique name to the other database to the configuration, and the unique name of the current database will be added automatically according to the scene, but for the sake of clarity and consistency in all databases, the unique names of the current database will be added explicitly. There is no requirement for the configuration order of names, which must be configured in environments with RAC and should always be used.

The code is as follows: Log_archive_config= ' dg_config= (matrix,matrix_dr0) '

Control_files We all know the purpose of this parameter (note: The location of the current database control file), remember that for the standby database, it points to the location of the standby control file (Standby. This control file is created automatically, or created manually, depending on how you create the standby database. (Note: Automatic creation usually occurs when using the Rman feature to generate a standby database, and if you are using a manual method, the control file needs to be copied manually from the main library)

The code is as follows: control_files= '/oracle/oradata/matrix/control01.ctl '

log_archive_max_processes mentions this parameter because its default value is still 2, which is too small. In the main library, the archive process is responsible for archiving the online log files that have already been filled (Redo log) and transferring them as a redo stream (Redo Steam) to the standby database to complete the interval processing (GAP); In the standby repository, the archive process is responsible for archiving the repository log files (Standby Redo LOG) and forward it to its cascading standby database. (Note: Cascading standby database refers to the next level of standby database, that is, the standby of the standby, from here can be seen in any database role, the content of the archive process is the same: 1, archive log files; 2, forward log files to standby)

In the main library, there is an archive process limited to serving online log files, not authorized to communicate with the repository, this particular arch process is known as the "dedicated arch process", and other archiving processes can do both of these functions. When the archive process sends archived log files to the repository, it is not possible to assist in archiving the ORL files; Although the primary instructions for the archive process are "to archive the online log files first, and then to process the master repository interval," in the worst case, there may still be only one archive process in which to archive the task. If there are not enough archive processes in the slow network, there is a large log interval between the primary and standby libraries, and you may have only one process working on the log file. There is a very tricky problem here: If all your log files are already full at this time, the production library will stall until one of the files is archived. The Multithreading interval processing feature (max_connections), introduced in 10g, allows DG to use multiple archive processes to send a single log file to the standby, which means that we will use more of the archive log process, so this parameter must be set at least 4 and the maximum value is 30.

The code is as follows: log_archive_max_processes= ' 4 '

Dedicated arch process for standby library

It is important to note that there is also a "dedicated arch process" in the standby database, but this only means that there is one less archive of SRL files in the repository, and in physical standby, the dedicated arch process does not have the ability to archive SRL files.

One thing to be aware of when using multiple archive processes is that increasing the archive process can reduce the likelihood of a production outage, but a large number of archive processes increase the time of primary standby switching (switchover) because it requires waking up all the archive processes and leaving them out. We can avoid this by lowering the parameter before the switch is executed. In addition, the introduction of the new streaming function (streaming Capability) in 11g, if the log interval between the primary and standby libraries is very large, too much of the archive process transfer will fill the entire network bandwidth.

Db_create_file_dest Although this is not a DG-specific parameter, it still needs to be introduced, because if you use ASM in the repository, this parameter is defined.

The code is as follows: Db_create_file_dest=+data

Second, the main library role parameters

Log_archive_dest_n This is the main parameter of DG Redo log transfer, usually in the main library, and of course there are exceptions, such as the processing of the Cascade repository scenario; This parameter can also be used to specify either an online redo log (ORL) or a standby redo log (SRL) The resulting archive log file transfer destination, but with the introduction of the flash Recovery zone in the 10GR1 version, the locally archived log files are placed by default in the Flashback recovery area, so there is no need to set up a local archive in this case; we'll discuss the local archive and location properties, However, you should have used the flashback recovery area, so you do not need to set the Log_archive_dest_n parameter again.

This parameter has 17 properties, all of which are used to set the main library to the backup of the redo log transfer; in fact, you only need to set 7 of them to make the log transfer work properly; Let's start by introducing these 7 properties and using some examples to illustrate their usage, Then let's explore the remaining 10 properties and their usage scenarios and usage reasons, and we recommend that you do not set 6 of these properties.

The following are the required properties:

The SERVICE specifies the TNSNames descriptor of the repository that has been created, and the early network tuning starts here. (Note: This is a network-related attribute that will be encountered earlier in the DG Setup)

Sync Specifies that the redo data is transferred using the synchronous method, that is, the commit of the client transaction occurs after the LGWR process receives the acknowledgement from the repository LNS, which requires at least one repository (Standby) for maximum available mode and maximum protected mode.

Async defaults, and if no log transport type is specified, the redo data is used asynchronously, which is the log transfer method under Maximum performance mode.

net_timeout Specifies the time that the LGWR process waits for the LNS process to respond, and if no response is received, the standby is considered to be faulted (failed), the default value is 30 seconds, but 10-15 may be a more appropriate value, depending on your network reliability. Do not set this value to 101, or you may not be able to establish a connection after the standby is restored, because it takes a few seconds to reconnect to the repository, so before we do that, we need to do:

1. Stop the old LNS process
2. Start the new LNS process
3. Establish a connection to the standby library
4. Detect and stop the old RFS process
5. Start a new RFS process
6. Select and open a new Srl
7. Initialize the SR header (note: Redo log data for the standby library)
8. Respond to the LNS process to inform that the preparation has been completed

After all these operations are completed, the LNS process will tell the LGWR process that the repository has been successfully connected, and if the process takes longer than the Net_timeout value, LGWR will discard the standby again, and this reconnection will occur every time the log switchover occurs.

REOPEN This property controls the wait time for the main library to attempt to reconnect to the failed standby, which is the default value of 300 (5 minutes), which is usually the reason why you are complaining about the non-reconnection of the primary library at the end of the standby. Generally speaking, the test will be faster, shutdown abort standby, observe the main library alert logs to see if the repository disconnected, and then start the standby library, switch logs in the main library to observe if there is a reconnection, these operations will be completed in 5 minutes, so if you move fast, DG will not be the first time ( or more times) to re-connect during log switching. This property is designed to avoid this situation where, if the repository immediately switches logs after a failure of the repository, the re-connection at this time is likely to fail, so you can consider setting this property to 30 seconds or even 15 seconds, so that DG will be able to complete the re-connect work as soon as possible.

Db_unique_name To use this property in the parameter Log_archive_dest_n parameter requires setting the Log_archive_config parameter at the same time, otherwise the DG will refuse to connect to the target library; the service target (remote Name is the unique name of the database (that is, the standby database) that you use to connect to the other end.

You must add the unique name to the Log_archive_config parameter in the database at both ends. When the main library initiates a connection to the standby, it sends its own database unique name to the standby, requiring the repository to return a unique name. The Log_archive_config parameter will be checked in the repository to ensure that the unique name of the main library exists, and if it does not, the connection request will be rejected, and if present, the repository will return its unique name back to the LNS process of the main library, if the value of the return does not match the value of the property in the main library. The connection will be terminated.

As with the Log_archive_config parameter, this property must be configured in a RAC environment.

Valid_for This is the last property that has to be configured. Although you do not think it is possible for DG to work properly without configuring this property (it does), it is recommended that you use it. The main function of this parameter is to define when to use the target parameter log_archive_dest_n and what type of log file it acts on.

The following are the legal values for the log file:

1.Online_logfile only valid when archiving ORL files
2.Standby_logfile only valid when an SRL file is archived
3.All_logfiles Whether the redo log file type is valid

The following are the legal values for the role:

1.primary_role only takes effect in the main library
2.Standby_role only effective in the standby library
3.All_roles The primary and standby roles are valid

If both arguments are true,valid_for, the target parameter is allowed. (Note: This means that the target parameter will be used when the above two subkeys of Valid_for are true.) For example, set to Valid_for= (Online_logfiles,primary_role) Then if the current database satisfies the conditions of the main library and archives the ORL file, the property settings in Log_archive_dest_n will take effect. With this parameter, we can predefine all the target parameters of all the databases in the DG, and they only take effect when the Valid_for property is true, so there is no need to enable and disable the target when the role is converted.

So what is log_archive_dest_n going to look like? You can set up to 9 targets, which means that we can have up to 9 repositories at a maximum. You can actually use 10, but one is reserved for the default local archive target, which we'll discuss later. Here we use the number 2nd parameter to add a maximum available standby library in Manchester. (modified for display purposes)

The code is as follows:
Log_archive_dest_2= ' Service=matrix_dr0
SYNC reopen=15 net_timeout=15
Valid_for= (Online_logfiles,primary_role)
Db_unique_name=matrix_dr0 '

Now add a repository in Newark as the number 3rd parameter, which has a network delay longer than sync, so this is transmitted in asynchronous mode:

The code is as follows:
Log_archive_dest_3= ' SERVICE=MATRIX_DR1
ASYNC reopen=15
Valid_for= (Online_logfiles,primary_role)
Db_unique_name=matrix_dr1 '

Of course we used the appropriate Db_unique_name property, so we also configure the Log_archive_config parameter:

The code is as follows:
Log_archive_config= ' dg_config= (MATRIX,MATRIX_DR0,MATRIX_DR1) '

The following is an optional attribute:

affirm This is the default value for the target using sync mode. The LNS process is required to wait for the RFS process to complete the direct I/O to the Srl file and return a success message, which is also required to be "highest available" or "Maximum protected" mode, since this property is based on the default value of the target, so you do not need to set it, although in 10g you can specify this property for the Async method But there is no reason for that. In fact, it slows down the LNS process. In 11g, the Affirm property is ignored by the async target.

Noaffirm If not specifically specified, it will be the default value for the async target. For "Maximum performance" mode, it is declared again because it is the default value of async, so it is not necessary to specify it, and if you set the Noaffirm property on the sync target, your protection mode will violate the rules and be marked as "resynchronized". If this is your only sync backup and is in the maximum available mode, you will not be able to fail over 0 data loss (Failover); If this is your only sync target and is in maximum protection mode, setting the Affirm property will crash your main library.

COMPRESSION This property will enable advanced compression for the standby target. By default, this means that any archive process that sends an interval log to the target will compress the archive when it is sent. If you set this hidden property, it also compresses the currently sent redo log stream. For example, if you set this hidden parameter, we will add the compression attribute to the current two target libraries:

The code is as follows:
Log_archive_dest_2= ' Service=matrix_dr0
LGWR SYNC reopen=15 net_timeout=15
Compression=enable
Valid_for= (Online_logfiles,primary_role)
Db_unique_name=matrix_dr0 '

Log_archive_dest_3= ' SERVICE=MATRIX_DR1
LGWR ASYNC reopen=15
Compression=enable
Valid_for= (Online_logfiles,primary_role)
Db_unique_name=matrix_dr1 '

The Matrix_dr0 Target library uses the compression feature only when the arch process sends an archive log for interval processing (not the archive log used to sync Sync), and the MATRIX_DR1 library compresses the redo log from start to finish. This explains that the log does not remain compressed on the disk, because only the logs are compressed during the transfer process, so the data transferred to the repository is decompressed and then written to the Srl file.

Max_connections This property is introduced in 10gr2, which allows you to specify the number of archive processes used for standby interval processing, which has been deprecated in 11g. However, if your version is 10g, you can specify a value of 1-5 (the default value of 1), if you set the value is greater than 1 o'clock, whenever the repository needs to be interval processing, the main library will allocate the corresponding number of archive processes used to send the archive log files, these files are fragmented to these archive processes, It is also transmitted as a parallel stream in the network, and reassembled when it is transferred to the standby repository.

The code is as follows:
Log_archive_dest_2= ' Service=matrix_dr0
LGWR SYNC reopen=15 net_timeout=15
Max_connections=5
Valid_for= (Online_logfiles,primary_role)
Db_unique_name=matrix_dr0 '

Now when the MATRIX_DR0 library disconnects from the main library, the main library's interval processing process will use multiple redo streams for each of the actual archived log files.

Attention:

Do not use in a 11g database? The Max_connections property, which reduces the performance of log transfers.

The Delay property is not a deferred retransmission of data as most imagined, it is simply a log application process that instructs the repository target to apply the redo data after the delay attribute is set for the time (in seconds). With the flashback database, this attribute is almost deprecated, especially since we recommend that you always enable the Flashback database feature in the Master repository. If you are inclined to complete some amount of tasks that the flashback database cannot handle, you may need to set this delay time. The 8th chapter will discuss the flashback database and data Guard.

The ALTERNATE substitution (ALTERNATE) goal was originally intended to keep the database running continuously when the disk space for the ORL log file is full. With an alternative target, you can redirect the archive log file to an alternate disk. With the Flashback recovery area (automatic management space), the problem basically disappears.

If you have multiple network paths to the standby, you can also use this property for remote standby destinations. Obviously, you will use multiple standby network paths in a RAC environment, but this is not the intention of the alternate attribute design. For single-instance or RAC environments with multiple NICs, it is easier to use the connect-time failover in the TNS descriptor of the standby library. (Note: see Connect-time failover)

We recommend that you do not use the following properties:

location Before 10GR2, this property must specify a file position for the archive process to store the archived log files, and this is true for the main library (for ORL files) and for the standby (for SRL files). However, with the use of the Flashback recovery Zone and the default local archive, this property is no longer required. Targets numbered 10 are automatically set to flash back to the recovery area.

The code is as follows:
Sql> SELECT DESTINATION from V$archive_dest WHERE dest_id=10;
Use_db_recovery_file_dest

sql> ARCHIVE LOG LIST
Database Log Mode Archive mode
Automatic Archival Enabled
Archive Destination Use_db_recovery_file_dest
Oldest online log sequence 19
Next Log sequence to archive 21
Current Log sequence 2

If you are using the Flashback recovery area and you want to define a local target, you should use the same syntax:

The code is as follows:
Log_archive_dest_1= ' Location=use_db_recovery_file_dest
Valid_for= (Online_logfiles,primary_role)
Db_unique_name=matrix '

If you are still not using the Flashback recovery area, you can also use the old disk path notation:

The code is as follows:
Log_archive_dest_1= ' location=/u03/oradata/matrix/arch/
Valid_for= (Online_logfiles,primary_role)
Db_unique_name=matrix '

Note that in both cases, the Db_unique_name is the database that you defined on the target (note: That is, where the archive is stored), not the remote standby repository. In the example above, the archive location target is on the matrix library, so if you want to use the Db_unique_name property here, you need to specify the value of the matrix as db_unique_name.

Attention:

If you use the Flashback recovery area, do not use the Location property to specify the local archive position.

MANDATORY This is one of the most dangerous properties on the standby. Basically, it specifies that the redo information in the ORL file must be sent to the repository. If the redo information cannot be sent to the standby, the Orl file containing the redo information in the main library will not be reused (reuse) until it is successfully sent to the repository. Imagine that when the repository is inaccessible and all the available log files in the main library are traversed, the production system will stall. Of course, there is a local target that is mandatory to keep the file on disk, but there is no need to set another one. By default, a target in the local archive is set to mandatory.

Attention:

Do not set the mandatory property.

Max_failure This property is one of the most misunderstood of all attributes. People tend to think that this property represents the number of times the LGWR process reconnected the repository before discarding the failed standby and continuing to generate the log. This is not the case, if you set this property, it is actually defined the number of times the log group switches when LGWR attempts to re-connect the failed standby (note: The original text is more easily misunderstood, this means to switch the log once, re-attached to the library). For example, if the value of Max_failure is set to 5, then LGWR will initiate a total of 5 connection requests to the repository during its cyclic switchover of the log, and if it switches 5 times or fails to connect to the repository, then LGWR will discard the reconnection. After that you either wait for the property to re-enable it manually or wait for the main library reboot to take effect.

Attention:

Do not set the Max_failure property.

Noregister This is the last property of the Log_archive_dest_n parameter that we discussed. By default, the DG requires that any redo data sent to the repository need to be registered to the standby when it is archived to disk. For a physical repository, it means that the data is registered in the control file of the repository, and for the logical repository it means that SQL apply registers the log file in the metadata. DG does not need this attribute, it can be used in the streams target library that uses the downstream feature.

Attention:

Do not set the Noregister property.

Log_archive_dest_state_n This is the parameter used with the Log_archive_dest_n. In the past, there are two reasons why we need to configure it. One is to enable the pre-defined log_archive_dest_n parameter of the master role in the repository so that the archive process can use Log_archive_dest_n to work when the parameter is enabled, and another reason is to configure a alternate target as described earlier. The first reason has no effect (now using valid_for), and unless you use it? Alternate attribute, otherwise the second reason is not true, because now this parameter is enable by default, you no longer need to set it for your target library.

The code is as follows:
Log_archive_dest_state_1=enable

Third, alternate role parameters

Db_file_name_convert in the repository, this parameter allows you to logically migrate data files from the main library to the standby, if you are using a disk-based storage structure and the storage path is not the same on both systems, then it is necessary to configure it. This conversion is only performed when the standby is switched to the primary library. These values are written to the control file and the data file header once the primary and standby switch or failover to the standby is made. Functions can be implemented with simple character substitution.

The code is as follows:
Db_file_name_convert= '/matrix/', '/matrix_dr0/'

The above command will have the following data file name:

The code is as follows:
'/U03/ORADATA/MATRIX/SYSAUX.DBF '

Convert to:

The code is as follows:
'/U03/ORADATA/MATRIX_DR0/SYSAUX.DBF '

Similarly, the following configuration points the data file to the +recovery disk group instead of the +data;

The code is as follows:
Db_file_name_convert= ' +data ', ' +recovery '

The rest of the path will remain the same, in this case, ASM is used to create the repository, and you do not need to define this parameter.

Log_file_name_convert It has the same function as the Db_file_name_convert parameter, except that it converts the log file, including the Orl file and any SRL files.

The code is as follows:
Log_file_name_convert= '/matrix/', '/matrix_dr0/'

Fal_server The FAL (Fetch Archive Log) feature has made a lot of progress compared to the DG at 9ir1. It is used only for the physical repository, which allows the physical repository to get the missing archive log file from a database in the DG configuration (main or standby) in the case of a problem discovery, and sometimes we turn it into a passive interval processing (reactive gap resolution), However, FAL technology has been greatly enhanced in the previous three versions so that it is almost no longer necessary to define the FAL parameter. With the use of active interval processing (proactive gap resolution) technology introduced by the 9IR2 version, almost any type of interval request on a physical or logical standby can be handled by the ping process on the main library.

During the normal operation of the main library, the archive process (which is designated as a ping process) will take turns querying all the repositories to find the redo interval, while processing any unresolved interval requests from any application process. FAL technology can be used when the physical standby needs to obtain the interval files from a database outside the main library. For example, if the physical standby now needs to be spaced, but the main library is inaccessible, it needs to request additional repositories to complete the interval processing, so you define the Fal_server parameter as a list of TNS identifiers that point to the main library or any repository. Include the main library (Matrix) and other standby libraries (MATRIX_DR1) in the MATRIX_DR0 library:

The code is as follows:
Fal_server= ' Matrix, Matrix_dr1 '

fal_client The FAL client is the TNS name of the database initiating the interval request, and the receiver of the interval request (Fal_server) needs the TNS name so that the database on the FAL server can be connected back to the requester. On the standby matrix_dr0, we send Matrix_dr0 as the client name so that the matrix and MATRIX_DR1 libraries can connect back to the MATRIX_DR0 library to send the missing archive log files.

The code is as follows:
Fal_client= ' Matrix_dr0 '

' matrix_dr0′ must be defined in the TNS file of the FAL server so that the DG can successfully connect to the repository, because we will set the redo transfer parameters in all of these databases, so we also need to configure the TNS name for them. If you use the same TNS name in the FAL parameter, these TNS names are defined as well. If you choose a different name, you will need to add the name to the TNS file for all systems. As with the Fal_server parameter, the fal_client parameter is only valid for the physical standby.

Standby_file_management This is the last parameter discussed in this section. This simple parameter is only used for the physical standby library. When this parameter is set to auto, the data files are added and deleted in the main library, and the corresponding changes are made automatically in the repository. As long as the top-level directories in the repository exist or can be aided by db_

The File_name_convert parameter is found, then DG executes the DDL statement to create the data file in the standby repository. It will even create the missing subdirectories as much as possible. By default, the value of this parameter is manual, which means that the application process on the standby does not create new data files and you need to create them manually.

The code is as follows:
Standby_file_management= ' AUTO '

We may set this parameter to manual only if you need to perform a definition operation on the ORL file on the physical standby. The Srl file can be added without changing this parameter. If you really want to add or delete online log files on the physical standby (for example, because of changes on the main library), you can also dynamically set this parameter to manual, perform DDL operations, and revert to auto value without restarting the repository.

Summary of parameters and attributes

After understanding all of the parameters and attributes above, you should have a deep understanding of their features and features and can be used correctly.

I hope you don't get a headache with this, because one thing you might be surprised at: If you use Data Guard Broker (even without a grid Control), you don't have to configure these parameters yourself, DG Broker will do everything for you.

--END--

"Go" Oracle 11g Dataguard parameter details