还不算晕的专栏

归档日志间隙是在 Standby 端一系列丢失的重做日志，导致日志应用服务无法继续运行。这通常发生在 Standby 端无法从 Primary Database 接收重做日志或重做日志在 Standby Database 上不可用时。网络连接断开或者日志传输服务停止Standby Database 不可用日志传输服务的配置错误Standby 端的 IO 问题归档日志在应用到 Standby 前被手工删除Primary 和 Standby 之间的网络带宽不足。...

近期，某用户的DATAGUARD备机，在只读查询模式，隔一段时间就出现ORA-01555错误。在ADG备机中，ORA-01555错误有几个相关的BUG，本次为典型的SQL执行Query Duration=0 sec时报错，可以参考文档ORA-01555 on Active Data Guard Standby Database (文档 ID 1273808.1)来进行排查。一般建议就是安装最新的PSU来规避这些问题，有些可以通过重启或刷共享池等方式解决，也可以在ADG备机上写成定时脚本每天执行来处理此问

经常遇到有DATAGUARD备机不使用standby redo log的情况发生，特别是RAC到单机环境；很多人在说重启一下、不行删除重加之类，还不行了重启下主节点（当然生产环境下比较困难）等；从从数据库层面，从v$standby_log中可以清楚查出standby redo log所属的THREAD，据此，可以确认standby redo log不被使用的原因，如典型的THREAD不匹配；如下为一次DATAGUARD备机不使用standby redo log的情况的处理：1.查询当前v$sta

在上一篇“dataguard standby备机上tempfile的问题”中，我们分析了向已经存在的临时表空间中，添加TEMPFILE时，DG备机为何不会自动同步创建以及人工如何处理的问题。那么另一种场景，如果在主库上新建一个临时表空间，会如何向备机上同步呢？经测试，主库上创建临时表空间（create temporary tablespace test_temp）是会修改ORACLE数据字典，这部分数据字典信息的修改，是会同步的，即查询dba_tablespaces视图，备机在同步状态下可以查到已.

近期，某用户将报表业务转移到DATAGUARD的备机上运行，发现程序有报错临时表空间的信息；经排查为ADG备机上，没有临时表空间的文件问题~用户困惑；在正常的RMAN备份恢复过程中，只恢复数据文件，不恢复临时表空间的文件。临时表空间的文件信息仅为数据字典中的一条记录，在数据库OPEN过程中会自动创建；那么在DATAGUARD环境下，备库的TEMP文件会怎么样呢？1.首先明确一点，在主库添加tempfile时，没有REDO产生，所以不会同步到DG备库(dba_temp_files中也查不到)2

晚上接到用户电话，DG备机报错无法正常同步。ORA-00600: internal error code, arguments: [2619], [84747]，了解到之前出现磁盘空间满，已经人为删除处理过；这是一个典型的DG空间满后的问题，官方文档ORA-600[2619] During Physical Standby Recovery (Doc ID 1138913.1)对此有说明；总结理解一下，问题原因为磁盘空间满，导致归档日志未完全写入而出现损失，DG备机的MRP进程无法使用此归档日志。了解了原理

在Oracle ADG环境中，当使用的存储过程、视图中具有调用DBLINK的代码时，或反复执行带DBLINK的查询语句时，会遇到报错：ORA-16000: database open for read-only access这是由于ADG环境为只读状态，使用一次DBLINK后必须提交或回滚事务后，才能再执行第二次的DBLINK调用。Oracle官方文档及MOS文档中对此也有明确说明，如https://docs.oracle.com/cd/E11882_01/server.112/e25494/star

总结：1.主库配置为：arch async，备库无STANDBY LOG。日志中会有：RFS[4]: No standby redo logfiles created2.主库配置为：arch async，备库有STANDBY LOG，日志中未显示使用。特殊情况：主库配置为：arch async，备库有STANDBY LOG，备库未打开日志应用 ，日志中有：RFS[8]: Succe

切换时报错总结：--活动会话-应该是GC客户端的。1.主库在进行物理主备库角色转换的时候遇到ORA-01093错误SQL> select switchover_status from v$database;SWITCHOVER_STATUS--------------------SESSIONS ACTIVESQL> ALTER DATABASE COMMIT TO SWI

配置DG涉及的参数大致如下：具体的设置语句可以参考其它的安装DG记录1.DB_NAME，数据库名字，需要保持同一个Data Guard 中所有数据库DB_NAME相同2.DB_UNIQUE_NAME，对应数据库的实例名，每一个数据库需要指定一个唯一的名字ALTER SYSTEM SET DB_UNIQUE_NAME=aaa scope=spfile;3.LOG_ARCHIV

前提：归档开启，默认不指定归档目录。今晚遇到客户那里设置了闪回区和log_archive_dest，不停库做DG时，无法指定log_archive_dest_n参数，巨坑。。实验了下，结论如下：数据库版本:ORACLE10.2.0.11.未设置闪回区时，可以动态配置log_archive_dest或log_archive_dest_12.配置闪回区时，不可以动态配置log_ar

ORACLE 8I standby增加数据文件与10G后略有不同。在10G及以后，DATAGUARD架构下在主库增加数据文件后，STANDBY_FILE_MANAGEMENT=AUTO时，备库会自动在DB_FILE_NAME_CONVERT指定的或者默认的与主库相同的位置创建同样的数据文件，不需要手动干预。在ORACLE 8I standby中，主库增加数据文件后，待包含此信息的REDO在

