每個(gè)數(shù)據(jù)庫(kù)治理員都會(huì)面臨數(shù)據(jù)導(dǎo)入的問(wèn)題，這有可能發(fā)生在數(shù)據(jù)庫(kù)的新老移植過(guò)程中，或者是在數(shù)據(jù)庫(kù)崩潰后的恢復(fù)重建過(guò)程中，還有可能是在創(chuàng)建測(cè)試數(shù)據(jù)庫(kù)的模擬環(huán)境過(guò)程中，總之作為一名合格的數(shù)據(jù)庫(kù)治理員，你應(yīng)該做好接受各種數(shù)據(jù)導(dǎo)入請(qǐng)求的技術(shù)儲(chǔ)備，同時(shí)還要盡量滿(mǎn)足人本能的對(duì)導(dǎo)入速度的苛求。本文僅針對(duì) Oracle 數(shù)據(jù)庫(kù)所提供的加速數(shù)據(jù)導(dǎo)入的各種特性和技術(shù)進(jìn)行探討，其中的一些方法也可以轉(zhuǎn)化應(yīng)用于其他數(shù)據(jù)庫(kù)。以下七種數(shù)據(jù)導(dǎo)入方法哪個(gè)最適用需要針對(duì)具體情況具體分析，我也附帶列舉了影響導(dǎo)入速度的各種因素供斟酌。為了比較各種數(shù)據(jù)導(dǎo)入方法的效果，我創(chuàng)建了示例表和數(shù)據(jù)集，并用各種方法導(dǎo)入示例數(shù)據(jù)集來(lái)計(jì)算總體導(dǎo)入時(shí)間和導(dǎo)入進(jìn)程占用 CPU 時(shí)間，這里得出的時(shí)間僅供參考。需要說(shuō)明的是，建議你使用 Oracle 9i 企業(yè)版數(shù)據(jù)庫(kù)，當(dāng)然你也可以嘗試使用 Oracle 7.3 以上的標(biāo)準(zhǔn)版數(shù)據(jù)庫(kù)。本文使用的機(jī)器配置為：CPU Intel P4，內(nèi)存 256M，數(shù)據(jù)庫(kù) Oracle 9i 企業(yè)版。 示例表結(jié)構(gòu)和數(shù)據(jù)集 為了演示和比較各種數(shù)據(jù)導(dǎo)入方法，我假定數(shù)據(jù)導(dǎo)入任務(wù)是將外部文件數(shù)據(jù)導(dǎo)入到 Oracle 數(shù)據(jù)庫(kù)的CALLS表中，外部數(shù)據(jù)文件包含十萬(wàn)條呼叫中心記錄，將近 6MB 的文件大小，具體的數(shù)據(jù)示例如下:823022843842003-04-18:13:18:585001投訴手機(jī)三包維修質(zhì)量823022843852003-04-18:13:18:593352咨詢(xún)供水熱線(xiàn)的號(hào)碼823022843862003-04-18:13:19:013142建議增設(shè)公交線(xiàn)路 接受導(dǎo)入數(shù)據(jù)的表名是 CALLS，表結(jié)構(gòu)如下：NameNull?TypeCommentCALL_ID NOT NULLNUMBERPrimary keyCALL_DATENOT NULLDATENon-unique indexEMP_IDNOT NULLNUMBERCALL_TYPENOT NULLVARCHAR2(12)DETAILSNOT NULLVARCHAR2(25) 逐條數(shù)據(jù)插入INSERT 數(shù)據(jù)導(dǎo)入的最簡(jiǎn)單方法就是編寫(xiě) INSERT 語(yǔ)句，將數(shù)據(jù)逐條插入數(shù)據(jù)庫(kù)。這種方法只適合導(dǎo)入少量數(shù)據(jù)，如 SQL*Plus 腳本創(chuàng)建某個(gè)表的種子數(shù)據(jù)。該方法的最大缺點(diǎn)就是導(dǎo)入速度緩慢，占用了大量的 CPU 處理時(shí)間，不適合大批量數(shù)據(jù)的導(dǎo)入；而其主要優(yōu)點(diǎn)就是導(dǎo)入構(gòu)思簡(jiǎn)單又有修改完善的彈性，不需要多做其它的預(yù)備就可以使用。假如你有很多時(shí)間沒(méi)法打發(fā)，又想折磨一下數(shù)據(jù)庫(kù)和 CPU，那這種方法正適合你。:) 為了與其它方法做比較，現(xiàn)將十萬(wàn)條記錄通過(guò)此方法導(dǎo)入到 CALLS 表中，總共消耗 172 秒，其中導(dǎo)入進(jìn)程占用 CPU 時(shí)間為 52 秒。 逐條數(shù)據(jù)插入 INSERT，表暫無(wú)索引 為什么上一種方法占用了較多的 CPU 處理時(shí)間，要害是 CALLS 表中已創(chuàng)建了索引，當(dāng)一條數(shù)據(jù)插入到表中時(shí)，Oracle 需要判別新數(shù)據(jù)與老數(shù)據(jù)在索引方面是否有沖突，同時(shí)要更新表中的所有索引，重復(fù)更新索引會(huì)消耗一定的時(shí)間。因此提高導(dǎo)入速度的好辦法就是在創(chuàng)建表時(shí)先不創(chuàng)建索引或者在導(dǎo)入數(shù)據(jù)之前刪除所有索引，在外部文件數(shù)據(jù)逐條插入到表中后再統(tǒng)一創(chuàng)建表的索引。這樣導(dǎo)入速度會(huì)提高，同時(shí)創(chuàng)建的索引也很緊湊而有效，這一原則同樣適用于位圖索引（Bitmap Index）。對(duì)于主要的和唯一的要害約束(key constraints)，可以使之先暫時(shí)失效(disabling)或者刪除約束來(lái)獲得同樣的效果，當(dāng)然這些做法會(huì)對(duì)已經(jīng)存在的表的外鍵約束產(chǎn)生相關(guān)的影響，在刪除前需要通盤(pán)斟酌。 需要說(shuō)明的是，這種方法在表中已存在很多數(shù)據(jù)的情況下不太合適。例如表中已有九千萬(wàn)條數(shù)據(jù)，而此時(shí)需要追加插入一千萬(wàn)條數(shù)據(jù)，實(shí)際導(dǎo)入數(shù)據(jù)節(jié)省的時(shí)間將會(huì)被重新創(chuàng)建一億條數(shù)據(jù)的索引所消耗殆盡，這是我們不希望得到的結(jié)果。但是，假如要導(dǎo)入數(shù)據(jù)的表是空的或?qū)氲臄?shù)據(jù)量比已有的數(shù)據(jù)量要大得多，那么導(dǎo)入數(shù)據(jù)節(jié)省的時(shí)間將會(huì)少量用于重新創(chuàng)建索引，這時(shí)該方法才可以考慮使用。 加快索引創(chuàng)建是另一個(gè)需要考慮的問(wèn)題。為了減少索引創(chuàng)建中排序的工作時(shí)間，可以在當(dāng)前會(huì)話(huà)中增加 SORT_AREA_SIZE 參數(shù)的大小，該參數(shù)答應(yīng)當(dāng)前會(huì)話(huà)在內(nèi)存的索引創(chuàng)建過(guò)程中執(zhí)行更多的排序操作。同樣還可以使用 NOLOGGING 要害字來(lái)減少因創(chuàng)建索引而生成的 REDO 日志量，NOLOGGING 要害字會(huì)對(duì)數(shù)據(jù)庫(kù)的恢復(fù)和 Standby 備用數(shù)據(jù)庫(kù)產(chǎn)生明顯的影響，所以在使用之前要仔細(xì)斟酌，到底是速度優(yōu)先還是穩(wěn)定優(yōu)先。 運(yùn)用這種方法，先刪除 CALLS 表的主鍵和不唯一的索引，然后逐條導(dǎo)入數(shù)據(jù)，完成后重新創(chuàng)建索引( 表在導(dǎo)入數(shù)據(jù)前是空的)。該方法總共消耗 130 秒，包括重建索引的時(shí)間，其中導(dǎo)入進(jìn)程占用 CPU 時(shí)間為 35秒。 這種方法的優(yōu)點(diǎn)是可以加快導(dǎo)入的速度并使索引更加緊湊有效；缺點(diǎn)是缺乏通用性，當(dāng)你對(duì)表增加新的復(fù)雜的模式元素（索引、外鍵等）時(shí)你需要添加代碼、修改導(dǎo)入執(zhí)行程序。另外針對(duì) 7*24 在線(xiàn)要求的數(shù)據(jù)庫(kù)在線(xiàn)導(dǎo)入操作時(shí)，刪除表的索引會(huì)對(duì)在線(xiàn)用戶(hù)的查詢(xún)有很大的性能影響，同時(shí)也要考慮，主要或唯一的要害約束條件的刪除或失效可能會(huì)影響到引用它們的外鍵的使用。 批量插入，表暫無(wú)索引 在Oracle V6 中 OCI 編程接口加入了數(shù)組接口特性。數(shù)組操作答應(yīng)導(dǎo)入程序讀取外部文件數(shù)據(jù)并解析后，向數(shù)據(jù)庫(kù)提交SQL語(yǔ)句，批量插入 SQL 語(yǔ)句檢索出的數(shù)據(jù)。Oracle 僅需要執(zhí)行一次 SQL 語(yǔ)句，然后在內(nèi)存中批量解析提供的數(shù)據(jù)。批量導(dǎo)入操作比逐行插入重復(fù)操作更有效率，這是因?yàn)橹恍枰淮谓馕?SQL 語(yǔ)句，一些數(shù)據(jù)綁訂操作以及程序與數(shù)據(jù)庫(kù)之間往返的操作都顯著減少，而且數(shù)據(jù)庫(kù)對(duì)每一條數(shù)據(jù)的操作都是重復(fù)可知的，這給數(shù)據(jù)庫(kù)提供了優(yōu)化執(zhí)行的可能。其優(yōu)點(diǎn)是數(shù)據(jù)導(dǎo)入的總體時(shí)間明顯減少，非凡是進(jìn)程占用 CPU 的時(shí)間。 需要提醒的是，通過(guò) OCI 接口確實(shí)可以執(zhí)行數(shù)據(jù)批量導(dǎo)入操作，但是許多工具和腳本語(yǔ)言卻不支持使用此功能。假如要使用該方法，需要研究你所使用的開(kāi)發(fā)工具是否支持 OCI 批量操作功能。導(dǎo)入程序需要進(jìn)行復(fù)雜的編碼并可能存在錯(cuò)誤的風(fēng)險(xiǎn)，缺乏一定的彈性。 運(yùn)用上述方法，程序?qū)⑼獠繑?shù)據(jù)提取到內(nèi)存中的數(shù)組里，并執(zhí)行批量插入操作（100行/次），保留了表的刪除/重建索引操作，總的導(dǎo)入時(shí)間下降到 14 秒，而進(jìn)程占用 CPU 的時(shí)間下降到7秒，可見(jiàn)實(shí)際導(dǎo)入數(shù)據(jù)所花費(fèi)的時(shí)間顯著下降了 95%。 CREATE TABLE AS SELECT，使用Oracle9i的External Table Oracle 9i 的一項(xiàng)新特性就是 External Table，它就象通常的數(shù)據(jù)庫(kù)表一樣，擁有字段和數(shù)據(jù)類(lèi)型約束，并且可以查詢(xún)，但是表中的數(shù)據(jù)卻不存儲(chǔ)在數(shù)據(jù)庫(kù)中，而是在與數(shù)據(jù)庫(kù)相關(guān)聯(lián)的普通外部文件里。當(dāng)你查詢(xún) External Table 時(shí)，Oracle 將解析該文件并返回符合條件的數(shù)據(jù)，就象該數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)庫(kù)表中一樣。 需要注重的是，你可以在查詢(xún)語(yǔ)句中將 External Table 與數(shù)據(jù)庫(kù)中其他表進(jìn)行連接（Join），但是不能給 External Table 加上索引，并且不能插入/更新/刪除數(shù)據(jù)，究竟它不是真正的數(shù)據(jù)庫(kù)表。另外，假如與數(shù)據(jù)庫(kù)相關(guān)聯(lián)的外部文件被改變或者被刪除，這會(huì)影響到 External Table 返回查詢(xún)結(jié)果，所以在變動(dòng)前要先跟數(shù)據(jù)庫(kù)打招呼。 這種方法為導(dǎo)入數(shù)據(jù)打開(kāi)了新的一扇門(mén)。你可以很輕易的將外部文件與數(shù)據(jù)庫(kù)相關(guān)聯(lián)，并且在數(shù)據(jù)庫(kù)中創(chuàng)建對(duì)應(yīng)的 External Table，然后就可以立即查詢(xún)數(shù)據(jù)，就象外部數(shù)據(jù)已經(jīng)導(dǎo)入到數(shù)據(jù)庫(kù)表中一樣。唯一的不足需要明確，數(shù)據(jù)并未真正導(dǎo)入到數(shù)據(jù)庫(kù)中，當(dāng)外部文件被刪除或覆蓋時(shí)，數(shù)據(jù)庫(kù)將不能訪(fǎng)問(wèn) External Table 里的數(shù)據(jù)，而且索引沒(méi)有被創(chuàng)建，訪(fǎng)問(wèn)數(shù)據(jù)速度將有所緩慢。創(chuàng)建 CALLS_EXTERNAL（External Table表）如下，使之與外部數(shù)據(jù)文件關(guān)聯(lián)：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 'yyyy-mm-dd:hh24:mi:ss', emp_id, call_type, details ); ); LOCATION ('calls.dat') ); 然后將 External Table 與真正被使用的表 CALLS 關(guān)聯(lián)同步，刪除 CALLS 表并重建它： CREATE TABLE calls (; call_id NUMBER; NOT NULL, call_date; DATENOT 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 FROMcalls_external; 因?yàn)?CALLS 表是真正的數(shù)據(jù)庫(kù)表，可以創(chuàng)建索引來(lái)加快訪(fǎng)問(wèn)，表中的數(shù)據(jù)將被保留，即使外部數(shù)據(jù)文件被更新或被刪除。在建表語(yǔ)句中NOLOGGING要害字用于加快索引重建。 運(yùn)用這種方法導(dǎo)入數(shù)據(jù)，總的導(dǎo)入時(shí)間為 15 秒，進(jìn)程占用 CPU 的時(shí)間為8秒，這比前一種方法稍微慢些，但不能就此認(rèn)為使用 External Table 導(dǎo)入數(shù)據(jù)一定比 OCI 批量插入慢。 這種方法的優(yōu)點(diǎn)是，未經(jīng)進(jìn)行大量的編寫(xiě)代碼就取得了不錯(cuò)的結(jié)果，不象 OCI 批量插入存在編碼錯(cuò)誤風(fēng)險(xiǎn)，它還可以使用 dbms_job 包調(diào)度數(shù)據(jù)導(dǎo)入進(jìn)程，實(shí)現(xiàn)數(shù)據(jù)導(dǎo)入的自動(dòng)化。其缺點(diǎn)是目標(biāo)表必須先刪除后重建，假如只需要導(dǎo)入增量數(shù)據(jù)時(shí)此方法就不合適了，另外用戶(hù)在表的重建過(guò)程中訪(fǎng)問(wèn)數(shù)據(jù)時(shí)會(huì)碰到 'table or view does not exist' 的錯(cuò)誤，它僅適用于 Oracle 9i 以上版本的數(shù)據(jù)庫(kù)。 INSERT Append as SELECT，使用 Oracle9i 的 External Table 上一種方法演示了如何創(chuàng)建與外部數(shù)據(jù)文件關(guān)聯(lián)的數(shù)據(jù)庫(kù)表，其表的數(shù)據(jù)是由外部數(shù)據(jù)文件映射過(guò)來(lái)。缺點(diǎn)是數(shù)據(jù)庫(kù)表需要被先刪除再重建來(lái)保持與外部數(shù)據(jù)文件的一致和同步，對(duì)導(dǎo)入增量的數(shù)據(jù)而不需要?jiǎng)h除已有數(shù)據(jù)的情況不合適。針對(duì)這種需求，Oracle 提供了 INSERT 語(yǔ)句外帶 APPEND 提示來(lái)滿(mǎn)足。 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; 該語(yǔ)句讀取引用外部數(shù)據(jù)文件的 CALLS_EXTERNAL 表中內(nèi)容，并將之增加到表 CALLS 中。Append 提示告訴 Oracle 使用快速機(jī)制來(lái)插入數(shù)據(jù)，同時(shí)可以配合使用表的 NOLOGGING 要害字。 可以預(yù)見(jiàn)這種方法與前一方法消耗了相同的時(shí)間，究竟它們是使用 External Table 特性導(dǎo)入數(shù)據(jù)的不同階段解決方法。假如目標(biāo)表不是空的，那將會(huì)消耗稍微長(zhǎng)的時(shí)間（因?yàn)橐亟ǜL(zhǎng)的索引），而前一 CREATE TABLE as SELECT 方法是整體創(chuàng)建索引。 SQL*Loader的強(qiáng)大功能 SQL*Loader 是 Oracle 提供的導(dǎo)入實(shí)用程序，非凡針對(duì)從外部文件導(dǎo)入大批量數(shù)據(jù)進(jìn)入數(shù)據(jù)庫(kù)表。該工具已經(jīng)有多年的歷史，每一次版本升級(jí)都使其更加強(qiáng)大、靈活和快捷，但遺憾的是它的語(yǔ)法卻是神秘而不直觀(guān)，并且只能從命令行窗口處進(jìn)行調(diào)用。 盡管它有不直觀(guān)的缺點(diǎn)，但卻是最快最有效的導(dǎo)入數(shù)據(jù)方法。缺省情況下它使用 'conventional path' 常規(guī)選項(xiàng)來(lái)批量導(dǎo)入數(shù)據(jù)，其性能提高度并不明顯。我建議使用更快速的導(dǎo)入?yún)?shù)選項(xiàng)，在命令行添加'direct=true' 選項(xiàng)調(diào)用 'direct path' 導(dǎo)入選項(xiàng)。在 'direct path' 導(dǎo)入實(shí)現(xiàn)中，程序在數(shù)據(jù)庫(kù)表的新數(shù)據(jù)塊的 high water mark 處直接寫(xiě)入導(dǎo)入數(shù)據(jù)，縮短了數(shù)據(jù)插入的處理時(shí)間，同時(shí)優(yōu)化使用了非常有效的B+二叉樹(shù)方法來(lái)更新表的索引。 運(yùn)用這種方法，假如使用缺省的 conventional path 導(dǎo)入選項(xiàng)，總的導(dǎo)入時(shí)間是 81 秒，進(jìn)程占用 CPU 時(shí)間大約是 12 秒，這包括了更新表的索引時(shí)間。假如使用 direct path 導(dǎo)入選項(xiàng)，總的導(dǎo)入時(shí)間竟是 9 秒，進(jìn)程占用 CPU 時(shí)間也僅僅是 3 秒，也包括了更新表的索引時(shí)間。 由此可見(jiàn)，盡管表中的索引在數(shù)據(jù)導(dǎo)入之前并沒(méi)有被刪除，使用SQL*Loader的direct path 導(dǎo)入選項(xiàng)仍然是快速和有效的。當(dāng)然它也有缺點(diǎn)，就像NOLOGGING要害字一樣該方法不生成REDO日志數(shù)據(jù)，導(dǎo)入進(jìn)程出錯(cuò)后將無(wú)法恢復(fù)到先前狀態(tài)；在數(shù)據(jù)導(dǎo)入過(guò)程中表的索引是不起作用的，用戶(hù)此時(shí)訪(fǎng)問(wèn)該表時(shí)將出現(xiàn)遲緩，當(dāng)然在數(shù)據(jù)導(dǎo)入的過(guò)程中最好不要讓用戶(hù)訪(fǎng)問(wèn)表。 分區(qū)交換 (Partition Exchange) 以上討論的數(shù)據(jù)導(dǎo)入方法都有一個(gè)限制，就是要求用戶(hù)在導(dǎo)入數(shù)據(jù)完成之后才可以訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)表。面對(duì)7×24不間斷訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)來(lái)說(shuō)，假如我們只是導(dǎo)入需要增加的數(shù)據(jù)時(shí)，這種限制將對(duì)用戶(hù)的實(shí)時(shí)訪(fǎng)問(wèn)產(chǎn)生影響。Oracle在這方面提供了表分區(qū)功能，它可以減少導(dǎo)入數(shù)據(jù)操作對(duì)用戶(hù)實(shí)時(shí)訪(fǎng)問(wèn)數(shù)據(jù)的影響，操作模式就象使用可熱插拔的硬盤(pán)一樣，只不過(guò)這里的硬盤(pán)換成了分區(qū)（Partition）而已。需要聲明的是 Partitioning 分區(qū)功能只有在企業(yè)版數(shù)據(jù)庫(kù)中才提供。 在一個(gè)被分區(qū)過(guò)的表中，呈現(xiàn)給用戶(hù)的表是多個(gè)分區(qū)段（segments）的集合。分區(qū)可以在需要時(shí)被添加，在維護(hù)時(shí)被卸載或刪除，分區(qū)表可以和數(shù)據(jù)庫(kù)中的表交換數(shù)據(jù)，只要它們的表結(jié)構(gòu)和字段類(lèi)型是一致的，交換后的分區(qū)表將擁有與之互動(dòng)的表的數(shù)據(jù)。需要注重的是，這種交換只是在Oracle數(shù)據(jù)庫(kù)的數(shù)據(jù)字典層面上進(jìn)行，并沒(méi)有數(shù)據(jù)被實(shí)際移動(dòng)，所以分區(qū)表交換是極其快速的。 為了創(chuàng)建實(shí)驗(yàn)環(huán)境，先假設(shè)CALLS表是個(gè)分區(qū)表，要?jiǎng)?chuàng)建一個(gè)空的分區(qū)PART_01012004，用來(lái)保存2004年1月1日的呼叫數(shù)據(jù)。然后需要再創(chuàng)建一臨時(shí)表為CALLS_TEMP，該表與CALLS表?yè)碛邢嗤淖侄魏蛿?shù)據(jù)類(lèi)型。 我們使用先前介紹的導(dǎo)入方法將十萬(wàn)條數(shù)據(jù)導(dǎo)入到CALLS_TEMP表中，可以耐心等待數(shù)據(jù)完全導(dǎo)入到CALLS_TEMP表中，并且創(chuàng)建好索引和相關(guān)約束條件，所有這一切操作并不影響用戶(hù)實(shí)時(shí)訪(fǎng)問(wèn)CALLS表，因?yàn)槲覀冎粚?duì)CALLS_TEMP臨時(shí)表進(jìn)行了操作。一旦數(shù)據(jù)導(dǎo)入完成，CALLS_TEMP表就存有2004年1月1日的呼叫數(shù)據(jù)。同時(shí)利用CALLS表中名為PART_01012004的空分區(qū)，使用如下語(yǔ)句執(zhí)行分區(qū)交換：;;; ALTER; TABLE; callsEXCHANGE; PARTITION; part_01012004 WITH; TABLE calls_tempINCLUDING; INDEXES; WITHOUT; VALIDATION; 分區(qū)交換操作將非常快速地只更新CALLS表的數(shù)據(jù)字典，PART_01012004分區(qū)表即刻擁有CALLS_TEMP表的所有數(shù)據(jù)，而CALLS_TEMP表變?yōu)榭毡怼＜俣–ALLS表使用局部索引而非全局索引，上述語(yǔ)句中的INCLUDING INDEXES將保證分區(qū)交換包括索引的可用性，WITHOUT VALIDATION 指明不檢查交替表中數(shù)據(jù)的匹配，加快了交換的速度。 結(jié)論 以上探討了Oracle數(shù)據(jù)庫(kù)的多種數(shù)據(jù)導(dǎo)入方法，每種方法都有其優(yōu)缺點(diǎn)和適用環(huán)境，能夠滿(mǎn)足你不同的導(dǎo)入需求，當(dāng)然你需要在了解了這些方法后，在速度、簡(jiǎn)易性、靈活性、可恢復(fù)性和數(shù)據(jù)可用性之間尋求最佳導(dǎo)入方案。 為了對(duì)比各種方法的效果，我們創(chuàng)建了一個(gè)實(shí)例來(lái)展示各種方法的導(dǎo)入效率和效果，從中你可以選擇最適合的方法用于今后的數(shù)據(jù)導(dǎo)入工作。同時(shí)請(qǐng)記住，本文并未囊括所有的ORACLE數(shù)據(jù)導(dǎo)入技術(shù)（比如并行數(shù)據(jù)導(dǎo)入技術(shù)），這需要我們繼續(xù)不懈的探索和嘗試。數(shù)據(jù)導(dǎo)入方法總體導(dǎo)入時(shí)間(秒)導(dǎo)入進(jìn)程占用CPU時(shí)間(秒)逐條數(shù)據(jù)插入INSERT17252逐條數(shù)據(jù)插入INSERT，表暫無(wú)索引13035批量插入，表暫無(wú)索引 147Create As Select，使用Oracle9i的External Table158INSERT Append as SELECT，使用Oracle9i的External Table158SQL*Loader conventional path 缺省導(dǎo)入選項(xiàng)8112SQL*Loader direct path 導(dǎo)入選項(xiàng) 93