DATAGUARD之三：12C使用命令行进行swichover，failover以及snapshot standby

Ryan_Wo
关注文章
TinyMind专栏频道

一，SWITCHOVER

1，检查参数

col name for a30
col value for a150
set line 200 pages 300
SELECT 
    NAME,
    VALUE 
FROM 
    V$PARAMETER 
WHERE 
    NAME IN (
        'db_unique_name',
        'log_archive_config',
        'log_archive_dest_1',
        'log_archive_dest_2',
        'log_archive_dest_state_1',
        'log_archive_dest_state_2',
        'remote_login_passwordfile',
        'log_archive_format',
        'standby_file_management',
        'compatible',
        'fal_server',
        'db_file_name_convert',
        'log_file_name_convert'
        )
order by name        
;

重新启动备用数据库并启动MRP时，只要正确设置了log_file_name_convert，它将清除备用数据库上的所有ORL，online redo logs

2，检查备库当前日志应用状态正常

主备对比，看看备库应用到了哪个归档

ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';
col dest_name for a25
set line 200 pages 300
SELECT
    al.dest_id,
    ads.dest_name,
    ads.type,
    ads.status,
    sequence#,
    first_time,
    next_time,
    applied
FROM
    v$archived_log al,
    v$archive_dest_status ads
WHERE
    al.dest_id=ads.dest_id
--    and applied='YES'
ORDER BY
    dest_id,
    sequence#;

查看日志传输进程以及应用进程是否在线，在备库运行

col status for a15
SELECT
    client_process,
    process,
    thread#,
    sequence#,
    status
FROM
    v$managed_standby
WHERE
    client_process = 'LGWR'
    OR process = 'MRP0';
--12.2
SELECT
    name,
    role,
    instance,
    thread#,
    sequence#,
    action
FROM
    gv$dataguard_process;

3，检查switchover status

SELECT
    NAME,
    OPEN_MODE,
    DATABASE_ROLE,
    SWITCHOVER_STATUS
FROM
    V$DATABASE;

SWITCHOVER_STATUS有几种状态：

SWITCHOVER_STATUS 解释
NOT ALLOWED 在主库，这个值表示没有有效的或者可用的备库
在备库，这个值表示它没有收到主库发来的switchover信号
SESSIONS ACTIVE 表示数据库有活动会话，在一个物理备库，角色转换命令必须指定WITH SESSION SHUTDOWN
逻辑备库则可以使用普通命令进行转换，但是该操作会等到所有事务都提交了才能完成
SWITCHOVER PENDING 在一个物理备库，表示已经收到了switchover的请求，并且主库正在进行转换
这个时候备库还不能够进行转换
SWITCHOVER LATENT 在物理备库，该状态表示switchover的请求已经挂起，但是原本的主库已经切换回了primary角色
这个时候检查下原主库的角色，归档状态
TO PRIMARY 数据库可以切换为主库了
TO STANDBY 数据库已经可以切换为物理备库或者逻辑备库了
TO LOGICAL STANDBY 数据库已经从逻辑备库收到了数据字典信息，已经可以转换为逻辑备库角色了
RECOVERY NEEDED 在一个物理备库，这个状态表示在转换为primary角色之前需要应用额外的日志
PREPARING SWITCHOVER 主库这个状态表示正在从逻辑备库接收数据字典信息来准备切换成逻辑备库。
在逻辑备库，这个状态表示数据字典信息已经被发送给了主库和其他的物理备库。
PREPARING DICTIONARY 在逻辑备库，这个状态表示数据字典信息正在发送给主库和其他物理备库
FAILED DESTINATION 在主库，这个状态表示有一个或者多个归档路径处于ERROR状态
RESOLVABLE GAP 在主库，这个状态表示有一个或者多个备库仍然有日志缺口，但是这个缺口可以自动从主库或者其他备库接收所需日志
UNRESOLVABLE GAP 同上，只不过这个缺口无法自动解决
LOG SWITCH GAP 在主库，这个状态表示有一个或者多个备库因为最近的日志切换导致的日志缺口

