使用隱含Trace參數診斷Oracle Data Pump故障

Data Pump資料泵是Oracle從10g開始推出的，用於取代傳統exp/imp工具的資料備份還原組件。經過若干版本的演化和修改，Data Pump已經非常成熟，逐漸被越來越多的DBA和營運人員接受。

相對於傳統的exp/imp，Data Pump有很多優勢，也變得更加複雜。資料泵一個最顯著的特點就是Server-Side運行。Exp/Imp是運行在用戶端上面的小工具，雖然使用方便，但是需要處理資料來源端和目標端各自伺服器和用戶端四個版本的差異相容問題。這就是為什麼網路上很多朋友都在糾結如何處理Exp/Imp的版本差異。而且，運行在用戶端上的Exp/Imp受網路影響很大，一旦操作時間較長網路不穩定，操作過程可能就以失敗告終。同時，exp/imp還存在很多效能、穩定性和特性支援上的不足。

Data Pump資料泵是運行在服務端，直接就減少了版本問題出現的可能。即使存在版本問題，使用version參數也可以進行有效控制。此外單獨的作業運行，可以避免出現意外中斷的情況。

儘管如此，我們還是經常會遇到Data Pump的故障和問題，很多時候僅僅藉助提示資訊不能做到完全的診斷。這個時候，我們可以考慮使用Data Pump的隱藏參數Trace來產生追蹤檔案，逐步排查錯誤。

從10046 Trace RAW File看Cursor 

如何通過Trace診斷ORA-00060 Deadlock Type? 

ORA-01157: cannot identify/lock data file 6 - see DBWR Trace file ORA-01110: 解決方案

解決autoTrace不顯示Predicate Information的問題

Oracle 11g新SQL Trace 10046方法

Oracle SQL Trace 和 10046 事件

1、  Data Pump工作原理和環境準備

Data Pump工作原理有兩個特點：作業調度，多進程配合協作。在Oracle中，Data Pump是作為一個特定的Job來進行處理的，可以進行Job作業的啟動、終止、暫停，而且更重要的是Dump作業的工作過程是獨立於外部使用者的。也就是說，使用者不需要和Exp/Imp一樣“死盯著”介面，也不需要使用nohup &後台作業化，就可以實現自動的後台操作。

在工作中，Data Pump是一個多進程配合的工作。我們從工作日誌上就可以看到，每個Data Pump作業在建立的時候，會自動建立一個作業表，其中記錄操作過程。Job工作的時候有兩類Process進程工作，一個是master control process，負責整體過程協調，Work Process池管理，任務分配。實際進行匯入匯出的是Work process，如果設定了parallel參數，就會有多個Work Process進行資料工作。

對Data Pump的診斷本質上就是對各種Process行為的跟蹤。Oracle提供了一個Trace的隱含參數，來協助我們實現這個目標。

首先，我們準備一下Data Pump工作環境。開始需要準備Directory對象。

[root@SimpleLinux /]# ls -l | grep dumpdata

drwxr-xr-x  2 root  root      4096 Sep 11 09:01 dumpdata

[root@SimpleLinux /]# chown -R oracle:oinstall dumpdata/

[root@SimpleLinux /]# ls -l | grep dumpdata

drwxr-xr-x  2 oracle oinstall  4096 Sep 11 09:01 dumpdata

--建立directory對象

SQL> select * from v$version where rownum<2;

BANNER

-----------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Producti

SQL> create directory dumpdir as '/dumpdata';

Directory created

2、隱含參數Trace

Trace參數是Data Pump隱含內部使用的一個參數。使用方法和其他資料泵參數相同，但是使用取值需要有一些注意之處。下面是我們實驗的Trace命令。

[oracle@SimpleLinux dumpdata]$ expdp \"/ as sysdba\" directory=dumpdir schemas=scott dumpfile=scott_dump.dmp parallel=2 trace=480300

Export: Release 11.2.0.3.0 - Production on Wed Sep 11 09:45:07 2013

Trace並不像其他跟蹤過程相同，使用y/n的參數，開啟或者關閉。Data Pump的Trace參數是一個7位十六進位組成的數字串。不同的數字串表示不同的跟蹤對象方法。7位十六進位數字分為兩個部分，前三個數字表示特定的資料泵組件，後四位使用0300就可以。

根據Oracle MOS中提供資訊資料，Trace字元遵守如下設定規則：
 
 
 
ü  不要輸入超過7位長度；
 
ü  不需要使用0X指定十六進位字元；
 
ü  不能將十六進位字元轉化為數字取值；
 
ü  如果7位字元以0開頭，可以省略0；
 
ü  輸入字元大小寫不敏感； 
 
各個組件分別使用不同的三位十六進位數字代表。如下片段所示：
 
 
-- Summary of Data Pump trace levels:
-- ==================================

  Trace  DM  DW  ORA  Lines
  level  trc  trc  trc    in
  (hex) file file file  trace                                        Purpose
------- ---- ---- ---- ------ -----------------------------------------------
  10300    x    x    x  SHDW: To trace the Shadow process (API) (expdp/impdp)
  20300    x    x    x  KUPV: To trace Fixed table
  40300    x    x    x  'div' To trace Process services
  80300    x            KUPM: To trace Master Control Process (MCP)      (DM)
 100300    x    x      KUPF: To trace File Manager
 200300    x    x    x  KUPC: To trace Queue services
 400300        x      KUPW: To trace Worker process(es)                (DW)
 800300        x      KUPD: To trace Data Package
1000300        x      META. To trace Metadata Package
--- +
1FF0300    x    x    x  'all' To trace all components          (full tracing) 
 
 
如果需要同時跟蹤多個組件，需要將目標組件的hex值進行累加，後面四位的300相同。

目標Dump作業產生的Trace檔案，同其他Trace檔案沒有什麼本質差異。預設都是在BACKGROUP_DUMP_DEST目錄。但是注意，Data Pump的Trace過程，會產生多個Trace檔案，而且定位需要知道dm和dw的Process ID資訊。

筆者建議的一種方法是，如果系統業務不是非常繁忙，可以將目錄上的Trc和trm檔案暫時儲存在其他的地方。再進行Trace作業，此時產生的檔案就可以明顯看出是哪些。

對於跟蹤的Trace取值，Oracle建議使用480300就可以應對大部分的情況。480300會跟蹤Oracle Dump作業的Master Control Process（MCP）和Work Process。作為初始化跟蹤的過程，480300基本就夠用了。

更多詳情見請繼續閱讀下一頁的精彩內容：

1 2 3 下一頁