• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Prayer

            在一般中尋求卓越
            posts - 1256, comments - 190, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理

            數(shù)據(jù)庫日志空間滿-- SQL0964C錯(cuò)誤

            Posted on 2010-02-09 15:14 Prayer 閱讀(813) 評論(0)  編輯 收藏 引用 所屬分類: DB2

            15.2  數(shù)據(jù)庫常見問題總結(jié)

            15.2.1  數(shù)據(jù)庫日志空間滿-- SQL0964C錯(cuò)誤

            數(shù)據(jù)庫運(yùn)行時(shí)如果報(bào)SQL0964C的錯(cuò)誤,那么一般和數(shù)據(jù)庫日志有關(guān),先看圖15-3所示的案例。

             
            (點(diǎn)擊查看大圖)圖15-3  數(shù)據(jù)庫日志已滿
            DB2使用的活動(dòng)日志的最大空間是由公式
            1. (logprimary + logsecond) * logfilsiz * 4096 

            計(jì)算出的大小來決定的(logprimary、logsecond、logfilsiz是數(shù)據(jù)庫配置參數(shù))。在DB2中,一個(gè)長事務(wù)最多可以使用不超過256GB日志(DB2 V5是2GB,DB2 V7是32GB,DB2 V8是256GB)

            若該空間已全部被分配,而應(yīng)用仍試圖請求更多活動(dòng)日志空間時(shí),就會發(fā)生日志滿的情況。此時(shí),用戶的更新、刪除或插入操作都會使DB2DIAG.LOG中寫入以下信息:

            SQL0964C數(shù)據(jù)庫的事務(wù)日志已滿。

            SQL0964C錯(cuò)誤表明數(shù)據(jù)庫日志已滿,DB2活動(dòng)日志滿通常是由于存在大量未提交事務(wù)的數(shù)據(jù),使得活動(dòng)日志的空間不能及時(shí)釋放,使新的事務(wù)無法申請到可用日志空間,而最終報(bào)出SQL0964C的錯(cuò)誤所致。要解決這些問題,您可以增加日志文件或日志個(gè)數(shù)。這種錯(cuò)誤一般是批量插入、刪除或更新時(shí)報(bào)的錯(cuò)誤。所以最好是能夠調(diào)整業(yè)務(wù)邏輯,分批次刪除、更新或插入。這樣做會降低日志報(bào)錯(cuò)的概率。

            但還有另外一種原因,即在日志空間并未用盡的情況下,當(dāng)某個(gè)占有最舊活動(dòng)日志的應(yīng)用長時(shí)間未作提交操作,阻止了日志的LSN的分配,造成日志空間無法使用,同樣會引發(fā)這一日志滿的報(bào)錯(cuò)。對于這種情況,可以提交該交易或利用FORCE命令來終止此應(yīng)用程序,以便釋放它所占用的日志空間,使LSN可以繼續(xù)分配,空閑的日志空間可用。這里就提供了由這一原因?qū)е氯罩緷M問題的解決方法。

            首先檢查DB2診斷日志文件db2diag.log,在其中查找如下類似信息:

            1. 2008-01-16-02.53.54.935308 Instance:db2inst1 Node:016  
            2. PID:144252(db2agntp (SAMPLE) 16) Appid:*.*  
            3. data_protection sqlpgrsp Probe:50 Database:SAMPLE  
            4. Log Full -- active log held by appl. handle 787273   
            5. End this application by COMMITROLLBACK or FORCE APPLICATION. 

            由此,可以找到最早持有日志空間的應(yīng)用程序,其句柄為787273。使用DB2的快照工具,通過從快照的輸出中查找如下類似信息:

            1. Appl id holding the oldest transaction = 787273 

            同樣可以找到這個(gè)應(yīng)用程序的句柄。這時(shí)使用以下命令可以在無需斷開數(shù)據(jù)庫其他應(yīng)用程序的連接的情況下強(qiáng)行終止該應(yīng)用程序:

            1. db2 force application (787273)  
            2. DB20000I FORCE APPLICATION命令成功完成。  
            3. DB21024I 該命令為異步的,可能不會立即生效。 

            根據(jù)提示,由于該命令是異步操作,所以可再次使用:

            1. db2 list applications 

            驗(yàn)證應(yīng)用是否已被真正停止,如果輸出中已沒有該應(yīng)用,那么它所占有的日志空間會因應(yīng)用程序被回滾而立即釋放,DB2日志因此重新可用。

            亚洲日本va中文字幕久久| 久久久久国产一区二区三区| 色婷婷综合久久久久中文一区二区| 久久精品久久久久观看99水蜜桃| 久久久久av无码免费网| 国产午夜福利精品久久2021| 久久久久一级精品亚洲国产成人综合AV区 | 欧美亚洲国产精品久久| 亚洲中文久久精品无码ww16| 大蕉久久伊人中文字幕| 亚洲欧美伊人久久综合一区二区| 国产精品一区二区久久精品| 色青青草原桃花久久综合| 亚洲成人精品久久| 久久香综合精品久久伊人| 亚洲日本va午夜中文字幕久久| 91视频国产91久久久| 亚洲国产成人久久综合区| 国产成人精品综合久久久| 国产美女久久久| 丁香五月网久久综合| 久久精品国产亚洲AV香蕉| 久久妇女高潮几次MBA| 国产香蕉久久精品综合网| 久久久久香蕉视频| 国产成人久久777777| 久久久九九有精品国产| 亚洲午夜久久久久久噜噜噜| 久久久国产99久久国产一| 精品一久久香蕉国产线看播放| 99久久精品日本一区二区免费| 亚洲午夜久久久影院伊人| 欧美日韩精品久久免费| 欧美成a人片免费看久久| 久久久噜噜噜久久| 日本精品久久久久影院日本 | 久久久久免费精品国产| 久久综合鬼色88久久精品综合自在自线噜噜 | 亚洲国产精品婷婷久久| 欧美亚洲另类久久综合| 中文精品久久久久国产网址|