Dataguard巡检 - 常用查询、巡检命令、v$archived_log详解、问题记录

于 2024-08-05 08:15:00 发布
阅读量330 收藏 12
点赞数 13
分类专栏： 数据库 文章标签： 数据库 sql oracle
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_tank88921/article/details/140880173
版权

常用查询

环境检查

-- 查看数据库状态
select NAME,OPEN_MODE, PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;
-- 查看实例信息
select INSTANCE_NAME,STATUS,LOGINS,INSTANCE_ROLE from v$instance;
-- 查看归档路径信息
select dest_name,status,error from v$archive_dest;
-- 按照线程分组查看已经应用的最大的日志序列号
select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
-- 查看归档存放位置，所属线程、日志序列号，是否应用
select name,thread#,sequence#,applied from v$archived_log;
-- 查看有没有归档没有被应用，没有的话证明数据是同步的，没有丢任何数据（备库查询）
select name,thread#,sequence# from v$archived_log where applied='NO';
-- 查看日志第一次归档时间和下一次归档时间
select name,thread#,sequence#,applied,first_time,next_time from v$archived_log;
-- 查看归档是否有中断
select * from v$archive_gap;

主备切换

-- 环境检查
select NAME,OPEN_MODE, PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;
/*主库switchover状态为 session active说明还有活动的会话
  备库switchover状态为not allowed表示还不能切换*/
-- 备库查询（是否有未被应用的日志）
select THREAD#,SEQUENCE#,FIRST_TIME,NEXT_TIME,APPLIED from v$archived_log where APPLIED='NO';
-- 备库先取消恢复
alter database recover managed standby database cancel;
-- 主库操作（主库切备库）
alter database commit to switchover to physical standby;
or:
alter database commit to switchover to physical standby with session shutdown;
/*转换结束之后主库自动关闭*/

-- 启动主库
startup
-- 此时查询主库信息就会看到变为了备库
select NAME,OPEN_MODE, PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;



-- 备库操作（备库切主库）
alter database commit to switchover to primary;
or:
alter database commit to switchover to primary with session shutdown;
切换报错：ORA-16139
则恢复一下，再取消恢复
alter database recover managed standby database disconnect from session;
alter database recover managed standby database cancel;
然后再切换
alter database commit to switchover to primary;
or:
alter database commit to switchover to primary with session shutdown;
切换成功之后查看备库状态
select open_mode,database_role,switchover_status,protection_mode from v$database;
此时就可以看到备库变为了主库，同时备库的状态为mount
打开备库（新主库）
alter database open;


-- 新备库启动恢复
alter database recover managed standby database disconnect from session;
-- 查看归档序列是否一致
archive log list;

-- 新主库（原备库）测试：

conn /as sysdba;
create tablespace test_tbs2 datafile 'D:\oracle\oradata\dbsta\test2.dbf' size 100m autoextend off;
create user test_user2 identified by test default tablespace test_tbs2;
grant dba to test_user2;
create table test_user2.yk (id number);
insert into test_user2.yk values(666);
commit;
select * from test_user2.yk;
-- 主库切换归档之后备库才能查询到信息
alter system switch logfile;
-- 查看归档序列是否一致
archive log list;



-- 主备回切
-- 环境检查
select NAME,OPEN_MODE, PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;
/*主库switchover状态为 session active说明还有活动的会话
  备库switchover状态为not allowed表示还不能切换*/
-- 备库查询（是否有未被应用的日志）
select THREAD#,SEQUENCE#,FIRST_TIME,NEXT_TIME,APPLIED from v$archived_log where APPLIED='NO';
-- 备库先取消恢复
alter database recover managed standby database cancel;
-- 主库操作（主库切备库）
alter database commit to switchover to physical standby;
or:
alter database commit to switchover to physical standby with session shutdown;
/*转换结束之后主库自动关闭*/
-- 启动主库
startup
-- 此时查询主库信息就会看到变为了备库
select NAME,OPEN_MODE, PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS from v$database;



