Oracle 18c使用dbca创建级联DG

0    137    1

Tags:

👉 本文共约15430个字,系统预计阅读时间或需59分钟。

配置完结果:

【DG】Oracle之级联DG--(cascade dg) --(一主一备一级联)

dataguard 一主一备一级联,意思是主库将日志传输给备库,然后备库在将日志传输给级联库,主库和级联库其实没有任何关系。另外,在Oracle 11g中,关于数据同步问题,主库上的操作一般情况下是可以实时同步到备库的,但是级联库必须等备库归档时,才能同步。如果主库切换日志,那么这时级联库也能及时同步。

Oracle 11g的级联备库是不支持实时应用的,要等源库日志切换后才会应用。Oracle 12c的级联备库支持实时应用。

在11.2及以上版本支持级联备库,就是第二备库从第一个备库接受redo日志,而不是直接从主库接受redo日志。

这样会减少主库的压力。实际上和正常搭建DG没什么区别,只是改一下参数即可。

最多支持30个级联备库,因为LOG_ARCHIVE_DEST_n,只有31个。

更多详细信息,参考官方文档:

Oracle 级联DG部署以及切换测试:

https://blog.csdn.net/weixin_36239782/article/details/91316703

1 说明

A standby database that cascades redo to other standby databases can transmit redo directly from its standby redo log file as soon as it is received from the primary database. Cascaded standby databases receive redo in real-time. They no longer have to wait for standby redo log files to be archived before redo is transmitted.

启用real-time redo,不需要等归档standby redo日志文件,然后再传输到级联备库上。

As of Oracle Database 12c Release 1 (12.1), a cascading standby database can either cascade redo in real-time (as it is being written to the standby redo log file) or non-real-time (as complete standby redo log files are being archived on the cascading standby).

从12c开始,支持real-time级联redo(等写入备库redo log)。

限制:

Only physical standby databases can cascade redo.

Real-time cascading requires a license for the Oracle Active Data Guard option.

Non-real-time cascading is supported on destinations 1 through 10 only. (Real-time cascading is supported on all destinations.)

If you specify ASYNC transport mode on destinations 1 through 10, then redo is shipped in real-time. If you do not specify a transport mode or you specify SYNC on destinations 1 through 10, then redo is shipped in non-real-time. Destinations 11 through 31 operate only in ASYNC (real-time) transport mode.

在用于级联的备库中的LOG_ARCHIVE_DEST_n(1…10)指定ASYNC,则是real-time。如果不指定,或者指定SYNC,则是non-real-time。

LOG_ARCHIVE_DEST_n(11…31)只支持ASYNC,即real-time传输模式。

oracle 12c 支持实时级联同步了,很11g不支持 There are new Possibilities for cascading Standby Databases in Oracle 12c. The main Differents between Oracle 12c and the previous Releases are: 1. Real-Time Cascading 2. Far Sync Standby Database 3. Data Guard Broker now supports cascaded Standby Database


12c 的 Cascaded Standby 数据库 (文档 ID 2179701.1)

适用于:

Oracle Database - Enterprise Edition - 版本 12.1.0.1 和更高版本
Oracle Database Cloud Schema Service - 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine - 版本 N/A 和更高版本
Oracle Cloud Infrastructure - Database Service - 版本 N/A 和更高版本
Oracle Database Cloud Exadata Service - 版本 N/A 和更高版本
本文档所含信息适用于所有平台
Checked for relevance on 13-Jul-2015

用途

这篇文档解释了 Cascaded Standby 在 oracle 12c 上的增强特性。

详细信息

Oracle 12c 的 cascading standby 数据库为用户增加了更多的选项。12c 的版本对比以前的版本增加了以下的新选项:

  1. 实时 Cascading
  2. Far Sync Standby 数据库
  3. Data Guard Broker 提供对 cascading standby 数据库的支持

但是,你还只能从配置 physical standby 数据库去 cascade 另一个 standby 数据库。 目前 logical standby 数据库还不支持 cascade 另一个 standby 数据库。

实时 Cascading:

新版本现在支持以实时的模式将 redo 从第一个 standby 数据库传递到 cascaded standby 数据库。因此在第一个 standby 数据库,Redo 的信息会在被写到 Standby Redolog 后立即传递到 cascaded standby 数据库。

而非实时 Cascading 意味着:只有主库的 log Switch 之后,整个 log sequence 才会被传递到最终的 Standby 数据库上。

