Oracle数据库管理每周一例（12.2,18c,19c） 2020-07-23

第八期 记一次HPUX到Exadata的xtts数据迁移——实战篇

本周依然忙于原来数据库的各种管理工作，以及一体机迁移后的各项后续问题处理，疲的要死。
本文中如无特殊说明，均使用oracle用户执行相关操作

1.全量备份与应用

完成预先各项准备以后就要开始进行xtts的迁移工作，第一个任务就是全量备份和应用。
1.源端数据库：

export TMPDIR=/acfs01/xtts
cd /acfs01/xtts
./xttdriver.pl -p

该命令会记录各文件备份时的SCN号，在/acfs01/data目录生成对应表空间数据文件的全量备份，生成convert命令和日志记录。

2.目标数据库：

root用户执行，这一步需要在每次源端操作完成后目标端执行，后面不在重复：
chmod 777 -R /acfs01

export TMPDIR=/acfs01/xtts
cd /acfs01/xtts
./xttdriver.pl -c

该命令会将全量备份的对应表空间数据文件convert到指定的pdb数据文件目录中。

2.增量备份与应用

1.源端数据库：

export TMPDIR=/acfs01/xtts
cd /acfs01/xtts
./xttdriver.pl -i

该命令会记录各文件备份时的SCN号，在/acfs01/data目录生成对应表空间数据文件的增量备份，日志记录。

2.目标数据库：

export TMPDIR=/acfs01/xtts
cd /acfs01/xtts
./xttdriver.pl -r

该命令会将对应表空间数据文件的增量备份convert并应用到对应数据文件中，并生成相关日志。

3.源端数据库：

./xttdriver.pl -s

该命令会将新的SCN记录到主SCN记录文件，用于下次增量备份SCN获取。

在最终迁移之前可以多次重复上面的步骤以减少最终迁移时间。

3.最终增量备份与应用

源端数据库：

alter tablespace TS1 read only;
alter tablespace TS2 read only;
......

export TMPDIR=/acfs01/xtts
cd /acfs01/xtts
./xttdriver.pl -i

目标数据库：

export TMPDIR=/acfs01/xtts
cd /acfs01/xtts
./xttdriver.pl -r

最终增量备份时间直接与上一次增量备份间隔有关。

4.用户元数据导出与导入

1.在源端和目标数据库提前创建directory

create directory dpump as '/acfs01/dpump';
grant all on directory dpump to sys;

2.目标端数据库还需要配置指向本机VIP上对应PDB的TNS本地命名

PDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = host02-vip)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = pdb.xxxx.com)
    )
  )

3.源端数据库：

expdp "'/ as sysdba'" directory=dpump schemas=user1,user2,user3...... content=metadata_only exclude=table,index,statistics dumpfile= userinfo.dmp logfile=userinfo_exp.log parallel=2 metrics=yes job_name = migrate_meta cluster=n

在这一步操作中出现了一个问题，expdp无法在NFS对应目录中产生文件，前期测试中是能够正常生产文件的，浪费了不少时间进行了多次尝试也无法生产，最终选择在本地目录生产dmp文件后再传输到目标端对应目录中。

4.目标端数据库：

impdp "'sys/password@pdb as sysdba'" directory=dpump schemas=user1,user2,user3...... dumpfile=userinfo.dmp logfile=userinfo_imp.log parallel=2 metrics=yes job_name = migrate_meta cluster=n

在这一步操作中，根据debug反馈和日志查询，发现role信息未传输过来，因为还没有表空间中的表信息，需要在后面表空间元数据导入完成后手动建立并授权role。

5.表空间元数据导出与导入

1.源端数据库

expdp "'/ as sysdba'" directory=dpump dumpfile=tablespaceinfo.dmp logfile=tablespaceinfoexp.log transport_tablespaces = TS1,TS2,TS3...... exclude=table_statistics,index_statistics cluster=n

这里遇到了两个问题，在对应表空间中出现了一个前期检查没有的非自包含内容，是一个sys用于统计redo计数的表，导致初次导出失败。虽然表空间已经只读，但是仍然可以用sys用户删除对应表。
另一个问题是时间预估不足，根据数据量估算原计划40分钟，结果耗时105分钟，严重超时，这里要说明一点，表空间元数据导出导入时间和数据量关系不大，和object的数量有直接关系，另一方面，一定不要导出统计信息。

2.目标端数据库

