点击上方"蓝字"

关注我们，享更多干货！

最近在某银行进行OGG迁移时，遇到一个超过1T的数据库，由于开始没有注意到一些细节，导致在导入过程中出现了一些问题。现在将这些问题总结记录下来，防止之后再发生类似问题。

目前在该银行的OGG迁移流程中，旧数据的迁移使用imp/impdp两种方式，对于源库：目标库字符集相同的情况使用expdp/impdp，字符集不同的情况使用exp/imp。

使用exp对大库迁移时，为提高导出导入效率，缩短导出导入时间，需要采用将旧数据拆分导出导入，并且针对每个拆分创建对应的OGG抽取，应用进程。

使用expdp对大库迁移时，就可以使用开多个并行的方式进行导出导入。

问题：

对于大库的impdp导入，最需要注意的就是数据量太大，导入时在目标库短时间产生大量归档日志，导致整个CDB的归档日志空间被撑满，影响CDB上的所有PDB。

解决方案：

检查目标库归档空间大小，如果可以提前清理出足够空间，则导入时不用人为干预，导完之后删除归档。如果目标库总归档空间依然不足，则需要人为干预，边导入边删归档清理空间，并且主库、备库都需要清理。

Step by Step 的实操和要点：

导出前检查：

查询用户：

select username from dba_users where account_status='OPEN' order by username;

查询字符集：

select property_value from database_properties where property_name='NLS_CHARACTERSET';

在目标库检查是否创建了对应的表空间：

select distinct tablespace_name from dba_tables where owner='MYUSER';

查询当前SCN号：

select current_scn from v$database;

配置OGG抽取流程：

（略）

使用expdp导出：

创建par文件:

vi expdp_dbname_20210801120323.par

在文件中写入：

userid="/ as sysdba"
directory=dmp_upgrade_by_ogg
dumpfile=dbname1_20210801120323_%U.dmp
schemas=MYUSERlogfile=dbname1_20210801120323.log
flashback_scn=7557975
parallel=4
cluster=n
version=19.3

执行导出：

expdp
PARFILE=expdp_dbname_20210801120323.par

导出不会产生大量归档，所以不用担心。

记录好导出文件dbname1_20210801120323_%U.dmp，导出的SCN号7557975。

重点：impdp导入

由于要导入的数据量很大，在导入表的阶段会产生大量归档日志，所以需要在导入前检查目标库各个主库备库的归档空间是否足够。

检查ASM磁盘空间：

在grid用户下执行：
asmcmd lsdg
检查FRADG的Usable_file_MB的大小。

在Oracle用户下进入数据库：

su - oracle
sqlplus / as sysdba

查询：

在CDB中执行命令：

show parameter recovery
查看db_recovery_file_dest_size大小。
在某银行的数据库设置中，归档会占用此空间。

查看percent_space_used列，此列相加得出空间的总使用率。

select * from v$recovery_area_usage;
select * from v$flash_recovery_area_usage;
archived_log行就是归档日志的使用率。

如果导入前目标库可用的归档空间已经不足，可以尝试删除一些。在导入过程中，如果总使用率大于80，就需要手动删除归档。

删除归档：

首先需要检查DG状态：

在Oracle用户下：
su - oracle
dgmgrl /
show configuration lag verbose
检查备库的数据延迟，没有延迟或延迟小于10分钟，则可以开始删除归档。
如果延迟大于10分钟，需要查询备库应用到哪个归档日志文件了，检查是不是断掉了

在备库执行：

检查是否断掉：
select * from v$archive_gap；
如果没有结果，表示没有gap断开。

查看备库当前归档：

select process,sequence#,thread#,status from v$managed_standby;
MRP0就是正在应用的归档。MRP0就是正在应用的归档。

RFS进程：

sequence对比
select * from v$standby_log;
中的sequence。

检查完成没有问题后，可以开始删除归档日志。

进入rman：

su - oracle
rman target /

检查归档日志应用的删除策略：

show all;

显示当前所有归档：

crosscheck archivelog all
可以看到序号和日期等信息。

删除1天前的归档日志：

delete noprompt archivelog all completed before 'sysdate -1'

如果清理的空间有限（一般情况下是这样），可以修改归档删除策略，此时不改，如果数据库归档总空间不足，边导入边删除时也要改。

原始为：

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';
归档日志备份到设备SBT_TAPE上之后才能删除。

修改为：

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
归档日志应用之后就可以删除。

修改删除策略之后，再尝试删除归档，或调整时间继续删除：

删除2小时前的归档日志：

delete noprompt archivelog all completed before 'sysdate -2/24'

删除半小时前的归档日志（边导入边删除一般使用这条）：

delete noprompt archivelog all completed before 'sysdate -0.5/24'

开始导入：

编辑导入配置文件：

vi impdp_dbname_20210801120323.par

写入：

userid="data_migrate_user/pa#Ggi02xd@PDBNAME"
directory=dmp_upgrade_by_ogg
dumpfile=dbname1_20210801120323_%U.dmp
logfile=dbname_20210801120323.log
parallel=4
cluster=n
schemas=MYUSERimpdp PARFILE=impdp_dbname_20210801120323.par

开始导入后，人工监控归档使用情况，依照上文给出的查询和删除命令进行归档删除。

在导入表的阶段，归档日志增长很快，表的数据导完后，在进行导入索引，统计信息等数据时，归档增长相对较慢。

在实际生产中，迁移1T的数据库，在主库、本地备、远程备上共产生了大约2.2T的归档，

查询产生归档：

select sum(blocks*block_size)/1024/1024/1024 from v$archive_log where dest_id=1 and completion_time>to_date('2021-08-01 15:30:00','yyyy-mm-dd hh24:mi:ss');
select sum(blocks*block_size)/1024/1024/1024 from v$archive_log where dest_id=1 and first_time>to_date('2021-08-01 15:30:00','yyyy-mm-dd hh24:mi:ss');

墨天轮原文链接：https://www.modb.pro/db/102195?sjhy（复制到浏览器或者点击“阅读原文”立即查看）

关于作者

陈坤，云和恩墨DBA，服务于金融行业。现负责某大型银行OGG迁移专项，热衷于研究数据库自动化运维、数据库迁移等技术。

END

推荐阅读：267页！2020年度数据库技术年刊

推荐下载：2020数据技术嘉年华PPT下载

2020数据技术嘉年华近50个PPT下载、视频回放已上传墨天轮平台，可在“数据和云”公众号回复关键词“2020DTC”获得！

你知道吗？我们的视频号里已经发布了很多精彩的内容，快去看看吧！↓↓↓

点击下图查看更多 ↓

云和恩墨大讲堂 | 一个分享交流的地方

长按，识别二维码，加入万人交流社群

请备注：云和恩墨大讲堂

  点个“在看”

你的喜欢会被看到❤