先决条件:

  • 第一个(Cascading)standby 数据库必须是物理的或者是 Far Sync Standby 数据库
  • 必须保证至少在 Cascading standby 数据库上使用 Standby Redolog
  • Active Data guard 的选项必须是有 license 的
  • Primary,Cascading,Cascaded standby 数据库的 db_unique_name 必须体现在所有数据库 log_archive_config 的 dg_config 中

设置:

首先 ,创建一个通常的 Dataguard 环境到 cascading standby 数据库。Log 的传输模式应该为 SYNC,同时在 cascading standby 配置 Standby Redolog。在创建完 cascaded standby 数据库以后就可以设置 cascading log 的传输服务了,下面是一些注意事项:

  • Primary,Cascading,Cascaded standby 数据库的 db_unique_name 必须体现在所有数据库 log_archive_config 的 dg_config 中。
  • 在 Cascading standby 数据库的 log_archive_dest_n 里面设置 ‘valid_for=(STANDBY_LOGFILES,STANDBY_ROLE)’ 的属性来传输给 cascaded(最终)standby 数据库。
  • 你可以通过设置 Log Transport 的模式来切换实时以及非实时的 cascading 模式:

ASYNC = Real-Time Cascading

SYNC = Non Real-Time Cascading

  • 你只可以设置从 log_archive_dest_1 到 log_archive_dest_10 作为非实时模式的目的地,而你可以在 cascading standby 数据库上设置所有的 log_archive_dest_n 作为实时 cascading 的目的地。
  • Cascading Standby 数据库可以运行在任何保护模式下。
  • Cascading Standby 数据库可以传输给一个或者多的 terminal standby 数据库。
  • Cascading Standby 数据库的 FAL_SERVER 应该设置为 primary 库或者是其他的 primary 直接连接的 standby 数据库。
  • Terminal Standby 数据库的 FAL_SERVER应该设置 cascading Standby 数据库或者 Primary 数据库。

Far Sync Standby 数据库:

Far Sync Standby 数据库对于 Terminal standby 数据库来说是作为一个 RedoLog repository 数据库的作用。他不含有任何的数据文件。Far Sync Standby 数据库只是启动了 Log 传输服务。Far Sync Standby 数据库的优点是它可以作为 Primary 数据库的一个在最大保护模式下的本地的 ArchiveLog Repository,而 Physical 和 logical standby 数据库可以运行在远端,请参考文档:

Note 1565071.1: Data Guard 12c New Feature: Far Sync Standby

来了解具体的关于 Far Sync Standby 数据库内容以及设置的步骤。

Data Guard Broker 和 Cascaded Standby 数据库:

Data Guard Broker 有一个新的‘RedoRoutes’的属性可以用来构建和部署 cascaded Data Guard Broker 的配置。 以下是它的格式:

RedoRoutes = ‘( : )’

Redo Source: Redo 的来源,他可以是 db_unique_name 或者是一个本地数据库名别名的 ‘LOCAL’-Keyword(不能被 Far Sync Standby 数据库使用)

Redo Destination: Redo 从这个数据库传输到的目的地。他可以是一个或者多个(用逗号分开)db_unique_name 或者是代表所有在 Data Guard Broker 配置中可能目的地的别名的‘ALL’-Keyword。 你可以设置到目的地的传输的模式。包括以下:

  • SYNC: 等同于 log_archive_dest_n 中的属性 ‘SYNC AFFIRM’ 或者是非实时 Cascade
  • ASYNC: 等同于 log_archive_dest_n 中的属性 ‘ASYNC’ 或者是 实时 Cascade
  • FASTSYNC : 等同于 log_archive_dest_n 中的属性 ‘SYNC NOAFFIRM’

例子:

Primary Database: prim

Cascading Standby Database: local_stdby

Cascaded (terminal) Standby Database: remote_stdby

如果想实现’SYNC NOAFFIRM’的本地 standby 数据库和在实时 cascade 模式下的远程 standby 数据库,设置如下:

Primary Database (prim)

RedoRoutes = ‘(LOCAL : local_stdby FASTSYNC)’

-> Primary 数据库只传送 Redo 到 local Standby 数据库,但是有到远程 standby 数据库的 Archive 目的地。

Local Standby Database (local_stdby)

RedoRoutes = ‘(prim : remote_stdby ASYNC)’

-> 这里需要配置来源于 ‘prim’的 REDO 是以实时 cascade(ASYNC)的方式转发到远程的 Standby 数据库。

参考

NOTE:1565071.1 - Data Guard 12c New Feature: Far Sync Standby

