風(fēng)險(xiǎn)預(yù)警·11g容易被忽略的導(dǎo)入性能問題-創(chuàng)新互聯(lián)

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

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

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

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

老K提示：

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

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

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

02分析中。。。

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

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

03猜測(cè)&驗(yàn)證

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

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

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

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

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

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

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

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

知識(shí)點(diǎn)：

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

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

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

04疑問&解答

那么10g數(shù)據(jù)庫的導(dǎo)入是不是也是這樣呢？我們用同樣方法來測(cè)試觀察，可以發(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)入進(jìn)程在等待什么嗎？

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

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

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

我們?cè)倩仡櫼幌赂鱾€(gè)表的導(dǎo)入情況：

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

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

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

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

05

我們遇到了什么

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

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

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

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

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

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

我們可以做什么：

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

1.導(dǎo)入分區(qū)表時(shí)盡量避免使用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小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

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

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

廣告

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