oracle 容灾库日常维护 ,健康检查脚本 以及常见问题分析

select DEST_ID, APPLIED_SCN FROM v$archive_dest 

select * from v$dataguard_status;

 SELECT gvi.thread#, timestamp, message FROM gv$dataguard_status gvds, gv$instance gvi WHERE gvds.inst_id = gvi.inst_id AND severity in ('Error','Fatal') ORDER BY timestamp, thread#; 

 

 

1.日常维护

1.停止Standby
select process, status from v$managed_standby; --查看备库是否在应用日志进行恢复
alter database recover managed standby database cancel;
shutdown immediate;
 
2.切换到只读模式
-----由shutdown模式切换到只读模式-------
startup nomount;
alter database mount standby database;
alter database open read only;
-----由应用日志模式切换到只读模式-------
alter database recover managed standby database cancel;-- 取消日志应用
alter database open read only;
 
3.切换回管理恢复模式
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;-- 启动日志应用
alter database recover managed standby database using current logfile disconnect from session;
 
4.

-查看应用日志延迟时间:

select value from v$dataguard_stats where name='apply lag';

 

-查看接收日志延迟时间:

select value from v$dataguard_stats where name='transport lag';

 

-查看主库归档

Primary: SQL> select thread#, max(sequence#) "Last Primary Seq Generated"

from v$archived_log val, v$database vdb

where val.resetlogs_change# = vdb.resetlogs_change#

group by thread# order by 1;

 

-查看备库已接收归档

PhyStdby:SQL> select thread#, max(sequence#) "Last Standby Seq Received"

from v$archived_log val, v$database vdb

where val.resetlogs_change# = vdb.resetlogs_change#

group by thread# order by 1;

 

-查看备库已应用归档

PhyStdby:SQL>select thread#, max(sequence#) "Last Standby Seq Applied"

from v$archived_log val, v$database vdb

where val.resetlogs_change# = vdb.resetlogs_change#

and val.applied in ('YES','IN-MEMORY')

group by thread# order by 1;

 

-查看归档应用详细情况

select first_time,sequence#,applied from v$archived_log;

 

-查看主备库GAP

select * from v$archive_gap;

  
 
 
11g 备库上面 停止MRP ,启动MRP

 
SQL> recover managed standby database cancel; 
Media recovery complete. 
startup mount;



SQL> recover managed standby database using current logfile disconnect; 
Media recovery complete. 
SQL> select open_mode,database_role,log_mode,flashback_on from v$database; 
 

 
 
4.主库和备库之间角色切换
4.1 主库切换为备库
alter database commit to switchover to physical standby;
alter database commit to switchover to physical standby with session shutdown;-- 主库有会话连接的时候
shutdown immediate
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;
 
4.2 从库切换为主库
alter database commit to switchover to primary;
shutdown immediate;
startup
alter system switch logfile;
 
5.备库自动使用主库传过来的日志进行恢复
alter database recover automatic standby database;
 
6.更改保护模式
alter database set standby database to maximize protection;
alter database set standby database to maximize availability;
alter database set standby database to maximize performancen;
 
7.取消自动恢复模式
alter database recover managed standby database cancel;
alter database recover managed standby database finish;
alter database recover managed standby database finish force;

 
8.

FAL_CLIENT和FAL_SERVER是配置dataguard用到的两个参数,FAL指获取归档日志(Fetch Archived Log)

在一定的条件下,或者因为网络失败,或者因为资源紧张,会在primary和standby之间产生裂隙,也就是有些归档日志没有及时的传输并应用到standby库。因为MRP(managed recovery process)/LSP(logical standby process)没有与primary直接通讯的能力来获取丢失的归档日志。因此这些gaps通过FAL客户和服务器来解决,由初始化参数定义FAL_CLIENT和FAL_SERVER。

 

 

FAL_SERVER指定一个Oracle Net service name,standby数据库使用这个参数连接到FAL server,这个参数适用于standby站点。

 

比如,FAL_SERVER = PrimaryDB,此处PrimaryDB是一个TNS name,指向primary库。

 

FAL_CLIENT指定一个FAL客户端的名字,以便FAL Server可以引用standby库,这也是一个TNS name,primary库必须适当配置此TNS name指向stanby库。这个参数也是在standby库端设置。比如,

 

FAL_CLIENT = StandbyDB,StandbyDB是standby库的TNS name。

FAL_CLIENT和FAL_SERVER应该成对设置或改变。

这两个参数只需在standby库设置,但也可以在primary库设置这两个参数,以方便switchover或failover时primary库转变为standby角色。

 

alter system set fal_server='db1-old,db2-old';

ALTER SYSTEM SET fal_client='db2-1-old' SID='db2';

 
###11g Real-Time Apply
 
when pysical is  read-only status, can also active mrp as follows: 
 
 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 

【Oracle官方文档中对Real-Time Apply介绍】

If the real-time apply feature is enabled, apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.

Use the ALTER DATABASE statement to enable the real-time apply feature, as follows:

  • For physical standby databases, issue the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE statement.



转自:http://blog.csdn.net/robbie1314520/article/details/8267283

 

2. 检查脚本 check script:

Primary Site Script

===============================================================================

-- This script is to be run on the Primary of a Data Guard Physical Standby Site

set echo off
set feedback off
column timecol new_value tstamp
column spool_extension new_value suffix
select to_char(sysdate,'Mondd_hhmi') timecol from sys.dual;
column output new_value dbname
select value || '_' output from v$parameter where name = 'db_name';

-- Output the results to this file

spool dg_Primary_diag_&&dbname&&tstamp
set lines 132
set pagesize 500
set numformat 999999999999999
set trim on
set trims on

-- Get the current Date

alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
set feedback on
select systimestamp from dual;

-- Primary Site Details
set heading off
set feedback off
select 'Primary Site Details' from dual;
select '********************' from dual;
set heading on
set feedback on

col db_unique_name format a15
col flashb_on format a10

select DB_UNIQUE_NAME,DATABASE_ROLE DB_ROLE,FORCE_LOGGING F_LOG,FLASHBACK_ON FLASHB_ON,LOG_MODE,OPEN_MODE,
GUARD_STATUS GUARD,PROTECTION_MODE PROT_MODE
from v$database;

-- Current SCN - this value on the primary and standby sites where real time apply is in place should be nearly the same

set heading off
set feedback off
select 'Primary Site last generated SCN' from dual;
select '*******************************' from dual;
set heading on
set feedback on

select DB_UNIQUE_NAME,SWITCHOVER_STATUS,CURRENT_SCN from v$database;

set heading off
set feedback off
select 'Standby Site last applied SCN' from dual;
select '*****************************' from dual;
set heading on
set feedback on

select DEST_ID, APPLIED_SCN FROM v$archive_dest WHERE TARGET='STANDBY';


-- Incarnation Information
--

set heading off
set feedback off
select 'Incarnation Destination Configuration' from dual;
select '*************************************' from dual;
set heading on
set feedback on

select INCARNATION# INC#, RESETLOGS_CHANGE# RS_CHANGE#, RESETLOGS_TIME, PRIOR_RESETLOGS_CHANGE# PRIOR_RS_CHANGE#, STATUS,FLASHBACK_DATABASE_ALLOWED FB_OK from v$database_incarnation;

-- Archivelog Destination Details
--

set heading off
set feedback off
select 'Archive Destination Configuration' from dual;
select '*********************************' from dual;
set heading on
set feedback on

-- Current Archive Locations
--