Cascaded Standby Databases in Oracle 12c (文档 ID 1542969.1)

In this Document

Purpose
Details
Real-Time Cascading
Prerequisites
Setup
Far Sync Standby Database
Data Guard Broker and Cascaded Standby Database
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.1 and later
Information in this document applies to any platform.
Checked for relevance on 13-Jul-2015

PURPOSE

This Documents explains the Enhancements for Cascaded Standby Databases in Oracle 12c.

DETAILS

There are new Possibilities for cascading Standby Databases in Oracle 12c. The main Differents between Oracle 12c and the previous Releases are:

  1. Real-Time Cascading
  2. Far Sync Standby Database
  3. Data Guard Broker now supports cascaded Standby Database

However, you can still only cascade a Standby Database from a Physical Standby Database. It is not supported to cascade a Standby Database from a Logical Standby Database.

Real-Time Cascading

It is now possible to forward Redo in Real-Time Mode from the first to the cascaded Standby Database. So the Redo Record is forwarded to the cascaded Standby Database once written into a Standby RedoLog of the first Standby Database.

Non Real-Time Cascading means that the whole Log Sequence is transferred to the terminal Standby Database(s) after a Log Switch on the Primary Database.

Prerequisites

  • First (Cascading) Standby must be a Physical or Far Sync Standby Database
  • Standby RedoLogs must be in Place and used at least on the Cascading Standby Database
  • Active Data Guard Option must be licensed
  • Primary, Cascading and Cascaded Standby Database db_unique_name must be present in the dg_config of log_archive_config on all the Databases

Setup

First of all setup a Data Guard Environment as usual to the cascading Standby Database. The Log Transport Method should be ‘SYNC’ and Standby RedoLogs must be configured on the cascading Standby Database. Once you created the cascaded Standby Database you can now setup the cascading Log Transport Services. Here are some Hints for correct Setup:

  • Primary, Cascading and Cascaded Standby Database db_unique_name must be present in the dg_config of log_archive_config on all the Databases
  • Setup log_archive_dest_n on the cascading Standby Database to serve the cascaded (terminal) Standby Databases using the Attribute ‘valid_for=(STANDBY_LOGFILES,STANDBY_ROLE)’
  • You can toggle between Real-Time and Non Real-Time Cascading using the Log Transport Method.

ASYNC = Real-Time Cascading

SYNC = Non Real-Time Cascading

  • You can only use log_archive_dest_1 until log_archive_dest_10 for Non Real-Time Cascading Destinations where all log_archive_dest_n’s can be used for Real-Time Cascading on the Cascading Standby Database
  • The Cascading Standby Standby can be in any Protection Mode
  • A Cascading Standby Database can serve one or multiple terminal Standby Databases
  • FAL_SERVER on the cascading Standby Database should be set to the Primary or any other Standby Database served by the Primary Database directly
  • FAL_SERVER on the terminal Standby Database should be set to the cascading Standby Database or the Primary Database

Far Sync Standby Database

A Far Sync Standby Database is a cascading Standby Database which acts as a Redo Log Repository for a Terminal Database. It does not contain any Datafiles. Only Log Transport Services are active on a Far Sync Standby Database. The Advantage of a Far Sync Standby Database is that it can be a local ArchiveLog Repository for the Primary Database acting in Maximum Protection Mode where the Physical or Logical Standby Database can be on a far remote Site. See

Note 1565071.1: Data Guard 12c New Feature: Far Sync Standby

for further Details and Setup of a Far Sync Standby Database.

Data Guard Broker and Cascaded Standby Database

There is a new Data Guard Broker Property called ‘RedoRoutes’ used to build and implement a cascaded Data Guard Broker Configuration. It has the following Format:

RedoRoutes = ‘( : )’

Redo Source: This is the Source the Redo is coming from. It can be a db_unique_name or the ‘LOCAL’-Keyword which is an Alias for the local Database Name (Cannot be used for a Far Sync Standby Database)

Redo Destination: This is the Destination where the Redo is shipped to from this Database. It can be one or more (comma separated) db_unique_name’s or the ‘ALL’-Keyword which is an Alias for all possible Destinations inside the Data Guard Broker Configuration. Optional you can also specify the Transport Method to be used to the Destination. This can be

  • SYNC: corresponds to log_archive_dest_n Attributes ‘SYNC AFFIRM’ or Non Real Time Cascade
  • ASYNC: corresponds to log_archive_dest_n Attribute ‘ASYNC’ or Real Time Cascade
  • FASTSYNC : corresponds to log_archive_dest_n Attributes ‘SYNC NOAFFIRM’

