前言    某大型國有銀行一套關(guān)鍵系統(tǒng)10g升級到11g，老K負責升級后第一天早上的運行保障；在升級前甲方客戶已經(jīng)先后做了各種測試，以保證升級后不會存在任何性能問題。然而，事與愿違，老K剛到現(xiàn)場，客戶應(yīng)用團隊就已經(jīng)反饋到客戶說批量慢了一段時間，根據(jù)應(yīng)用日志與現(xiàn)場負責協(xié)助升級的友商DBA的核查，初步定位問題為升級后使用的存儲變慢導(dǎo)致的導(dǎo)出緩慢，拖慢了批量的執(zhí)行時間。對于這一結(jié)論，客戶在調(diào)動存儲相關(guān)工程師進行核查的同時，還存在疑惑，于是老K便開始參與這一問題的追查；現(xiàn)在問題就可以描述為：oracle從10g升級到11g后，導(dǎo)入操作變慢。

創(chuàng)新互聯(lián)公司客戶idc服務(wù)中心，提供IDC機房托管、成都服務(wù)器、成都主機托管、成都雙線服務(wù)器等業(yè)務(wù)的一站式服務(wù)。通過各地的服務(wù)中心，我們向成都用戶提供優(yōu)質(zhì)廉價的產(chǎn)品以及開放、透明、穩(wěn)定、高性價比的服務(wù)，資深網(wǎng)絡(luò)工程師在機房提供7*24小時標準級技術(shù)保障。01開始思考

  因為是升級前后導(dǎo)入的效率變化，于是老K首先將生產(chǎn)系統(tǒng)分別在10g和11g的環(huán)境下導(dǎo)入的日志來進行對比，主要核對導(dǎo)入的時間點后再進一步查看相關(guān)時間點數(shù)據(jù)庫的狀態(tài)。然而，在看過兩個日志后，老K就有了自己的疑惑，于是，我就啟動自己的虛擬機，開始自己的驗證探索之旅。

上面兩圖是我在自己的虛擬機上直接測試導(dǎo)入得到的導(dǎo)入日志文件，細心的你在看完下圖之后，是否也發(fā)現(xiàn)了一些疑惑呢？老K提示：

老K提示：

1.導(dǎo)入時啟用了并行（并行為6，大于表的個數(shù)）

2.導(dǎo)入時使用了content=data_only（說明數(shù)據(jù)庫中原來已經(jīng)有了表的定義）

3.導(dǎo)入的表中存在分區(qū)表（A1，A2，A3共計24個分區(qū)）和非分區(qū)表（A6）

02分析中。。。

如圖所示，表A6比較大，有超過500萬條記錄（而且這里老K還在A6表上建了索引，在導(dǎo)入時還需要維護A6表的索引，其他表則沒有索引），而其他所有的表占用空間加起來也不過300M大小而已。在10g的日志中，A6表的日志記錄寫在了最后一行，而在11g的日志中則出現(xiàn)在了第四行。

正常來說，使用數(shù)據(jù)泵導(dǎo)入/導(dǎo)出多個表時，會在導(dǎo)入/導(dǎo)出完成時在日志中打出相應(yīng)表的信息，如果這里A6表作為一個大表，卻相較于其他表先完成導(dǎo)入操作，我們就可以懷疑分區(qū)表和非分區(qū)表同時導(dǎo)入時，11g數(shù)據(jù)泵的機制是存在問題的，特別是在對比了10g的導(dǎo)入情況后。

03猜測&驗證

上面梳理出疑惑，我們應(yīng)該怎么去驗證呢？如果我們是正在執(zhí)行導(dǎo)入/導(dǎo)出的操作，我們可以attach到導(dǎo)入/導(dǎo)出任務(wù)中進行實時觀察；而如果是導(dǎo)入/導(dǎo)出已經(jīng)完成了，那我們就需要從數(shù)據(jù)庫的歷史性能視圖中去尋找答案了（這里我們主要針對11g數(shù)據(jù)庫進行驗證）。

首先，我們先來通過v$active_session_history視圖來查看導(dǎo)入的整體情況：

這里使用v$active_session_history視圖來核查，每秒做一次采樣發(fā)現(xiàn)，導(dǎo)入期間，數(shù)據(jù)庫確實啟動了6個并行進程（worker），其中DW00進程采樣次數(shù)最多，但是各進程的最早采樣到的時間和最后采樣到的時間相差無幾，都是從12:36左右到12:51;顯然，這個過程中有部分worker進程是空閑的；

