Shulou(Shulou.com)06/01 Report--

(HADR) replication operation:

High availability disaster recovery (HADR) uses database logs to copy data from the primary database to the standby database. When replaying the logs on the standby database, some activities may cause the standby database to lag behind the primary database. Some activities require a large number of records, and the large number of log files they generate can cause storage problems. Although using logs to replicate data to a standby database is the core of the availability strategy, the record itself can have a negative impact on the availability of the solution. Properly design maintenance strategies, configure the system to minimize the negative impact of logging, and allow logging to protect your transaction data.

Data definition language (DDL)

Data manipulation language (DML)

Buffer pool operation

Tablespace operation

Online reassembly records all operations in detail

Offline reorganization usually records operations by hundreds or thousands of affected lines

Metadata for stored procedures and user-defined functions (UDF) (but not related objects or library files)

During the online reorganization process, all operations are recorded in detail. As a result, HADR can replicate operations without making the standby database lag further behind than it does when making more typical database updates. However, because a large number of logging records are generated, this behavior may have a significant impact on the system.

If offline reorganization is not recorded as much as online reorganization, operations are usually recorded by hundreds or thousands of affected lines. This means that the standby database will lag behind because it waits for each log record and then replays many updates immediately. If the offline reorganization is non-clustered, a single log record is generated after the entire reorganization operation. This method affects the ability of the standby database to keep synchronized with the primary database to the greatest extent. After the standby database receives log records from the primary database, the entire reorganization process is performed.

HADR does not copy stored procedures, UDF objects, and library files. Files must be created on the same path in the primary and standby databases. If the standby database cannot find the referenced object or library file, the stored procedure or UDF call on the standby database will fail

(HADR) No replication operations: high availability disaster recovery (HADR) uses database logs to copy data from the primary database to the standby database. The primary database allows operations without logging, but does not replicate such operations to the standby database. If you want to reflect unlogged operations in the standby database (for example, updates to history files), you must perform additional steps to achieve this.

The following are examples of situations in which operations on the primary database are not replicated to the standby database:

Tables created with the NOT LOGGED INITIALLY option specified will not be replicated. Attempting to access such a table after the HADR standby database takes over the primary database will result in an error.

All LOB columns that have been logged will be copied. Unlogged LOB columns will not be copied. However, space will be allocated to them on the standby database, with binary zeros as the value of the column.

Updates made to the database configuration using the UPDATE DATABASE CONFIGURATION (Update Database configuration) and UPDATE DATABASE MANAGER CONFIGURATION (Update Database Management configuration) commands are not replicated.

Database configuration parameters and database manager configuration parameters are not replicated.

For user-defined functions (UDF), changes made to objects outside the database, such as related objects and library files, are not replicated. You need to set them up on the standby database in other ways.

The recovery history file (db2rhist.asc) and changes made to it are not automatically copied from the primary database to the standby database.

By issuing the RESTORE DATABASE command with the REPLACE HISTORY FILE option, you can place the original copy of the history file (obtained from the backup image of the primary database) on the standby database:

RESTORE DB KELLY REPLACE HISTORY FILE

After initializing HADR and then performing backup activities on the primary database, the history file on the standby database is out of date. However, a copy of the history file is stored in each backup image. You can update the history file on the standby database by using the following command to extract the history file from the backup image:

RESTORE DB KELLY HISTORY FILE

Do not use regular operating system commands to copy history files in the database directory from the primary database to the standby database. When copying, if the primary database is updating the history files, those files will be corrupted.

If a takeover operation is performed and the standby database has the latest history file, the backup and restore operations performed on the new primary database generate new records in the history file and are fully mixed with the records generated on the original primary database. If the history file is out of date or missing entries, automatic incremental recovery may not be possible; instead, you will need to perform a manual incremental recovery operation.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.