在數據庫初始化過程中，管理員需要面對的一個現實問題就是如何把大容量的數據導入到數據庫系統中。在SQL Server數據庫中提供了一些大容量數據導入導出的工具供數據庫管理員實用。如管理員可以通過bcp實用工具，實現大容量導出數據和大容量導入數據并生 成格式化文件。如可以利用bulk insert語句將大容量數據直接從數據文件導入數據庫表或者未分區的視圖中去等等。

  雖然在SQL Server數據庫中提供了這些實用工具。不過管理員在實際工作中，仍然需要謹慎對待這項工作。具體的來說，在大容量數據導入導出的過程中，需要注意如下幾方面的內容。

  1.盡量采用系統提供的工具來倒入導出大容量的數據。

  以上筆者提到的幾款實用工具，他們有一個共同的特點，即在導入的過程中會對大容量的數據進行一定的優化。如會規范一些數據的格式、節省導入導出的時間等 等。但是利用這些工具的話，跟其他普通的數據導入導出工具有一個差異，就是大容量導入操作不支持逗號分隔符文件中導入數據，也就是常說的文本文件。雖然此 時管理員也可以通過其他的工具來導入文件文件格式的大容量數據，但是通常情況下筆者不建議這么做。因為其他的工具不支持導入過程中的優化功能。為此筆者建 議先用其他工具，如ACCESS等中間工具先把文本文件中的數據轉化為普通的表格形式，然后再利用上面這些工具導入到系統中。這雖然會增加一定的工作量， 但是卻可以保證大容量數據的質量。為此，筆者在實際工作中，如果用戶遇到這種問題筆者是強烈建議他們要采用系統提供的工具來導入導出大容量數據。

  另外，利用格式化文件來提高大容量數據的規范化，也是一個不錯的選擇。上面提到的幾款大容量導入導出工具都支持使用專門的格式化文件來存儲原始數據文件中 每個字段的格式信息。格式化文件還可以包含相應的數據庫表的有關信息。格式化文件可以用于提供從數據庫實例大容量導出數據和向其中大容量導入數據時所需的 所有格式信息。通俗的講，格式化文件提供了一種解釋導入期間數據文件中數據的格式以及設置導出期間數據文件中數據格式的靈活方式。這種靈活性使得解釋數據 時無需編寫專用代碼，也無需為滿足數據庫或外部應用程序的特殊需要而重新設置數據的格式。如果靈活利用格式化文件，那么用戶可以直接按需要的格式導出或者 導入大容量數據，而不用事后再進行額外的格式調整。

  2.選擇合適的數據庫日志操作模式。

  正如大家所知道的，用戶在數據庫中做的任何變化，都會記錄在相關的日志中。導入導出大容量數據也不例外。可是由于大容量數據比較大，會占用比較大的事務日 志功能。為此筆者建議，在用戶導入大容量數據之前，最好選擇合適的數據庫日志操作模式。筆者的做法是，如果用戶需要導入大容量數據，那么最好選擇大容量日 志恢復模式。等到導入工作完成之后，再恢復到原先的模式。

  這主要是因為在大容量日志模式下，對于大容量數據導入工作中說，支持力度相對來說比較好。與其他日志恢復模式相比(如完全恢復模式)，大容量日志恢復模式 只對大容量操作進行最小記錄。為此大容量日志操作恢復模式保護大容量操作不受硬件故障的危害，提供比較好的性能并且占用日志的空間也是最小的。所以，使用 大容量日志恢復有助于防止事務日志出現空間不足的情況，因為大容量日志恢復不會插入日志行。這個大容量日志操作模式，非常適用于使用完整恢復模式的數據 庫。對無索引表執行大容量操作時，大容量日志恢復模式非常有用。

  不過大容量日志操作模式也具有一定的風險。如大容量日志恢復模式會增加這些大容量復制操作丟失數據的風險。因為大容量日志操作模式將會阻止數據庫系統捕獲 對每個事務逐一所做的更改。如果日志備份包含大容量日志操作，則無法還原到該日志備份中的時點，而只能還原整個日志備份。另外在大容量日志恢復模式下，如 果日志備份覆蓋了任何大容量操作，則日志備份將包含由大容量操作所更改的日志記錄和數據頁。這對于捕獲大容量日志操作的結果至關重要。合并的數據區可使日 志備份變得非常龐大。再者，備份日志需要訪問包含大容量日志事務的數據文件。如果無法訪問任何受影響的數據庫文件，則事務日志將無法備份，并且在此日志中 提交的所有操作都會丟失。所以大容量日志備份模式并不是安全的日志模式。

  通常情況下，只有在需要大容量導入導出數據的時候才臨時啟用這種操作模式。為了大容量導入性能與數據庫安全考慮，筆者建議建議數據庫管理員可以在執行大容量導入操作之前，先將數據庫改為使用大容量日志恢復模式。完成之后馬上將數據庫重設為完整恢復模式。

  3.考慮是否需要先暫時刪除表的索引。

  引是一種特殊的文件，在數據庫中它的作用是舉足輕重的。簡單的來說，如果把數據庫比喻成一本書的話，那么索引就好像是書的目錄。索引包含著對數據表里所有 記錄的引用指針。索引可以提高數據庫的性能，這是毋庸置疑的。但是不是在任何場合索引都可以起到正面的效果。在某些特殊情況下，其反而會降低一些操作的性 能，如大容量數據的導入。

  索引可以加快數據檢索操作，但它會使數據修改操作變慢。因為每次修改或者插入數據記錄，索引就必須刷新一次。也就是說，插入一百萬條記錄，則索引就必須重 新所新一百萬次。可見，當大容量數據導入的時候，索引將耗費數據庫大量的資源，從而降低數據庫的性能。如果目的表中有索引，那么不僅會影響數據庫大容量數 據導入的速度，而且還會降低其他用戶正常訪問數據庫的性能。

  為此，筆者的建議是，如果要導入的表中數據并不是很多，那么最好先刪除索引來提高大容量數據導入的性能。導入之后再重新啟用索引。但是，如果在需要導入的 表中已經有不少的數據，而需要導入的數據可能跟已存在的數據差不多或者要少的話，那么還是不用刪除索引。此時如果刪除索引會起到適得其反的效果。因為數據 庫系統重新生成索引所需要的時間可能比大容量導入操作期間所節省的時間要更長。此時管理員刪除目的表的索引就有點得不償失了。

  4.數據導入后即時進行數據庫備份。

  同建立數據庫對象一樣，把大容量數據導入到數據庫系統后，管理員要及時對現有的數據庫進行備份。因為及時有系統大容量導入工具的幫助，這個數據導入的工作 仍然是非常繁瑣、耗時的。為此當大容量數據順利導入到數據庫系統之后，管理員要及時得對數據庫進行備份。這里筆者要提醒大家的是，不同的操作日志模式下， 其備份的方法往往是不同的。

  大容量數據導入后，管理員需要對數據庫進行備份。對此筆者的建議是，如果當時管理員采用的是簡單的日志恢復模式，則管理員在大容量導入操作完成后應該立即 執行完整備份或差異備份(如果時間允許的話，最好還是完整備份)。而如果數據庫管理員當時采用的是大容量日志恢復模式或完整恢復模式，如果時間不是很多或 者怕擔心完全備份會影響當時用戶的訪問，那么只需執行日志備份就足夠了。如果數據庫服務器還沒有變成生產服務器(即還有沒有用戶在用)，則還是對數據庫進 行完全備份保險一點。

  5.常見的錯誤。

  在大容量數據導入過程中，最常見的錯誤大概有兩個。

  一是提供文件的格式不對。如上面所說，通常情況下數據庫提供的大容量導入工具不支持文本文件。為此管理員需要進行事先的轉換。二是要注意隱藏字符可能帶來 到問題。許多軟件和文本編輯器都會顯示隱藏字符。這些隱藏字符通常位于數據文件末尾。在大容量導入操作期間，數據文件中的隱藏字符可能會導致一些難以預測 的問題，如意外空字符錯誤等等。這個錯誤很好避免。只要數據庫管理員在導入數據之前先查找并刪除所有隱藏字符即可。其實，不僅在大容量數據導入過程中，還 是在少量數據導入過程中，都會遇到這個問題。

關鍵字：SQL Server、數據庫、服務器