在對DB2資料庫進行批量增刪的時候, 如果資料量比較大會導致SQL0964N錯誤, DB2 Knowledge center(http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.messages.sql.doc/doc/msql00964c.html)對該錯誤的解釋為"The transaction log for the database is full", 即事務日誌滿. 由於在進行增刪操作的時候資料庫需要記錄事務日誌以便在發生異常時能夠回滾, 當批處理的資料量比較大超過了事務日誌空間的容量就會發生這樣的錯誤.
解決這個問題主要有兩個方法
1, 對執行的操作取消事務日誌
首先取消資料庫的自動提交功能, 在命令列可以通過+C引數取消, 然後需要修改導致事務日誌滿的表tbl.
ALTER TABLE tbl ACTIVATE NOT LOGGED INITIALLY;
現在可以執行之前導致事務日誌滿的SQL語句了, 例如
DELETE FROM tbl
現在可以發現沒有事務日誌滿的錯誤了, 最後再提交. 這是最為簡單快速的方式.
ATTENTION: 但是必須要慎重使用這個方法, 因為當操作失敗的時候將導致改表無法恢復.
有一次我需要從一個有1.4億行的表裡面刪除大概3000W的資料, 執行完NOT LOGGED INITIALLY後開始刪除資料, 由於刪除時間太長我就強制取消了刪除操作, 刪除操作取消後DB2返回如下資訊:
DB21034E 該命令被當作 SQL 語句來處理,因為它是無效的“命令列處理器”命令。在 SQL 處理期間,它返回: SQL1476N 當前事務因錯誤 "-952" 而回滾。 SQLSTATE=40506
悲劇的是當我準備再次對這張表進行操作的時候DB2報如下資訊:
DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL1477N For table "DB2INST1.IBASE_RAW2" an object "28" in table space "2" cannot be accessed. SQLSTATE=55019
經查詢DB2 Info Center, 得到的結果是...
The table had NOT LOGGED INITIALLY activated when the unit of work was rolled back.
解決辦法是...
If the object is a table and it had NOT LOGGED INITIALLY activated, drop the table. If this table is required, re-create it
只能刪除表, 哭瞎...
2, 增大日誌空間
日誌空間的大小=(LOGPRIIMARY + LOGSECOND) * LOGFILSIZ * 4K, 因此可以通過修改資料庫的配置檔案LOGPRIIMARY, LOGSECOND和LOGFILSIZ來增大事務日誌空間. 其中更改LOGSECOND不需要斷開DB連線, 是最為簡單的方法是