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