引言

在银行业中，数据是生命、是金钱、是最重要的资产，因此数据库运维工作更是IT运维中的重点。在数据库日常管理中，数据迁移是一项极为重要的工作。迁移不仅要保证数据完整性，还要确保业务连续稳定运行，是一项极其庞大，需要精细调整和综合运用技术手段的工程。

近期我们迁移了多套生产环境，积累了较为丰富的经验，而“大鹏之动，非一羽之轻也；骐骥之速，非一足之力也”，在此分享给各位业界同仁，欢迎大家留言讨论，共同夯实数据库运维管理之基石！

●背景●

我行随着业务的指数增长，某重要应用数据库服务器硬件性能已经不能满足业务需求，需要将该数据库迁移到高性能服务器上。

Oracle数据库常用迁移方式及适用场景包括以下五种：

1. 物理迁移

有停机窗口且源端目标端的平台相同的情况下，可通过拷贝数据文件、控制文件、日志文件、参数文件等到目标服务器对应目录下，可直接打开数据库。

2. 数据泵迁移

有停机窗口情况下，可通过expdp/impdp的方式迁移数据库。对平台无要求。

3. DG迁移

在停机时间短且源端目标端的平台相同的情况下，采用DG方式，通过DG切换的方式迁移。

4. RMAN迁移

在停机时间短且源端目标端的平台相同的情况下，采用RMAN的方式，通过全量恢复和追归档的方式迁移。

5. 存储迁移

停机时间短(包括停库、切存储、启库时间)且源端目标端的平台、数据库版本相同，通过存储复制或存储切换的方式，启动新环境数据库。

待迁移数据库特点：原生产数据库有较长停机窗口，且在生产环境中，因业务属性DML操作较多，并且由于前期配置问题，产生过多碎片，数据库关联应用系统较少。

根据行内现有环境现状，初选方案是存储复制和数据泵两种。经过对比两种方案的优缺点，以及结合实际应用的特点，最终选择了第二种数据泵的方式进行迁移。此方案其在迁移的过程中可以清理大量碎片，提升数据库整体性能，对后期业务的运行能力提升有积极的效果，同时移方法具有简单、平稳的优势。本文中重点介绍数据泵迁移方案的过程。同时简单描述存储复制这个备选迁移方案的实现过程。

●流程及操作模板●

数据库迁移流程图

操作模板

主机信息介绍

序号	内容	原数据库	目标数据库
1	主机名	host1/host2	newhost1/newhost2
2	服务器型号	IBM p740	IBM p750
3	CPU	16c	20c
4	MEM	128G	256G
5	系统	AIX6.1	AIX7.1
6	物理IP	192.168.1.1/2	192.168.2.1/2
7	vip	192.168.1.3/4	192.168.2.3/4
8	scan	192.168.1.5	192.168.2.5
9	DB版本	11.2.0.4	11.2.0.4.190716
10	模式	RAC	RAC

1. 准备阶段

前期准备阶段，需将主机、系统、网络、软件及补丁等相关信息准备好，新环境需要按照基线文档安装主机系统，并配置相关参数、时区、DNS、NTP、数据库备份目录等；并核实原环境的root密码、各个在用用户的定时任务及相关脚本；将新环境添加相关监控工具。

2. 准备迁移

注意：迁移过程中新系统导入用户密码和原系统密码保持不一致，迁移完成后再进行修改，directory名称要保持不一致。

• 拷贝原数据库主机相关文件(定时任务脚本、tnsname.ora)到对应新环境主机，并核实tnsnams.ora文件是否需要修改信息；

• 应用人员停止应用——>停止数据库监听——> kill掉应用相关会话

检查用户连接信息命令：

select inst_id, sid, serial#, username, machine, program, statusfrom v$sessionwhere type = 'USERS'and username in(select usernamefrom dba_userswhere created >(select created from dba_users where username = ‘SYSTEM‘) + 1);

kill掉应用相关会话命令：

select 'alter system kill session ''' || sid || ',' || serial# || ’,       @’ || inst_id || ‘;''' immediate；'   from v$session where type = 'USERS' and username in (select usernamefrom dba_userswhere created >       (select created from dba_users where username = ‘SYSTEM‘) + 1);

