Minso

mcposdb数据库存储迁移流程

明确mcposdb数据库存储迁移需求

将现有的AFF8040存储替换为EF570存储，采用asm rebalance技术进行在线迁移。

前期准备工作

查看ASM磁盘组信息

$ asmcmd lsdg

查看ASM 磁盘空间使用情况

$ asmcmd lsdsk –k
$ sqlplus / as sysasm
sqlplus / as sysasm
SQL> set linesize 300
SQL> column path format a50
SQL> select GROUP_NUMBER,DISK_NUMBER,HEADER_STATUS,MODE_STATUS,MOUNT_STATUS,STATE,total_mb,free_mb,NAME,FAILGROUP,LABEL,PATH from v$asm_disk;

SQL> select
   mount_status,
   header_status,
   mode_status,
   state,
   total_mb,
   free_mb,
   name,
   path,
   label
from
   v$asm_disk;

检查多路径状态

multipath –ll

mcposdb数据库存储迁移步骤

查看磁盘的分区和挂载情况

lsblk

确认新挂载的磁盘

multipath -ll | grep -A 1 'EF570'

配置多路径

/etc/multipath.conf /etc/multipath/bindings

多路径配置生效

service multipathd reload

udev 磁盘绑定

vi /etc/udev/rules.d/99-asm.rules

udev 规则生效

优先采用使用Redhat udev 规则生效推荐的方法操作

udevadm control --reload-rules
udevadm trigger --type=devices --action=change

将磁盘EF570-DATA01p1、EF570-DATA02p1、EF570-DATA03p1、EF570-DATA04p1加入到 DATAVG

alter diskgroup DATAVG add disk '/dev/oracleasm/disks/EF570-DATA01p1','/dev/oracleasm/disks/EF570-DATA02p1','/dev/oracleasm/disks/EF570-DATA03p1','/dev/oracleasm/disks/EF570-DATA04p1' rebalance power 5; 备注：尽量在业务不繁忙的情况下操作;

查看rebalance情况与日志对比

使用以下命令查看观察:当没有输出时则表明reblance完成。

select * from v$asm_operation;

$ asmcmd -p lsop
$ tail -f alert.log

备注：确认rebalance 完成后，再进行下一步删盘操作；尽量在业务不繁忙的情况下操作;

逐次剔除旧存储对应的asm disk

alter diskgroup DATAVG drop disk DATAVG_0000 rebalance power 16;
alter diskgroup DATAVG drop disk DATAVG_0001 rebalance power 16;
alter diskgroup DATAVG drop disk DATAVG_0002 rebalance power 16;

select * from v$asm_operation;

查看rebalance情况与asm日志对比

$ asmcmd -p lsop
$ tail -f alert.log

== 删除ARCHVG磁盘组 ==
{{{
sqlplus / as sysasm
SQL> alter diskgroup ARCHVG dismount;
SQL> drop diskgroup ARCHVG force including contents;

当主库发生故障时切换到备库，采用DataGuard 主备切换方式

Pre-Switchover Checks

The following query at the standby verifies that managed recovery is running:

SQL> SELECT PROCESS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%';

The following query at the Primary verifies that recovery is running with “REAL TIME APPLY” option.

SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;

RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY

If managed standby recovery is not running or not started with real-time apply, restart managed recovery with real-time apply enabled:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Verify Primary and Standby tempfiles match and all datafiles are ONLINE

SQL> SELECT TMP.NAME FILENAME, BYTES, TS.NAME TABLESPACE
     FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#;

On the target standby:

SQL> SELECT NAME FROM V$DATAFILE WHERE STATUS=’OFFLINE’;

If there are any OFFLINE datafiles, and these are needed after switchover, bring them ONLINE:

SQL> ALTER DATABASE DATAFILE ‘datafile-name’ ONLINE;

switch over切换（先主库端）

Turn on Data Guard tracing on primary and standby

  * Capture the current value on both the primary and the target physical standby databases
SQL> SHOW PARAMETER log_archive_trace

  * Set Data Guard trace level to 8191 on both the primary and the target physical standby databases
SQL> ALTER SYSTEM SET log_archive_trace=8191;

SQL> SHOW PARAMETER background_dump_dest

  * Tail the alert logs.
> tail –f <background_dump_dest location>/alert*

主库端操作

select database_role,switchover_status from v$database; //查看数据角色及切换状态
select protection_mode,protection_level from v$database; //确认保护模式和级别

alter database commit to switchover to physical standby with session shutdown; //切换为备库

startup mount; //开启数据库
alter database recover managed standby database using current logfile disconnect from session; //开启日志应用

备库端操作（后备库端）

Verify that the standby database can be switched to the primary role

select database_role,switchover_status from v$database; //查看角色及状态

alter database commit to switchover to primary with session shutdown;  //切换为主库
alter database open;

désert/2019-03-11