impdp "'sys/password@pdb as sysdba'" directory=dpump dumpfile=tablespaceinfo.dmp logfile=tablespaceinfoimp.log transport_datafiles=
'+DATAC1/SID/PDB字符串/DATAFILE/ts1_x_xx.dbf',
'+DATAC1/SID/PDB字符串/DATAFILE/ts1_x_xx.dbf',
'+DATAC1/SID/PDB字符串/DATAFILE/ts2_x_xx.dbf',
'+DATAC1/SID/PDB字符串/DATAFILE/ts3_x_xx.dbf',
......
exclude=table_statistics,index_statistics cluster=n

其中数据文件信息需要提前准备。
这里遇到了个问题是之前参数检查时漏掉的，db_files仅为默认200，实际文件更多，导入终止，调整参数重启数据库以后又发现无法重启或继续之前的导入，试了官方文档参数也无法成功，所以删除了已导入表空间的元数据，完全重新开始表空间元数据导入：

drop tablespace TS1;
drop tablespace TS2;
......
drop tablespace TSN;
#不添加including contents and datafiles字句不会删除文件，因为只读状态也不会造成文件内容变更

这里还有个问题是预估20分钟结果导入也花了100分钟，这里还不能开并行，可以申明一点，纵然是Exadata，导入耗时也不会比导出快多少。

6.数据检查及及时问题处理

1.下面是官方文档提供的一些语句

declare
parallel pls_integer:= 20; begin
utl_recomp.recomp_parallel(parallel); end;
/

select count(*) from dba_objects where owner=’username’;
#要注意临时表

select t.name "Tablespace", f.file# "File#", f.name "Filename", f.status "Status" from v$datafile f, v$tablespace t where f.ts#=t.ts# and t.name like 'TSPACE%' order by 1, 2;
#查看是否还有在导入中的表空间

2.另一方面通过对比重要表的数据量进行对比
3.表空间逻辑检查

RMAN> validate tablespace TS1,TS2,TS3...... check logical;

4.创建并授权缺失的roles
5.由于11g与19c的用户密码加密方式不同，需要手动重置密码
6.数据验证完成后进行表空间read write，开始业务验证

7.后续问题处理

1.在刚开始业务验证时，反馈数据库十分卡，这里有以下几点原因
SGA中还未缓存数据，需要通过语句执行将数据刷入内存中。
Exadata会在存储中建立索引等加速机制，需要时间。

无统计信息，通过以下语句对重点schema进行了统计信息收集:

exec dbms_stats.gather_schema_stats(ownname=> 'USERNAME',degree=> 48);

然而语句执行完成后语句执行效率仍然较低，与原厂工程师沟通后使用以下语句：

exec dbms_stats.gather_schema_stats(ownname=> 'USERNAME',method_opt=> 'for all columns size auto',degree=> 256);

同时针对业务反馈查询的一些重要表、大表进行单独统计信息收集：

exec dbms_stats.gather_schema_stats(ownname=> 'USERNAME',tabname=>'table_name',method_opt=> 'for all columns size auto',degree=> 256);

经过大约40分钟的“不懈努力”，数据库速度终于提起来了，而且速度非常看，大多数SQL只需要0.0x秒完成。

2.其他操作
对失效内容进行处理，比如对过程、函数等进行重新编译，索引进行重建。
在生产过程中还多次发现因为索引失效造成的锁，这点也需要关注。

业务操作过程中发现过一张表报在数据操作是报出：ORA-10632： Invalid rowid
重建索引没有解决问题，使用以下语句解决了问题：

alter table user.table enable row movement;
alter table user.table shrink space;
alter table user.table disable row movement;

3.undo问题
因为承载业务每晚会有非常大的数据抽取操作，需要较大的undo来保证语句正常执行，然而在确保每个实例上undo表空间和原来数据库大小一致时，仍不能满足条件，随机继续增大undo表空间，这里判断为由于SQL执行加快，同时执行的SQL变相增多造成的。
还有个问题是，当undo表空间数据文件自动增长时，出现过数据库判定表空间不足，使用CDB的undo表空间的现象，因为CDB的undo表空间很小造成语句执行失败的问题。通过resize所有PDB的undo表空间数据文件的方式直接扩大undo表空间容量。同时在CDB中增加了undo表空间容量。

后续还有其他问题也会在这里更新。

下期预告：

最近遇到的一些故障及其处理方案。