DG學習筆記(1)_入門介紹

DG學習筆記(1)_入門介紹

 

目錄

 

1 What is Oracle DataGuard ?

2 Why Oracle DG ? Oracle DG 帶來哪些好處?

3 physical standby database and logical standby database

4 three types of services

5 three data protection mode

6 Operational Requirements

7 Standby Database States

8 Data Guard Interfaces

9 Notes

 

1 What is Oracle DataGuard ?

Oracle Data Guard is the management, monitoring, and automation software that works with a production database and one or more standby databases to protect your data against failures, errors, and corruptions that might otherwise destroy your database.(DG其實也是一種軟體)

 

The Primary purpose of Oracle9i Data Guard is to keep your data highly available against any event, including disasters; it is complementary to traditional backup, restore, and clustering techniques.(DG主要目的,是維護資料的高可用性,是作為備份,叢集的一個補充. )

 

2 Why Oracle DG ? Oracle DG 帶來哪些好處?

 

2.1 Enhancing high availability and disaster protection using standby databases.

加強了高可用性

 

2.2 Offering there protection mode to help you balance data availability against performance requirements.

提供了不同的保護模式來平衡資料的可用性與效能.

 

2.3 Centralizing and simplifying management.

集中化管理

 

2.4 Continuous service through a disaster or crippling data failure.

災難時的業務連續服務和零資料丟失.

配置簡單. 但DG並不能帶來業務的不中斷,當Primary當機時,還是會出現業務中斷.

而RAC,則可解決部分主機的當機.但不能提供零資料丟失.

 

RAC provides high availability, and DG provides disaster protection and prevents data loss.

 

RAC + DG 是比較完美的組合.

3 physical standby database and logical standby database

 

3.1 Physical standby databases

 

A physical standby database is physically identical to the primary database, with on-disk database structures that are identical to the primary database on a block-for-block basis. The physical standby database is updated by performing recovery (Redo Apply) on the redo information that is received from the primary database. It can either be recovering data or open for read-only reporting.

 

Physical standby databases provide the following benefits:  

物理Standby的優勢:

1)  Support for all DDL and DML

支援所有的DDL 和DML 操作,沒有任何額外的限制.

 

2)  Provides better apply performanc than Logical Standby Database.

 

3)  Off-loading backup operation from primary.

在Standby上做的備份可以給Primary使用,從而可減輕Primary的負擔

 

4) Report generation

 

 

3.2 Logical standby databases

 

A logical standby database is logically identical to the primary database. The logical standby database is updated by using SQL Apply. This is done with the use of the LogMiner technology on the log information received from the primary database. The tables in a logical standby database can be used simultaneously for recovery and for other tasks such as reporting, summations, and queries.

 

Oracle9i introduces logical standby databases, which answers Oracle users’ requests for a standby database that provides data protection while simultaneously satisfying additional reporting requirements.(Oracle 引入Logical的初衷就是滿足使用者同時查詢的要求)

 

Although the logical standby database is open in read/write mode, its target tables for the regenerated SQL are available only in read-only mode for reporting purposes. Logical standby databases support reporting because changes are applied to the database from the redo logs using SQL statements. Although the tables built from regenerated SQL are available in read-only mode for reporting purposes, a logical standby database using additional indexes and materialized views can provide optimized query performance.(邏輯Standby可以用以做Report,但也是有限制的)

 

邏輯Standby帶來的優勢:

 

1) Efficient use of system resources

2) Decision support

Because the data in a logical standby database can be presented with a different physical layout, you can create additional indexes and materialized views to suit your reporting and query requirements.

 

In this release of Oracle9i, some datatypes and DML operations cannot be maintained in a logical standby database. Before setting up a logical standby database for disaster recovery, you must make sure the logical standby database can maintain all of the datatypes and tables in your primary database.

(邏輯Standby不支援某些資料型別, 這是其中的一個限制)

 

3.3 Redo Apply 與 SQL Apply到底有何實質的區別.

 

Apply 過程具體是怎麼樣實現的?

Redo Apply:

Redo is applied to each standby database using standard Oracle recovery techniques.(標準的Oracle recovery技術,是怎麼樣的? because a recovery operation applies changes block-for-block using the physical row ID.)

 

SQL Apply:

Data Guard SQL Apply uses redo information shipped from the primary system. However, instead of using media recovery to apply changes,archived redo log information is transformed into equivalent SQL statements by using LogMiner technology.

 

同樣傳輸Redo log到Standby,但不是透過Media Recovery技術來應用日誌,而是將日誌透過LogMiner Technology轉換成SQL Statements,再執行相應的SQL Statements.

 

 

4 three types of services

 

4.1 Log Transport Services

 

Controls the automated transmittal of archived redo logs from the primary database to one or more standby database’s or destinations.(Log Transport Services只傳輸歸檔日誌,而不傳輸線上日誌?  不是的)

 

