oracle adg与dg区别12c adg 逻辑standby支持吗

后使用快捷导航没有帐号?
查看: 111|回复: 1
UID帖子阅读权限20精华贴数技术排名15193 专家积分1 社区排名2570165 技术积分200 社区积分0 注册时间
精华贴数专家积分1 技术积分200 社区积分0 注册时间
论坛徽章:3
Oracle 11G,搭建了ADG后把Rman备份丢到了standby库上执行了,现在想吧定期的EXP备份也放standby上去执行,但是测试过程中会出现ora-01555快照过旧的问题。
这个不太好理解了,ADG Readonly,undo retention也不会产生约束力,怎么会产生这个报错?
如果想继续保持逻辑备份的实现,是否应该先停止归档应用后再exp。
UID267265帖子阅读权限100精华贴数技术排名36 专家积分318 社区排名221 技术积分44591 社区积分12745 注册时间
精华贴数专家积分318 技术积分44591 社区积分12745 注册时间
论坛徽章:164
逻辑备份要保持一致性,你最好停止应用,再备份.
好好学习,天天向上!
:&&nbsp&&nbsp&&nbsp&&nbsp&&nbsp
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有    
 北京市公安局海淀分局网监中心备案编号: 广播电视节目制作经营许可证:编号(京)字第1149号That’s Me