column host_name format a30 tru
column version format a10 tru
select INSTANCE_NAME,HOST_NAME,VERSION,ARCHIVER from v$instance;

column destination format a35 wrap
column process format a7
column archiver format a8
column dest_id format 99999999

select DEST_ID,DESTINATION,STATUS,TARGET,ARCHIVER,PROCESS,REGISTER,TRANSMIT_MODE
from v$archive_dest
where DESTINATION IS NOT NULL;

column name format a22
column value format a100
select NAME,VALUE from v$parameter where NAME like 'log_archive_dest%' and upper(VALUE) like 'SERVICE%';

set heading off
set feedback off
select 'Archive Destination Errors' from dual;
select '**************************' from dual;
set heading on
set feedback on

column error format a55 tru
select DEST_ID,STATUS,ERROR from v$archive_dest
where DESTINATION IS NOT NULL;

column message format a80
select MESSAGE, TIMESTAMP
from v$dataguard_status
where SEVERITY in ('Error','Fatal')
order by TIMESTAMP;

-- Redo Log configuration
-- The size of the standby redo logs must match exactly the size on the online redo logs

set heading off
set feedback off
select 'Data Guard Redo Log Configuration' from dual;
select '*********************************' from dual;
set heading on
set feedback on

select GROUP# STANDBY_GROUP#,THREAD#,SEQUENCE#,BYTES,USED,ARCHIVED,STATUS from v$standby_log order by GROUP#,THREAD#;

select GROUP# ONLINE_GROUP#,THREAD#,SEQUENCE#,BYTES,ARCHIVED,STATUS from v$log order by GROUP#,THREAD#;

-- Data Guard Parameters
--
set heading off
set feedback off
select 'Data Guard Related Parameters' from dual;
select '*****************************' from dual;
set heading on
set feedback on

column name format a30
column value format a100
select NAME,VALUE from v$parameter where NAME IN ('db_unique_name','cluster_database','dg_broker_start','dg_broker_config_file1','dg_broker_config_file2','fal_client','fal_server','log_archive_config','log_archive_trace','log_archive_max_processes','archive_lag_target','remote_login_password_file','redo_transport_user') order by name;


-- Redo Shipping Progress

set heading off
set feedback off
select 'Data Guard Redo Shipping Progress' from dual;
select '*********************************' from dual;
set heading on
set feedback on

select systimestamp from dual;

column client_pid format a10
select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;

host sleep 10

select systimestamp from dual;

select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;

host sleep 10

select systimestamp from dual;

select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;


set heading off
set feedback off
select 'Data Guard Errors in the Last Hour' from dual;
select '**********************************' from dual;
set heading on
set feedback on

select TIMESTAMP,SEVERITY,ERROR_CODE,MESSAGE from v$dataguard_status where timestamp > systimestamp-1/24;
spool off

================================================================================

 

Standby Site Script

================================================================================

-- This script is to be run on the Standby of a Data Guard Physical Standby Site

set echo off
set feedback off
column timecol new_value tstamp
column spool_extension new_value suffix
select to_char(sysdate,'Mondd_hhmi') timecol from sys.dual;
column output new_value dbname
select value || '_' output from v$parameter where name = 'db_name';

-- Output the results to this file

spool dg_Standby_diag_&&dbname&&tstamp
set lines 132
set pagesize 500
set numformat 999999999999999
set trim on
set trims on

-- Get the current Date

set feedback on
select systimestamp from dual;

-- Standby Site Details
set heading off
set feedback off
select 'Standby Site Details' from dual;
select '********************' from dual;
set heading on
set feedback on

col db_unique_name format a15
col flashb_on format a10

select DB_UNIQUE_NAME,DATABASE_ROLE DB_ROLE,FORCE_LOGGING F_LOG,FLASHBACK_ON FLASHB_ON,LOG_MODE,OPEN_MODE,
GUARD_STATUS GUARD,PROTECTION_MODE PROT_MODE
from v$database;

-- Current SCN - this value on the primary and standby sites where real time apply is in place should be nearly the same

select DB_UNIQUE_NAME,SWITCHOVER_STATUS,CURRENT_SCN from v$database;

-- Incarnation Information
--

set heading off
set feedback off
select 'Incarnation Destination Configuration' from dual;
select '*************************************' from dual;
set heading on
set feedback on

select INCARNATION# INC#, RESETLOGS_CHANGE# RS_CHANGE#, RESETLOGS_TIME, PRIOR_RESETLOGS_CHANGE# PRIOR_RS_CHANGE#, STATUS,FLASHBACK_DATABASE_ALLOWED FB_OK from v$database_incarnation;


set heading off
set feedback off
select 'Archive Destination Configuration' from dual;
select '*********************************' from dual;
set heading on
set feedback on
-- Current Archive Locations
--

column host_name format a30 tru
column version format a10 tru
select INSTANCE_NAME,HOST_NAME,VERSION,ARCHIVER from v$instance;

column destination format a35 wrap
column process format a7
column archiver format a8
column dest_id format 99999999

select DEST_ID,DESTINATION,STATUS,TARGET,ARCHIVER,PROCESS,REGISTER,TRANSMIT_MODE
from v$archive_dest
where DESTINATION IS NOT NULL;

column name format a22
column value format a100
select NAME,VALUE from v$parameter where NAME like 'log_archive_dest%' and upper(VALUE) like 'SERVICE%';

set heading off
set feedback off
select 'Archive Destination Errors' from dual;
select '**************************' from dual;
set heading on
set feedback on

column error format a55 tru
select DEST_ID,STATUS,ERROR from v$archive_dest
where DESTINATION IS NOT NULL;

column message format a80
select MESSAGE, TIMESTAMP
from v$dataguard_status
where SEVERITY in ('Error','Fatal')
order by TIMESTAMP;

-- Redo Log configuration
-- The size of the standby redo logs must match exactly the size on the online redo logs

set heading off
set feedback off
select 'Data Guard Redo Log Configuration' from dual;
select '*********************************' from dual;
set heading on
set feedback on

select GROUP# STANDBY_GROUP#,THREAD#,SEQUENCE#,BYTES,USED,ARCHIVED,STATUS from v$standby_log order by GROUP#,THREAD#;

select GROUP# ONLINE_GROUP#,THREAD#,SEQUENCE#,BYTES,ARCHIVED,STATUS from v$log order by GROUP#,THREAD#;

-- Data Guard Parameters
--
set heading off
set feedback off
select 'Data Guard Related Parameters' from dual;
select '*****************************' from dual;
set heading on
set feedback on

column name format a30
column value format a100
select NAME,VALUE from v$parameter where NAME IN ('db_unique_name','cluster_database','dg_broker_start','dg_broker_config_file1','dg_broker_config_file2','fal_client','fal_server','log_archive_config','log_archive_trace','log_archive_max_processes','archive_lag_target','remote_login_password_file','redo_transport_user') order by name;

-- Managed Recovery State

set heading off
set feedback off
select 'Data Guard Apply Status' from dual;
select '***********************' from dual;
set heading on
set feedback on

select systimestamp from dual;

column client_pid format a10
select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;

host sleep 10

select systimestamp from dual;

select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;

host sleep 10

select systimestamp from dual;

select PROCESS,STATUS,CLIENT_PROCESS,CLIENT_PID,THREAD#,SEQUENCE#,BLOCK#,ACTIVE_AGENTS,KNOWN_AGENTS
from v$managed_standby order by CLIENT_PROCESS,THREAD#,SEQUENCE#;