4.2 Log Apply Services:

 

Controls when and how the redo logs will be applied to the standby database.

Apply the archived redo logs to a physical standby database when it is performing recovery (for example, in managed recovery mode), but not when it is open for reporting access (for example, in read-only mode).

Apply the archived redo logs to a logical standby database by converting the redo data into SQL statements and applying them to an open logical standby database.

 

4.3 Role Management Services

 

A database operates in one of two mutually exclusive roles: primary or standby. Role management services operate in conjunction with the log transport services and log apply services to change these roles dynamically as a planned transition called a switchover operation, or as a result of a database failure through a failover operation.

 

 

5 three data protection mode

 

5.1 Maximum Protection

 

Maximum protection mode offers the highest level of data availability for the primary database, ensuring a comprehensive zero-data loss disaster recovery solution. When operating in maximum protection mode, redo records are synchronously transmitted from the primary database to the standby database, and a transaction is not committed on the primary database until it has been confirmed that the transaction data is available on at least one standby database. This mode is usually configured with at least two standby databases, thus offering double failure protection. If the last participating standby database becomes unavailable, processing automatically halts on the primary database as well. This ensures that no transactions are lost when the primary database loses contact with all of its standby databases. This is only available with a physical standby.

 

5.2 Maximum Availability

 

Maximum availability mode has the next highest level of data availability for the primary database, offering zero data loss and protecting against single component failures. As with the maximum protection mode, redo data are synchronously transmitted from the primary database to the standby database. The transaction is not committed on the primary database until it has been confirmed that the transaction data is available on the standby database. However, if a standby database becomes unavailable – say, because of network connectivity problems, processing continue on the primary database. The standby database may temporarily diverge from the primary database, but when it is available again, the databases will automatically synchronize, and no data will be lost. This is available for both physical and logical standbys.

 

5.3 Maximum Performance

 

Maximum performance mode is the default protection mode. It offers slightly less primary data protection, but higher performance, than maximum availability mode. In this mode, as the primary database processes transactions, log data is asynchronously shipped to the standby database. This can be done by either the LGWR or ARCH. The commit operation of the primary database does not wait for the standby to acknowledge receipt before completing the write on the primary. If any standby destination becomes unavailable at any time, processing continues on the primary database and there is little or no effect on performance. In the case of a failure of the primary database, there may be some transactions that were committed on the primary database that had not completed shipping to the standby database. If the network has sufficient throughput to keep up with peaks in log traffic, the number of lost transactions should be very small.(最大效能,預設模式,非同步傳輸日誌.日誌的傳輸可以透過LGWR或ARCH. )

 

 

6 Operational Requirements 操作的要求

6.1 Primary database must run in ARCHIVELOG mode.

 

6.2 Use the same database release, operating system, and hardware architecture.

相同的資料庫版本和作業系統版本,但發行版本可以不一致, 硬體結構必須一致,都是32bit或64bi,也就是說不能做異構的DataGuard.

 

6.3 Each database must have its own control file

 

If both database are on the same system, make sure the OS allows you to mount two instances with the same database name. (怎麼確認是否支援兩個同樣的資料庫名呢? Unique_dbname ?? 沒做過lock_name_space引數)

 

6.4 Turn on FORCE LOGGING at the primary before taking datafile backups for standby creation.

 

 

7 Standby Database States 備庫的不同狀態

 

For Physical standby databases

Managed Recovery Mode

In this mode, log transport services archives logs to the standby database, and log apply services automatically applies these logs. The database is in the MOUNT state, no reads on the data are possible.

 

Open Read-Only Mode

Log apply services cannot apply archived redo logs to the standby database when it is in this mode, but primary database continues to ship redo to the standby database.

 

For Logical standby databases

Open Read-Write Mode

In this mode, log apply services continue to manage the application of log information from archived redo logs. In addition the database is open for reporting. 日誌應用與查詢可以同時進行. Users are not allowed to perform. DML on the tables in the schemas that the log apply service is updating.But users could modify database objects in other schemas that are not being maintained by the log apply service.

 

8 Data Guard Interfaces

You can use the following interfaces to configure, implement, and manage a standby database:

8.1 SQL statements

 

8.2 Initialization parameters

 

8.3 Oracle9i Data Guard Manager

 

8.4 Oracle9i Data Guard command-line interface

 

8.5 RMAN

 

 

9 Notes

 

1 如何配置不同的模式?

只是在引數選擇上有所不同而已.

 

2 不同的模式下日誌傳輸有什麼區別?

日誌傳輸的時機不一樣.

 

 

3 既然邏輯Standby可以同時用以作為查詢庫,為什麼不配置成邏輯方式呢.而是配置成物理方式呢? 邏輯方式究竟在哪方面有問題,而大家不採用呢?

 

主要問題:

1 邏輯庫對有些資料型別不支援

 

2 效能不夠好