案例：DG主库未设置force logging导致备库坏块
DG搭建时，官方文档手册有明确提到要设置数据库为force_logging，防止有nologging操作日志记录不全导致备库应用时出现问题。
虽然是老生常谈的安装规范，但现实中总会遇到不遵守规范的场景，最近就在某客户现场遇到一则这样的案例，因为DG主库设置force_logging晚于DG搭建，导致备库出现坏块，使用dbv检查就表现为DBV-201错误。
下面我们来模拟下这个场景，同时演示下具体修复过程：
1.准备实验环境
主库确认没有开启force logging 模式，如果是，修改为不是，这是模拟故障场景的前提条件：
select force_logging from v$database;
ALTER DATABASE NO FORCE LOGGING;
搭建一套测试DG：主库修改系列DG配置参数后，创建pfile给备库修改使用，同时将密码文件、tnsnames.ora文件传输到备库端，启动实例到nomount状态：
create pfile='/tmp/pfile_for_standby.txt' from spfile;
scp /tmp/pfile_for_standby.txt ora11204@192.168.1.11:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/
scp $ORACLE_HOME/dbs/orapwcrmdb1 ora11204@192.168.1.11:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwsingle
scp $ORACLE_HOME/network/admin/tnsnames.ora ora11204@192.168.1.11:/u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
change pfile depend on standby env;
sqlplus / as sysdba
startup nomount pfile=$ORACLE_HOME/dbs/pfile_for_standby.txt
使用duplicate搭建DG备库，注意备库需要静态监听：
vi dup_dg.sh
rman target sys/oracle@crmdb1 auxiliary sys/oracle@single <<EOF
duplicate target database for standby from active database dorecover nofilenamecheck;
EOF
nohup sh dup_dg.sh > dup_dg.log &
tail -200f dup_dg.log
注意：目标端所需目录要提前手工创建，因为duplicate过程发现没有对应目录会报错。
2.构造故障场景
主库用户表空间xxx，创建一张表插入数据，nologging创建索引；切换日志，备库检查坏块情况。
在jingyu用户下创建测试表，并使用nologging方式创建索引：
jingyu@CRMDB> create table TEST as select * from dba_objects;
Table created.
jingyu@CRMDB> create index idx_test on test(object_id) nologging;
Index created.
jingyu@CRMDB> select USERNAME, DEFAULT_TABLESPACE, TEMPORARY_TABLESPACE from dba_users where username = 'JINGYU';
USERNAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE
------------------------------ ------------------------------ ------------------------------
JINGYU DBS_D_JINGYU TEMP
备库查看同步状态OK：
SQL>
set lines 1000
col value for a20
col name for a30
col unit for a30
col TIME_COMPUTED for a30
col DATUM_TIME for a30
select * from v$dataguard_stats;
NAME VALUE UNIT TIME_COMPUTED DATUM_TIME
------------------------------ -------------------- ------------------------------ ------------------------------ ------------------------------
transport lag +00 00:00:00 day(2) to second(0) interval 06/08/2020 09:14:26 06/08/2020 09:14:26
apply lag +00 00:00:00 day(2) to second(0) interval 06/08/2020 09:14:26 06/08/2020 09:14:26
apply finish time day(2) to second(3) interval 06/08/2020 09:14:26
estimated startup time 40 second 06/08/2020 09:14:26
但备库使用dbv检查数据文件，发现已经存在坏块，报错都是DBV-00201：
[ora11204@OEL-ASM arch]$ dbv file=/u01/oradata/crmdb/datafile/dbs_d_jingyu.365.1041070633
DBVERIFY: Release 11.2.0.4.0 - Production on Mon Jun 8 08:52:12 2020
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oradata/crmdb/datafile/dbs_d_jingyu.365.1041070633
DBV-00201: Block, DBA 25168260, marked corrupt for invalid redo application
DBV-00201: Block, DBA 25168261, marked corrupt for invalid redo application
...这里省略大量DBV-00201的输出...
DBV-00201: Block, DBA 25168422, marked corrupt for invalid redo application
DBV-00201: Block, DBA 25168423, marked corrupt for invalid redo application
DBVERIFY - Verification complete
Total Pages Examined : 12800
Total Pages Processed (Data) : 1998
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 157
Total Pages Failing (Index): 0
Total Pages Processed (Other): 354
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 10291
Total Pages Marked Corrupt : 155
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 2168379 (0.2168379)
[ora11204@OEL-ASM arch]$
此时再通过主库设置force logging挽救，为时过晚，只能对之后的操作起作用，但对已造成的坏块无法修复：
ALTER DATABASE FORCE LOGGING;
3.解决故障
在主库确认已设置force logging后，重新搭建DG环境。
当然如果造成坏块的数据文件不是很多，相比较全库而言，直接重新备份受损的数据文件也许是更效率的方案：
比如我这里测试环境，就只有1个数据文件收到了影响，只需要修复它就好：
3.1 确认下主库的这个文件是好的（无坏块）：
[oracle@jystdrac1 trace]$ dbv userid=sys/oracle file=+DATA/crmdb/datafile/dbs_d_jingyu.365.1041070633
DBVERIFY: Release 11.2.0.4.0 - Production on Mon Jun 8 09:26:21 2020
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = +DATA/crmdb/datafile/dbs_d_jingyu.365.1041070633
DBVERIFY - Verification complete
Total Pages Examined : 12800
Total Pages Processed (Data) : 1998
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 312
Total Pages Failing (Index): 0
Total Pages Processed (Other): 199
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 10291
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 0 (0.0)
3.2 备份这个文件并传输到备库：
backup as compressed backupset datafile 6 format '/public/rman/primary_datafile_6.bak';
RMAN> backup as compressed backupset datafile 6 format '/public/rman/primary_datafile_6.bak';
Starting backup at 2020-06-08 09:29:15
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=71 instance=crmdb1 device type=DISK
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=+DATA/crmdb/datafile/dbs_d_jingyu.365.1041070633
channel ORA_DISK_1: starting piece 1 at 2020-06-08 09:29:17
channel ORA_DISK_1: finished piece 1 at 2020-06-08 09:29:25
piece handle=/public/rman/primary_datafile_6.bak tag=TAG20200608T092917 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:08
Finished backup at 2020-06-08 09:29:25
3.3 备库关闭，启动到mount，restore损坏的数据文件，然后open开启应用
RMAN> catalog start with '/public/rman/primary_';
RMAN> list backup of datafile 6;
RMAN> restore datafile 6;
再次使用dbv查看坏块情况，已经修复：
[ora11204@OEL-ASM rman]$ dbv file=/u01/oradata/crmdb/datafile/dbs_d_jingyu.365.1041070633
DBVERIFY: Release 11.2.0.4.0 - Production on Mon Jun 8 09:37:28 2020
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
DBVERIFY - Verification starting : FILE = /u01/oradata/crmdb/datafile/dbs_d_jingyu.365.1041070633
DBVERIFY - Verification complete
Total Pages Examined : 12800
Total Pages Processed (Data) : 1998
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 312
Total Pages Failing (Index): 0
Total Pages Processed (Other): 10311
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 179
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 2168379 (0.2168379)
[ora11204@OEL-ASM rman]$
备库重新开启日志应用：
SQL> alter database open;
SQL> recover managed standby database using current logfile disconnect;
SQL> select * from v$dataguard_stats;
NAME VALUE UNIT TIME_COMPUTED DATUM_TIME
------------------------------ -------------------- ------------------------------ ------------------------------ ------------------------------
transport lag +00 00:00:00 day(2) to second(0) interval 06/08/2020 09:40:57 06/08/2020 09:40:56
apply lag +00 00:00:00 day(2) to second(0) interval 06/08/2020 09:40:57 06/08/2020 09:40:56
apply finish time day(2) to second(3) interval 06/08/2020 09:40:57
estimated startup time 32 second 06/08/2020 09:40:57
坏块消除后，再确认DG重新同步正常即可。
案例：DG主库未设置force logging导致备库坏块的更多相关文章
- linux下oracle11G DG搭建（三）：环绕备库搭建操作
linux下oracle11G DG搭建(三):环绕备库搭建操作 环境 名称 主库 备库 主机名 bjsrv shsrv 软件版本号 RedHat Enterprise5.5.Oracle 11g 1 ...
- 【转载】mysql主键的缺少导致备库hang
最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的 ...
- mysql主键的缺少导致备库hang
最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的 ...
- JqGrid 查询时未设置初始页码导致的问题
本文所述问题发生在查询的数据有至少2页数据时的情况下.本例中的产品质量查询就是这样. 第一步:查询该时间段内的数据,结果为13页的数据内容,显示当前页第1页.如下图所示: 第二步:点击翻页按钮,打开第 ...
- 安卓手机和ios手机上图片未设置宽度可能导致ios上图片贼小
处理方法: 设置固定宽度,高度自适应
- DG备库无法接受主库归档日志之密码文件
DG备库无法接受主库归档日志之密码文件 实验目的:还原某个客户案例,客户审计需要,对主库sys用户进行锁定,一小时后对sys用户进行解锁后,发现备库无法接受主库的归档日志 本篇文章,测试sys用户与D ...
- KingbaseES V8R3集群运维案例之---主库系统down failover切换过程分析
案例说明: KingbaseES V8R3集群failover时两个cluster都会触发,但只有一个cluster会调用脚本去执行真正的切换流程,另一个有对应的打印,但不会调用脚本,只是走相关的 ...
- DG之主库、备库切换（物理备库）
DG之主库.备库切换 一．开库与关库顺序 开库顺序 先启备库,再启主库(启动监听.打开告警日志) 关库顺序 先关主库,再关备库 二．主备库切换 1.操作过程一览 步骤1:启动备库.监听.告警: 步骤2 ...
- DG备库缺失归档文件GAP日志
问题现象: XXXsdgebus-dg GAP手工注册归档 #出现GAP idle>select * from v$archive_gap; THREAD# LOW_SEQUENCE# HIGH ...
随机推荐
- 读懂这几个关键词，你就能了解 Docker 啦
基于高度虚拟化所诞生的容器技术,如今已经走向大规模应用.那么容器.虚拟机.Docker.Openstack.Kubernetes 之间又有什么关系,对现在的选择有什么影响呢? 上世纪 60 年代,计算 ...
- 3.11 Go Struct结构体
3.11 Go Struct结构体 Golang支持OOP面向对象编程. Go的结构体struct如同python的class. Go基于struct实现OOP特性,只有组合composition这个 ...
- Django之ORM属性类型和约束条件
ORM属性类型: 1. CharField 字符串字段, 用于较短的字符串. CharField 要求必须有一个参数 maxlength, 用于从数据库层和Django校验层限制该 ...
- python3.x 基础四：json与pickple
每次打开一个文件,只dump1次 json.dump(dump的内容,文件句柄) json.load(文件句柄) json可以处理列表/字典/字符串等简单数据类型,但是不能处理复杂的数据类型,如函数的 ...
- sql语句 怎么从一张表中查询数据插入到另一张表中？
sql语句 怎么从一张表中查询数据插入到另一张表中? ----原文地址:http://www.phpfans.net/ask/MTc0MTQ4Mw.html 比如我有两张表 table1 字段 un ...
- 第三方动画库 Lottie嵌入记录
预览网址 https://lottiefiles.com/preview 在Podfile文件中加入 pod 'lottie-ios’ pod install 把 lottie-ios加入到项目中 ...
- E. Alternating Tree 树点分治|树形DP
题意:给你一颗树,然后这颗树有n*n条路径,a->b和b->a算是一条,然后路径的权值是 vi*(-1)^(i+1) 注意是点有权值. 从上头往下考虑是点分治,从下向上考虑就是树形DP, ...
- HDU3746 Cyclic Nacklace
题目链接:https://vjudge.net/problem/HDU-3746 知识点: KMP 解题思路: 论如何用 \(Next[]\) 数组求循环节. AC代码: #include <b ...
- PHP 连接数据库基础操作
<?phpheader('Content-type:text/html;charset=utf-8');//1建立 或者 关闭mysql服务器 @符号用于屏蔽错误信息$link=@mysql ...
- 第3章_关系数据库标准语言(SQL)_006_由元组关系演算到SQL Command_001_蕴含式 (其中有对EXISTS的分析)
前序的链接:元组关系演算 六. 蕴含式 ===>1. 什么是“蕴含式”===>设p.q为两个命题.复合命题“如果p,则q”称为p与q的蕴含式,记作p→q,并称p为蕴含式的前件,q为后件.定 ...