在银行业中,数据是生命、是金钱、是最重要的资产,因此数据库运维工作更是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 100
select '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 a30
select object_type,object_name from dba_objects where owner='&owner' and status='INVALID';
set serveroutput on
alter &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 disk
do
chdev -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,现任职于北京银行系统运营部,负责数据库运维相关工作。