Oracle表数量对数据泵备份恢复速度的影响情况

Oracle表数量对数据泵备份恢复速度的影响情况

---

背景

随着公司产品交付后的时间越来越久.
数据库的备份恢复速度会越来越慢. 最开始一直认为是因为数据量导致的.
但是最近发现, 如果只是将数据库表的量扩展, 导出速度并不会特别大的影响.
所以感觉比较奇怪:
为何运行一段时间后, 数据库备份恢复的速度会下降如此的多.

---

一个现象

最近有一个项目反馈:
清理了部分没太有用的表之后, 机器的CPU占用率有了很大的降低.
想到之前同事反馈的背景里的问题. 思考既然运行时的CPU能够降低
是否也会减少备份恢复过程站时间和资源的使用.
基于此, 准备进行一次专门的验证, 顺便总结一下并行与压缩相关的内容
需要说明的是 去年总结的并行命令存在错误. 

Oracle的EXPDP 和IMPDP 的并行度必须以文件数为核心驱动.
文件数量是并行度的基础. 如果只有一个文件, 并行度设置的在高其实也没意义.

---

进行验证-思路

思路:
在清理表之前进行两次备份:
1次为 不压缩不并行的导出速度.
1次为 压缩然后并行导出的速度.

清理表之后再次执行两次备份, 验证时间.

---

进行验证-命令

1. 最基础的命令:
   最基本的导出:
expdp 'myapp2103ora/TestBirthdayOfSon'@127.0.0.1/ora19cauto
directory=dir schemas=myapp2103ora dumpfile=myapp2103ora_with_alltemp.dump
logfile=2022092301.log   EXCLUDE=STATISTICS
2. 加强版的命令:
   压缩加并行:
expdp 'myapp2103ora/TestBirthdayOfSon'@127.0.0.1/ora19cauto
directory=dir schemas=myapp2103ora
dumpfile=myapp2103ora_with_alltemp_parallel_compression_%U.dump
parallel=10 COMPRESSION=DATA_ONLY
logfile=2022092302.log  EXCLUDE=STATISTICS
# 注意可以在导出文件增加 "_%U.dump" 的后缀. 就可以根据parallel的参数进行形成多个文件.
# 注意 COMPRESSION 建议选择 DATA_ONLY 不建议使用ALL, 元数据可能会有损坏.

---

执行验证-清理部分开头的表信息

begin
  for t in (select table_name tn from user_tables where table_name like 'SOMETHING%' AND LENGTH(TABLE_NAME) > 15) loop
      begin
    execute immediate 'drop table '||t.tn;
    end;
  end loop;
end;

---

执行验证-验证清理后的性能.

结论:
清理垃圾表后并行压缩备份的速度是不清理并且不压缩不并行时间的: 1/8
清理垃圾表能够极大的提高备份的效率. 降低时间
并行和压缩也有很大的提升.
建议不要有太多的可以清理的垃圾表. 务必要定期清理.
推断:
如果会影响备份速度, 就可能影响系统运行速度.尤其是查询系统资源视图时. 

总表数 3万5
T开头垃圾表   1万
B开头垃圾表   1.5万
其他表(业务) 1万
数据文件大小: 88G

清理垃圾表之前 不压缩 不并行备份: 40分钟 清理之后 12分钟
备份文件大小                       53G             13G
清理垃圾表之前 压缩    并行备份:  9分钟  清理之后  5分钟
备份文件大小                       49G             12G