9i中DG remote archive可能导致Primary Database挂起

9i中若dg的remove archive stuck卡住可能即便在Max Performance最大性能模式下也会导致Primary database 主库的local archive 本地归档无法正常进行, 进而导致Primary db hang挂起。

Solaris sparce 64 平台上的9.2.0.5 库 的相关日志:

 

Verifying the issue in the alert log Fri Oct 28 08:10:12 2011 ALTER SYSTEM SET log_archive_dest_1=’location=/u24/app/oradata/temp_arch’ SCOPE=BOTH; Fri Oct 28 08:10:51 2011 ORACLE Instance maclean – Can not allocate log, archival required Fri Oct 28 08:10:51 2011 . . . → Read More: 9i中DG remote archive可能导致Primary Database挂起

ORA-26786造成逻辑备库无法应用SQL一例

一套Linux x86-64 上的11.2.0.2逻辑备库因为出现ORA-26786: A row with key exists but has conflicting column(s) “导致APPLIER 进程无法继续工作,详细信息如下:

 

1) ### Primary OS Details ### Hostname – vrh6 OS details – [oracle@vrh6 ~]$ uname -a Linux vrh6 2.6.18-194.8.1.el5 #1 SMP Wed Jun 23 10:52:51 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux 2) ### Standby OS Details ### Hostname – vrh7 . . . → Read More: ORA-26786造成逻辑备库无法应用SQL一例

Does Duplicate Target Database need Pre-existing DB backup?

之前有网友问我在10g中通过RMAN 的duplicate target database命令复制数据库时是否需要先完成全库的备份。

实际我在10g中并不常用duplicate target database 来帮助创建DataGuard Standby Database,所以虽然记忆中仍有些印象,却不能十分确定地回答了。

今天查了一下资料,发现原来Active database duplication 和 Backup-based duplication 是11g才引入的特性,换句话说10g中duplication是要求预先完成数据库的RMAN backup备份的。

具体关于以上2个特性见文档<RMAN ‘Duplicate Database’ Feature in 11G>,引文如下:

RMAN ‘Duplicate Database’ Feature in 11G You can create a duplicate database using the RMAN duplicate command. The duplicate database has a different DBID from the source database and functions entirely . . . → Read More: Does Duplicate Target Database need Pre-existing DB backup?

11gR2新特性:STANDBY_MAX_DATA_DELAY

Active Data Guard 是 Oracle 11g 的亮点特性之一,而在11G release 2中对Active Data Guard引入了更多诱人的新特性,这些特性将Active Data Guard打造成Oracle 读写分离或报表查询的理想方案之一。

 

STANDBY_MAX_DATA_DELAY是11gr2中对Active Data Guard的最大增强(buffer)之一,这是一个可以在会话级别指定的参数(session parameter),该参数指定了在Primary Database已commit提交的变化与standby Database数据库上涉及相关变化的查询之间所允许的时间延迟,单位为second 秒(Specifies a limit for the amount of time (in seconds) allowed to elapse between when changes are committed on the primary and when those same changes can be queries on the standby database)。

 

. . . → Read More: 11gR2新特性:STANDBY_MAX_DATA_DELAY

解决DGMGRL Unable to connect to database ORA-12541: TNS:no listener问题

晚上配了一套11.2.0.2 的DataGuard物理备库,准备用DGMGRL做切换测试,结果发现在切换过程中会遇到”Unable to connect to database”的问题,具体日志如下:

 

DGMGRL> switchover to dgogg Performing switchover NOW, please wait… New primary database “dgogg” is opening… Operation requires shutdown of instance “SBDB” on database “sbdb” Shutting down instance “SBDB”… ORACLE instance shut down. Operation requires startup of instance “SBDB” on database “sbdb” Starting instance “SBDB”… Unable to connect to . . . → Read More: 解决DGMGRL Unable to connect to database ORA-12541: TNS:no listener问题

DataGuard与异构平台

DataGuard对主备库异构平台的支持一直是让很多人纠结的问题,我们在学习Oracle数据卫士时必要优先阅读的官方文档是<Oracle Data Guard Concepts and Administration 10g Release 2>,在这个文档中给出了极为苛刻的硬件环境限制条件:

All members of a Data Guard configuration must run an Oracle image that is built for the same platform. For example, this means a Data Guard configuration with a primary database on a 32-bit Linux on Intel system can have a standby database that is configured . . . → Read More: DataGuard与异构平台

Examine 11g automatic block Corruption recovery

11g的高可用框架中DataGuard为我们带来了大量有用的特性,最引入注目的显然是Active Data Guard,这一特性几乎彻底改观了Oracle HA的原有格局。除了Active Data Guard外Automatic Block Media Repair即自动的块介质恢复也是11g中数据卫士一个不容忽视的特色。该特性通过后台进程ABMR自动将物理备库(physical standby)上的健康数据块传输到主库(primary database)上以替换在主库发现的已损坏的数据块。同样的若物理备库上发现数据块损坏那么也可以利用到以上特性来修复。注意使用该特性无需额外设置db_lost_write_protect参数为非默认的NONE值,ABMR的自动修复不依赖于该参数。

深入研究的话可以发现实际控制Automatic Block Media Repair特性的是一系列隐藏参数,它们包括:

_auto_bmr enabled enable/disable Auto BMR _auto_bmr_req_timeout 60 Auto BMR Requester Timeout _auto_bmr_sess_threshold 30 Auto BMR Request Session Threshold _auto_bmr_pub_timeout 10 Auto BMR Publish Timeout _auto_bmr_fc_time 60 Auto BMR Flood Control Time _auto_bmr_bg_time 3600 Auto BMR Process Run Time _auto_bmr_sys_threshold 100 . . . → Read More: Examine 11g automatic block Corruption recovery

Duplicate standby database from active database

11g Release1 中引入了新的RMAN duplicate命令,即duplicate from active database命令。利用该命令可以更加便捷地创建Data Guard环境,你甚至不需要将Primary Database shutdown(整个过程中主库都可以处于打开状态下),也不需要在配置前做一些额外的备份操作,仅需要配置起auxiliary辅助实例,同时创建密码文件,并在监听(LISTENER)中加入静态注册信息后就可以开始工作了!

以下示例中我们会在Primary Database所在的同一台服务器上部署一套物理备库(Physical Standby),实际上这样比在不同的2台服务器上配置Data Guard要复杂些,原因是那样的话我们无需做File Name的转换,具体的环境:

Database Role DB_UNIQUE_NAME Primary Database PROD Standby Database SBDB

 

/* 需要注意的是DG环境中force logging,不要用了新特性就将这个基本的要求忘记了 ! */ SQL> select * from v$version; BANNER ——————————————————————————– Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – 64bit Production PL/SQL Release 11.2.0.2.0 – Production CORE 11.2.0.2.0 Production . . . → Read More: Duplicate standby database from active database