示例表結構和數據集
為了演示和比較各種數據導入方法，我假定數據導入任務是將外部文件數據導入到 Oracle 數據庫的CALLS表中，外部數據文件包含十萬條呼叫中心記錄，將近 6MB 的文件大小，具體的數據示例如下:
82302284384,2003-04-18:13:18:58,5001,投訴,手機三包維修質量82302284385,2003-04-18:13:18:59,3352,咨詢,供水熱線的號碼82302284386,2003-04-18:13:19:01,3142,建議,增設公交線路
接受導入數據的表名是 CALLS，表結構如下：
Name Null? Type Comment ------------ --------- ------------- ----------------- CALL_ID NOT NULL NUMBER Primary key CALL_DATE NOT NULL DATE Non-unique index EMP_ID NOT NULL NUMBER CALL_TYPE NOT NULL VARCHAR2(12) DETAILS VARCHAR2(25)
逐條數據插入INSERT
數據導入的最簡單方法就是編寫 INSERT 語句，將數據逐條插入數據庫。這種方法只適合導入少量數據，如 SQL*Plus 腳本創建某個表的種子數據。該方法的最大缺點就是導入速度緩慢，占用了大量的 CPU 處理時間，不適合大批量數據的導入；而其主要優點就是導入構思簡單又有修改完善的彈性，不需要多做其它的準備就可以使用。如果妳有很多時間沒法打發，又想折磨壹下數據庫和 CPU，那這種方法正適合妳。:)
為了與其它方法做比較，現將十萬條記錄通過此方法導入到 CALLS 表中，總***消耗 172 秒，其中導入進程占用 CPU 時間為 52 秒。
逐條數據插入 INSERT，表暫無索引
為什麽上壹種方法占用了較多的 CPU 處理時間，關鍵是 CALLS 表中已創建了索引，當壹條數據插入到表中時，Oracle 需要判別新數據與老數據在索引方面是否有沖突，同時要更新表中的所有索引，重復更新索引會消耗壹定的時間。因此提高導入速度的好辦法就是在創建表時先不創建索引或者在導入數據之前刪除所有索引，在外部文件數據逐條插入到表中後再統壹創建表的索引。這樣導入速度會提高，同時創建的索引也很緊湊而有效，這壹原則同樣適用於位圖索引（Bitmap Index）。對於主要的和唯壹的關鍵約束(key constraints)，可以使之先暫時失效(disabling)或者刪除約束來獲得同樣的效果，當然這些做法會對已經存在的表的外鍵約束產生相關的影響，在刪除前需要通盤斟酌。
需要說明的是，這種方法在表中已存在很多數據的情況下不太合適。例如表中已有九千萬條數據，而此時需要追加插入壹千萬條數據，實際導入數據節省的時間將會被重新創建壹億條數據的索引所消耗殆盡，這是我們不希望得到的結果。但是，如果要導入數據的表是空的或導入的數據量比已有的數據量要大得多，那麽導入數據節省的時間將會少量用於重新創建索引，這時該方法才可以考慮使用。
加快索引創建是另壹個需要考慮的問題。為了減少索引創建中排序的工作時間，可以在當前會話中增加 SORT_AREA_SIZE 參數的大小，該參數允許當前會話在內存的索引創建過程中執行更多的排序操作。同樣還可以使用 NOLOGGING 關鍵字來減少因創建索引而生成的 REDO 日誌量，NOLOGGING 關鍵字會對數據庫的恢復和 Standby 備用數據庫產生明顯的影響，所以在使用之前要仔細斟酌，到底是速度優先還是穩定優先。
運用這種方法，先刪除 CALLS 表的主鍵和不唯壹的索引，然後逐條導入數據，完成後重新創建索引( 表在導入數據前是空的)。該方法總***消耗 130 秒，包括重建索引的時間，其中導入進程占用 CPU 時間為 35秒。
這種方法的優點是可以加快導入的速度並使索引更加緊湊有效；缺點是缺乏通用性，當妳對表增加新的復雜的模式元素（索引、外鍵等）時妳需要添加代碼、修改導入執行程序。另外針對 7*24 在線要求的數據庫在線導入操作時，刪除表的索引會對在線用戶的查詢有很大的性能影響，同時也要考慮，主要或唯壹的關鍵約束條件的刪除或失效可能會影響到引用它們的外鍵的使用。
批量插入，表暫無索引
在Oracle V6 中 OCI 編程接口加入了數組接口特性。數組操作允許導入程序讀取外部文件數據並解析後，向數據庫提交SQL語句，批量插入 SQL 語句檢索出的數據。Oracle 僅需要執行壹次 SQL 語句，然後在內存中批量解析提供的數據。批量導入操作比逐行插入重復操作更有效率，這是因為只需壹次解析 SQL 語句，壹些數據綁訂操作以及程序與數據庫之間來回的操作都顯著減少，而且數據庫對每壹條數據的操作都是重復可知的，這給數據庫提供了優化執行的可能。其優點是數據導入的總體時間明顯減少，特別是進程占用 CPU 的時間。
需要提醒的是，通過 OCI 接口確實可以執行數據批量導入操作，但是許多工具和腳本語言卻不支持使用此功能。如果要使用該方法，需要研究妳所使用的開發工具是否支持 OCI 批量操作功能。導入程序需要進行復雜的編碼並可能存在錯誤的風險，缺乏壹定的彈性。
運用上述方法，程序將外部數據提取到內存中的數組裏，並執行批量插入操作（100行/次），保留了表的刪除/重建索引操作，總的導入時間下降到 14 秒，而進程占用 CPU 的時間下降到7秒，可見實際導入數據所花費的時間顯著下降了 95%。
CREATE TABLE AS SELECT，使用Oracle9i的External Table
Oracle 9i 的壹項新特性就是 External Table，它就象通常的數據庫表壹樣，擁有字段和數據類型約束，並且可以查詢，但是表中的數據卻不存儲在數據庫中，而是在與數據庫相關聯的普通外部文件裏。當妳查詢 External Table 時，Oracle 將解析該文件並返回符合條件的數據，就象該數據存儲在數據庫表中壹樣。
需要註意的是，妳可以在查詢語句中將 External Table 與數據庫中其他表進行連接（Join），但是不能給 External Table 加上索引，並且不能插入/更新/刪除數據，畢竟它不是真正的數據庫表。另外，如果與數據庫相關聯的外部文件被改變或者被刪除，這會影響到 External Table 返回查詢結果，所以在變動前要先跟數據庫打招呼。
這種方法為導入數據打開了新的壹扇門。妳可以很容易的將外部文件與數據庫相關聯，並且在數據庫中創建對應的 External Table，然後就可以立即查詢數據，就象外部數據已經導入到數據庫表中壹樣。唯壹的不足需要明確，數據並未真正導入到數據庫中，當外部文件被刪除或覆蓋時，數據庫將不能訪問 External Table 裏的數據，而且索引沒有被創建，訪問數據速度將有所緩慢。創建 CALLS_EXTERNAL（External Table表）如下，使之與外部數據文件關聯：
CREATE TABLE calls_external (call_id NUMBER, call_date DATE, emp_id NUMBER, call_type VARCHAR2(12), details VARCHAR2(25)) ORGANIZATION EXTERNAL (TYPE oracle_loader DEFAULT DIRECTORY extract_files_dir ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY ',' MISSING FIELD VALUES ARE NULL (call_id, call_date CHAR DATE_FORMAT DATE MASK "yyy-mm-dd:hh24:mi:ss", emp_id, call_type, details ) ) LOCATION ('calls.dat') );
然後將 External Table 與真正被使用的表 CALLS 關聯同步，刪除 CALLS 表並重建它：
CREATE TABLE calls ( call_id NUMBER NOT NULL, call_date DATE NOT NULL, emp_id NUMBER NOT NULL, call_type VARCHAR2(12) NOT NULL, details VARCHAR2(25) ) TABLESPACE tbs1 NOLOGGING AS SELECT call_id, call_date, emp_id, call_type, details FROM calls_external;
因為 CALLS 表是真正的數據庫表，可以創建索引來加快訪問，表中的數據將被保留，即使外部數據文件被更新或被刪除。在建表語句中NOLOGGING關鍵字用於加快索引重建。
運用這種方法導入數據，總的導入時間為 15 秒，進程占用 CPU 的時間為8秒，這比前壹種方法稍微慢些，但不能就此認為使用 External Table 導入數據壹定比 OCI 批量插入慢。
這種方法的優點是，未經進行大量的編寫代碼就取得了不錯的結果，不象 OCI 批量插入存在編碼錯誤風險，它還可以使用 dbms_job 包調度數據導入進程，實現數據導入的自動化。其缺點是目標表必須先刪除後重建，如果只需要導入增量數據時此方法就不合適了，另外用戶在表的重建過程中訪問數據時會遇到 "table or view does not exist" 的錯誤，它僅適用於 Oracle 9i 以上版本的數據庫。
INSERT Append as SELECT，使用 Oracle9i 的 External Table
上壹種方法演示了如何創建與外部數據文件關聯的數據庫表，其表的數據是由外部數據文件映射過來。缺點是數據庫表需要被先刪除再重建來保持與外部數據文件的壹致和同步，對導入增量的數據而不需要刪除已有數據的情況不合適。針對這種需求，Oracle 提供了 INSERT 語句外帶 APPEND 提示來滿足。
INSERT /*+ APPEND */ INTO calls (call_id, call_date, emp_id, call_type, details) SELECT call_id, call_date, emp_id, call_type, details FROM calls_external;
該語句讀取引用外部數據文件的 CALLS_EXTERNAL 表中內容，並將之增加到表 CALLS 中。Append 提示告訴 Oracle 使用快速機制來插入數據，同時可以配合使用表的 NOLOGGING 關鍵字。
可以預見這種方法與前壹方法消耗了相同的時間，畢竟它們是使用 External Table 特性導入數據的不同階段解決方法。如果目標表不是空的，那將會消耗稍微長的時間（因為要重建更長的索引），而前壹 CREATE TABLE as SELECT 方法是整體創建索引。
SQL*Loader的強大功能
SQL*Loader 是 Oracle 提供的導入實用程序，特別針對從外部文件導入大批量數據進入數據庫表。該工具已經有多年的歷史，每壹次版本升級都使其更加強大、靈活和快捷，但遺憾的是它的語法卻是神秘而不直觀，並且只能從命令行窗口處進行調用。
盡管它有不直觀的缺點，但卻是最快最有效的導入數據方法。缺省情況下它使用 "conventional path" 常規選項來批量導入數據，其性能提高度並不明顯。我建議使用更快速的導入參數選項，在命令行添加"direct=true" 選項調用 "direct path" 導入選項。在 "direct path" 導入實現中，程序在數據庫表的新數據塊的 high water mark 處直接寫入導入數據，縮短了數據插入的處理時間，同時優化使用了非常有效的B+二叉樹方法來更新表的索引。
運用這種方法，如果使用缺省的 conventional path 導入選項，總的導入時間是 81 秒，進程占用 CPU 時間大約是 12 秒，這包括了更新表的索引時間。如果使用 direct path 導入選項，總的導入時間竟是 9 秒，進程占用 CPU 時間也僅僅是 3 秒，也包括了更新表的索引時間。
由此可見，盡管表中的索引在數據導入之前並沒有被刪除，使用SQL*Loader的direct path 導入選項仍然是快速和有效的。當然它也有缺點，就像NOLOGGING關鍵字壹樣該方法不生成REDO日誌數據，導入進程出錯後將無法恢復到先前狀態；在數據導入過程中表的索引是不起作用的，用戶此時訪問該表時將出現遲緩，當然在數據導入的過程中最好不要讓用戶訪問表。
分區交換 (Partition Exchange)
以上討論的數據導入方法都有壹個限制，就是要求用戶在導入數據完成之後才可以訪問數據庫表。面對7×24不間斷訪問數據庫來說，如果我們只是導入需要增加的數據時，這種限制將對用戶的實時訪問產生影響。Oracle在這方面提供了表分區功能，它可以減少導入數據操作對用戶實時訪問數據的影響，操作模式就象使用可熱插拔的硬盤壹樣，只不過這裏的硬盤換成了分區（Partition）而已。需要聲明的是 Partitioning 分區功能只有在企業版數據庫中才提供。
在壹個被分區過的表中，呈現給用戶的表是多個分區段（segments）的集合。分區可以在需要時被添加，在維護時被卸載或刪除，分區表可以和數據庫中的表交換數據，只要它們的表結構和字段類型是壹致的，交換後的分區表將擁有與之互動的表的數據。需要註意的是，這種交換只是在Oracle數據庫的數據字典層面上進行，並沒有數據被實際移動，所以分區表交換是極其快速的。
為了創建實驗環境，先假設CALLS表是個分區表，要創建壹個空的分區PART_01012004，用來保存2004年1月1日的呼叫數據。然後需要再創建壹臨時表為CALLS_TEMP，該表與CALLS表擁有相同的字段和數據類型。
我們使用先前介紹的導入方法將十萬條數據導入到CALLS_TEMP表中，可以耐心等待數據完全導入到CALLS_TEMP表中，並且創建好索引和相關約束條件，所有這壹切操作並不影響用戶實時訪問CALLS表，因為我們只對CALLS_TEMP臨時表進行了操作。壹旦數據導入完成，CALLS_TEMP表就存有2004年1月1日的呼叫數據。同時利用CALLS表中名為PART_01012004的空分區，使用如下語句執行分區交換：
ALTER TABLE calls EXCHANGE PARTITION part_01012004 WITH TABLE calls_temp INCLUDING INDEXES WITHOUT VALIDATION;
分區交換操作將非常快速地只更新CALLS表的數據字典，PART_01012004分區表即刻擁有CALLS_TEMP表的所有數據，而CALLS_TEMP表變為空表。假定CALLS表使用局部索引而非全局索引，上述語句中的INCLUDING INDEXES將保證分區交換包括索引的可用性，WITHOUT VALIDATION 指明不檢查交替表中數據的匹配，加快了交換的速度。
結論
以上探討了Oracle數據庫的多種數據導入方法，每種方法都有其優缺點和適用環境，能夠滿足妳不同的導入需求，當然妳需要在了解了這些方法後，在速度、簡易性、靈活性、可恢復性和數據可用性之間尋求最佳導入方案。
為了對比各種方法的效果，我們創建了壹個實例來展示各種方法的導入效率和效果，從中妳可以選擇最適合的方法用於今後的數據導入工作。同時請記住，本文並未囊括所有的ORACLE數據導入技術（比如並行數據導入技術），這需要我們繼續不懈的探索和嘗試。