Example:

Primary Database: prim

Cascading Standby Database: local_stdby

Cascaded (terminal) Standby Database: remote_stdby

We want to serve the local Standby Database with ‘SYNC NOAFFIRM’ and the remote Standby Database in Real-Time Cascade Mode. So the Setting would be:

Primary Database (prim)

RedoRoutes = ‘(LOCAL : local_stdby FASTSYNC)’

-> So the Primary Database only ships Redo to the local Standby Database, but has Archive Destination to the remote Standby Database

Local Standby Database (local_stdby)

RedoRoutes = ‘(prim : remote_stdby ASYNC)’

-> Here we configure that the Redo coming from ‘prim’ is forwarded in Real-Time Cascade (ASYNC) to the remote Standby Database

REFERENCES

NOTE:1565071.1 - Data Guard 12c New Feature: Far Sync Standby

FAL_SERVER And FAL_CLIENT Settings For Cascaded Standby (文档 ID 358767.1)

In this Document

Goal
Solution
References

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

APPLIES TO:

Oracle Database - Enterprise Edition - Version 9.2.0.1 to 11.2.0.4 [Release 9.2 to 11.2]
Information in this document applies to any platform.
Checked for relevance on 27-Sep-2012
Checked for relevance on 10-Dec-2015

GOAL

How to configure the FAL_CLIENT and FAL_SERVER parameters in cascaded standby setup.

FAL_SERVERspecifies the FAL (fetch archive log) server for a standby database. The value is an Oracle Net service name, which is assumed to be configured properly on the standby database system to point to the desired FAL server.

FAL_CLIENTspecifies the FAL (fetch archive log) client name that is used by the FAL service, configured through the FAL_SERVERparameter, to refer to the FAL client. The value is an Oracle Net service name, which is assumed to be configured properly on the FAL server system to point to the FAL client (standby database). Given the dependency of FAL_CLIENTon FAL_SERVER, the two parameters should be configured or changed at the same time.

You can read about the cascaded redo log solution in

Note 409013.1: Cascaded Standby Databases in Oracle 10g/11g

SOLUTION

For simplification the following 3 service names are assumed, and assume all these 3 service names are available at all the 3 sites tnsnames.ora file (primary,cascaded standby and remote standby) in the same form.

dg_prim -> primary database
dg_standby_cas -> cascaded standby database
dg_standby_rem -> the remote standby database.

Assuming the above configuration the parameter needs to be the following:
At primary:

Primary will never will have gap, so no need for any fal* parameter here.

At cascaded standby

Cascaded when has gap, can only get the archive logs from the primary
database. Hence the fal_server parameter. It wants the primary to send the FAL
request response to 'dg_standby_cas', hence fal_client setting.

At remote standby database:

Remote standby when has gap, can get the archive logs from the primary
database or cascaded standby database. Hence the fal_server parameter. It wants
the primary to send the FAL request response to 'dg_standby_rem', hence
fal_client setting.

Note: If primary receives a FAL request from the remote standby in the above case then It ships the archive logs directly to the remote standby without going via cascaded standby. FAL_CLIENT is obsolete in Oracle 11.2.0 and is not required any more


REFERENCES

NOTE:1537316.1 - Data Guard Gap Detection and Resolution Possibilities
NOTE:409013.1 - Cascaded Standby Databases in Oracle 10g/11g

