1. <i id="s6b2k"><small id="s6b2k"></small></i>
    <b id="s6b2k"><bdo id="s6b2k"></bdo></b>
  2. <wbr id="s6b2k"></wbr>

    DB2死鎖的解決過程全記錄_DB2

    來源:腳本之家  責任編輯:小易  

    SQLSTATE 42601:字符、標記或子句無效或丟失。我把你的語句在我本地DB2做了一遍,修改了一下,沒有問題。我執行的語句:db2"insert into t_zm_dhyc(ID,COMPANYID,DEPTID,WEEK,STARTWEEK,ENDWEEK,EXECUTOR,EXECUTIONTIME,KHMC,KHDZ,XKZH,PPMC,SZDH,BZDH,HQB,YY,TXRID,TXRMC,TXSJ,STATUS,REMARK,TAG,TAG2)with t1 as(select COMPANYID,DEPTID,ORDERID,PRODUCTCODE,QUANTREQ qzsl,ISCANCEL from T_VISITSALES_ORDERDETAIL where ORDERDATE='1' and productid='1'),t2 as(select QUANTREQ bzsl from T_VISITSALES_ORDERDETAIL where ORDERDATE='1' and productid='1')select distinct '1' id,t1.COMPANYID,t1.DEPTID,'1' week,'2' startweek,'2' endweek,'' executor,'2' executiontime,'' khmc,'' khdz,'' xkzh,t1.PRODUCTCODE,t1.qzsl,t2.bzsl,t2.bzsl|t1.qzsl hqb,'' yy,'1' txrid,'' txrmc,'2' txsj,'0' status,'' remark,'' tag,'' tag2 from t1,t2查詢結果:ID COMPANYID DEPTID WEEK STARTWEEK ENDWEEK EXECUTOR EXECUTIONTIME KHMC KHDZ XKZH PPMC SZDH BZDH HQB YY TXRID TXRMC TXSJ STATUS REMARK TAG TAG2-1-1 2 2 2-1 2 0 1 條記錄已選擇。為了方便檢查,我將所有表字段都設置為char(1)了。從錯誤代碼來看,請你檢查一下數據庫里面這兩張表是否有齊你select或where的字段www.yu113.com防采集請勿采集本網。

    生產環境里使用的數據庫是DB2。但是最近頻繁出現一個奇怪的死鎖現象:某一個select sql 語句總是會出現死鎖。

    并發操作帶來了數據的不一致性: 主要有三種: 計算機系統中,如果系統的資源分配策略不當,更常見的可能是程序員寫的程序有錯誤等,則會導致進程因競爭資源不當而產生死鎖的現象。

    按照以往的經驗,通常都是update/delete之類的更新sql語句會出現死鎖的問題。而且這個 select sql 語句是一個很普通的sql,沒有任何大數據量的處理。

    在系統中已經出現死鎖后,應該及時檢測到死鎖的發生,并采取適當的措施來解除死鎖。死鎖預防。這是一種較簡單和直觀的事先預防的方法。方法是通過設置某些限制條件,去破壞產生死鎖的四個必要條件中的一個

    分析這個死鎖,有很多難以處理的地方。

    我覺得方法總比困難多,一定要學會尋找方法

    1、因為生產環境數據量大,我們無法把生產環境中關聯表的數據導入到測試環境。也就是說,無法模擬數據量。

    12345的流程: 一、受理 接線人對各類訴求進行登記,轉交交辦處理組(接線受理人員當即解答除外)。二、辦理 交辦處理人拿出擬交辦意見,交熱線辦分管副主任簽發具體擬辦意見。1、直辦 對咨詢性

    2、沒有任何log輸出。因為生產環境的log輸出級別是ERROR。

    根據你的問題: 答復如下:1.索引只是解決查詢效率問題,和鎖沒什么關系。2.如果插入表2時,表2有一條和當前插入的值相同,會產生主鍵沖突,你怎么處理?其實不知道你想解決什么問題。

    3、無法在生產環境進行測試,因為客戶不允許。

    4、生產環境的數據庫無法開啟快照等功能。因為會影響性能。

    大家可以想象,在沒有快照等功能下,分析死鎖就只能靠分析代碼了。但是這個處理非常復雜,單憑分析代碼,沒有任何頭緒。

     

    階段1:我們懷疑是數據量的原因

     

    由于生產環境的數據量特別大,這個處理還有很多其他表的處理。所以我們懷疑是不是大數據量導致系統負荷過高,導致了死鎖?

    于是我們取得了發生死鎖時CPU,硬盤,網絡等等負載信息。沒有找到任何線索。

     

    階段2:做一個測試程序,在測試環境中用多線程模擬多用戶去做這個處理。

     

    為了能夠在開發環境再現出這個死鎖,我們做了一個多線程的測試程序,模擬多用戶運行。可惜,還是沒有再現出來。

     

    階段3:分析測試環境數據庫和產品環境數據庫的差異

     

    此時我們懷疑還是數據量導致的問題。于是我們盡可能的將開發環境的數據弄得和產品環境一樣多。

    之后在運行測試,還是沒有再現出來。

     

    階段4:分析用戶的操作log

     

    沒有任何辦法的情況下,我們只好分析用戶的操作log,希望從中找到一點線索。功夫不負有心人,我們發現,當兩個人同時

    進行這個操作的時候,基本都會發生死鎖。所以,我們判斷還是兩個人同時操作導致的問題。但是,為什么開發環境上模擬了

    很多人的操作,卻沒有發生死鎖呢?

     

    階段5:發現數據庫設置的問題

     

    我們又修改了測試程序,將模擬的用戶數量提高,但是很不幸,仍然沒有再現這個問題。此時我們注意到了:是不是開發環境的

    數據庫設置和產品環境的數據庫設置不同?我們對比了一下兩個數據庫的設置:發現好多參數不同。但是我們僅僅關注了和鎖有關

    的設置,也就是包含 LOCK關鍵字的設置。

     

    階段6:將測試環境數據庫和產品環境數據庫的設置保持一致

     

    我們將所有和lock有關的設置都改成了和產品環境一直。但是仍然沒有再現這個死鎖。終于,一個人發現,"cur_commit"這個設置

    不同。于是查詢文檔,發現了 cur_commit的特點。

    當 cur_commit = false的時候,下列情況會造成死鎖:

    線程1插入數據A,然后線程2插入數據B。

    在線程2還沒有提交事物之前,線程1查詢數據A,就會造成死鎖了。

    開發環境中,cur_commit = true,所以我們一直也模擬不出來這個現象。

    于是,我們把cur_commit也改成了 false。

     

    階段7:使用測試程序去模擬

     

    我們修改了測試程序,模擬上面兩個線程的操作,成功地再現了這個死鎖。錯誤的log信息和產品環境上也是一致的。

     

    階段8:使用畫面操作去模擬

     

    然后我們修改了程序,使用畫面去操作,也成功地再現了這個死鎖。

     

    解決方案:

     

    解決方案很簡單,就是把查詢語句中的條件加為索引,就不會出現死鎖了。

    由于這個表數據量不大,所以性能幾乎沒有任何影響。

    JAVA中幾種常見死鎖及對策:解決死鎖沒有簡單的方法,這是因為線程產生死鎖都各有各的原因,而且往往具有很高的負載。大多數軟件測試產生不了足夠多的負載,所以不可能暴露所有的線程錯誤。在這里中,下面將討論開發過程常見的4類典型的死鎖和解決對策。(1)數據庫死鎖在數據庫中,如果一個連接占用了另一個連接所需的數據庫鎖,則它可以阻塞另一個連接。如果兩個或兩個以上的連接相互阻塞,則它們都不能繼續執行,這種情況稱為數據庫死鎖。數據庫死鎖問題不易處理,通常數據行進行更新時,需要鎖定該數據行,執行更新,然后在提交或回滾封閉事務時釋放鎖。由于數據庫平臺、配置的隔離級以及查詢提示的不同,獲取的鎖可能是細粒度或粗粒度的,它會阻塞(或不阻塞)其他對同一數據行、表或數據庫的查詢。基于數據庫模式,讀寫操作會要求遍歷或更新多個索引、驗證約束、執行觸發器等。每個要求都會引入更多鎖。此外,其他應用程序還可能正在訪問同一數據庫模式中的某些對象,并獲取不同應用程序所具有的鎖。所有這些因素綜合在一起,數據庫死鎖幾乎不可能被消除了。值得慶幸的是,數據庫死鎖通常是可恢復的:當數據庫發現死鎖時,它會強制銷毀一個連接(通常是使用最少的連接),并回滾其事務。這將釋放所有與已經結束的事務相關聯的鎖,至少允許其他連接中有一個可以獲取它們正在被阻塞的鎖。由于數據庫具有這種典型的死鎖處理行為,所以當出現數據庫死鎖問題時,數據庫常常只能重試整個事務。當數據庫連接被銷毀時,會拋出可被應用程序捕獲的異常,并標識為數據庫死鎖。如果允許死鎖異常傳播到初始化該事務的代碼層之外,則該代碼層可以啟動一個新事務并重做先前所有工作。當出現問題就重試,由于數據庫可以自由地獲取鎖,所以幾乎不可能保證兩個或兩個以上的線程不發生數據庫死鎖。此方法至少能保證在出現某些數據庫死鎖情況時,應用程序能正常運行。(2)資源池耗盡死鎖客戶端的增加導致資源池耗盡死鎖是由于負載而造成的,即資源池太小,而每個線程需要的資源超過了池中的可用資源。假設連接池最多有10個連接,同時有10個對外部并發調用。這些線程中每一個都需要一個數據庫連接用來清空池。現在,每個線程都執行嵌套的調用。則所有線程都不能繼續,但又都不放棄自己的第一個數據庫連接。這樣,10個線程都將被死鎖。研究此類死鎖,會發現線程存儲中有大量等待獲取資源的線程,以及同等數量的空閑且未阻塞的活動數據庫連接。當應用程序死鎖時,如果可以在運行時檢測連接池,就能確認連接池實際上已空。修復此類死鎖的方法包括:增加連接池的大小或者重構代碼,以便單個線程不需要同時使用很多數據庫連接。或者可以設置內部調用使用不同的連接池,即使外部調用的連接池為空,內部調用也能使用自己的連接池繼續。(3)單線程、多沖突數據庫連接死鎖對同一線程執行嵌套的調用有時出現死鎖,此情形即使在非高負載系統中通常也會發生。當第一個(外部)連接已獲取第二個(內部)連接所需要的數據庫鎖,則第二個連接將永久阻塞第一個連接,并等待第一個連接被提交或回滾,這就出現了死鎖情形。因為數據庫沒有注意到兩個連接之間的關系,所以數據庫不會將此情形檢測為死鎖。這樣即使不存在并發,此代碼也將導致死鎖。此情形有多種具體的變種,可以涉及多個線程和兩個以上的數據庫連接。(4)Java虛擬機鎖與數據庫鎖沖突這種情形發生在數據庫鎖與Java虛擬機鎖并存的時候。在這種情況下,一個線程占有一個數據庫鎖并嘗試獲取Java虛擬機鎖。同時,另一個線程占有Java虛擬機鎖并嘗試獲取數據庫鎖。此時,數據庫發現一個連接阻塞了另一個連接,但由于無法阻止連接繼續,所以不會檢測到死鎖。Java虛擬機發現同步的鎖中有一個線程,并有另一個嘗試進入的線程,所以即使Java虛擬機能檢測到死鎖并對它們進行處理,它還是不會檢測到這種情況。總而言之,JAVA應用程序中的死鎖是一個大問題—它能導致整個應用程序慢慢終止,還很難被分離和修復,尤其是當開發人員不熟悉如何分析死鎖環境的時候。五.死鎖的經驗法則筆者在開發中總結以下死鎖問題的經驗。(1)對大多數的Java程序員來說最簡單的防止死鎖的方法是對競爭的資源引入序號,如果一個線程需要幾個資源,那么它必須先得到小序號的資源,再申請大序號的資源。可以在Java代碼中增加同步關鍵字的使用,這樣可以減少死鎖,但這樣做也會影響性能。如果負載過重,數據庫內部也有可能發生死鎖。(2)了解數據庫鎖的發生行為。假定任何數據庫訪問都有可能陷入數據庫死鎖狀況,但是都能正確進行重試。例如了解如何從應用服務器獲取完整的線程轉儲以及從數據庫獲取數據庫連接列表(包括互相阻塞的連接),知道每個數據庫連接與哪個Java線程相關聯。了解Java線程和數據庫連接之間映射的最簡單方法是向連接池訪問模式添加日志記錄功能。(3)當進行嵌套的調用時,了解哪些調用使用了與其它調用同樣的數據庫連接。即使嵌套調用運行在同一個全局事務中,它仍將使用不同的數據庫連接,而不會導致嵌套死鎖。(4)確保在峰值并發時有足夠大的資源池。(5)避免執行數據庫調用或在占有Java虛擬機鎖時,執行其他與Java虛擬機無關的操作。最重要的是,多線程設計雖然是困難的,但在開始編程之前詳細設計系統能夠幫助你避免難以發現死鎖的問題。死鎖在語言層面上不能解決,就需要一個良好設計來避免死鎖內容來自www.yu113.com請勿采集。


  3. 本文相關:
  4. 數據庫觸發器db2和sqlserver有哪些區別
  5. centos下db2數據庫安裝過程詳解
  6. db2數據庫常用操作命令大全
  7. db2新手使用的一些小筆記:新建實例、數據庫路徑不存在、客戶端連接 .
  8. db2 導入導出單個表的操作詳解
  9. db2比較常用與實用sql語句總結
  10. db2 常用命令小結
  11. db2 常用命令速查(備忘)
  12. db2 日期和時間的函數應用說明
  13. 詳解db2 sqlstate 57016 sqlcode=-668 原因碼 "7"錯誤的快速解決辦法
  14. db2 9數據服務器發展3部曲
  15. ibm db2 日常維護匯總(六)
  16. db2 9(viper)快速入門
  17. db2中reverse函數的實現方法
  18. ibm db2 日常維護匯總(二)
  19. ibm db2 日常維護匯總(八)
  20. db2常用傻瓜問題1000問(五)
  21. db2 日期和時間的函數應用說明
  22. db2數據庫中常見的堵塞問題分析與處理方法
  23. 對比db2 9和db2 v8.x中的xml功能
  24. java線程死鎖有幾種解決方法
  25. DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC
  26. SQL 進程死鎖
  27. 簡化資源分配圖 判斷是否死鎖 大神求教 求分析
  28. 并發控制、沖突解決、死鎖
  29. 避免死鎖的方法有哪些?
  30. 閱讀文章過程中,遇到不懂的問題,有哪些解決的方法? 請列舉出來。
  31. 12345的流程是什么
  32. 數據表死鎖 有兩個表 結構都是一樣的 主鍵設置也相同 寫了一個存儲過程,
  33. 索賠的最終解決是什么?
  34. 網站首頁網頁制作腳本下載服務器操作系統網站運營平面設計媒體動畫電腦基礎硬件教程網絡安全mssqlmysqlmariadboracledb2mssql2008mssql2005sqlitepostgresqlmongodbredisaccess數據庫文摘數據庫其它首頁db2數據庫觸發器db2和sqlserver有哪些區別centos下db2數據庫安裝過程詳解db2數據庫常用操作命令大全db2新手使用的一些小筆記:新建實例、數據庫路徑不存在、客戶端連接 .db2 導入導出單個表的操作詳解db2比較常用與實用sql語句總結db2 常用命令小結db2 常用命令速查(備忘)db2 日期和時間的函數應用說明詳解db2 sqlstate 57016 sqlcode=-668 原因碼 "7"錯誤的快速解決辦法db2 9數據服務器發展3部曲ibm db2 日常維護匯總(六)db2 9(viper)快速入門db2中reverse函數的實現方法ibm db2 日常維護匯總(二)ibm db2 日常維護匯總(八)db2常用傻瓜問題1000問(五)db2 日期和時間的函數應用說明db2數據庫中常見的堵塞問題分析與處理方法對比db2 9和db2 v8.x中的xml功能db2 常用命令小結db2數據庫的備份和恢復db2優化(簡易版)ibm db2 日常維護匯總(一)db2數據庫的安裝db2常用傻瓜問題1000問(一)db2比較常用與實用sql語句總結db2數據同步方面的經驗db2常用傻瓜問題1000問(四)db2個人版(linux)安裝db2 常用命令小結db2 9產品說明書在線參考地址(http)db2數據庫中常見的堵塞問題分析與處理方法jsp如何連接db2數據庫db2編程序技巧 (一)db2 9(viper)快速入門db2中reverse函數的實現方法db2編程序技巧 (三)db2編程序技巧 (五)如何安裝sql server 2008 management stu
    免責聲明 - 關于我們 - 聯系我們 - 廣告聯系 - 友情鏈接 - 幫助中心 - 頻道導航
    Copyright © 2017 www.yu113.com All Rights Reserved
    战天txt全集下载