DataGuard

Troubleshooting Oracle 12cR2 Standby database crash due to Corrrupted block

by

最近一套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并没有自动修复该错误。这里简单记录。

Troubleshooting Oracle 19c cascade Dataguard Gap ORA-03135: connection lost contact

by

最近客户一套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”。

Troubleshooting Dataguard SYNC同步模式时网络问题

by

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

oracle 18c 、19c 重建 PDB standby database

by

在Oracle 12c之后版本多租户环境的Standby DATABASE,当某一个PDB出现文件丢失时或PDB多个文件损坏，如何重建PDB standby database? 这里简单记录在18c后的方法。 方法1：使用RMAN复制（推荐） 12c后可以使用from serivce xx. # on standby alter database recover managed standby database cancel; shut immedaite statup MOUNT RMAN> run{ allocate channel disk1 device type disk; allocate channel disk2 device type disk; allocate channel disk3 device type disk; allocate channel disk4 device type disk; allocate channel disk5 device type … Read more

Oracle 12cR2 : DataGuard 、 ZDLRA、REDO_TRANSPORT_USERT

by

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

Oracle Dataguard在standby failover后如何加回原primary？

by

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

Troubleshooing ORA-600 [2663] after DataGuard switchover

by

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

利用RMAN增量备份(Incremental Backup)修复standby 环境中的nologging corupted blocks

by

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

Oracle12c R2注意事项：DB password file in ASM (DataGuard环境重建PWD）

by

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