如果switchover_status显示UNRESOLVABLE GAP：

a）检查是否存在任何已关闭的线程，如果有的话，需要关闭掉

SELECT
    thread#,
    instance,
    status
FROM
    v$thread;

关闭线程的方法：

ALTER DATABASE DISABLE THREAD <n>;

b）检查是否有任何归档路径指向了无效的系统路径

SELECT
    status,
    dest_id,
    type,
    error,
    gap_status,
    synchronized,
    synchronization_status,
    recovery_mode
FROM
    v$archive_dest_status
WHERE
    status <> 'INACTIVE';

4，检查临时文件

在备库创建完成之后再创建的临时文件不会传递到备库，因此需要进行临时文件的检查

col name for a100
set line 200 pages 300
SELECT
    ts#,
    name,
    ts#,
    status
FROM
    v$tempfile;

5，12c之后的verify命令

alter database switchover to ryanstd verify;
这条命令会帮你验证： a，版本最低为12.1 b，主库日志有在传输 c，备库MRP有在运行并且和主库是同步的，其他情况会输出错误，alert也会有记录 正常的输出结果是: 
Database altered.
如果是ORA-或者是warning，一般都是为了你好，fix吧

6，SWITCHOVER

主备都开trace，以防万一需要troubleshoot 
alter system set log_archive_trace=8191 sid='*';

另开窗口，跟踪alert日志

SQL>show parameter background_dump_dest
$tail -600f background_dump_dest/alert*

注意，在RAC环境不需要把所有实例关闭只剩下一个实例，SWITCHOVER命令会自动关闭所有节点。

切换备库为主库，在主库执行

alter database switchover to ryanstd;

完成之后，12.2的时候，新备库会自动被关闭，新主库会自动启动到mount状态，这里就不贴图了

接下来，需要把新主库打开，新备库打开并且开始应用日志

新主库：

alter database open;
--检查状态
SELECT
    NAME,
    OPEN_MODE,
    DATABASE_ROLE,
    SWITCHOVER_STATUS
FROM
    v$database;
--RAC环境
#srvctl config database -db ryanstd
...
Database Role: PHYSICAL_STANDBY

#srvctl modify database -db ryanstd -role PRIMARY

新备库：

startup；
alter database recover managed standby database disconnect;
--检查状态
SELECT
    NAME,
    OPEN_MODE,
    DATABASE_ROLE,
    SWITCHOVER_STATUS
FROM
    v$database;
--RAC
#srvctl config database -db ryanpr
...
Database Role: PRIMARY

#srvctl modify database -db ryanpr -role PHYSICAL_STANDBY

另外，不要忘记关闭trace，并且检查下trace文件里面有没有报错

alter system set log_archive_trace=0;

最后，重新验证下DG状态，是否正常启动并应用日志

二，FAILOVER

1，停止日志应用

alter database recover managed standby database cancel;

2，检查SWITCHOVER_STATUS

SELECT
    NAME,
    OPEN_MODE,
    DATABASE_ROLE,
    SWITCHOVER_STATUS
FROM
    v$database;

3，备库转换为主库操作

--on standby cancel redo apply
alter database recover managed standby database cancel;

--do a terminal recovery
alter database recover managed standby database finish;

--active standby to mount as primary
alter database activate standby database;

--check status
SELECT
    DB_UNIQUE_NAME,
    OPEN_MODE,
    DATABASE_ROLE,
    SWITCHOVER_STATUS
FROM
    v$database;

--restart standby
shutdown immediate;
startup;

4，旧主库的恢复

a）如果有开启flashback database

--从新主库获取其failover为主库时的SCN,在新主库运行
select to_char(standby_became_primary_scn+1) from v$database;

--在旧主库 , startup to mount state
shutdown immediate;
startup mount;