那么，是不是分區(qū)表導(dǎo)入存在問題呢？

我們先來分析分區(qū)表（以A1為例）的導(dǎo)入過程：

通過上面結(jié)果，我們能看到一個特征，就A1表而言，其各個分區(qū)的導(dǎo)入散落在不同的DW進程上，但是從采樣的大最小時間上看，沒有重合時間區(qū)域，也就是說，在目前DATAPUMP啟動了6個并行來導(dǎo)入4個表的時候，看起來分區(qū)表A1表并沒有做到多個分區(qū)并行導(dǎo)入，同樣我們核查A2、A3表的導(dǎo)入情況：

得出結(jié)論如下：導(dǎo)入時，雖然并行度是6，只導(dǎo)入4個表（含分區(qū)表）的情況下，所有的表的多個分區(qū)間沒有并行地導(dǎo)入，至少有個兩個DW進程是空閑的（實時attach到導(dǎo)入進程監(jiān)控時更是一目了然）。

此類情況是不是與我們以往的經(jīng)驗相違背呢？

知識點：

1.數(shù)據(jù)泵導(dǎo)入時，并行主要是通過多個進程分別導(dǎo)入不同的表來提高導(dǎo)入速度的，而不同的分區(qū)作為不同的segment一般也被當做不同的表來處理；

2.數(shù)據(jù)泵導(dǎo)入時，默認使用的是insert append的方式，也就是說在導(dǎo)入時會持有對象的表鎖；

本次的導(dǎo)入好像就是與第一條有所不符，導(dǎo)入時在存在空閑進程的情況下，同一個表的不同分區(qū)并沒有做到并行，那是為什么呢？我們需要注意到我們在前面提到的幾個導(dǎo)入特征，其中一個就是，我們使用了content=data_only; 使用這個參數(shù)就意味著，當前數(shù)據(jù)庫中已經(jīng)有了該分區(qū)表的定義，只是將數(shù)據(jù)導(dǎo)入到已存在的表中去，在數(shù)據(jù)庫中已經(jīng)存在分區(qū)表的定義而需要向其中導(dǎo)入數(shù)據(jù)時，則可能會遇到的一種情況是，數(shù)據(jù)庫中分區(qū)表的定義與DUMP文件中分區(qū)表的定義不一致（比如分區(qū)鍵不一致），導(dǎo)致DUMP文件中的分區(qū)無法與數(shù)據(jù)庫中的已有分區(qū)一一對應(yīng)，而無法做到一一對應(yīng)就意味著，如果啟動多個WORKER同時導(dǎo)入一個表的不同分區(qū)，不同WORKER就有可能會同時向一個目標分區(qū)中執(zhí)行insert append操作，前面提到，insert append操作會持有行鎖，這樣最后會出現(xiàn)導(dǎo)入worker間的互相阻塞的情況，而且有可能形成死鎖，所以oracle較新的版本中，在導(dǎo)入已存在分區(qū)表時（使用了參數(shù)content=data_only等），同一表的多個分區(qū)是順序?qū)氲模m然有可能是通過不同的worker來執(zhí)行）。

04疑問&解答

那么10g數(shù)據(jù)庫的導(dǎo)入是不是也是這樣呢？我們用同樣方法來測試觀察，可以發(fā)現(xiàn)10g數(shù)據(jù)庫的導(dǎo)入也是如此，那么客戶在10g、11g環(huán)境中導(dǎo)入的數(shù)據(jù)、表的定義、導(dǎo)入命令，都沒有變化，看起來并行+metadata_only并不是問題所在，那么真正的問題在哪里呢？我再次回到最開始的問題：

在10g的日志中，A6表的日志記錄寫在了最后一行，而在11g的日志中則出現(xiàn)在了第四行，也就是說，在10g中，A6表是最后完成的，而在11g中A6表卻在A1、A2、A3表的大部分分區(qū)完成前已經(jīng)完成了，是A1、A2、A3表的導(dǎo)入進程在等待什么嗎？

還是要回到v$active_session_history視圖上來:

可以看到，A6導(dǎo)入時間大約從12:36持續(xù)到12:49，包含索引維護