-- 备库操作（备库切主库）
alter database commit to switchover to primary;
or:
alter database commit to switchover to primary with session shutdown;
切换报错：ORA-16139
则恢复一下，再取消恢复
alter database recover managed standby database disconnect from session;
alter database recover managed standby database cancel;
然后再切换
alter database commit to switchover to primary;
or:
alter database commit to switchover to primary with session shutdown;
切换成功之后查看备库状态
select open_mode,database_role,switchover_status,protection_mode from v$database;
此时就可以看到备库变为了主库，同时备库的状态为mount
打开备库（新主库）
alter database open;


--新备库启动恢复
alter database recover managed standby database disconnect from session;
--查看归档序列是否一致
archive log list;

--新主库（原备库）测试：

conn /as sysdba;
create tablespace test_tbs3 datafile 'D:\oracle\oradata\dbpri\test3.dbf' size 100m autoextend off;
create user test_user3 identified by test default tablespace test_tbs3;
grant dba to test_user3;
create table test_user3.yk (id number);
insert into test_user3.yk values(666);
commit;
select * from test_user3.yk;
--主库切换归档之后备库才能查询到信息
alter system switch logfile;
--查看归档序列是否一致
archive log list;

归档删除策略配置

#归档删除策略（在主库和备库配置归档删除策略）
#备库：
rman target sys/Q1w2e3r4@dgplatform
configure archivelog deletion policy to applied on standby;

#主库：
rman target /
configure archivelog deletion policy to applied on all standby;
 
配这个参数的意义：假设配置的归档删除策略是3天后删除归档，则3天后归档就会被删除，不配置这个参数，即便是归档没有应用到备库，归档也被删除了，这就导致主备数据不一致了，配置了这个参数之后，要删除归档前提是归档应用到了备库，这样才能删除

数据库启停操作

-- 关机
先关主库，再关备库
关闭备库前，做取消恢复操作
alter database recover managed standby database cancel;
关闭主库与备库的监听程序
lsnrctl stop
关闭OS


-- 开机
先开备库，再开主库
进去备库，
启动监听程序
lsnrctl start
启动备库数据库：
startup
选择一种恢复方式：
#归档式同步
alter database recover managed standby database disconnect from session;
#实时同步：
alter database recover managed standby database using current logfile disconnect from session;
然后启动主库

巡检命令

-- 检查归档序列信息
archive log list;

-- 当前时间与预计下次产生归档的时间的间隔
select 'standby gap is: ' || to_char(apply_lag) || ' minute at ' || to_char(sysdate, 'yyyy-mm-dd hh24:mi')||' DATABASE: testdb' as warn_message
from (select round((sysdate - MAX(G.NEXT_TIME))*1440) as apply_lag
      from v$archived_log G
	  where G.applied = 'YES');

-- apply lag（备库应用延迟），transport lag（日志传输延迟）
select NAME,VALUE from v$dataguard_stats where regexp_like(name,'lag');

v$archived_log详解

V$ARCHIVED_LOG视图描述了系统中已经归档的日志文件的相关信息。归档日志是ARCHIVELOG模式的一种，用来记录DML以及DDL对数据库中对象所做的更改，保护数据库以及实施重做数据库恢复。

V$ARCHIVED_LOG视图的主要用途是查看已经归档的日志的信息，确定要恢复的日志。可以直接执行：

#查询当前被归档日志的相关信息
SELECT ARCHIVED, DELETED, SEQUENCE#, RESETLOGS_CHANGE#,
FLAGS, ARCHIVE_DATE, ARCHIVE_SCN, SESSION_INFO
FROM V$ARCHIVED_LOG;

V$ARCHIVED_LOG displays archived log information from the control file, including archive log names.

An archive log record is inserted after the online redo log is successfully archived or cleared (name column is NULL if the log was cleared). If the log is archived twice, there will be two archived log records with the same THREAD#, SEQUENCE#, and FIRST_CHANGE#, but with a different name. An archive log record is also inserted when an archive log is restored from a backup set or a copy and whenever a copy of a log is made with the RMAN COPY command.