Exadata Database Machine 2014 Certified
Oracle Certified Professional
7.3, 8i, 9i,10g, 11g, 12c
11i Apps DBA OCP
10g RAC OCE
Certified GoldenGate Implementation Specialist
Oracle Enterprise Manager 12c Certified Implementation Specialist
Oracle 11g Exadata Implementation Specialist
Thanks A MILLION for your support!
Please your valuable feedback and suggestions
Categories
Recent Posts
Administration
This note examines how to create an Oracle 12.1.0 physical standby Active Data Guard database using the RMAN DUPLICATE FROM ACTIVE command.
We will be creating the data guard configuration in a 12c Container Database.
Remember – in 12c Data Guard is set up at the Container level and not the individual Pluggable database level as the redo log files only belong to the Container database and the individual pluggable databases do not have their own online redo log files.
In my next post we will examine how to unplug a pluggable database from a Container database not having Data Guard set up and how easy it is to provide high availability for a pluggable database by just plugging it into a container database which has Data Guard configured.
The platform is Linux 64 bit OEL 5.9 and the primary database db_unique_name is CONDB1 and the db_unique_name of the Active Standby database is CONDB1_DR.
Let us look at the steps involved.
On Primary
SQL& alter da
Database altered.
On Standby
Create the required directory structure
$ mkdir -p
/u01/app/oracle/admin/condb1/adump
$ mkdir -p /u01/app/oracle/oradata/condb1/pdb1/
$ mkdir -p /u01/app/oracle/oradata/condb1/pdbseed
$ mkdir -p /u01/app/oracle/fast_recovery_area/condb1/
$ mkdir -p /u01/app/oracle/oradata/condb1/pdbseed/
Copy the password file from primary to standby
$ scp -rp orapwcondb1* oracle@orasql-001-test:/u01/app/oracle/product/12.1.0/dbhome_1/dbs
oracle@orasql-001-test's password:
orapwcondb1
On Standby
Add a static entry in the listener.ora for condb1_dr
LISTENER12C =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orasql-001-test.corporate.domain)(PORT = 1523))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1523))
SID_LIST_LISTENER12C =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = condb1_dr)
(ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)
(SID_NAME = condb1)
Reload the listener
$ lsnrctl reload listener12c
LSNRCTL for Linux: Version 12.1.0.1.0 - Production on 06-NOV-:46
Copyright (c) , Oracle.
All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=orasql-001-test.corporate.domain)(PORT=1523)))
The command completed successfully
Add an entry in the initcondb1.ora – just one line with the entry for db_name
$ cat initcondb1.ora
*.db_name=condb1
Add an entry in the oratab file
condb1:/u01/app/oracle/product/12.1.0/dbhome_1:N
Add the tns aliases on both the primary as well as standby site
On Primary
condb1_dr =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orasql-001-test.corporate.domain)(PORT = 1523))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = condb1_dr)
On Standby
Since we are using a non-standard port for the listener we need to add an entry in the tnsnames.ora file for the LOCAL_LISTENER database parameter.
LISTENER_CONDB1 =
(ADDRESS = (PROTOCOL = TCP)(HOST = orasql-001-test.corporate.domain)(PORT = 1523))
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orasql-001-dev.corporate.domain)(PORT = 1525))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = condb1)
CONDB1_DR =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orasql-001-test.corporate.domain)(PORT = 1523))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = condb1_dr)
On Standby
Start the Standby instance in NOMOUNT mode
$ . oraenv
ORACLE_SID = [condb1] ? condb1
The Oracle base has been set to /u01/app/oracle
[oracle@orasql-001-test admin]$ sqlplus sys as sysdba
SQL*Plus: Release 12.1.0.1.0 Production on Wed Nov 6 10:57:42 2013
Copyright (c) , Oracle.
All rights reserved.
Enter password:
Connected to an idle instance.
ORACLE instance started.
Total System Global Area
Fixed Size
2286800 bytes
Variable Size
Database Buffers
Redo Buffers
5095424 bytes
On Primary
Connect to Primary and auxiliary connection to Standby
$ rman target sys/syspassword auxiliary sys/syspassword@condb1_dr
Recovery Manager: Release 12.1.0.1.0 - Production on Wed Nov 6 10:58:43 2013
Copyright (c) , Oracle and/or its affiliates.
All rights reserved.
connected to target database: CONDB1 (DBID=)
connected to auxiliary database: CONDB1 (not mounted)
This is the command we will run to create the Standby Database.
Note – since the data file names are not being changed on the standby database we need to include the NOFILENAMECHECK
allocate channel c1
allocate channel c2
allocate auxiliary c
duplicate target database for standby from active database nofilenamecheck spfile
set log_archive_max_processes='8'
set db_unique_name='condb1_dr'
set standby_file_management='AUTO'
set log_archive_config='dg_config=(condb1,condb1_dr)'
set log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=condb1_dr'
set log_Archive_dest_2='service=condb1 async noaffirm reopen=15 valid_for=(all_logfiles,primary_role) db_unique_name=condb1';
After the RMAN DUPLICATE command completes we now need to add the relevant parameters for the redo log transport on the Primary database.
RMAN& alter system
set standby_file_management='AUTO';
Statement processed
RMAN& alter system set log_archive_config='dg_config=(condb1,condb1_dr)';
Statement processed
RMAN& alter system set log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=condb1';
Statement processed
RMAN& alter system set log_Archive_dest_2='service=condb1_dr async noaffirm reopen=15 valid_for=(all_logfiles,primary_role) db_unique_name=condb1_dr';
Statement processed
We will be running the standby database in Maximum Availability mode, so we need to create the standby redo log files on both the primary as well as standby site.
Since we have 3 online redo log file groups, we need to create (3+1) 4 Standby redo log file groups
On Standby
SQL& ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo01.log' size 50m;
Database altered.
SQL& ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo02.log'
Database altered.
SQL& ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo03.log'
Database altered.
SQL& ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo04.log' size 50m;
Database altered.
On Primary
RMAN& ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo01.log' size 50m;
Statement processed
RMAN& ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo02.log' size 50m;
Statement processed
RMAN& ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo03.log' size 50m;
Statement processed
ALTER DATABASE ADD STANDBY LOGFILE '/u01/app/oracle/oradata/condb1/standby_redo04.log' size 50m;
Statement processed
On Primary change the protection mode
RMAN& alter database set standby database to m
Statement processed
Check the status
RMAN& select destination,status from v$archive_dest_status where rownum &3;
DESTINATION
--------------------------------------------------------------------------------
Test Redo Apply is working
Connect to the pluggable database PDB1 as SH and create a table called SALES_DR.
Populate it with rows from SALES table in the SH schema.
$ sqlplus sh/sh@localhost:1525/pdb1
SQL*Plus: Release 12.1.0.1.0 Production on Wed Nov 6 11:40:26 2013
Copyright (c) , Oracle.
All rights reserved.
Last Successful login time: Sat May 25 :15 +08:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL& create table sales_dr as select *
Table created.
On the Standby database, the RMAN script which we ran from the primary database has not opened the database and started managed recovery.
Let us now manually do it.
On Standby
ORA-01109: database not open
Database dismounted.
ORACLE instance started.
Total System Global Area
Fixed Size
2296576 bytes
Variable Size
Database Buffers
Redo Buffers
Database mounted.
Database opened.
SQL& recover managed standby database using curren
Media recovery complete.
Check the MRP process is running
SQL& !ps -ef |grep mrp
00:00:00 ora_mrp0_condb1
SQL& select process,status,thread#,sequence#,blocks from v$managed_standby where process like '%MRP%';
--------- ------------ ---------- ---------- ----------
WAIT_FOR_LOG
SQL& select name,open_mode from v$
------------------------------ ----------
alter pluggable databas
Pluggable database altered.
SQL& select name,open_mode from v$
------------------------------ ----------
The Pluggable database PDB1 has been opened in READ ONLY mode, but the Container Database is running as an Active Standby
database and applying changes real-time as soon as they are received from the primary even when the Standby Container database and all the associated pluggable databases have been opened in read only mode.
Let us see if the SALES_DR table we had created on the Primary database can be accessed from the active standby database.
On the standby site, connect to the container database PDB1 as SH
[oracle@orasql-001-test condb1]$ sqlplus sh/sh@localhost:1523/pdb1
SQL*Plus: Release 12.1.0.1.0 Production on Wed Nov 6 11:43:40 2013
Copyright (c) , Oracle.
All rights reserved.
Last Successful login time: Wed Nov 06 :26 +08:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
SQL& select count(*) from sales_
----------
The test is successful and we have created our first Oracle 12c Active Stanbdy database!!
(required)
&&Email (will not be published) (required)
Now Oracle 12c Certified!
for Oracle 12c DBA and Oracle GoldenGate training courses
Who's Online23 visitors online now13 guests, 10 botsOracle 12c ADG特性_中华文本库
第1页/共5页
为 ORACLE 数据库提供实时数据保护和可用性
o 全面的 Oracle 感知数据库保护
o 独特的损坏检测和自动修复
o 手动或自动地快速故障切换到同步生产 副本
o 将生产负载分流到以只读方式打开的同步备用数据库
o 使用物理备用数据库进行数据库滚动升 级和备用数据库优先修补
o 跨越任意距离实现零数据丢失的灾难恢 复保护而不会影响性能
o Active Data Guard 是 Oracle 数据库企 业版包含的基本 Data Guard 功能的一 个超集。
o 最佳 Oracle 数据库保护
o 性能最高的灾难恢复保护 — 针对所有 负载,没有限制、易于管理
o 风险最低 — 对备用数据库进行不间断 的 Oracle 和用户验证
o 可用性最高 — 通过快速故障切换消除单点故障
o 全面 — 既能支持计划维护,又能应对 意外停机
o 利用简单的物理复制以最小的投入实现 高投资回报
ORACLE 数据表
ORACLE ACTIVE DATA GUARD Oracle Active Data Guard 可以为 Oracle 数据库提供实时数据保护和可用性,同时它消除了其他解决方案所固有的折衷的性质。它能跨越任意距离实现零数据丢失的灾难恢复保护而不会影响数据库性能。它能修复物理损坏而不会影响可用性,并且无需使用专用的网络设备既可节省网络带宽。该解决方案没有易于出错的手动过程,能够减少 Oracle 数据库升级所需的停机时间。它利用物理复制的简易性提高灾难恢复系统的投资回报。
实时数据保护和高可用性
Active Data Guard 是用于避免任务关键型 Oracle 数据库发生单点故障的全面的解决方案。该解决方案能够维护一个生产数据库(主数据库)的同步物理副本(备用数据库),从而以最简单和最经济的方式防止数据丢失和停机。如果出现停机,客户端连接会迅速故障切换到备用数据库并恢复服务。Active Data Guard 与 Oracle 数据库深度集成,提供强大的故障隔离和独特的 Oracle 感知的数据验证,从而能够提供最高程度的数据保护。影响主数据库的系统和软件缺陷、数据损坏和管理员错误不会镜像到备用数据库。该解决方案通过将只读负载及备份转至活动备用数据库而消除了空闲冗余,从而实现了高投资回报。
通过使用易于部署和管理并且功能强大和主动的灾难恢复系统,Oracle Database 12c 中的 Oracle Active Data Guard 功能不再需要在数据保护、成本和复杂性之间进行折衷。Active Data Guard: o
采用低成本的方法跨越任意距离实现零数据丢失灾难恢复保护
通过增加分流到活动备用数据库的报表应用程序的数量实现高投资回报
通过使用新的数据库滚动升级自动化手段提高可用性并降低风险
Active Data Guard 远程同步 — 任意距离的零数据丢失保护
远程同步功能通过在距离主站点位置任意距离的位置维护一个同步备用数据库,为生产数据库提供零数据丢失保护,并且这不会影响性能,而且成本和复杂性也最小。一种新的称作远程同步实例的 Data Guard 目标从主数据库同步接收变更,并将其以异步方式转发到远程备用数据库。可以手动或自动地将生产数据库快速故障切换到远程备用数据库,而不会产生任何数据丢失。
远程同步实例是一个轻型实体,它只管理一个控制文件和一些日志文件。它只需要占用备用数据库的一小部分 CPU、内存和 I/O。它没有用户数据文件,也不执行恢复。其唯一目的是透明地分流主数据库为远程目标提供服务的负载。
第1页/共5页
寻找更多 ""Oracle ADG Heartbeat failed to connect to standby故障案例_数据库技术_Linux公社-Linux系统门户网站
你好,游客
Oracle ADG Heartbeat failed to connect to standby故障案例
来源:Linux社区&
作者:尛样儿
客户的主数据库是一套 Database 11gR2 for AIX的单机数据库,在系统层面部署了IBM HACMP软件,将该数据库做成了能在两台物理机之间切换的主备模式,并且为该数据库实施了ADG。客户将主数据库切换到备用服务器之后,主数据库与备用数据库不再同步,在数据库的告警日志中收到如下告警:
Fri Mar 13 02:28:00 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.& &&&&& 注意错误编号。Fri Mar 13 02:29:01 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.Fri Mar 13 02:30:01 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.Fri Mar 13 02:31:02 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.Fri Mar 13 02:32:02 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.Fri Mar 13 02:33:02 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.Fri Mar 13 02:34:03 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.Fri Mar 13 02:35:03 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.Fri Mar 13 02:36:04 2015PING[ARC2]: Heartbeat failed to connect to standby 'd012dg'. Error is 16057.
& & 以上告警在ADG的环境中已经多次遇到,请注意类似报错的错误ID,这里的ID是16057,Oracle对该错误是这样解释的:ORA-16057: DGID from server not in Data Guard configuration Cause: The Data Guard name of the primary database or the FAL server is not in the Data Guard configuration of the standby.
Action: In order for the primary database or the FAL server to archive logs to the standby database, the Data Guard name of the primary or FAL server must be in the Data Guard configuration of the standby.
在MOS中找到如下文章:
Primary Remote log shipping failing with ORA-16057 - Server not in Data Guard configuration (Doc ID )
&In this Document
&Symptoms&
&Solution&
Applies to: Oracle Database - Enterprise Edition - Version 12.1.0.1 and laterInformation in this document applies to any platform.
&------------Primary Alert log-----------------Thu Jul 11 16:28:16 2013ALTER SYSTEM SET log_archive_dest_2='service=chicago async valid_for=(all_logfiles,primary_role) db_unique_name=chicago'
SCOPE=BOTH;Thu Jul 11 16:28:17 2013PING[ARC1]: Heartbeat failed to connect to standby 'chicago'. Error is 16057..' ...Error 16057 for archive log file 1 to 'chicago'Thu Jul 11 16:28:19 2013Errors in file /u01/app/oracle/diag/rdbms/boston/boston/trace/boston_tt01_6296.trc:ORA-16057: server not in Data Guard configuration
SQL& col error for a30SQL& select dest_id,error,status,log_sequence,applied_scn from v$archive_dest where dest_id=2;
DEST_ID ERROR& & & & & & & & & & & & & STATUS& & LOG_SEQUENCE APPLIED_SCN---------- ------------------------------ --------- ------------ -----------& & & &
2 ORA-16057: server not in Data& ERROR& & & & & & &
61& & & & &
0& & & & &
Guard configuration
log_archive_config not set.
SQL& col error for a30SQL& select dest_id,error,status,log_sequence,applied_scn from v$archive_dest where dest_id=2;
DEST_ID ERROR& & & & & & & & & & & & & STATUS& & LOG_SEQUENCE APPLIED_SCN---------- ------------------------------ --------- ------------ -----------& & & &
2 ORA-16057: server not in Data& ERROR& & & & & & &
61& & & & &
0& & & & &
Guard configuration
SQL& sho parameter log_archive_config
NAME& & & & & & & & & & & & & & & &
TYPE& & & & VALUE------------------------------------ ----------- ------------------------------log_archive_config& & & & & & & & &
SQL&ALTER SYSTEM SET log_archive_config='dg_config=(boston,ChicagO)' SCOPE=BOTH;
System altered.
SQL& alter system set log_archive_dest_state_2=
System altered.
SQL&& alter system set log_archive_dest_state_2=enable
System altered.
SQL& alter s
System altered.
SQL& select dest_id,error,status,log_sequence,applied_scn from v$archive_dest where dest_id=2;
DEST_ID ERROR& & & & & & & & & & & & & STATUS& & LOG_SEQUENCE APPLIED_SCN---------- ------------------------------ --------- ------------ -----------& & & &
2& & & & & & & & & & & & & & & & VALID& & & & & & &
SQL& sho parameter log_archive_config
NAME& & & & & & & & & & & & & & & &
TYPE& & & & VALUE------------------------------------ ----------- ------------------------------log_archive_config& & & & & & & & &
1.& It is not mandatary to set the config parameter at standby side. But we need this to be set on standby side as well for any role
transition purpose and for DG broker configuration.
2.& Once remote shipping established then log_archive_config to null will not affect the remote destination until DB is restarted.
Restart will verify log_archive_config.
rti.run" type="text/javascript"&
& & 这个错误是由于没有配置log_archive_config造成的,重新配置该参数,重新启用log_archive_dest_state_x参数之后,主备数据库同步恢复正常。出现这个错误的原因是客户没有同步主数据库的主备服务器下的初始化参数文件造成的。
当遇到Heartbeat failed to connect to standby的错误时一定注意错误编号,根据编号来找错误,对新完成配置的ADG环境也可以尝试重启备库或主库观察是否能正常同步。
更多Oracle相关信息见 专题页面
本文永久更新链接地址:
相关资讯 & & &
图片资讯 & & &
   同意评论声明
   发表
尊重网上道德,遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款

我要回帖

更多关于 oracle adg与dg区别 的文章

 

随机推荐