• 修改数据库用户密码，生成新库下用户和DBLINK语句；

修改密码命令：

alter user 用户名identified by 密码;

生成相关用户的密码脚本命令：

select ‘alter user ’ || username || ‘ identified by 密码;’ from dba_users where username in (  select username    from dba_users   where created >         (select created from dba_users where username = ‘SYSTEM‘) + 1)   order by created;

用数据库运维工具查询并复制各个迁移用户和DBLINK的创建脚本，尤其对用户拥有的执行权限和directory权限要格外关注。

3. 数据泵迁移

• 对比新旧数据库相关启动参数；

• 创建表空间、相关用户并授权、原数据库导出目录与新数据库导入目录并授权；

创建和扩容表空间命令：

create tablespace SCOTT datafile '+ASM_DATA/host/datafile/scott01.dbf' size 30G;alter tablespace SCOTT add datafile '+ASM_DATA/host/datafile/scott02.dbf' size 30G;

生成创建表空间脚本命令：

set lin 200 pages 100select 'create tablespace ' || TABLESPACE_NAME || ' datafile ''' ||       file_name || ''' size ' || BYTES || ';' from  dba_data_files;

创建相关用户脚本命令：

select 'create user ' || name || ' identified by values ''' || u.password ||       ''' default tablespace ' || default_tablespace ||       ' temporary tablespace ' || temporary_tablespace || ';'  from user$ u, dba_users du where du.username = u.name   and du.created >       ((select created from dba_users where username = 'SYSTEM') + 1) order by u.ctime;

创建对应directory

创建导出目录命令：

create or replace directory expdp_dir as '/dmps/backup/expdp';grant read,write on directory expdp_dir to public;

创建导入目录命令：

create or replace directory IMPDP_DIR as '/dmps/backup/expdp';grant read,write on directory IMPDP_DIR to public;

如生产环境后期需备份nfs需要event配置增加以下内容，否则无法使用nas，提示以下报错(ora-39001,ora-39000,ora-31641,ora-27054):

alter system set events='10298 trace name context forever, level 32';

• 迁移用户相关信息；

• 数据库导出导入；

用户备份命令(用户名称已调整)：

expdp system/oracle job_name=scott directory=EXPDP_DIR dumpfile=SCOTT_0608%U.dmp logfile=expscott_0608.log PARALLEL=8 cluster=no SCHEMAS=scott,monitor

用户恢复命令(用户名称已调整)：

impdp system/oracle  directory=IMPDP_DIR dumpfile=scott_0608%U.dmp logfile=impscott_0608.log PARALLEL=8 cluster=no SCHEMAS=scott,monitor

4. 迁移后续工作

• 核实数据库对象；

• 核实并编译无效对象；

编译无效对象命令：

@$ORACLE_HOME/rdbms/admin/utlrp.sql

核实数据库中无效对象性命令：

select owner, object_type, status, count(*)  from dba_objects where owner in       (select username          from dba_users         where created >               ((select created from dba_users where username = 'SYSTEM') + 1)) group by owner, object_type, status order by 1, 2;

如存在无效对象，可以进行手动编译:

col object_name for a30select object_type,object_name  from dba_objects where owner='&owner' and status='INVALID';set serveroutput onalter &object_type &owner.&objectname compile;

• Dblink验证

• 开启归档并切换归档验证

• 应用验证

5. 存储复制

【此处简单描述存储复制备选迁移方案的实现过程】

• 新环境检查(内存、补丁、集群)；

• 识别共享盘，挂载磁盘组；

修改存储盘权限：

lspv | grep hdiskpower | grep -v grep |awk '{split($1,b,"r");if(b[2]>10)print}'|awk '{print $1}'  | while read diskdochdev -l ${disk} -a reserve_policy=no_reserve;chmod 660 /dev/r${disk}   chown grid:asmadmin /dev/r${disk}done

说明：使用kfod查看老的asm磁盘组(grid用户下)，新环境使用新的ocr、vote磁盘组，原相应磁盘组可以删除。

newhost1[/home/grid]$kfod disks=all ds=true cluster=true status=true

• 创建相关审计目录，拷贝系统层面Oracle相关文件，修改oracle用户下$ORACLE_HOME/bin/oracle文件权限，启动数据库，注册数据库，调整local listener、内存相关、scan name相关参数；

• 重启集群；

6. 完成阶段

• 停止原数据库集群并修改主机root密码；

• 新数据库添加到相关监控工具；

• 新数据库完成全量备份；

• 清理用于迁移的相关脚本及目录。

最终数据库迁移平稳完成，但是由于生产数据库迁移过程繁琐，即使做好迁移计划跟准备工作，还是有部分细节问题没有注意到，遇到问题如下：

1. 迁移后出现应用跑批前备份报错，现象如下图：

根据报错信息排查数据库涉及权限，核实涉及相关权限和迁移后的权限一致，如图：

同时核查数据泵相关目录及权限均和原生产保持一致，oracle用户相关home目录正确，解决方法：重新对报错的文件再次单独授予权限：

exec DBMS_JAVA.GRANT_PERMISSION(grantee => 'HSAP',permission_type => 'SYS:java.io.FilePermission',permission_name => '/oracle/db/product/11.2.0/bin/expdp',permission_action => 'read,write,execute');

执行完权限后，通知应用进行重新发起备份后，批前备份成功，分析主机及数据库情况，怀疑该问题是由于操作系统java版本不一致引起，后续需在测试环境进行验证。

2. 应用跑批任务执行缓慢，前后差距1：24倍，针对该情况核实表及索引有效，表分析在迁移完数据库后执行，现场排查后通过再次执行表分析，跑批任务恢复正常，经查业务表上存在数据倾斜问题，所以直方图信息尤为重要，后经查询MOS确定，采取默认方式进行表分析不会自动收集直方图信息，为了防止日后的数据库迁移出现类似问题，同时减少迁移时间(指定method_opt方式收集会导致表分析时间变长)，决定日后在数据库迁移方案中进行如下设置：

• 源库导出、目标库导入过程均带统计信息；

• 目标库设置全局参数。

●工作梳理及展望●

整个迁移准备过程耗时两周，此次数据库迁移暴露的问题：耗时长、细节问题多、流程不规范、操作无模板、人工依赖性强、专业要求性高等，针对这些问题，我们重新回顾并完善了数据库迁移的整个过程，形成标准化操作步骤，规范化迁移流程，自动化迁移脚本。按照新的迁移方案，降低数据库迁移技术门槛，避免迁移细节的遗漏，大幅缩短了迁移时间，并通过自动化运维编排工具初步形成数据库的逻辑迁移自动化。

通过这次数据库的迁移，也让我们对现阶段的运维工作做了深刻反思，并对以后的运维模式有了新的规划。现阶段的人工运维模式对运维工作来说局限性很大，隐患也较多。运维工作中的细节操作时有遗漏，且存在定位问题耗时长，很多运维工具也没有很好的运用起来，无法帮助解决实际运维问题。本次迁移实现了流程与运维操作的规范化、标准化，也让我们对运维有了更清晰的理解和认识。但是对于未来将要实现大数据、人工智能的时代，这些还远远不够。未来的大数据与AIOps决不仅是一种概念，而是需要真正将大数据与AI技术应用到实际运维工作中，实现对主机、网络、系统、数据库、中间件等多维度、全生命周期的运维管理，不仅能够解决现在运维中存在的问题，还要能够实现对问题的预测、故障的自愈，真正做到“运筹帷幄之中，决胜千里之外”！

作者简介

王新宇

王新宇：Oracle OCP、RHCE，现任职于北京银行系统运营部，负责Oracle、TiDB、GP数据库、负载均衡等多个领域的运维相关工作。

高永超

高永超：Oracle  OCM、PCP、RHCE，现任职于北京银行系统运营部，负责Oracle、Tidb数据库运维相关工作。

王冬梅

王冬梅：Oracle  OCP，现任职于北京银行系统运营部，负责数据库运维相关工作。