set heading off
set feedback off
select 'Data Guard Apply Lag' from dual;
select '********************' from dual;
set heading on
set feedback on

column name format a12
column lag_time format a20
column datum_time format a20
column time_computed format a20
SELECT NAME, VALUE LAG_TIME, DATUM_TIME, TIME_COMPUTED
from V$DATAGUARD_STATS where name like 'apply lag';

-- If there is a lag remove the comment for the select below
--SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' AND COUNT > 0;

set heading off
set feedback off
select 'Data Guard Gap Problems' from dual;
select '***********************' from dual;
set heading on
set feedback on

select * from v$archive_gap;

set heading off
set feedback off
select 'Data Guard Errors in the Last Hour' from dual;
select '**********************************' from dual;
set heading on
set feedback on

select TIMESTAMP,SEVERITY,ERROR_CODE,MESSAGE from v$dataguard_status where timestamp > systimestamp-1/24;
spool off

 

 

3.############### 常见问题1

https://blog.csdn.net/huangliang0703/article/details/46558995

由dg中的db_file_name_convert参数不生效想到的db_file_create

 

-》 就是说,如果db_file_create这个参数有值,那么就是启用了omf(oracle的一种自动文件管理方式) 它的优先级要高于convert参数设置。

 

oracle搭建dg过程中涉及到一个参数db_file_name_convert

这个参数在备库库参数中是成对出现的,比如主库数据文件有两个路径

+DATA和+DATAA两个路径,'+DATA/orcl/datafile/user01.dbf',‘+DATAA/ocrl/datafile/user05.dbf''

本地路径为/oradata/orcl/datafile/

此时备库该参数这样写

alter system set DB_FILE_NAME_CONVERT='+DATA/orcl/datafile/','/oradata/orcl/datafile/', '+DATAA/orcl/datafile/','/oradata/orcl/datafile/', scope=spfile;    

设置完搭建测试dg备库日志同步没有问题,主库创建一个表空间,备库没有跟随生成,或者在一个其他位置$ORACLE_HOME/dbs下生成一个uname的文件

检查convert 参数没有问题,检查STANDBY_FILE_MANAGEMENT为auto

没有问题

后来查询oracle官方文档发现我的db_create_file='/u01....'

是这个参数在起作用。

就是说,如果db_file_create这个参数有值,那么就是启用了omf(oracle的一种自动文件管理方式)

它的优先级要高于convert参数设置。

 

另外在备库正常运行的过程中STANDBY_FILE_MANAGEMENT参数是auto;如果是维护状态要改为mananul,比如上面我要删掉那个uname的文件。

 

 

 

 
 
4、 ###############################
 

 

-》db_file_name_convert   在日常运维 生效 ,主库新加数据文件,备库也根据配置 增加数据文件位置

-》log_file_name_convert    在日常运维 不生效,主库新加日志文件, 备库不会根据配置 新加日志。

                                          只在搭建DG 环境时候,生效

 

分类: Oracle

2011-05-28 22:28:49

 
问题:今天就dataguard从库参数中的db_file_name_convert和log_file_name_convert两个参数的作用和别人争论了很久,只知道这两个参数用来转换路径,但是不知道具体怎么工作。

     回来后上网查这两个参数的具体作用,一无所获。看来只有靠自己,通过分析主从库的参数文件、控制文件,总结了一些结论。只是自己的结论,是否准确尚不知道,如果有错误,欢迎指出。
 
从库参数文件中db_file_name_convert和log_file_name_convert的作用:
 
下面通过跟踪恢复从库的过程来分析这两个参数文件的作用:
1.dataguard的主库完全备份数据库;

2.将主库的完全备份复制到从库的相应位置

3.恢复从库,下面到了最关键部分了

1>用主库的备份来恢复从库,可以想到从库恢复出来中的控制文件和主库的控制一样。但是我们要记住,主从库的数据文件路径、联机日志路径不同;如果从库恢复出的控制文件和主库的控制文件相同是绝对不行的。那怎么不呢?

2>最关键的参数要用到了,那就是db_file_name_convert和log_file_name_convert
  从库通过主库的备份恢复控制文件--->恢复控制文件时,oracle查看从库参数文件中的db_file_name_convert和log_file_name_convert参数---->将主库保存数据文件、联机日志的路径转换成从库保存数据文件、联机日志的路径---->生成从库的控制文件
 
所以,db_file_name_convert和log_file_name_convert这两个参数像桥梁一样,来完成转换dataguard的主库和从库数据文件和联机日志保存路径不同的问题。

 

 

###########6

https://blog.csdn.net/surperping/article/details/7902267

第一步:查看standby同步情况,通过如下语句:select sequence#,applied from v$archived_log order by sequence#;

发现好几天的归档日志都没有应用。

第二步:查看告警日志,显示如下信息:

MRP0: Background Media Recovery process shutdown (kehudb)
Sat May 28 14:10:04 2011
Completed: alter database recover managed standby database disconnect from session
Sat May 28 14:10:13 2011
alter database recover managed standby database disconnect from session
Sat May 28 14:10:13 2011
Attempt to start background Managed Standby Recovery process (kehudb)
MRP0 started with pid=23, OS id=18081
Sat May 28 14:10:13 2011
MRP0: Background Managed Standby Recovery process started (kehudb)
Managed Standby Recovery not using Real Time Apply
MRP0: Background Media Recovery terminated with error 1111
Sat May 28 14:10:18 2011
Errors in file /u01/oracle/admin/kehudb/bdump/kehudb_mrp0_18081.trc:
ORA-01111: name for data file 10 is unknown - rename to correct file
ORA-01110: data file 10: '/u01/oracle/product/10.2.0/db/dbs/UNNAMED00010'
ORA-01157: cannot identify/lock data file 10 - see DBWR trace file
ORA-01111: name for data file 10 is unknown - rename to correct file
ORA-01110: data file 10: '/u01/oracle/product/10.2.0/db/dbs/UNNAMED00010'
Sat May 28 14:10:18 2011
Errors in file /u01/oracle/admin/kehudb/bdump/kehudb_mrp0_18081.trc:
ORA-01111: name for data file 10 is unknown - rename to correct file
ORA-01110: data file 10: '/u01/oracle/product/10.2.0/db/dbs/UNNAMED00010'
ORA-01157: cannot identify/lock data file 10 - see DBWR trace file
ORA-01111: name for data file 10 is unknown - rename to correct file
ORA-01110: data file 10: '/u01/oracle/product/10.2.0/db/dbs/UNNAMED00010'

以上问题主要是因为:Standby_file_management参数设置STANDBY_FILE_MANAGEMENT =MANUAL造成不会自动管理数据文件,比如主库增加了数据文件,备库不会自动增加,若设置为AUTO即可实现自动管理。

可以查看备库一下:

SQL>show parameter  Standby_file_management

 STANDBY_FILE_MANAGEMENT =MANUAL

可以通过如下语句在备库执行:

1)调整standby_file_management参数为AUTO
SQL> alter system set standby_file_management=auto;

第三步:

在这种故障场景下,我们可以通过调整数据文件的方法在备库端进行处理,查看主库和备库数据文件对比一下是否一致。

SQL> select name from v$datafile;

NAME
----------------------------------------------------------------------
/oradata/twwww01.dbf
/oradata/users01.dbf
/oradata/system01.dbf
/oradata/sysaux01.dbf
/u01/oracle/product/10.2.0/db/dbs/UNNAMED00010

通过以上参数设置后,还必须做如下处理才能解决以上问题