ColumnDatatypeDescription解释
RECIDNUMBERArchived log record ID归档日志记录的唯一标识号
STAMPNUMBERArchived log record stamp时间戳，与RECID一起构成归档日志记录的全局唯一标识
NAMEVARCHAR2(513)Archived log file name. If set to NULL, either the log file was cleared before it was archived or an RMAN backup command with the “delete input” option was executed to back up archivelog all (RMAN> backup archivelog all delete input;).归档日志文件名
DEST_IDNUMBEROriginal destination from which the archive log was generated. The value is 0 if the destination identifier is not available.归档生成的目标
THREAD#NUMBERRedo thread number数据库线程的编号。Oracle数据库可以由多个线程组成，每个线程负责处理特定的事务。
SEQUENCE#NUMBERRedo log sequence number归档日志的序列号。表示日志的生成顺序。
RESETLOGS_CHANGE#NUMBERResetlogs change number of the database when the log was written重置日志序列号，用于标识新的一组日志
RESETLOGS_TIMEDATEResetlogs time of the database when the log was written日志重置的时间戳编号
RESETLOGS_IDNUMBERResetlogs identifier associated with the archived redo log重置日志的时间戳
FIRST_CHANGE#NUMBERFirst change number in the archived log归档日志中第一个重做记录的重做号（Redo Log Sequence Number）
FIRST_TIMEDATETimestamp of the first change归档日志的创建时间
NEXT_CHANGE#NUMBERFirst change in the next log归档日志中最后一个重做记录的重做号
NEXT_TIMEDATETimestamp of the next change下一个归档日志的预计创建时间
BLOCKSNUMBERSize of the archived log (in blocks)归档日志的块数
BLOCK_SIZENUMBERRedo log block size. This is the logical block size of the archived log, which is the same as the logical block size of the online log from which the archived log was copied. The online log logical block size is a platform-specific value that is not adjustable by the user.归档日志块的大小
CREATORVARCHAR2(7)Creator of the archivelog:
ARCH – Archiver process
FGRD – Foreground process
RMAN – Recovery Manager
SRMN – RMAN at standby
LGWR – Logwriter process		触发归档的原因
REGISTRARVARCHAR2(7)Registrar of the entry:
RFS – Remote File Server process
ARCH – Archiver process
FGRD – Foreground process
RMAN – Recovery manager
SRMN – RMAN at standby
LGWR – Logwriter process		条目注册
STANDBY_DESTVARCHAR2(3)Indicates whether the entry is an archivelog destination (YES) or not (NO)显示条目是否是归档日志目标
ARCHIVEDVARCHAR2(3)Indicates whether the online redo log was archived (YES) or whether RMAN only inspected the log and created a record for future application of redo logs during recovery (NO).显示是否归档(YES)或是否是RMAN恢复创建的记录(NO)
APPLIEDVARCHAR2(9)Indicates whether an archived redo log file has been applied to the corresponding physical standby database. The value is always NO for local destinations.This column is meaningful on a physical standby database for rows where REGISTRAR = RFS:If REGISTRAR = RFS and APPLIED = NO, then the log file has been received but has not yet been applied.If REGISTRAR = RFS and APPLIED = IN-MEMORY, then the log file has been applied in memory, but the data files have not yet been updated.If REGISTRAR = RFS and APPLIED = YES, then the log file has been applied and the data files have been updated.This column can be used to identify log files that can be backed up and deleted. When used for this purpose, the value IN-MEMORY should be treated as if it were NO.显示归档日志已被应用到了physical standby中,对本地节点值为NO在物理standby中的意义：
REGISTRAR=RFS && APPLIED=NO,表示logfile已被接受并注册但没有应用
REGISTRAR=RFS && APPLIED=IN-MEMORY,表示在内存中已应用logfile,还没有更新到datafiles中
REGISTRAR=RFS && APPLIED=YES,表示已应用logfile并更新到datafiles
DELETEDVARCHAR2(3)Indicates whether an RMAN DELETE command has physically deleted the archived log file from disk, as well as logically removing it from the control file of the target database and from the recovery catalog (YES) or not (NO)显示是否使用了RMAN DELETE命令物理删除了归档日志,是否在逻辑上从controlfile恢复目录移除(YES/NO)
STATUSVARCHAR2(1)Status of the archived log:
A – Available
D – Deleted
U – Unavailable
X – Expired		归档日志状态
COMPLETION_TIMEDATETime when the archiving completed归档完成时间
DICTIONARY_BEGINVARCHAR2(3)Indicates whether the log contains the start of a LogMiner dictionary (YES) or not (NO)显示是否是LogMiner数据字典包含日志的开始(YES/NO)
DICTIONARY_ENDVARCHAR2(3)Indicates whether the log contains the end of a LogMiner dictionary (YES) or not (NO)显示是否是LogMiner数据字典包含日志的结束(YES/NO)
END_OF_REDOVARCHAR2(3)Indicates whether the archived redo log contains the end of all redo information from the primary database (YES) or not (NO)显示primary端归档日志是否包含redo结束信息
BACKUP_COUNTNUMBERIndicates the number of times this file has been backed up. Values range from 0-15. If the file has been backed up more than 15 times, the value remains 15.显示文件被备份的次数(0-15),如果次数超出15,则保留显示为15
ARCHIVAL_THREAD#NUMBERRedo thread number of the instance that performed the archival operation. This column differs from the THREAD# column only when a closed thread is archived by another instance.执行归档操作的实例线程号,当关闭的线程被其他实例归档时值与THREAD#不同
ACTIVATION#NUMBERNumber assigned to the database instantiation被实例分配的次数
IS_RECOVERY_DEST_FILEVARCHAR2(3)Indicates whether the file was created in the fast recovery area (YES) or not (NO)显示文件是否被创建到fast recovery ares(YES/NO)
COMPRESSEDVARCHAR2(3)Reserved for internal use保留作内部使用
FALVARCHAR2(3)Indicates whether the archive log was generated as the result of a FAL request (YES) or not (NO)显示归档日志是否为FAL请求产生的(YES/NO)
END_OF_REDO_TYPEVARCHAR2(10)Possible values are as follows:
SWITCHOVER – Shows archived redo log files that are produced at the end of a switchover
TERMINAL – Shows archived redo log files produced after a failover
RESETLOGS – Shows online redo log files archived on the primary database after an ALTER DATABASE OPEN RESETLOGS statement is issued
ACTIVATION – Shows any log files archived on a physical standby database after an ALTER DATABASE ACTIVATE STANDBY DATABASE statement is issued
empty string – Any empty string implies that the log is just a normal archival and was not archived due to any of the other events		SWITCHOVER ：Switchover产生的EOR
TERMINAL : Failover产生的EOR
RESETLOGS : 主库执行ALTER DATABASE OPEN RESETLOGS语句后产生的归档
ACTIVATION ：物理standby执行ALTER DATABASE ACTIVATE STANDBY DATABASE语句后产生的归档
空值 ：正常的归档
BACKED_BY_VSSVARCHAR2(3)Whether or not the file has been backed up by Volume Shadow Copy Service (VSS). This column is reserved for internal use.显示文件是否以Volume Shadow Copy Service(VSS)备份,保留作内部使用
CON_IDNUMBERThe ID of the container to which the data pertains. Possible values include:0: This value is used for rows containing data that pertain to the entire CDB. This value is also used for rows in non-CDBs.1: This value is used for rows containing data that pertain to only the rootn: Where n is the applicable container ID for the rows containing data容器ID，对于多租户数据库，用于标识租户的容器

