15.2 數(shù)據(jù)庫(kù)常見(jiàn)問(wèn)題總結(jié)
15.2.1 數(shù)據(jù)庫(kù)日志空間滿-- SQL0964C錯(cuò)誤
數(shù)據(jù)庫(kù)運(yùn)行時(shí)如果報(bào)SQL0964C的錯(cuò)誤，那么一般和數(shù)據(jù)庫(kù)日志有關(guān)，先看圖15-3所示的案例。
 |
| （點(diǎn)擊查看大圖）圖15-3 數(shù)據(jù)庫(kù)日志已滿 |
DB2使用的活動(dòng)日志的最大空間是由公式
- (logprimary + logsecond) * logfilsiz * 4096
計(jì)算出的大小來(lái)決定的(logprimary、logsecond、logfilsiz是數(shù)據(jù)庫(kù)配置參數(shù))。在DB2中，一個(gè)長(zhǎng)事務(wù)最多可以使用不超過(guò)256GB日志(DB2 V5是2GB，DB2 V7是32GB，DB2 V8是256GB)
若該空間已全部被分配，而應(yīng)用仍試圖請(qǐng)求更多活動(dòng)日志空間時(shí)，就會(huì)發(fā)生日志滿的情況。此時(shí)，用戶的更新、刪除或插入操作都會(huì)使DB2DIAG.LOG中寫入以下信息：
SQL0964C數(shù)據(jù)庫(kù)的事務(wù)日志已滿。
SQL0964C錯(cuò)誤表明數(shù)據(jù)庫(kù)日志已滿，DB2活動(dòng)日志滿通常是由于存在大量未提交事務(wù)的數(shù)據(jù)，使得活動(dòng)日志的空間不能及時(shí)釋放，使新的事務(wù)無(wú)法申請(qǐng)到可用日志空間，而最終報(bào)出SQL0964C的錯(cuò)誤所致。要解決這些問(wèn)題，您可以增加日志文件或日志個(gè)數(shù)。這種錯(cuò)誤一般是批量插入、刪除或更新時(shí)報(bào)的錯(cuò)誤。所以最好是能夠調(diào)整業(yè)務(wù)邏輯，分批次刪除、更新或插入。這樣做會(huì)降低日志報(bào)錯(cuò)的概率。
但還有另外一種原因，即在日志空間并未用盡的情況下，當(dāng)某個(gè)占有最舊活動(dòng)日志的應(yīng)用長(zhǎng)時(shí)間未作提交操作，阻止了日志的LSN的分配，造成日志空間無(wú)法使用，同樣會(huì)引發(fā)這一日志滿的報(bào)錯(cuò)。對(duì)于這種情況，可以提交該交易或利用FORCE命令來(lái)終止此應(yīng)用程序，以便釋放它所占用的日志空間，使LSN可以繼續(xù)分配，空閑的日志空間可用。這里就提供了由這一原因?qū)е氯罩緷M問(wèn)題的解決方法。
首先檢查DB2診斷日志文件db2diag.log，在其中查找如下類似信息：
- 2008-01-16-02.53.54.935308 Instance:db2inst1 Node:016
- PID:144252(db2agntp (SAMPLE) 16) Appid:*.*
- data_protection sqlpgrsp Probe:50 Database:SAMPLE
- Log Full
- End this application by COMMIT, ROLLBACK or FORCE APPLICATION.
由此，可以找到最早持有日志空間的應(yīng)用程序，其句柄為787273。使用DB2的快照工具，通過(guò)從快照的輸出中查找如下類似信息：
- Appl id holding the oldest transaction = 787273
同樣可以找到這個(gè)應(yīng)用程序的句柄。這時(shí)使用以下命令可以在無(wú)需斷開(kāi)數(shù)據(jù)庫(kù)其他應(yīng)用程序的連接的情況下強(qiáng)行終止該應(yīng)用程序：
- db2 force application (787273)
- DB20000I FORCE APPLICATION命令成功完成。
- DB21024I 該命令為異步的，可能不會(huì)立即生效。
根據(jù)提示，由于該命令是異步操作，所以可再次使用：
- db2 list applications
驗(yàn)證應(yīng)用是否已被真正停止，如果輸出中已沒(méi)有該應(yīng)用，那么它所占有的日志空間會(huì)因應(yīng)用程序被回滾而立即釋放，DB2日志因此重新可用。