SQL> alter database create datafile  '/u01/oracle/product/10.2.0/db/dbs/UNNAMED00010' as '/oradata/twwww03.dbf';

Database altered.

 

 

#########add logfile

 

### primary

 

alter database drop standby logfile group 4;
alter database drop standby logfile group 5;
alter database drop standby logfile group 6;
alter database drop standby logfile group 7;

alter database add logfile thread 1 group 4 size 512M;
alter database add logfile thread 1 group 5 size 512M;
alter database add logfile thread 1 group 6 size 512M;

 


alter database add standby logfile thread 1 group 7 size 512M;
alter database add standby logfile thread 1 group 8 size 512M;
alter database add standby logfile thread 1 group 9 size 512M;
alter database add standby logfile thread 1 group 10 size 512M;
alter database add standby logfile thread 1 group 11 size 512M;
alter database add standby logfile thread 1 group 12 size 512M;
alter database add standby logfile thread 1 group 13 size 512M;

 

########standby

 


备库:

首先要停掉备库的日志应用:

alter database recover managed standby database cancel;

再次,要把standby_logfile_management参数改成手动:

alter system set standby_file_management=manual;

现在就可以开始做drop和 add操作了。举例:

alter database add logfile group 4 '/data/oracle/oradata/test/redo04.log' size 300m;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 '/data/oracle/oradata/test/stredo1.log' size 1g;

这里在删除standby redo组的时候会遇到一些特使情况;

1. 首先要清理archive logfile,然后再drop

alter database clear logfile group 4;


2,如果还是 出现问题,尝试在主库切换下日志。 alter system switch logfile;

3.此外,在clear lofile 的时候可能会报错:

SQL> alter database clear logfile group 2;

alter database clear logfile group 2
*
ERROR at line 1:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 2 thread 1: '/u01/app/oracle/oradata/xezf/redo02.log'

 

ORA报错查询:

ORA-19527:
physical standby redo log must be renamed

Cause:
The CLEAR LOGFILE command was used at a physical standby database. This command cannot be used at a physical standby database unless the LOG_FILE_NAME_CONVERT initialization parameter is set. This is required to avoid overwriting the primary database's logfiles.

Action:
Set the LOG_FILE_NAME_CONVERT initialization parameter.

我们需要设置LOG_FILE_NAME_CONVERT 参数,才能使用clear logfile命令。

SQL> show parameter NAME_CONVERT

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string
log_file_name_convert string

 

-单机

SQL> alter system set log_file_name_convert='/data/oradata/test','/data/oradata/test' scope=spfile;

System altered. 之后重启数据库。

--或者rac 备库参数文件

 alter system set log_file_name_convert='+DATA/DSG/ONLINELOG','+DATA/DSG/ONLINELOG','+FRA/DSG/ONLINELOG','+FRA/DSG/ONLINELOG'

再进行clear logfile 就成功了。

结束后,要还原上面设置,并开启设置开启日志应用。

alter system set standby_file_management=auto;
alter database recover managed standby database cancel;
alter database recover managed standby database using current logfile disconnect from session;

 

 

 

##########sample 2

####### PRI
10.198.209.56
10.198.209.57

Thread# Group# Member Status Size_MB Type
1 1 +DATA_DG/sivms/onlinelog/group_1.276.935422543 CURRENT 256 ONLINE
+FRA_DG/sivms/onlinelog/group_1.275.935422545 CURRENT 256 ONLINE
2 +DATA_DG/sivms/onlinelog/group_2.277.935422545 INACTIVE 256 ONLINE
+FRA_DG/sivms/onlinelog/group_2.276.935422547 INACTIVE 256 ONLINE
5 +DATA_DG/sivms/onlinelog/group_5.280.935422553 INACTIVE 256 ONLINE
+FRA_DG/sivms/onlinelog/group_5.279.935422553 INACTIVE 256 ONLINE
6 +DATA_DG/sivms/onlinelog/group_6.281.935422555 INACTIVE 256 ONLINE
+FRA_DG/sivms/onlinelog/group_6.280.935422555 INACTIVE 256 ONLINE
2 3 +DATA_DG/sivms/onlinelog/group_3.278.935422547 INACTIVE 256 ONLINE
+FRA_DG/sivms/onlinelog/group_3.277.935422549 INACTIVE 256 ONLINE
4 +DATA_DG/sivms/onlinelog/group_4.279.935422551 CURRENT 256 ONLINE
+FRA_DG/sivms/onlinelog/group_4.278.935422551 CURRENT 256 ONLINE
7 +DATA_DG/sivms/onlinelog/group_7.282.935422557 INACTIVE 256 ONLINE
+FRA_DG/sivms/onlinelog/group_7.281.935422557 INACTIVE 256 ONLINE
8 +DATA_DG/sivms/onlinelog/group_8.283.935422559 INACTIVE 256 ONLINE
+FRA_DG/sivms/onlinelog/group_8.282.935422561 INACTIVE 256 ONLINE

DATA_DG EXTERN 409600 317283 22.54
FRA_DG EXTERN 204800 163511 20.16

需求:由原来的每组256增加到1024M

1、查看现在有日志组信息脚本:
set linesize 300
col MEMBER format a40
SELECT v$logfile.member, v$logfile.group#, v$log.status,v$log.ARCHIVED, v$log.bytes/1024/1024 ,v$log.thread#
FROM v$log, v$logfile
WHERE v$log.group# = v$logfile.group#
ORDER BY v$log.thread#,v$logfile.group#;

2、每个实例有4组日志文件,所以我们可以先删除两组,修改完成后再删除另外两组,具体操作如下

a.首先执行一次完全检查点
alter system checkpoint;

b.删除各节点状态为INACTIVE,并已归档的两组日志
ALTER DATABASE DROP LOGFILE GROUP 5;
ALTER DATABASE DROP LOGFILE GROUP 6;


ALTER DATABASE DROP LOGFILE GROUP 7;
ALTER DATABASE DROP LOGFILE GROUP 8;


c.各节点增加两组日志,大小为100M,文件由ASM自动生成
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 5 ('+DATA_DG','+FRA_DG') SIZE 1024M;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 6 ('+DATA_DG','+FRA_DG') SIZE 1024M;

ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 7 ('+DATA_DG','+FRA_DG') SIZE 1024M;
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 8 ('+DATA_DG','+FRA_DG') SIZE 1024M;


d.删除另外两组,然后再增加日志组,同b,c两步

3、如果原来日志组比较少,应该先增加新的日志组,再删除旧的,保证日志组在2组以上。


for standby logfile:

a:

set linesize 300
col MEMBER format a40
SELECT v$logfile.member, v$logfile.group#, V$STANDBY_LOG.status,V$STANDBY_LOG.bytes/1024/1024 ,V$STANDBY_LOG.thread#
FROM V$STANDBY_LOG, v$logfile
WHERE V$STANDBY_LOG.group# = v$logfile.group#
and v$logfile.type='STANDBY'
ORDER BY V$STANDBY_LOG.thread#,v$logfile.group#;

b:
alter database drop standby logfile group 9;
alter database drop standby logfile group 10;
alter database drop standby logfile group 11;
alter database drop standby logfile group 12;
alter database drop standby logfile group 13;


alter database drop standby logfile group 14;
alter database drop standby logfile group 15;
alter database drop standby logfile group 16;
alter database drop standby logfile group 17;
alter database drop standby logfile group 18;


c:
alter database add standby logfile thread 1 group 9 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 10 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 11 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 12 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 13 ('+DATA_DG','+FRA_DG') size 1024M;