问题记录

版本bug

DataGuard利用backup incremental from scn解决gap，11.2.0.4 v$archive_gap不显示存在的gap
https://blog.csdn.net/jwocnimabi/article/details/103200164

DataGuard ORA-01111 问题处理

https://blog.51cto.com/dbadadong/5196056

https://blog.csdn.net/sandy9919/article/details/84956266

参考资料

https://www.modb.pro/db/42408

穷苦书生_万事愁
关注
  • 13
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
oracle表v$log,v$archived_log 与v$log_history区别在哪里
weixin_40003233的博客
04-12 1338
用了很长时间的2机dataguard在物理standby机器上执行select max(sequence#) from v$archived_log;102select max(sequence#) from v$log_history;99过去几分钟后select max(sequence#) from v$archived_log;102select max(sequence#) from v...
DataGuard 问题集1 ----V$DATAGUARD_STATS的transport lag, apply lag的增长
weixin_56440136的博客
04-08 1907
DataGuard 问题集1 ----V$DATAGUARD_STATS的transport lag, apply lag的增长 现象： 2node RAC Primary–2node RAC Standby环境 DataGuard的同步没有问题，但是V$DATAGUARD_STATS的transport lag, apply lag有增长的趋势，并且越来越大。 这篇文章记录了我的分析解决过程。虽然绕了弯子，但是让我认识了RAC DataGuard的一些POINT，加深了理解。 客户提供的确认command
Oracle数据库 v$dataguard_stats
weixin_tank88921的博客
07-21 492
在一套Dataguard环境下，如果需要做failover Role Transition的话，建议先在备库上通过查询V$DATAGUARD_STATS视图来估算failover切换需要的时间在官方文档上，关于V$DATAGUARD_STATS是这样描述的：该动态性能视图显示出在主库上产生了多少重做日志数据，但是还没有被备库所应用。所以，通过查询该视图可以基本确定如果万一主库出现崩溃的话，备库上将丢失多少重做日志数据。
查询v$asm_disk v$asm_disk_stat v$asm_diskgroup Hang住
喝醉酒的小白
03-22 1938
问题 查看等待事件 select inst_id,sid,username,event,state,blocking_session from gv$session where username is not null; v$asm_disk_stat v$asm_diskgroup Hang住 v$asm_disk Hang住 select inst_id,sid,username,event,state,blocking_session from gv$session where userna
Oracle存在gap,ORACLE DATAGUARD中手工处理日志v$archive_GAP的方法
weixin_39712969的博客
04-07 143
从9i以后，oracle dataguard 备库一般都不需要手工处理丢失的日志，FAL自动会帮我们处理，下面通过个案例来讲下手工处理丢失的日志的方法:1.在备库查询有哪些日志丢失，没应用到备库select * from V$ARCHIVE_GAP;THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- ------------- --------------...
oracle 日志表 v$,ORACLE DATAGUARD中手工处理日志v$archive_GAP的方法
weixin_33498081的博客
04-03 122
从9i以后，oracle dataguard 备库一般都不需要手工处理丢失的日志，FAL自动会帮我们处理，下面通过个案例来讲下手工处理丢失的日志的方法:1.在备库查询有哪些日志丢失，没应用到备库SQL> select * from V$ARCHIVE_GAP;THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- ------------- ------...
关于dataguard需要查询的数据字典
cmbzwa6940的博客
12-17 498
主库： v$managed_standby v$archive_dest_status v$archive_dest 备库： v$archived_log 解释：关...
4.Oracle-Dataguard维护常用命令
weixin_43346403的博客
02-08 761
OracleDataguard维护
DG standby库v$standby_log视图异常
10-15 524
备库修改standb log文件位置后查询v$standby_log报错 SQL>select * from v$standby_log ORA-00314: log 9 of thread 1, expected...
ORACLE DATAGUARD中手工处理日志v$archive_GAP的方法
09-10
我们可以通过查看数据库日志或查询`V$ARCHIVED_LOG`视图的`APPLIED`字段来确认日志是否已被成功应用。如果`APPLIED`字段为`YES`，则表明日志已应用。 5. **验证无日志GAP**：最后，再次查询`V$ARCHIVE_GAP`视图，...
关于Oracle Dataguard 日志传输状态监控问题
09-09
5. **已应用的REDO日志**：查询`V$LOG_HISTORY`视图可以获取已应用于redo日志的历史记录，包括线程号、序列号、首次变更号和下次变更号，有助于跟踪日志应用过程。 6. **检查日志传输GAP**：`V$ARCHIVE_DEST_STATUS...
数据库巡检脚本.txt
11-19
### 数据库巡检脚本详解 #### 一、概述 在数据库管理中，定期进行数据库巡检是一项重要的工作，它可以帮助我们及时发现并解决数据库存在的问题，确保数据库系统的稳定运行。给定的“数据库巡检脚本”主要针对Oracle...
(完整版)Oracle-DataGuard建立维护恢复V1.2.doc
11-15
Oracle DataGuard 是 Oracle 数据库的一种高可用性和灾难恢复解决方案，它提供了一套全面的数据保护机制，确保在主数据库出现故障时能够快速切换到备用数据库，从而最大限度地减少数据丢失和业务中断。本文档将详细...
简单的 mongoDB 学习
qq_19342829的博客
07-31 531
mongodb入门学习整理
社区养老服务小程序的设计
Karen198的博客
07-31 578
管理员账户功能包括：系统首页，个人中心，用户管理，服务人员管理，服务产品管理，服务预约管理，服务状态管理，服务退订管理，活动管理，视频管理。主要技术：Java,Spring,mybatis,mysql,jquery,html。服务器：SpringBoot自带 apache tomcat。微信端账号功能包括：系统首页，服务产品，活动，视频，我的。JDK版本：Java JDK1.8。数据库可视化工具： navicat。数据库版本： mysql5.7。开发工具：IDEA(推荐)开发系统：Windows。
二进制部署k8s集群之master节点和etcd数据库集群（上）
zx52306的博客
07-30 1206
【代码】二进制部署k8s集群之master节点和etcd数据库集群（上）
MySQL备份与恢复
最新发布
m0_74860678的博客
08-01 579
在生产环境中，数据的安全性至关重要任何数据的丢失都可能产生严重的后果造成数据丢失的原因程序错误人为操作错误运算错误磁盘故障灾难（如火灾、地震）和盗窃# 开启二进制日志功能[mysqld]# 重启服务# 有 mysql-bin.000001 就代表成功。
杂谈 | windows批处理脚本 | 配置项目环境变量
zwcslj的博客
07-31 1264
命令回显功能是指在运行命令或脚本时，系统将命令的执行过程和结果显示在屏幕上，使用户能够实时地看到命令的执行情况。通常，当命令回显功能打开时，在执行每一步命令时，系统将会显示执行的命令本身以及对应的结果，从而帮助用户了解命令的执行过程，排查可能出现的问题。关闭回显时，命令提示符不会出现在“命令提示符”窗口中。若要再次显示命令提示符，请键入 echo on。
V$DATAGUARD_STATS这是一个视图吗
06-08
是的，V$DATAGUARD_STATS是Oracle数据库中的一个视图，用于显示Data Guard的统计信息和状态信息。在Oracle数据库中，以V$开头的视图一般都是动态性能视图，用于显示数据库的各种状态信息。这些视图的数据是从内存中的动态性能数据结构中读取的，可以及时地反映数据库的状态。 V$DATAGUARD_STATS视图显示了Data Guard的各种状态信息和统计信息，包括主库和备库的同步状态、重做应用状态、网络传输状态等等。通过查询这个视图，可以了解Data Guard的整体状态和性能状况，有助于进行故障排查和性能调优。 需要注意的是，访问V$DATAGUARD_STATS视图需要有相应的权限。在查询视图时需要使用SELECT语句，并指定需要查询的列名，例如： ``` SELECT NAME, VALUE FROM V$DATAGUARD_STATS; ``` 这个查询语句将会显示Data Guard的所有状态信息和统计信息。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值