而在此期間其他活動的會話中，各分區(qū)表只導(dǎo)入了一個分區(qū)（即各表導(dǎo)入的第一個分區(qū)），而且各WORKER在導(dǎo)入完第一個分區(qū)后（12:37:32~12:42:17）并沒有異常等待，而是處于空閑狀態(tài)。

我們再回顧一下各個表的導(dǎo)入情況：

可以看到，各個表在導(dǎo)完第一個分區(qū)后，出現(xiàn)長時間的停頓，一直等到非分區(qū)表導(dǎo)入完，才繼續(xù)后續(xù)的分區(qū)導(dǎo)入；

結(jié)合各worker的狀態(tài)及各表導(dǎo)入的時間狀態(tài)以及前面的結(jié)論我們可以確認一點：

在分區(qū)表和非分區(qū)表同時導(dǎo)入，而且是數(shù)據(jù)庫中表定義已經(jīng)存在（使用content=metadata_only等參數(shù)）時，分區(qū)表需要逐個導(dǎo)入無法使用并行，而在所有分區(qū)表分別導(dǎo)完第一個分區(qū)后，需要等待所有的非分區(qū)表導(dǎo)入完成，才能繼續(xù)后面的分區(qū)表的分區(qū)導(dǎo)入，進而影響導(dǎo)入進度。

而以上問題在10g數(shù)據(jù)泵中不存在，宇宙行客戶所遇到的問題正是這個問題，升級后多花費的時間也基本上就是單個非分區(qū)表導(dǎo)入的時間。以上問題已經(jīng)提交的ORACLE官方并確認為11g導(dǎo)入的調(diào)度機制問題，目前正在開發(fā)解決中。

05

我們遇到了什么

看看我們遇到了什么問題吧：

1.在10g中，我們使用并行導(dǎo)入分區(qū)表和非分區(qū)表，并且目標庫中已經(jīng)有了表的定義，于是我們加上了content=data_only參數(shù)；

2.導(dǎo)入的過程中，分區(qū)表的各個分區(qū)逐個導(dǎo)入，在并行進程足夠多的時候各個表之間實現(xiàn)并行導(dǎo)入；

3.升級到11g以后，各分區(qū)表僅僅導(dǎo)入第一個分區(qū)，然后開始等待；

4.非分區(qū)表導(dǎo)入完成后，各分區(qū)表繼續(xù)完成導(dǎo)入。

而現(xiàn)在我們知道了，多花費的時間就是第三步的時間，在10g環(huán)境先，非分區(qū)表可以與分區(qū)表并行導(dǎo)入，而到了11g環(huán)境中，非分區(qū)表只能與分區(qū)表導(dǎo)入的第一個分區(qū)并行導(dǎo)入；假設(shè)，我們需要導(dǎo)入的是一個超大的非分區(qū)表和3個分區(qū)表，每個分區(qū)表3個分區(qū)，各分區(qū)大小一致，如果單獨導(dǎo)所有的分區(qū)表需要1個小時，單獨導(dǎo)所有非分區(qū)表需要1個小時，啟用4個并行，在10g的環(huán)境里，理想情況下只需要1個小時即可導(dǎo)入完成（以導(dǎo)入最慢的非分區(qū)表導(dǎo)入完成，即整體導(dǎo)入完），而在11g的環(huán)境中，則需要1個小時+3/4個小時（即105分鐘）。

我們可以做什么：

當我們需要追求導(dǎo)入的效率時：

1.導(dǎo)入分區(qū)表時盡量避免使用content=data_only或table_exists_action=appen/truncate的方式，如果已有表的數(shù)據(jù)量不大，而且dump中表的結(jié)構(gòu)也與已存表的結(jié)構(gòu)一致，我們不妨先存留已有表的數(shù)據(jù)，再使用table_exists_action=replace的方式；

2.如果導(dǎo)入分區(qū)表無法避免使用content=data_only或table_exists_action=appen/truncate，那么我們建議分區(qū)表和非分區(qū)表分開導(dǎo)入。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

本文標題：風(fēng)險預(yù)警·11g容易被忽略的導(dǎo)入性能問題-創(chuàng)新互聯(lián)
文章網(wǎng)址：http://aaarwkj.com/article18/dpisdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、網(wǎng)站制作、用戶體驗、網(wǎng)站收錄、小程序開發(fā)、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)