alter database add standby logfile thread 2 group 14 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 15 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 16 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 17 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 18 ('+DATA_DG','+FRA_DG') size 1024M;

 

 

##########
###########
######### DG1 端操作

Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)
(HOST = 10.198.131.36)(PORT = 1528)) (ADDRESS = (PROTOCOL = TCP)
(HOST = 10.198.131.35)(PORT = 1528))


##当前日志组
a:

1、查看现在有日志组信息脚本:
set linesize 300
col MEMBER format a40
SELECT v$logfile.member, v$logfile.group#, v$log.status,v$log.ARCHIVED, v$log.bytes/1024/1024 ,v$log.thread#
FROM v$log, v$logfile
WHERE v$log.group# = v$logfile.group#
ORDER BY v$log.thread#,v$logfile.group#;

alter database recover managed standby database cancel;
alter system set standby_file_management=manual;


b.删除各节点状态为INACTIVE,并已归档的两组日志
alter database clear logfile group 5;
alter database clear logfile group 6;
alter database clear logfile group 1;

ALTER DATABASE DROP LOGFILE GROUP 5;
ALTER DATABASE DROP LOGFILE GROUP 6;
alter database DROP logfile group 1;

alter database clear logfile group 3;
alter database clear logfile group 4;
alter database clear logfile group 7;

ALTER DATABASE DROP LOGFILE GROUP 3;
ALTER DATABASE DROP LOGFILE GROUP 4;
ALTER DATABASE DROP LOGFILE GROUP 7;

c.各节点增加两组日志,大小为100M,文件由ASM自动生成
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 5 ('+DATA_DG','+FRA_DG') SIZE 1024M;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 6 ('+DATA_DG','+FRA_DG') SIZE 1024M;
ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 1 ('+DATA_DG','+FRA_DG') SIZE 1024M;

ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 3 ('+DATA_DG','+FRA_DG') SIZE 1024M;
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 4 ('+DATA_DG','+FRA_DG') SIZE 1024M;
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 7 ('+DATA_DG','+FRA_DG') SIZE 1024M;

d.对于当前状态为current 的日志组,先在主库切换日志,变换dg 库的current 日志组的状态标识,然后再增加日志组,同b,c两步

alter database clear logfile group 2;
alter database clear logfile group 8;

in primary:
a ALTER SYSTEM SWITCH LOGFILE;

alter database clear logfile group 2;
alter database clear logfile group 8;

alter database drop logfile group 2;
alter database drop logfile group 8;

ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 2 ('+DATA_DG','+FRA_DG') SIZE 1024M;
ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 8 ('+DATA_DG','+FRA_DG') SIZE 1024M;

 


for standby logfile:

a:

set linesize 300
col MEMBER format a40
SELECT v$logfile.member, v$logfile.group#, V$STANDBY_LOG.status,V$STANDBY_LOG.bytes/1024/1024 ,V$STANDBY_LOG.thread#
FROM V$STANDBY_LOG, v$logfile
WHERE V$STANDBY_LOG.group# = v$logfile.group#
and v$logfile.type='STANDBY'
ORDER BY V$STANDBY_LOG.thread#,v$logfile.group#;

b:
alter database drop standby logfile group 9;
alter database drop standby logfile group 10;
alter database drop standby logfile group 11;
alter database drop standby logfile group 12;
alter database drop standby logfile group 13;


alter database drop standby logfile group 14;
alter database drop standby logfile group 15;
alter database drop standby logfile group 16;
alter database drop standby logfile group 17;
alter database drop standby logfile group 18;


c:
alter database add standby logfile thread 1 group 9 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 10 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 11 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 12 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 1 group 13 ('+DATA_DG','+FRA_DG') size 1024M;


alter database add standby logfile thread 2 group 14 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 15 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 16 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 17 ('+DATA_DG','+FRA_DG') size 1024M;
alter database add standby logfile thread 2 group 18 ('+DATA_DG','+FRA_DG') size 1024M;


最后,开启设置开启日志应用。

alter system set standby_file_management=auto;
alter database recover managed standby database cancel;
alter database recover managed standby database using current logfile disconnect from session;

 

 

 

