Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (18)
Similar a D17316 gc20 l06_dataprot_logtrans
Similar a D17316 gc20 l06_dataprot_logtrans (20)
Último
Último (20)
D17316 gc20 l06_dataprot_logtrans
- 1. 6 Configuring Data Protection Modes and Redo Transport Services Copyright © 2006, Oracle. All rights reserved.
- 2. Objectives After completing this lesson, you should be able to do the following: • Describe the data protection modes • Change the data protection mode of your configuration • Modify redo transport services to serve your needs 6-2 Copyright © 2006, Oracle. All rights reserved.
- 3. Data Protection Modes and Redo Transport Modes • A data protection mode requires a specific redo transport mode. • A redo transport mode alone does not define a data protection mode. 6-3 Copyright © 2006, Oracle. All rights reserved.
- 4. Defining the Redo Transport Mode Use the attributes of LOG_ARCHIVE_DEST_n: • ARCH and LGWR – Specify that either the archiver process or the log writer process is responsible for transmitting redo to the standby destination – ARCH is the default. • SYNC and ASYNC (LGWR only) – Specify that network I/O operations are to be performed synchronously or asynchronously when using LGWR – SYNC is the default. • AFFIRM and NOAFFIRM – Ensure that redo has been successfully written to disk on the standby destination – NOAFFIRM is the default. 6-4 Copyright © 2006, Oracle. All rights reserved.
- 5. 6-5 Copyright © 2006, Oracle. All rights reserved.
- 6. Setting the Redo Transport Mode Click Edit to access the Edit Standby Database Properties page. 6-6 Copyright © 2006, Oracle. All rights reserved.
- 7. Setting the Redo Transport Mode Select the mode from the Log Transport Mode list. 6-7 Copyright © 2006, Oracle. All rights reserved.
- 8. Data Protection Modes • Three data protection modes: – Maximum protection – Maximum availability – Maximum performance • Help to balance data availability and system performance 6-8 Copyright © 2006, Oracle. All rights reserved.
- 9. Maximum Protection • Enables zero data loss • Redo data must be written to both the local online redo log and the standby redo log on at least one standby database. • Primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log. • Configuration requirements: – Standby redo log files on at least one standby database – SYNC, LGWR, and AFFIRM attributes for at least one standby database 6-9 Copyright © 2006, Oracle. All rights reserved.
- 10. Maximum Availability • Enables zero data loss • Provides the highest possible level of data protection without compromising the availability of the primary database • Redo data must be written to both the local online redo log and the standby redo log on at least one standby database. • Primary database does not shut down if a fault prevents it from writing its redo stream. • Configuration requirements: – Standby redo log files on at least one standby database – SYNC, LGWR, and AFFIRM attributes for at least one standby database 6 - 10 Copyright © 2006, Oracle. All rights reserved.
- 11. Maximum Performance • Default level of data protection • Provides the highest possible level of data protection without affecting the performance of the primary database • Transactions can commit as soon as the redo data is written to the local online redo log. • Redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data. 6 - 11 Copyright © 2006, Oracle. All rights reserved.
- 12. Setting the Data Protection Mode Click the Protection Mode link. 6 - 12 Copyright © 2006, Oracle. All rights reserved.
- 13. Setting the Data Protection Mode 6 - 13 Copyright © 2006, Oracle. All rights reserved.
- 14. Setting the Data Protection Mode by Using the CLI • Configure standby redo logs. • Set the LogXptMode property (if necessary). • Set the data protection mode. DGMGRL> EDIT DATABASE 'site1_edrsr8p1' SET PROPERTY 'LogXptMode'='SYNC'; DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; 6 - 14 Copyright © 2006, Oracle. All rights reserved.
- 15. Setting the Protection Mode by Using SQL • You must set attributes to support the type of protection desired. • Issue the ALTER DATABASE statement on the primary database: ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION; 6 - 15 Copyright © 2006, Oracle. All rights reserved.
- 16. Delaying the Application of Redo Delaying the application of redo helps safeguard against: • Data corruption • User errors Oracle Net Delayed application Production Standby database database 6 - 16 Copyright © 2006, Oracle. All rights reserved.
- 17. Using Enterprise Manager to Delay the Application of Redo Specify the delay in minutes. 6 - 17 Copyright © 2006, Oracle. All rights reserved.
- 18. Setting LOG_ARCHIVE_DEST_n to Delay the Application of Redo Use the attributes of LOG_ARCHIVE_DEST_n to control the application of redo: • DELAY: number of minutes to delay application of redo (default: 30 minutes) 6 - 18 Copyright © 2006, Oracle. All rights reserved.
- 19. Using Flashback Database Instead of Apply Delay Standby1 No delay Primary Standby2 database 4-hour delay Standby3 8-hour delay Primary Standby database 6 - 19 Copyright © 2006, Oracle. All rights reserved.
- 20. Additional Attributes That Affect Redo Transport Services • ALTERNATE • DEPENDENCY • MAX_FAILURE • NET_TIMEOUT • REOPEN 6 - 20 Copyright © 2006, Oracle. All rights reserved.
- 21. Using the ALTERNATE Attribute • Can specify one alternate destination for the LOG_ARCHIVE_DEST_n parameter • Allow a failed destination to change destinations – Disk full: switch to new disk – Oracle Net link fails: switch to new network link • Require REOPEN=0 or MAX_FAILURE • Enabled with LOG_ARCHIVE_DEST_STATE_n log_archive_dest_3='SERVICE=stby1_path1 REOPEN=0 ALTERNATE=LOG_ARCHIVE_DEST_4' log_archive_dest_4='SERVICE=stby1_path2 REOPEN=0 OPTIONAL' log_archive_dest_state_3=ENABLE log_archive_dest_state_4=ALTERNATE 6 - 21 Copyright © 2006, Oracle. All rights reserved.
- 22. Using the MAX_FAILURE Attribute MAX_FAILURE[=count] • Number of times redo transport services attempts to reestablish communication • Requires REOPEN • No default count log_archive_dest_3='SERVICE=o10g1 LGWR MAX_FAILURE=30 REOPEN' 6 - 22 Copyright © 2006, Oracle. All rights reserved.
- 23. Using the NET_TIMEOUT Attribute • Enables the LGWR process to avoid a network timeout issue • Valid with SYNC or ASYNC destinations • Value supplied is the number of seconds to wait. • Range of values for NET_TIMEOUT: 15 to 1200 • Default: 180 • Use caution in maximum protection mode. log_archive_dest_2='SERVICE=o10g2 LGWR SYNC NET_TIMEOUT=30' 6 - 23 Copyright © 2006, Oracle. All rights reserved.
- 24. Using the REOPEN Attribute • REOPEN[=seconds] – Minimum number of seconds to wait before retrying a failed destination at log switch – Failures can be network failures, quota exceptions, disk full, and so on. – Default: 300 seconds (5 minutes) • REOPEN=0 – Failed destinations remain disabled until: — Manually reenabled — ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE issued — Instance restart – Required when using ALTERNATE destinations with MAX_FAILURE=0 attributes 6 - 24 Copyright © 2006, Oracle. All rights reserved.
- 25. Optimized Asynchronous Redo Transmission Primary database MRP or transactions LSP Standby (MRP only) database LGWR LNSn RFS Oracle Net Online redo Backup logs Reports FAL ARC0 ARC1 ARC2 Archived redo Archived redo logs logs 6 - 25 Copyright © 2006, Oracle. All rights reserved.
- 26. Enabling Multiple Connections for Remote Archival of Redo The following conditions must be met to enable this feature: • Remote archiving is performed to disk. • LOG_ARCHIVE_LOCAL_FIRST must be set to TRUE (default). LOG_ARCHIVE_DEST_3= 'SERVICE=detroit MAX_CONNECTIONS=5' 6 - 26 Copyright © 2006, Oracle. All rights reserved.
- 27. Summary In this lesson, you should have learned how to: • Describe the data protection modes • Change the data protection mode of your configuration • Modify redo transport services to suit your needs • Delay the application of redo • Use additional transport services attributes 6 - 27 Copyright © 2006, Oracle. All rights reserved.
- 28. Practice 6: Overview This practice covers the following topics: • Changing the data protection mode • Delaying the application of redo 6 - 28 Copyright © 2006, Oracle. All rights reserved.
Notas del editor
- Data Protection Modes and Redo Transport Modes When you define a redo transport mode, you are configuring the shipment of log files from the primary database to the standby database (physical or logical). You must set your redo transport mode to support the protection mode that you want for your configuration. However, configuring the redo transport mode alone does not set up the protection mode. After you set up the redo transport mode, you can put the configuration into the desired data protection mode. The data protection mode setting causes internal rules to be implemented, ensuring that your configuration is protected at the level you desire.
- Attributes of LOG_ARCHIVE_DEST_ n The following attributes of the LOG_ARCHIVE_DEST_ n initialization parameter define the redo transport mode that is used by the primary database to send redo to the standby database: ARCH : Indicates that redo logs are transmitted to the destination during an archival operation. A foreground archival operation or the archiver background processes (ARC n ) serve as the redo log transport service. This is the default. LGWR : Indicates that redo is transmitted to the destination concurrently while the online redo log is being written. The log writer process (LGWR) submits the redo data to one or more network server (LNSn) processes, which then initiate the network I/O in parallel to multiple remote destinations. If a LGWR destination fails, the destination automatically reverts to using the archiver process until the error is corrected. With the LGWR attribute, you have the following additional options: SYNC : Specifies that network I/O is to be performed synchronously for the destination, meaning that once the I/O is initiated, the log writer process waits for the I/O to complete before continuing. ASYNC : Specifies that network I/O is to be performed asynchronously for the destination. In ASYNC mode all network I/O is done completely independent of the LGWR process. Use of the ASYNC attribute allows standby environments to be maintained with little or no performance impact on the primary database.
- Attributes of LOG_ARCHIVE_DEST_ n (continued) AFFIRM : ensures that all disk I/O to the archived redo log files or standby redo log files at the standby destination is performed synchronously and completes successfully. This attribute has the potential to affect primary database performance. When you use the LGWR , SYNC , and AFFIRM attributes, the transaction is not committed until the disk I/O is completed. NOAFFIRM : indicates that all redo disk I/O operations are to be performed asynchronously, which means that the log writer process does not wait until the disk I/O has completed before continuing. This is the default.
- Setting the Redo Transport Mode Use the following procedure to set the redo transport mode by using Enterprise Manager: 1. Select your standby database, and then click Edit on the Data Guard page. 2. Click “Standby Role Properties” on the Edit Standby Database Properties page. 3. Click “Show Advanced Properties.”
- Setting the Redo Transport Mode (continued) You can use the drop-down list to select the redo transport mode on the Standby Role Properties page. The values in the Log Transport Mode list are defined as follows: ARCH : configures redo transport services for your standby database using the ARCH attribute of the LOG_ARCHIVE_DEST_ n initialization parameter. You do not need standby redo log files for this mode. This mode enables the lowest grade of protection to the primary database as well as the lowest performance impact. ASYNC : configures redo transport services for your standby database using the LGWR , ASYNC , and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_ n initialization parameter. This mode, along with standby redo log files, enables a moderate grade of protection to the primary database and incurs a lower performance impact. SYNC : configures redo transport services for your standby database using the LGWR , SYNC , and AFFIRM attributes of the LOG_ARCHIVE_DEST_ n initialization parameter. This mode, along with standby redo log files, is required for the maximum protection or maximum availability protection modes. This redo transport mode enables the highest grade of data protection to the primary database, but it also incurs the highest performance impact.
- Oracle Database 10 g : Data Guard Administration 6 - Data Protection Modes Oracle Data Guard offers maximum protection, maximum availability, and maximum performance modes to help enterprises balance data availability against system performance requirements. In some situations, a business cannot afford to lose data. In other situations, the availability of the database may be more important than the loss of data. Some applications require maximum database performance and can tolerate a potential loss of data.
- Maximum Protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and the standby redo log on at least one standby database before the transaction commits. To ensure that data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log. For multiple-instance RAC databases, Data Guard shuts down the primary database if it is unable to write the redo records to at least one properly configured database instance. To enable maximum protection mode, perform the following configuration tasks: Configure standby redo log files on at least one standby database. Set the SYNC , LGWR , and AFFIRM attributes of the LOG_ARCHIVE_DEST_ n parameter for at least one standby database destination.
- Maximum Availability This protection mode provides the highest possible level of data protection without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to at least one remote standby redo log. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode. This mode guarantees that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database. To enable maximum availability mode, perform the following configuration tasks: Configure standby redo log files on at least one standby database. Set the SYNC , LGWR , and AFFIRM attributes of the LOG_ARCHIVE_DEST_ n parameter for at least one standby database.
- Maximum Performance This protection mode (the default) provides the highest possible level of data protection without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database’s redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the commitment of the transactions that create the redo data. When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance. The maximum performance mode enables you to either set the LGWR and ASYNC attributes or set the ARCH attribute on the LOG_ARCHIVE_DEST_ n parameter for the standby database destination. If the primary database fails, you can reduce the amount of data that is not received on the standby destination by setting the LGWR and ASYNC attributes.
- Setting the Data Protection Mode If the data protection mode that you need requires a standby database to use the SYNC or ASYNC redo transport mode, Enterprise Manager will automatically set the redo transport mode for the primary database and the selected standby databases. Enterprise Manager automatically determines the correct number and size of standby redo log files needed for all databases in the configuration and adds those log files using the directory locations you specify. After you upgrade the protection mode using Enterprise Manager, the primary database will be restarted automatically. The primary database need not be restarted following a downgrade of the protection mode. You can set the data protection mode by using Enterprise Manager as follows: 1. Navigate to the Data Guard page. 2. Click the link in the Protection Mode field to access the Change Protection Mode: Select Mode page.
- Setting the Data Protection Mode (continued) 3. Select Maximum Protection, Maximum Availability, or Maximum Performance, and then click Continue. 4. If prompted, enter the username and password of a user with SYSDBA privileges, and then click Login. 5. Select one or more standby databases to support the protection mode that you selected. If standby redo log files are needed, verify the names of the log files. Click OK. 6. On the Confirmation page, click Yes.
- Setting the Data Protection Mode by Using the CLI 1. If you are setting the protection mode to maximum protection or maximum availability, ensure that standby redo log files are configured on the standby database. You must also configure standby redo log files for the primary database or another standby database in the configuration to ensure that it can support the chosen protection mode after a switchover. 2. Use the EDIT DATABASE SET PROPERTY command to set the redo transport mode for the standby database. For example, if you are changing the data protection mode to maximum availability, use the EDIT DATABASE command to specify SYNC for redo transport services as follows: DGMGRL> EDIT DATABASE 'DR_Sales' SET PROPERTY 'LogXptMode'='SYNC'; You must also set the redo transport services for the primary database or another standby database in the configuration to ensure that it can support the chosen protection mode after a switchover. 3. Use the EDIT CONFIGURATION SET PROTECTION MODE AS command to set the overall configuration protection mode. To set the protection mode to maximum availability, issue the following command: DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
- Oracle Database 10 g : Data Guard Administration 6 - Setting the Protection Mode by Using SQL You must set attributes of the LOG_ARCHIVE_DEST_ n initialization parameter for each level of protection. For each level of protection, you must have at least one standby database with the following: Maximum protection: LGWR , SYNC , AFFIRM , and standby redo logs files Maximum availability: LGWR , SYNC , AFFIRM , and standby redo logs files for physical standby databases Maximum performance: Any combination of LGWR or ARCH Using the following SQL statement on the primary database, you can configure the Data Guard environment to maximize data protection, availability, or performance: ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};
- Delaying the Application of Redo You can delay the application of changes to standby databases, thereby providing protection from user errors or corruptions. You can protect against the application of corrupted or erroneous data to the standby database. The apply process also revalidates the log records to prevent application of log corruptions. For example, if a critical table is accidentally dropped from the primary database, you can prevent this action from affecting the standby database by delaying the application of this change in the standby database. If operating in maximum protection or maximum availability mode, Data Guard will ensure zero data loss even with the delayed apply in effect. If you define a delay for a destination that has real-time apply enabled, the delay is ignored. Note: You can use Flashback Database as an alternative to the Apply Delay configuration option as described later in this lesson.
- Using Enterprise Manager to Delay the Application of Redo You can configure delayed apply by using Enterprise Manager as follows: 1. On the Data Guard page, select your standby database. Then click Edit. 2. On the Edit Standby Database Properties page, click Standby Role Properties. 3. In the Apply Delay field, enter the delay value (in minutes). 4. Click Apply.
- Setting LOG_ARCHIVE_DEST_n to Delay the Application of Redo You can use the DELAY=<minutes> attribute of the LOG_ARCHIVE_DEST_ n initialization parameter to delay the application of archived redo log files to the standby database on the primary database and physical standby databases. Note: If you do not specify a value for minutes , the default is 30 minutes.
- Oracle Database 10 g : Data Guard Administration 6 - Using Flashback Database Instead of Apply Delay As an alternative to the Apply Delay configuration option, you can use Flashback Database to protect against the application of corrupted or erroneous data to the standby database. Flashback Database can quickly and easily flash back a standby database to an arbitrary time in the past. You can configure one standby database with Flashback Database to achieve the same benefit as multiple standby databases with different delays. Refer to the Oracle Database Backup and Recovery Advanced User’s Guide for additional information about Flashback Database.
- Oracle Database 10 g : Data Guard Administration 6 - Additional Attributes That Affect Redo Transport Services The following pages present additional attributes of the LOG_ARCHIVE_DEST_ n initialization parameter that affect redo transport services. The use of each attribute depends entirely on your individual business requirements.
- Oracle Database 10 g : Data Guard Administration 6 - Using the ALTERNATE Attribute You can use the ALTERNATE attribute to specify another LOG_ARCHIVE_DEST_ n destination to be used if archival operations to the original destination fail. A destination can have a maximum of one alternate destination specified. An alternate destination is used when the transmission of redo fails. If the archiving to the destination fails and the REOPEN attribute is specified with a value of zero (0), the Oracle Database server attempts to transmit the redo to the alternate destination on the next log switch. An alternate destination cannot be self-referencing. An alternate destination must be in the ALTERNATE state; this state is specified using the LOG_ARCHIVE_DEST_STATE_ n initialization parameter. The ALTERNATE state defers the processing of the destination until another destination failure automatically enables this destination (provided the alternate destination attributes are valid).
- Oracle Database 10 g : Data Guard Administration 6 - Using the MAX_FAILURE Attribute The MAX_FAILURE attribute of the LOG_ARCHIVE_DEST_ n initialization parameter specifies the maximum number of consecutive times that redo transport services attempt archival operations to a failed destination. Using this attribute, you can provide failure resolution for archiving destinations to which you want to retry archival operations after a failure, but not retry indefinitely. When you specify the MAX_FAILURE attribute, you must also set the REOPEN attribute to specify how often archival operations are retried to the particular destination. If you set both the MAX_FAILURE and REOPEN attributes to nonzero values, redo transport services limit the number of archival attempts to the number of times specified by the MAX_FAILURE attribute. Each destination contains an internal failure counter that tracks the number of consecutive archival failures that have occurred. You can view the failure count in the FAILURE_COUNT column of the V$ARCHIVE_DEST fixed view. The related column REOPEN_SECS identifies the REOPEN attribute value.
- Oracle Database 10 g : Data Guard Administration 6 - Using the NET_TIMEOUT Attribute The NET_TIMEOUT attribute enables you to bypass the default network timeout interval established for the system on which the primary database resides. Without the NET_TIMEOUT attribute, the primary database can potentially stall for the default network timeout period. By specifying a smaller, nonzero value for NET_TIMEOUT , you can enable the primary database to mark a destination as “failed” after the user-specified timeout interval expires. Note: Remember to specify a reasonable value when running in maximum protection mode. False network failure detection may cause the primary instance to shut down.
- Oracle Database 10 g : Data Guard Administration 6 - Using the REOPEN Attribute The REOPEN attribute of the LOG_ARCHIVE_DEST_ n parameter specifies the minimum number of seconds before the process shipping the redo should try again to access a previously failed destination. REOPEN applies to all errors, not just connection failures. These errors include (but are not limited to) network failures, disk errors, and quota exceptions.
- Optimized Asynchronous Redo Transmission In Oracle Database 10 g Release 2, the redo transport mechanism is enhanced to more effectively utilize all of the available bandwidth. A single, large redo log file may be transferred in parallel by multiple ARC n processes. This architecture increases the redo transfer rate and enables faster redo transmission to standby databases for bulk batch updates on the primary database. As a result of the improvement in transfer rates, there is an increased availability of data at the standby database site.
- Enabling Multiple Connections for Remote Archival of Redo The MAX_CONNECTIONS attribute of LOG_ARCHIVE_DEST_n is used to set the number of parallel connections that are used for transmitting archived redo log files to a remote destination. The MAX_CONNECTIONS attribute defaults to 1, indicating that a single connection is established for the communication and transfer of data. The maximum value for MAX_CONNECTIONS is 5. Note: You must set the LOG_ARCHIVE_MAX_PROCESSES initialization parameter to be greater than or equal to the value of MAX_CONNECTIONS to achieve the desired number of parallel connections. If the value of the MAX_CONNECTIONS attribute exceeds the value of LOG_ARCHIVE_MAX_PROCESSES , Data Guard will use the available ARC n processes.