OGG迁移大库注意要点之impdp导入产生大量归档
最近在某银行进行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=MYUSER
impdp 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');