ANBOB™

最近一套oracle 12c R2的数据库日志应用总是中断，并且在standby 节点发现了一些坏块，存储检查正常，并且primary db端并没有发现坏块，standby db alert log中发现了大量的ora-600报错，当前可能为logical corruption（Internal inconsistency in the block while the block may have good header and footer. The block checksum will be correct but the block structures may be corrupt.），ADG的ABMR并没有自动修复该错误。这里简单记录。

最近客户一套oracle 19.14 standalone Database做的cascade dataguard环境，暂且认为是A->B->C三台单实例, 但总是A->B的延迟，从oracle 12c后引入real time cascade，所以如果依赖该特性对延迟要求较高， 分析A->B延迟发现，B库总时会出现GAP,并且未自动FAL，需要人为干预, 并且主库alert日志报错出现:
ORA-03135: connection lost contact
TT02 (PID:64459): Error 3135 for LNO:3 to“xxx”。

有时跟踪 Data Guard 后台服务很有帮助，因此我们可以查看匹配的 NSSn 和 RFS 跟踪。对于深入研究，我们还希望在 Data Guard 配置的两端运行 tcpdump 捕获，并且可能在中间的网络组件上运行。为了最大限度地减少设备上的处理开销和捕获文件中的噪音，我们希望数据包过滤器尽可能具体。

很多时候我们在安装配置oracle dataguard时，需要在standby db 增加standby log, 但是有一些限制，如standby log file size和主库的online redo log size相同， standby log每个thread要比主库的online redo log要多1组，为什么需要standby log?为什么会有这样的要求呢？

在Oracle 12c之后版本多租户环境的Standby DATABASE,当某一个PDB出现文件丢失时或PDB多个文件损坏，如何重建PDB standby database. 这里简单记录在18c后的方法。

在 DataGuard 环境中，默认情况下，当使用密码文件时，SYS 用户的密码用于验证重做传输会话。但出于安全原因，您可能不希望仅将如此高特权的用户用于重做传输。为了克服这个问题，Oracle 实现了 REDO_TRANSPORT_USER 初始化参数。
REDO_TRANSPORT_USER是在DATAGUARD环境中用于 redo transport 远程密码认证指定数据库用户名，

今天谈起一种场景，如果oracle dataguard环境中，primary db长时间不可用或出现永久性故障，那么我们必须考虑failover到备用数据库以使其成为新的主数据库。之后，我们还要重建旧的主库，使其成为新的备库。关于备库在failover激活后，再次回到备库，Gavin Soorma在他的blog上有详细的测试记录。

这是一个非常典型的dataguard 环境中存在的bug, 在oracle 11.1-12.1版本之间一直存在的BUG，当Physical Standby Dataguard 环境发现switchover或者failover后，在验证索引块上存在无效的scn时抛出的错误ORA-600 [2663]，或者有时附带ORA-600 [ktbdchk1: bad dscn]， 该BUG不会导致当前数据块上有数据丢失，也不会有数据勘误在索引块上。 这里简单记录.

有时为了提升SQL执行速度或减少redo而使用NOLOGGING选项， 或者在segment 级使用NOLOGGING属性， 将使用最少的信息记录到online redo logfile，但是对于DataGuard环境是基于redo应用，所以这也是在DATAGUARD配置时需要在数据库级启用FORCE_LOGGING原因，如果缺少了日志必要的信息，在RECOVERY介质恢复期间将受影响的块标记为已损坏, 查询V$DATABASE_BLOCK_CORRUPTION.CORRUPTION_TYPE为NOLOGGING

Starting with 11gR1, Oracle Data Guard asynchronous redo transport will read redo directly from the in-memory log buffer, provided that the requested redo blocks still reside in the log buffer, start 11g R2 use NSA backgroup process do that.

2C中为了在不同实例间统一的密码管理， 支持把DB密码（ASM password same）存储到ASM DISKGROUP中，这样在维护DG环境时，当同步密码文件时就要先确认一下密码的位置， 同样DG端也可以把密码存储到ASM中，然后使用srvctl modify database修改pwd路径. 这个案例通过在标准化DG配置中因密码不一致产生了各种错误

前段时间配的一套11203 RAC ADG on EXADATA Machine的环境，在ADG 的standby side的node2 通过dblink查询时提示ora-1089错误，但是在node1 查询正常，DG的recover 进程是在node1 上..

该环境是主备两套11.2.0.3 2-NODES RAC ON EXADATA Machine ，存储在ASM， 数据库70TB 大小， 闲时每天1T归档日志， 忙时每天可达4T+归档， 之前朋友重建DG一直使用主机上一个shell 放后台，我查看了该shell 确实不算复杂，但是duplicate 一直hang在开始

DG 的作用举足轻重，在高可用的企业级数据库有着非常重要的角色，数据保护、备份、灾难恢复、容灾等很多形容词在oralce数据库中都与它相关。
DG 名字很多，又名数据卫士， 灾难恢复全名oracle data guard…