Cascaded Standby Databases in Oracle 10g/11g (文档 ID 409013.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 9.0.1.0 to 11.2.0.1 [Release 9.0.1 to 11.2]
Information in this document applies to any platform.
Checked for relevance on 02-OCT-2014
checked for relevance '23-Nov-2015'

GOAL

The information below replaces Appendix E Cascaded Destinations of Oracle Data Guard Concepts and Administration 10g Release 2 (10.2) part number B14239.

This information also applies to Oracle10g Release 1 and Oracle9i releases.

For information on Cascaded Destinations in Data Guard 11g Release 1, please see Appendix E here.

For 11g Release 2, see Chapter 6 Redo Transport Services :-

Please note that as of Version 11.2.0.2 many of the restrictions with cascaded standby databases have been lifted. Please refer to the documentation link above for up to date information in 11.2.0.2 and cascaded standby databases.

SOLUTION

Summary:

The significant changes from the previous Oracle Database 10g Release 2 documentation include:

  1. Cascading logical standby databases from a logical standby database is not supported.
  2. Cascading standby databases (logical or physical) from a primary database that is part of an Oracle Real Application Cluster (RAC) is not supported (This restriction has been lifted in 11.2.0.2)
  3. Using Cascaded standby databases in a Data Guard Broker environment is not supported.

Details:

To reduce the load on your primary system, or to reduce the bandwidth requirements imposed when your standbys are separated from the primary database through a Wide Area Network (WAN), you can implement cascaded destinations, whereby a standby database receives its redo data from another standby database, instead of directly from the primary database.

In a Data Guard configuration using a cascaded destination, a physical standby database can forward the redo data it receives from the primary database to another standby database. Only a physical standby database can be configured to forward redo data to another standby database. A logical standby database cannot forward redo to another standby database.

You cannot set up a physical standby to forward redo if the primary database is part of an Oracle Real Application Cluster (RAC) (lifted as of 11.2.0.2) or part of a Data Guard Broker environment.

The following Data Guard configurations using cascaded destinations are supported.

  1. Primary Database > Physical Standby Database with cascaded destination > Physical Standby Database
  2. Primary Database > Physical Standby Database with cascaded destination > Logical Standby Database

While a logical standby database cannot forward redo to another standby database, it can be configured to have its own physical standby database. In such a case, the physical standby database is not considered a Cascaded Destination because it does not receive redo that is forwarded from the primary database. Instead, it is receiving redo generated by the logical standby. However this can only be used for Rolling Upgrades since a failover to the Logical standby database's Physical standby would not result in a new Logical Standby. Instead it would become another Primary and no longer be part of the original Data Guard configuration.

A physical standby database can support a maximum of nine (30 as of Version 11.2) remote destinations. When a cascaded destination is defined on a physical standby database, the physical standby will forward redo it receives from the primary to a second standby database after its standby redo log becomes full and is archived. Thus, the second standby database receiving the forwarded redo as a result of a cascaded destination will necessarily lag behind the primary database.

Oracle recommends that cascaded destinations be used only for offloading reporting or for applications that do not require access to data that is completely up-to-date with the primary system. This is because the very nature of a cascaded destination means that the standby database that is the end-point will be one or more log files behind the primary database. Oracle also recommends that standby databases whose primary role is to be involved in role transitions receive their redo data directly from the primary database.

The remainder of this note contains information about the following:

  • Configuring a cascaded destination
  • Role transitions in the presence of a cascaded destination
  • Examples of cascaded destinations
  1. Configuring a Cascaded Destination

    To enable a physical standby database to forward incoming redo data to a cascaded destination perform the following steps:

    • Create standby redo log files on the physical standby database (if not already created).

      • If standby redo log files are not already defined, you can define them dynamically on the standby database. The standby database will begin using them after the next log switch on the primary database.
    • Define a LOG_ARCHIVE_DEST_n initialization parameter on the primary database to set up a physical standby database that will forward redo to a cascaded destination.

      Define the destination to use:

      • LGWR ASYNC or
      • LGWR SYNC

      Optionally, set the VALID_FOR attribute so that redo forwarding is enabled even after a role transition happens between the original primary database and the intermediate standby database that is forwarding redo. This may be meaningful in cases where the databases are separated over Wide Area Networks.

    • Ensure that archiving is enabled on the physical standby database where the cascaded destinations are defined (the standby database that will forward redo).

    • Configure a LOG_ARCHIVE_DEST_n parameter (on the physical standby that will forward redo data) for each cascaded destination.

    Below are the initialization parameters for a primary database named Boston, which sends redo to a physical standby database named Chicago, that forwards the redo it receives to a cascaded standby database named Denver. In this example, the database named Denver is a logical standby database, but note that a physical standby database can forward redo to either a physical or a logical standby database.

    When the cascaded destination is a logical standby database, remember that you will create it just as if the logical standby will be directly connected to the primary database (see Chapter 4 Creating a Logical Standby Database of Oracle Data Guard Concepts and Administration 10g Release 2).

    Boston Database (Primary Role)

    DB_UNIQUE_NAME=boston
    STANDBY_ARCHIVE_DEST=/arch1/boston/
    REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
    LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
    LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver'
    LOG_ARCHIVE_DEST_3='SERVICE=chicago VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'

    Chicago Database (Standby Role)

    本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!
    Oracle 18c使用dbca创建级联DG后续精彩内容已被小麦苗无情隐藏,请输入验证码解锁本站所有文章
    验证码:
    请关注本站微信公众号,回复“小麦苗博客”,获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。

标签:

Avatar photo

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部