问题描述：Linux上11.2.0.4.0 RAC-->RAC做的DG。在主库一个节点使用alter user sys命令对SYS用户进行了更新，之后因密码问题日志无法同步。发现问题后重新同步了密码文件；但是备库无法通过FAL配置获取节点2的归档日志，GAP机制未生产。解决方法：密码文件的错误：在以前也遇到过11.2.0.3时只能通过传输密码文件同步，通过相同命令在

参考文档：http://www.eygle.com/digest/2010/10/oracle_dataguard_redo_changing.htmlMetalink 473442.1 号文档近期客户的DATAGUARD环境中主库出现有 checkpoint not complete警告，当前系统只有3组REDO大小各100M，需要增加REDO日志组。1.在主库和备库设置standb

DG的安装与配置一、环境安装前规划：环境：VBOX虚拟机，操作系统：OracleLinux Server release 5.7数据库版本：OracleDatabase 11g Enterprise Edition Release 11.2.0.1.0 -  dg1做为主库，dg2做为备库。dg1/dg2目录相同。dg1:IP：192.168.1.241

一、用Read only方式打开standby db，做一些查询，然后恢复到打开前的状态(standby db的报表用途)。在备库上进行操作。首先取消恢复应用SYS@dg2>recover managed standby database cancel;Media recovery complete.SYS@dg2>alter database open;Database

11G新特性 Active Data Guard,特点:重做应用始终开启总是以只读方式打开查询和报告中总有最新的数在需要的时候立即容错，备用数据库保持更新据读操作和恢复同时进行把只读工作负载转换到备用数据库上本实验:dg1是主库，dg2是备库.DG正常运行于最大可用模式。bys是DBA用户。1.在dg2上打开数据库，并启用Active Data Guar

DG1是主库，DG2是备库；运行在最大可用模式。实验一：未使用using current logfile参数时，备库在最大可用模式下，不能实时同步备库的更新-此时需要等待主库进行归档---侧面证明备库应用的归档来恢复数据。  BYS@dg1>show parameter log_archive_dest_2NAME                                 T

总结 ：在备库dg2上停掉网络。此时主库日志中有出错提示。将备库网络恢复正常，过几分钟，ORACLE自动恢复归档的传递。1.关闭备库网络，在主库进行日志切换[oracle@dg1 ~]$ sqlplus / as sysdba                  SYS@dg1>alter system switch logfile;System altered.SYS@dg

DG目前正常运行在最大可用模式环境：DG1-主库[oracle@dg1 ~]$ sqlplus / as sysdbaSYS@dg1>select open_mode from v$database;OPEN_MODE--------------------READ WRITESYS@dg1>select protection_mode,database_role fr

证明DG主备库归档文件名受各自log_archive_format参数影响DG1 主库，DG2备库。一、DG正常运行在最大可用模式。使用的是alter database recover managed standby database disconnect from session;进行恢复BYS@dg1>show parameter log_archive_formatNAM

1.查询命令select name,db_unique_name from v$database;select max(sequence#) from v$archived_log; 查询保护模式select protection_mode,database_role,open_mode from v$database;查询最近5个应用的归档select * from (s

本实验中dg1是主库，dg2是备库，DG当前正常运行在最大可用模式。第一次计划将dg1转化为备库，dg2转为主库第二次最终再切换回dg1是主库，dg2是备库。环境检查：因为目前DG是可以正常使用，所以只需要检查以下参数就可以 ：切换前首先检查dg2备库上的参数设置是否正确。SYS@dg2>show parameter archive_dest_2NAME

DG正常运行于最大可用模式，DG2是备库。1.切换为SNAPSHOT STANDBYBYS@dg2>select * from test;         A----------       999         8BYS@dg2>conn / as sysdbaConnected.SYS@dg2>alter database convert to sna

1.停掉备库dg2的网络2.在主库进行切换日志的操作SYS@dg1>select protection_mode,database_role,protection_level from v$database;PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL-------------------- -------------

Dataguard依赖一个健康的网络，尤其是高负载的系统和网络环境，网络上有调整的需求。1.Oracle Net Session Data Unit (SDU) Size       Oracle Net在将数据进行网络传输的时候,先将数据放在SDU中，该参数在10gR2默认为2k，适当增加大小，可以提高网络性能和利用率。       Oracle推荐该参数取值为32767(最

rac+单实例组建DG示例一、初始环境：准备已经安装完毕可以正常运行的RAC数据库，以及一台安装完ORACLE软件未创建数据库的。RAC和单实例安装可以参考：RAC做为DG的主库。1.我的配置如下：RAC   节点1：-IP192.168.1.221 主机名 bysrac1.bys.com ，以及数据库名 bysrac，Database unique name:

转自 David Dai 博客。RAC， Data Gurad， Stream 是Oracle 高可用性体系中的三种工具，每个工具即可以独立应用，也可以相互配合。 他们各自的侧重点不同，适用场景也不同。RAC 它的强项在于解决单点故障和负载均衡，因此RAC 方案常用于7*24 的核心系统，但RAC 方案中的数据只有一份，尽管可以通过RAID 等机制可以避免存储故障，但是数据本身是没

1. 停止physical standby备库的redo applySQL> alter database recover managed standby database cancel;2. 在主库运行dbms_logstdby.buildSQL> execute dbms_logstdby.build;3. 在主库上切换物理备库转化为Logical standbyS