首页 > Linux操作系统 > Linux操作系统 > 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 性能不够好
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/10248702/viewspace-629919/ ,如需转载,请注明出处,否则将追究法律责任。