SQL_ID  c35yvu7uzqugq, child number 0-------------------------------------INSERT /*+ append */ INTO OMLOPR.VT_INC_550(   INTERNAL_KEY   ,BRANCH   ,CCY   ,CLIENT_NO   ,GLOBAL_ID_TYPE   ,GLOBAL_ID   ,CERTIFICATE_NO   ,CLIENT_SHORT   ,PROFIT_CENTRE   ,ACCT_OPEN_DATE   ,OPEN_TRAN_DATE   ,ACCT_STATUS   ,ACCT_NO   ,ACCT_TYPE   ,ACCT_DESC   ,OWNERSHIP_TYPE   ,FREE_CHEQUES   ,ATA_ACCT   ,DEPOSIT_TYPE   ,ACTUAL_OR_LEDGER_BAL   ,INT_STMT   ,STMT_PBK   ,PRINT_STMT   ,CLIENT_IND   ,DEL_FLAG   ,OD_FACILITY   ,RESTRAINT_PRESENT   ,LEDGER_BAL   ,ACTUAL_BAL   ,CALC_BAL   ,PREV_DAY_LEDGER_BAL   ,PREV_DAY_ACTUAL_BAL   ,PREV_DAY_CALC_BAL   ,TOLERANCE_AMT   ,TOTAL_FLOATS_AMT   ,TOTAL_PLEDGED_AMT   ,TOTAL_AUTH_OD   ,COMPENSE_ACCT_TYPE   ,COMPENSE_CTRL_ACCT   ,WS_ID   ,USER_ID   ,OFFICER_ID   ,LAST_CHANGE_OFFICER   ,LAST_CHANGE_DATE   ,LAST_RUN_DATE   ,LAST_TRAN_DATE   ,LAST_BAL_UPDATE   ,LAST_PBK_UPD_BAL   ,LAST_PBK_UPD_DATE   ,LAST_PBK_LINE   ,ACCT_CLOSE_DATE   ,ACCT_CLOSE_REASON   ,CATEGORY_TYPE   ,CLIENT_TYPE   ,DIRECT_DEBIT   ,ACCT_CLOSE_OFFICER   ,CASHIER_ORDER_IND   ,CB_CO Plan hash value: 3269117650 ----------------------------------------------------------------------------------------------------------------------------| Id  | Operation                | Name               | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |----------------------------------------------------------------------------------------------------------------------------|   0 | INSERT STATEMENT         |                    |       |       |  7303 (100)|          |        |      |            ||   1 |  PX COORDINATOR          |                    |       |       |            |          |        |      |            ||   2 |   PX SEND QC (RANDOM)    | :TQ10001           |     1 |  6682 |  7303   (3)| 00:01:43 |  Q1,01 | P->S | QC (RAND)  ||   3 |    LOAD AS SELECT        |                    |       |       |            |          |  Q1,01 | PCWP |            ||*  4 |     HASH JOIN            |                    |     1 |  6682 |  7303   (3)| 00:01:43 |  Q1,01 | PCWP |            ||   5 |      PX RECEIVE          |                    |     1 |  3341 |     2   (0)| 00:00:01 |  Q1,01 | PCWP |            ||   6 |       PX SEND BROADCAST  | :TQ10000           |     1 |  3341 |     2   (0)| 00:00:01 |  Q1,00 | P->P | BROADCAST  ||   7 |        PX BLOCK ITERATOR |                    |     1 |  3341 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            ||*  8 |         TABLE ACCESS FULL| E002_SYM_RB_ACCT03 |     1 |  3341 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            ||   9 |      PX BLOCK ITERATOR   |                    |  6157K|    19G|  7292   (3)| 00:01:43 |  Q1,01 | PCWC |            ||* 10 |       TABLE ACCESS FULL  | VT_BAK_550         |  6157K|    19G|  7292   (3)| 00:01:43 |  Q1,01 | PCWP |            |---------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):---------------------------------------------------    4 - access(NVL("N"."INTERNAL_KEY",0)=NVL("O"."INTERNAL_KEY",0))       filter((NVL("N"."BRANCH",' ')<>NVL("O"."BRANCH",' ') OR NVL("N"."CCY",' ')<>NVL("O"."CCY",' ') OR               NVL("N"."CLIENT_NO",' ')<>NVL("O"."CLIENT_NO",' ') OR NVL("N"."GLOBAL_ID_TYPE",' ')<>NVL("O"."GLOBAL_ID_TYPE",' ')               OR NVL("N"."GLOBAL_ID",' ')<>NVL("O"."GLOBAL_ID",' ') OR NVL("N"."CERTIFICATE_NO",' ')<>NVL("O"."CERTIFICATE_NO",'               ') OR NVL("N"."CLIENT_SHORT",' ')<>NVL("O"."CLIENT_SHORT",' ') OR NVL("N"."PROFIT_CENTRE",'               ')<>NVL("O"."PROFIT_CENTRE",' ') OR NVL("N"."ACCT_OPEN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd               hh24:mi:ss'))<>NVL("O"."ACCT_OPEN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR               NVL("N"."OPEN_TRAN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd               hh24:mi:ss'))<>NVL("O"."OPEN_TRAN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR               NVL("N"."ACCT_STATUS",' ')<>NVL("O"."ACCT_STATUS",' ') OR NVL("N"."ACCT_NO",' ')<>NVL("O"."ACCT_NO",' ') OR               NVL("N"."ACCT_TYPE",' ')<>NVL("O"."ACCT_TYPE",' ') OR NVL("N"."ACCT_DESC",' ')<>NVL("O"."ACCT_DESC",' ') OR               NVL("N"."OWNERSHIP_TYPE",' ')<>NVL("O"."OWNERSHIP_TYPE",' ') OR               NVL("N"."FREE_CHEQUES",0)<>NVL("O"."FREE_CHEQUES",0) OR NVL("N"."ATA_ACCT",' ')<>NVL("O"."ATA_ACCT",' ') OR               NVL("N"."DEPOSIT_TYPE",' ')<>NVL("O"."DEPOSIT_TYPE",' ') OR NVL("N"."ACTUAL_OR_LEDGER_BAL",'               ')<>NVL("O"."ACTUAL_OR_LEDGER_BAL",' ') OR NVL("N"."INT_STMT",' ')<>NVL("O"."INT_STMT",' ') OR NVL("N"."STMT_PBK",'               ')<>NVL("O"."STMT_PBK",' ') OR NVL("N"."PRINT_STMT",' ')<>NVL("O"."PRINT_STMT",' ') OR NVL("N"."CLIENT_IND",'               ')<>NVL("O"."CLIENT_IND",' ') OR NVL("N"."DEL_FLAG",' ')<>NVL("O"."DEL_FLAG",' ') OR NVL("N"."OD_FACILITY",'               ')<>NVL("O"."OD_FACILITY",' ') OR NVL("N"."RESTRAINT_PRESENT",' ')<>NVL("O"."RESTRAINT_PRESENT",' ') OR               NVL("N"."LEDGER_BAL",0)<>NVL("O"."LEDGER_BAL",0) OR NVL("N"."ACTUAL_BAL",0)<>NVL("O"."ACTUAL_BAL",0) OR               NVL("N"."CALC_BAL",0)<>NVL("O"."CALC_BAL",0) OR NVL("N"."PREV_DAY_LEDGER_BAL",0)<>NVL("O"."PREV_DAY_LEDGER_BAL",0)               OR NVL("N"."PREV_DAY_ACTUAL_BAL",0)<>NVL("O"."PREV_DAY_ACTUAL_BAL",0) OR               NVL("N"."PREV_DAY_CALC_BAL",0)<>NVL("O"."PREV_DAY_CALC_BAL",0) OR               NVL("N"."TOLERANCE_AMT",0)<>NVL("O"."TOLERANCE_AMT",0) OR               NVL("N"."TOTAL_FLOATS_AMT",0)<>NVL("O"."TOTAL_FLOATS_AMT",0) OR               NVL("N"."TOTAL_PLEDGED_AMT",0)<>NVL("O"."TOTAL_PLEDGED_AMT",0) OR               NVL("N"."TOTAL_AUTH_OD",0)<>NVL("O"."TOTAL_AUTH_OD",0) OR NVL("N"."COMPENSE_ACCT_TYPE",'               ')<>NVL("O"."COMPENSE_ACCT_TYPE",' ') OR NVL("N"."COMPENSE_CTRL_ACCT",0)<>NVL("O"."COMPENSE_CTRL_ACCT",0) OR               NVL("N"."WS_ID",' ')<>NVL("O"."WS_ID",' ') OR NVL("N"."USER_ID",' ')<>NVL("O"."USER_ID",' ') OR               NVL("N"."OFFICER_ID",' ')<>NVL("O"."OFFICER_ID",' ') OR NVL("N"."LAST_CHANGE_OFFICER",'               ')<>NVL("O"."LAST_CHANGE_OFFICER",' ') OR NVL("N"."LAST_CHANGE_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd               hh24:mi:ss'))<>NVL("O"."LAST_CHANGE_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR               NVL("N"."LAST_RUN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd               hh24:mi:ss'))<>NVL("O"."LAST_RUN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR               NVL("N"."LAST_TRAN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd               hh24:mi:ss'))<>NVL("O"."LAST_TRAN_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR               NVL("N"."LAST_BAL_UPDATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd               hh24:mi:ss'))<>NVL("O"."LAST_BAL_UPDATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR               NVL("N"."LAST_PBK_UPD_BAL",0)<>NVL("O"."LAST_PBK_UPD_BAL",0) OR NVL("N"."LAST_PBK_UPD_DATE",TO_DATE(' 1900-01-01               00:00:00', 'syyyy-mm-dd hh24:mi:ss'))<>NVL("O"."LAST_PBK_UPD_DATE",TO_DATE(' 1900-01-01 00:00:00', 'syyyy-mm-dd               hh24:mi:ss')) OR NVL("N"."LAST_PBK_LINE",0)<>NVL("O"."LAST_PBK_LINE",0) OR NVL("N"."ACCT_CLOSE_DATE",TO_DATE('               1900-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))<>NVL("O"."ACCT_CLOSE_DATE",TO_DATE(' 1900-01-01 00:00:00',               'syyyy-mm-dd hh24:mi:ss')) OR NVL("N"."ACCT_CLOSE_REASON",' ')<>NVL("O"."ACCT_CLOSE_REASON",' ') OR               NVL("N"."CATEGORY_TYPE",' ')<>NVL("O"."CATEGORY_TYPE",' ') OR NVL("N"."CLIENT_TY)   8 - access(:Z>=:Z AND :Z<=:Z)  10 - access(:Z>=:Z AND :Z<=:Z) Note-----   - dynamic sampling used for this statement (level=2) 

 

 

 

 

########sample 3

 

碰到一个问题,大面积的lag , 备库的归档日志没办法在备库 产生。

 
我们在备库开启了实时同步,也就是生产库 会一致持续 不断的将日志 传送到备库。

如果网络抖动在一段时间可以恢复的话,应该问题不大。

如果专线持续的调包,导致这个告警 会一直存在。

 

-》这条语句查询,发现lag 一致存在。









select '- value->',value, '- lag seconds->',substr(value,2,2)*24*3600+substr(value,5,2)*3600+substr(value,8,2)*60+substr(value,11,2) seconds from v$dataguard_stats where name='apply lag'

-》

检查日志,偶尔有报错 possible network diconnet ,

-》
临时解决方法:
将专线 调整到 主线路,很快就恢复了。

网络组事后的分析如下:
网络克来抓包工具应该能分析出来该问题,但是应该告诉问题时间点,比如1个小时范围,另外告诉不光要在生产库 抓网络包,还需要在容灾库抓网络包
初步分析,生产包发出去6个包,容灾库端只收到3个包,所以中间遗漏的3个包就是网络线路质量不佳导致的丢包

###########sample 4

#######sample 1
问题描述:数据库dg gap ,数据库无法传日志到dg库,dg库也无法抓取日志从主库,只能手工注册归档日志,追归档日志。

检查主库日志,一直打印如下信息
Sun Aug 08 12:48:13 2021
WARN: ARC2: Terminating pid 62245 hung on an I/O operation
Killing 1 processes with pids 62245 (Process by index) in order to remove hung processes. Requested by OS process 10788
ARC2: Error 16198 due to hung I/O operation to LOG_ARCHIVE_DEST_2

 

https://blog.csdn.net/myy10146/article/details/109220966
11g ADG没有实时应用redo日志分析

正常的

in primary :
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS ,CLIENT_PID, pid FROM gV$MANAGED_STANDBY WHERE THREAD#!=0 ORDER BY THREAD#, SEQUENCE#;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
CLIENT_PID PID
---------------------------------------- ----------
ARCH CLOSING 1 11174 69632 2046
11272542 11272542

ARCH CLOSING 1 11176 2048 1289
11731146 11731146

ARCH CLOSING 1 11178 8192 1547
7995838 7995838


PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
CLIENT_PID PID
---------------------------------------- ----------
LNS WRITING 1 11179 2816 1
11076094 11076094

ARCH CLOSING 2 11074 2048 1306
4391366 4391366

ARCH CLOSING 2 11075 1 6
10289386 10289386


PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
CLIENT_PID PID
---------------------------------------- ----------
ARCH CLOSING 2 11076 6144 433
7733822 7733822

LNS WRITING 2 11077 2737 1
10158218 10158218

ps -ef|grep -v grep|grep -E "ora_lns|ora_nsa|ora_nss"


有问题的。

SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS ,CLIENT_PID, pid FROM gV$MANAGED_STANDBY WHERE THREAD#!=0 ORDER BY THREAD#, SEQUENCE#;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
CLIENT_PID PID
---------------------------------------- ----------
ARCH OPENING 1 202822 0 0
167411 167411

ARCH OPENING 1 202823 0 0
169081 169081

ARCH CLOSING 1 203298 2048 1150
71324 71324


in standby:
SELECT INST_ID, PROCESS, PID, CLIENT_PROCESS, CLIENT_PID, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
FROM GV$MANAGED_STANDBY
WHERE THREAD#!=0 ORDER BY THREAD#, SEQUENCE#;


##step 0 注册归档日志
olution 8 Register those archive log files or use manual recovery.
a. Register those manually transferred archive log files and then use managed recovery to recover them.

SQL> alter database recover managed standby database cancel;
SQL> alter database register logfile '<full path/archive log file name>';
or you could use one rman command to catalog all the archive logs that were manually transferred and needed to be added to the controlfile at the standby site.

rman> catalog start with 'PATH_TO_ARCHIVELOGS/';
SQL> alter database recover managed standby database disconnect;

 


备库上检查归档日志应用情况:
select thread#, max(sequence#) "Last Standby Seq Applied"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
and val.applied in ('YES','IN-MEMORY')
group by thread# order by 1;


select max(sequence#) from v$archived_log where applied='YES';


####step 1
kill 掉主库arc 所有进程。
alter system switch logfile;
观察主库arc 进程是否启动


####
step 2: 尝试重启容灾库,问题没有恢复
####j检查容灾库,发现有public 用户,有Public 用户,说明hang,重启容灾库

QL> select username,MACHINE,MODULE from v$session where status='ACTIVE' AND USERNAME IS NOT NULL;

USERNAME
------------------------------
MACHINE
----------------------------------------------------------------
MODULE
----------------------------------------------------------------
SYS
phtfbdb02
sqlplus@phtfbdb02 (TNS V1-V3)

PUBLIC
shtfbdb02
oracle@shtfbdb02 (TNS V1-V3)


#####step 3
SELECT DESTINATION, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID=2;

 

 


##step 4 尝试在主库kill 掉arc 进程,然后重新发起归档日志进程切换,发起归档进程,发现也有问题

in primary:
alter system set log_archive_dest_state_2='defer' scope=both sid='*';
ps -ef|grep arc (杀掉所有的归档进程,数据库会自动重启这些进程);

alter system set log_archive_dest_state_2='enable' scope=both sid='*';


alter system set log_archive_dest_state_2='enable' scope=both sid='*';


###step 4.2 启动容灾库 检查主备库SCN好,发现主库的archive log list 和备库的archive log list,相差很大,说明主库的归档进程和备库的归档进程无法通信。


###step 4.3 检查容灾库的日志,如果是ora-链接进程 db_ora_190571.trc报错,暂时忽略,如果是后台进程,pr00_189215.trc,需要在仔细看看
检查主库的日志,如果是ora-链接进程 db_ora_190571.trc报错,暂时忽略,如果是后台进程,arc_.trc,需要在仔细看看

#col current_scn for 99999999999999999
#select current_scn from v$database;

#select scn_to_timestamp('9092586404') from dual;
select scn_to_timestamp(current_scn) from v$database;


#select scn_to_timestamp((select to_char(current_scn,'99999999999999999') from v$database)) from dual;
##select scn_to_timestamp((select to_number(current_scn,'999999999') from v$database)) from dual;

#select scn_to_timestamp(current_scn) from v$database;
#ORA-08181: specified number is not a valid system change number


##step 5 开始手工注册归档日志,发现只能手工注册归档日志,无法自动同步归档日志
ls -ltr /dba_bak/ddd_tmp/2021_08_07
ls -ltr /dba_bak/ddd_tmp/2021_08_06
ls -ltr /dba_bak/ddd_tmp/2021_08_08
ls -ltr /dba_bak/ddd_tmp/2021_08_09
catalog start with '/dba_bak/ddd_tmp/2021_08_06'
catalog start with '/dba_bak/ddd_tmp/2021_08_07'
catalog start with '/dba_bak/ddd_tmp/2021_08_08'
catalog start with '/dba_bak/ddd_tmp/2021_08_10'
cd /ddd/cus/fra/Rddd/archivelog/2021_08_08

 

###step 4.3 日志量太大,差不多300G 主库进程arc hang 住,尝试手工copy 。主库的alert 日志一直打印如下报错
检查主库
Sun Aug 08 12:48:13 2021
WARN: ARC2: Terminating pid 62245 hung on an I/O operation
Killing 1 processes with pids 62245 (Process by index) in order to remove hung processes. Requested by OS process 10788
ARC2: Error 16198 due to hung I/O operation to LOG_ARCHIVE_DEST_2

 

#######官方给出的检查sql, 发现用处不大,主备库同时检查
select max(sequence#) from v$archived_log where applied='YES';
select DEST_ID, APPLIED_SCN FROM v$archive_dest
select DEST_ID,scn_to_timestamp(APPLIED_SCN) FROM v$archive_dest where APPLIED_SCN !=0;
select * from v$dataguard_status;

SELECT gvi.thread#, timestamp, message FROM gv$dataguard_status gvds, gv$instance gvi WHERE gvds.inst_id = gvi.inst_id AND severity in ('Error','Fatal')
ORDER BY timestamp, thread#;

 

############step 5 参考文档,帮助不大,


Logs are not shipped to the physical standby database (Doc ID 1130523.1)

*** Reviewed for Relevance 15-Jul-2015 ***

May encounter different types of errors depending on the situations:

Logs are not shipped at log switch or fal archiving fails
Value of applied column on the primary is not consistent as that on the standby
RMAN does not delete logs and results in error RMAN-08137
In some rare cases ORA-12154 may show up in the primary alert log
Other possible errors ORA-3113, ORA-3135
WARN: ARCH: Terminating pid <PID> hung on an I/O operation
krsv_proc_kill: Killing 1 processes (Process by index)
CHANGES
Problem usually occurs after OS or network errors, or restarting the primary or standby instance or reboot the primary or standby node that abruptly crashes log shipping between the primary and standby


ARCx processes on the primary need to be restarted.

Assuming that log transport from the primary is configured by log_archive_dest_2.

Please perform the following:

1) If the Data Guard Broker is running, disable Data Guard Broker on both primary and standby:

##SQL> alter system set dg_broker_start=FALSE;

2) On the Primary Database:

- Set log transport state to DEFER status:
SQL> alter system set log_archive_dest_state_2='defer';
SQL> alter system switch logfile;
- Reset log_archive_dest_2
SQL> show parameter log_archive_dest_2 -------------------> Note this value
SQL> alter system set log_archive_dest_2 = '';
- Switch logfiles on the Primary
SQL> alter system switch logfile;

3) On the Standby Database:

- Cancel Managed Recovery
SQL> alter database recover managed standby database cancel;
- Shutdown the Standby Database
SQL> shutdown immediate

4) On the Primary: kill the ARCx Processes and the Database will respawn them automatically immediately without harming it.

ps -ef | grep -i arc
kill -9 <ospid of ARC process> <another ospid of ARC process> ...

5) On standby server, startup Standby Database and resume Managed Recovery

SQL> startup mount;
SQL> alter database recover managed standby database using current logfile disconnect;

6) Re-enable Log Transport Services on the Primary:

 

#SQL>Alter system set log_archive_dest_2='Service=..............' ; Set log_archive_dest_2 (Which was reset in step 2) to its original value

alter system set log_archive_dest_2='SERVICE=ddd lgwr async noaffirm reopen=60 valid_for=(online_logfiles,primary_role) db_unique_name=ddd';

SQL> alter system set log_archive_dest_state_2='enable' ;

At this point all the ARCx processes should be up and running on the Primary.

7) Re-enable the Data Guard Broker for both, Primary and Standby if applicable:

##SQL> alter system set dg_broker_start=true;

 

#########结论 ,最好考虑是个未知11.2.。0.4 的bug ,主库的arch 进程会自动同步 备库的arch 进程,他们之间会有Ping 动作,
因为某种网络原因,主库的arch 进程无法自动同步备库的arch 进程,对主库来说备库的归档日志序列号一直停在问题的那个时间点,
即使备库手工发起注册归档日志,把数据库日志追平到主库的时间点,主库仍然认为备库归档日志序列号一直停在问题的那个时间点,

问题描述至此。最后发现网络问题,将主线路切换到备份线路

网络组事后的分析如下:
网络克来抓包工具应该能分析出来该问题,但是应该告诉问题时间点,比如1个小时范围,另外告诉不光要在生产库 抓网络包,还需要在容灾库抓网络包
初步分析,生产包发出去6个包,容灾库端只收到3个包,所以中间遗漏的3个包就是网络线路质量不佳导致的丢包

 



###########sampel;
问题,如果RAC 作为容灾库,只启动一个节点,那么切换另外一个节点,要等30分钟才能同步,可能主库需要花30分钟才能得知备库的状态:

以下是监控检查常用sql:

Monitoring Data Guard Configuration Health Using SQL:

The following queries can be used to assess overall health on both the primary and the standby.

Primary Database Queries

Goal

Query

Expected Results

Check if any remote standby archive destination is getting errors. 
Check if all remote standby archive destinations is enabled or "VALID".

select sysdate,status,error from gv$archive_dest_status where type='PHYSICAL' and  status!='VALID' or error is not null;

Good behavior - no rows returned.
If query returns rows, then raise an alert with the returned data.

Check if any nologging activity has occurred on the primary for the last day.

select file#, name, unrecoverable_change#, unrecoverable_time 
from v$datafile  
where unrecoverable_time > (sysdate - 1);

 

Good behavior - no rows returned.
If query returns rows, then the standby is vulnerable and the subsequent file needs to be refreshed on the standby. 

Detect gaps on the standby 

select sysdate,database_mode,recovery_mode, gap_status from v$archive_dest_status where type='PHYSICAL' and gap_status !='NO GAP'; 

Good behavior - no rows returned.
If query returns rows, then there's an existing gap between the primary and the standby.  Subsequent action is to run the same query on the standby, if the output is identical, then no action required.  If the output on the standby does not match the primary then the datafile on the standby should be refreshed.
 

Assess if any severe Data Guard event occurred in the last day

select * from v$dataguard_status where 
severity in ('Error','Fatal') and 
timestamp > (sysdate -1);

Good behavior - no rows returned.
If query returns rows then the result should raise an alert with the returned output.

FOR SYNC ENVIRONMENTS ONLY:

 

Assess if running in Maximum Availability mode and configuration is in sync.

select sysdate,protection_mode, synchronized, synchronization_status from v$archive_dest_status where type='PHYSICAL' and synchronization_status !='OK';

Good behavior - no rows returned.
If query returns rows then the result should raise an alert with the returned output.

Physical Standby Database Queries

 

Goal

Query

Expected Results

Determine if there is a transport lag

select name,value,time_computed,datum_time from v$dataguard_stats where name='transport lag' and value > '+00 00:01:00';

Good behavior - no rows are returned. 
If no rows are returned then this implies that there is no transport lag 
 

Determine if there is an apply lag

select name,value,time_computed,datum_time from v$dataguard_stats where name='apply lag' and value > '+00 00:01:00';

Good behavior - no rows are returned. 
If no rows are returned then this implies that there is no apply lag 
 

Standby data file check (offline files or files that are not accessible)

select * from v$datafile_header where 
status ='OFFLINE' 
or ERROR is not null;

Good behavior - no rows returned.
Any rows returned will show which file(s) are having IO or recovery issues.
 

Verify that the Media Recovery Process is currently running.

 select * from v$managed_standby 
where process like 'MRP%';

Good behavior - rows returned.
If no rows are returned then the MRP process is not running.

Assess if any severe Data Guard event occurred in the last day

select * from v$dataguard_status where 
severity in ('Error','Fatal') and 
timestamp > (sysdate -1);

Good behavior - no rows returned.
If query returns rows, then the result should raise an alert with the returned output.




posted @ 2018-06-11 16:32  feiyun8616  阅读(996)  评论(0编辑  收藏  举报