--在旧主库，把数据库FLASHBACK回第一步获取的SCN
FLASHBACK DATABASE TO SCN <n>;

--check status
SELECT
    DB_UNIQUE_NAME,
    OPEN_MODE,
    DATABASE_ROLE,
    SWITCHOVER_STATUS
FROM
    v$database;

--此时旧主库还不是standby状态，执行以下命令切换
alter database convert to physical standby;

--再次验证下状态，如果没有问题，重启数据库，开启日志应用
shutdown immediate;
startup;
alter database recover managed standby database disconnect from session;

b）如果没有开启flashback database，但是平时有做备份

--从新主库获取其failover为主库时的SCN,在新主库运行
select to_char(standby_became_primary_scn+1) from v$database;
e.g 3153146

--在旧主库 , startup to mount state
shutdown immediate;
startup mount;

rman target / <<EOF
run{
set until scn 3153146;
restore database;
recover database;
}
EOF

--after recover completed, convert role
alter database convert to physical standby;

--restart
shutdown immediate;
startup;

--enable redo log apply
alter database recover managed standby database disconnect from session;

c）没有flashback，没有备份，请使用duplicate重新创建DB

--以下均为备库操作
--删库，如果mount不起来，直接删除相对应的所有文件
shutdown abort;
startup mount restrict;
drop database;

--创建个临时init$SID.ora文件，只要DB_NAME参数，启动到nomount状态
cat >> /tmp/initryan.ora <<EOF
DB_NAME='ryan'
EOF

startup nomount pfile='/tmp/initryan.ora'

--开始duplicate，关于duplicate参数说明，请看另一篇文章，dorecover可以不做
rman target sys/oracle@ryanstd auxiliary sys/oracle@ryanpr;

duplicate target database 
    for standby 
    from active database 
    dorecover 
    spfile 
    PARAMETER_VALUE_CONVERT = 'ryanstd','ryanpr'
    set DB_UNIQUE_NAME = 'ryanpr'
    set DB_FILE_NAME_CONVERT = 'RYANSTD','RYANPR','RYAN','RYANPR'
    SET LOG_FILE_NAME_CONVERT = 'RYANSTD','RYANPR','RYAN','RYANPR'
    comment 'Duplicate test' nofilenamecheck;

--虽然正常操作不会遇见，还是额外说一下，如果遇见ORA-01153，把dorecover删除
--duplicate完成后，就是正常的配置检查了

三，SNAPSHOT STANDBY

--备库操作
alter database convert to snapshot standby;

--打开
alter database open;

--你可以开始操作,测试了

--测试结束后，转换回去
shutdown immediate;

startup mount;

alter database convert to physical standby;

--开启应用
alter database recover managed standby disconnect from session;
优质内容筛选与推荐>>
1、原来还能这么玩
2、只是向往
3、利用mvn deploy命令上传包（转）
4、什么是Session共享？请举出使用场景
5、JProgressBar进度条


长按二维码向我转账

受苹果公司新规定影响，微信 iOS 版的赞赏功能被关闭，可通过二维码转账支持公众号。

    阅读
    好看
    已推荐到看一看
    你的朋友可以在“发现”-“看一看”看到你认为好看的文章。
    已取消，“好看”想法已同步删除
    已推荐到看一看 和朋友分享想法
    最多200字，当前共字 发送

    已发送

    朋友将在看一看看到

    确定
    分享你的想法...
    取消

    分享想法到看一看

    确定
    最多200字，当前共字

    发送中

    网络异常，请稍后重试

    微信扫一扫
    关注该公众号

    0 │ 收藏 │ 举报




    联系我们

    欢迎来到TinyMind。

    关于TinyMind的内容或商务合作、网站建议，举报不良信息等均可联系我们。

    TinyMind客服邮箱：support@tinymind.net.cn

    TinyMind.net.cn，专业AI技术社区