Informix常見(jiàn)錯(cuò)誤處理思路

2023年3月1日深圳IT-葉萬(wàn)華Informix常見(jiàn)錯(cuò)誤處理思路及應(yīng)用Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第1頁(yè)!informix常見(jiàn)錯(cuò)誤處理思路邏輯日志滿(mǎn)頻繁的鎖沖突長(zhǎng)事務(wù)I/O失敗Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第2頁(yè)!故障現(xiàn)象：數(shù)據(jù)庫(kù)不再進(jìn)行任何操作，使用

onstat–l命令觀察邏輯日志狀態(tài)，所有的邏輯日志都處于已使用未備份狀態(tài)，即

flags為

U------標(biāo)志。

onspa01g2:/home/szit>onstat–l

address

number

flags

uniqid

begin

size

used

%used1228d4ed0

1

U------

10521

3:53

12800

12800

100.001228d4f38

2

U------

10522

3:12853

12800

12800

100.001228d4fa0

3

U---C-L

10523

3:25653

12800

10828

84.591228bec50

4

U-B----

10504

3:38453

12800

12800

100.001228becb8

5

U-B----

10505

3:51253

12800

12800

100.001228bed20

6

U-B----

10506

3:64053

12800

12800

100.001228bed88

7

U------

10507

3:76853

12800

12800

100.001228bedf0

8

U------

10508

3:89653

12800

12800

100.001228bee58

9

U------

10509

3:102453

12800

12800

100.00(注：紅色部分為異常狀態(tài)，如綠色部分也被使用完，數(shù)據(jù)庫(kù)將出現(xiàn)異常。版面上只顯示出該店出現(xiàn)異常時(shí)用onstat–l監(jiān)控到的部分信息。)邏輯日志滿(mǎn)Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第3頁(yè)!故障分析：由于數(shù)據(jù)庫(kù)的大部分操作都需要記錄邏輯日志，所以如果邏輯日志由于各種各樣的原因被充滿(mǎn)都會(huì)導(dǎo)致數(shù)據(jù)庫(kù)停止正常的操作，等待邏輯日志空間的釋放、重新再利用。原因可能為：數(shù)據(jù)庫(kù)邏輯日志沒(méi)有及時(shí)備份數(shù)據(jù)庫(kù)邏輯日志空間分配過(guò)小邏輯日志里面包含活動(dòng)事務(wù)、包含檢查點(diǎn)信息邏輯日志滿(mǎn)Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第4頁(yè)!故障現(xiàn)象：在正常的數(shù)據(jù)庫(kù)操作中會(huì)經(jīng)常出現(xiàn)－243、－244等一類(lèi)的鎖錯(cuò)誤碼出現(xiàn)-243Couldnotpositionwithinatabletable-name.-244Couldnotdoaphysical-orderreadtofetchnextrow.類(lèi)似的鎖表現(xiàn)象中，我們?cè)谌粘５谋O(jiān)控過(guò)程中會(huì)經(jīng)常觀察得到。頻繁的鎖沖突Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第5頁(yè)!頻繁的鎖沖突使用onstat–gsql+sessid–r跟蹤查詢(xún)鎖狀態(tài)Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第6頁(yè)!故障現(xiàn)象：在數(shù)據(jù)庫(kù)日志里面出現(xiàn)發(fā)現(xiàn)長(zhǎng)事務(wù)的提示，受影響的事務(wù)處于回滾狀態(tài)，個(gè)別情況下會(huì)導(dǎo)致整個(gè)數(shù)據(jù)庫(kù)實(shí)例的其他數(shù)據(jù)庫(kù)會(huì)話(huà)都停止執(zhí)行。故障分析：當(dāng)一個(gè)活動(dòng)事務(wù)它所占用的邏輯日志個(gè)數(shù)的比例達(dá)到或超過(guò)

LTXHWM（長(zhǎng)事務(wù)基準(zhǔn)線(xiàn)）

所設(shè)定的值，數(shù)據(jù)庫(kù)就會(huì)判定該事務(wù)為一個(gè)長(zhǎng)事務(wù)，對(duì)該事務(wù)進(jìn)行回滾操作，如果這個(gè)時(shí)候邏輯日志的使用個(gè)數(shù)仍然持續(xù)上漲達(dá)到或超過(guò)

LTXEHWM所設(shè)定的值，則數(shù)據(jù)庫(kù)會(huì)停止其他會(huì)話(huà)的正常運(yùn)轉(zhuǎn)，全力保證該長(zhǎng)事務(wù)的回滾操作。長(zhǎng)事務(wù)Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第7頁(yè)!故障現(xiàn)象：數(shù)據(jù)庫(kù)日志中出現(xiàn)

chunkIO錯(cuò)誤，使用

onstat–d觀察

chunkflag的狀態(tài)是

down的狀態(tài)，數(shù)據(jù)庫(kù)操作中不能操作包含在這些

chunk中的數(shù)據(jù)，如果使用到這些數(shù)據(jù)可能會(huì)返回錯(cuò)誤，嚴(yán)重情況下會(huì)導(dǎo)致數(shù)據(jù)庫(kù)宕機(jī)。故障分析：由于發(fā)生

IO錯(cuò)誤，數(shù)據(jù)庫(kù)不能正常的操作包含在受影響

chunk中的數(shù)據(jù)，所有的操作請(qǐng)求都將失敗。這可能是由于磁盤(pán)設(shè)備出現(xiàn)問(wèn)題、chunk所使用的設(shè)備不存在、使用的鏈接設(shè)備不存在、設(shè)備的權(quán)限錯(cuò)誤等可能性。數(shù)據(jù)庫(kù)

chunk出現(xiàn)異常，I/O失敗Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第8頁(yè)!Informix的應(yīng)用案例dbschema常用命令UpdateStatistics的作用應(yīng)用案例Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第9頁(yè)!

為了提高數(shù)據(jù)庫(kù)的效率，INFORMIX提供了一個(gè)基于成本的查詢(xún)優(yōu)化器，執(zhí)行updatestatistics語(yǔ)句的作用就是將您創(chuàng)建的數(shù)據(jù)庫(kù)表的有關(guān)統(tǒng)計(jì)信息更新到系統(tǒng)sysmaster的相關(guān)表中，以便查詢(xún)優(yōu)化器選擇最佳的執(zhí)行路徑。當(dāng)sysmaster庫(kù)中沒(méi)有相應(yīng)的統(tǒng)計(jì)信息，或者統(tǒng)計(jì)信息不十分準(zhǔn)確時(shí)，優(yōu)化器便無(wú)法制定一個(gè)行之有效的查詢(xún)策略，其結(jié)果必然是進(jìn)行大量極其可怕的順序掃描，產(chǎn)生嚴(yán)重的性能問(wèn)題。

因此，當(dāng)您重新裝載數(shù)據(jù)或者對(duì)數(shù)據(jù)庫(kù)表進(jìn)行了大量的更新操作后，應(yīng)該及時(shí)執(zhí)行updatestatistics。也許您會(huì)發(fā)現(xiàn)，數(shù)據(jù)庫(kù)一些參數(shù)配置的不合理可能使數(shù)據(jù)庫(kù)效率降低百分之幾，但如果您沒(méi)有定期執(zhí)行updatestatistics的話(huà)。數(shù)據(jù)庫(kù)的性能則可能降低幾到十幾倍。UpdateStatistics的作用Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第10頁(yè)!Informix的應(yīng)用案例查詢(xún)業(yè)務(wù)庫(kù)中表大小（方式一）Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第11頁(yè)!Informix的應(yīng)用案例

在公司OA系統(tǒng)提交主機(jī)操作記錄，審核通過(guò)后即可操作

Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第12頁(yè)!Informix的應(yīng)用案例Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第13頁(yè)!有興趣的同事可以瀏覽：./informix-dba/194-informix.html中國(guó)Informix數(shù)據(jù)庫(kù)用戶(hù)協(xié)會(huì)

Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第14頁(yè)!故障處理：檢查是否是由于邏輯日志備份出現(xiàn)問(wèn)題，如果是不能備份請(qǐng)查找不能備份的原因，可能是由于磁帶滿(mǎn)或磁帶機(jī)出現(xiàn)故障，或者是磁帶設(shè)備繁忙；個(gè)別情況下即使邏輯日志標(biāo)志為已備份但是仍然是不可使用的，包括：該邏輯日志包含活動(dòng)的事務(wù)信息，由于數(shù)據(jù)庫(kù)需要考慮其可能的回滾操作，因此是不會(huì)讓該邏輯日志的內(nèi)容被覆蓋的，可以通過(guò)

onstat–x檢查其

beginlg來(lái)確定事務(wù)的邏輯日志起始位置；包含檢查點(diǎn)信息，可以通過(guò)

onstat–l觀察

flags的最后一位為

L的邏輯日志的位置，在它之后的邏輯日志即使已經(jīng)備份也是不可使用的，因?yàn)檫@些邏輯日志內(nèi)容將會(huì)在快速恢復(fù)中使用到。在這些情況出現(xiàn)以后如果暫時(shí)不能快速的處理，可以使用邏輯日志聯(lián)機(jī)增加的功能，只要有空閑的

chunk空間，即可在當(dāng)前邏輯日志后增加新的邏輯日志，并且不需要執(zhí)行

0級(jí)備份。邏輯日志滿(mǎn)Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第15頁(yè)!故障分析：數(shù)據(jù)庫(kù)在進(jìn)行修改操作的時(shí)候?yàn)榱朔乐蛊渌脩?hù)的同時(shí)修改，都會(huì)在修改所涉及的數(shù)據(jù)上設(shè)置對(duì)應(yīng)的鎖，如果其他用戶(hù)再訪(fǎng)問(wèn)到這些已經(jīng)被放置上鎖的數(shù)據(jù)，就會(huì)出現(xiàn)鎖失敗。例如如果需要知道在指定的表上是有哪些用戶(hù)具體占用了鎖，可以通過(guò)以下的方式查看：執(zhí)行

onstat–u來(lái)獲得實(shí)際的

session信息，從中就可以找到鎖的擁有者。

頻繁的鎖沖突Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第16頁(yè)!故障處理：調(diào)整數(shù)據(jù)庫(kù)隔離級(jí)別，例如使用

dirtyread，將數(shù)據(jù)庫(kù)表的缺省頁(yè)級(jí)鎖修改為行級(jí)鎖；設(shè)置鎖等待時(shí)間；調(diào)整應(yīng)用SQL，提高執(zhí)行效率，盡量快的完成事務(wù)處理，釋放資源；如果需要快速處理鎖沖突的情況，在確定鎖的實(shí)際擁有者以后可以確定是否應(yīng)該終止其操作，執(zhí)行

onmode–z<sid>Killspecifiedsessionid，以達(dá)到釋放鎖資源的目的。頻繁的鎖沖突Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第17頁(yè)!故障處理：根據(jù)數(shù)據(jù)庫(kù)日志里面所提供的信息可以很方便的發(fā)現(xiàn)具體是哪一個(gè)事務(wù)造成了長(zhǎng)事務(wù)。系統(tǒng)在將某個(gè)事務(wù)判定為長(zhǎng)事務(wù)以后就會(huì)自動(dòng)對(duì)其進(jìn)行回滾操作。事后可以有針對(duì)性的調(diào)整應(yīng)用將大的事務(wù)劃分為小事務(wù)進(jìn)行提交；避免一個(gè)活動(dòng)事務(wù)長(zhǎng)時(shí)間沒(méi)有后續(xù)的操作；提供充足的邏輯日志空間，這里所指出的不僅是空間的總量需要增加，邏輯日志的個(gè)數(shù)也是應(yīng)該增加的，因?yàn)榕袛嗟臉?biāo)準(zhǔn)是以邏輯日志的使用個(gè)數(shù)所占比例來(lái)確定的。在

INFORMIX9.3X以后的版本中可以通過(guò)動(dòng)態(tài)增加邏輯日志的手段避免由于長(zhǎng)事務(wù)帶來(lái)的一些不良影響，在長(zhǎng)事務(wù)回滾過(guò)程中如果邏輯日志空間被消耗完畢，如果

DYNAMIC_LOGS設(shè)置為

2，數(shù)據(jù)庫(kù)服務(wù)器會(huì)自動(dòng)在最后創(chuàng)建的邏輯日志所存在的

dbspace上查找空余空間，按照最后創(chuàng)建的邏輯日志的大小自動(dòng)在當(dāng)前邏輯日志之后新增邏輯日志，如果不能滿(mǎn)足需要?jiǎng)t會(huì)創(chuàng)建失敗，需要管理員手工添加。長(zhǎng)事務(wù)Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第18頁(yè)!故障處理：根據(jù)前面所列出的可能性逐一進(jìn)行檢查。一個(gè)快速確定存儲(chǔ)設(shè)備是否可用的辦法是：使用

dd命令實(shí)際讀取該設(shè)備，這里需要強(qiáng)調(diào)的是只能做讀取操作，不能寫(xiě)入，嚴(yán)禁在

of設(shè)備項(xiàng)指定為

chunk路徑，因此我們也只能驗(yàn)證其存儲(chǔ)設(shè)備是否可讀，例如：ddif=/home/informix/940/dsk/data_chk1of=/dev/nullbs=2048k

在確定所有硬件或設(shè)置都已經(jīng)恢復(fù)正常以后，可以首先嘗試使用

onspaces–s進(jìn)行恢復(fù)，如果還不能恢復(fù)成功，請(qǐng)聯(lián)系

IBM相關(guān)人員技術(shù)支持。數(shù)據(jù)庫(kù)

chunk出現(xiàn)異常，I/O失敗Informix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第19頁(yè)!1）導(dǎo)出數(shù)據(jù)庫(kù)中所有的表結(jié)構(gòu)到文件db.sql

$dbschema-dyour_database-talldb.sql2)導(dǎo)出數(shù)據(jù)庫(kù)中所有的存儲(chǔ)過(guò)程到文件db.sql

$dbschema-dyour_database-falldb.sql3）導(dǎo)出數(shù)據(jù)庫(kù)中的所有對(duì)象（包含表，存儲(chǔ)過(guò)程，觸發(fā)器。。。）到文件db.sql

$dbschema-dyour_databasedb.sql4)導(dǎo)出數(shù)據(jù)庫(kù)中一個(gè)表的結(jié)構(gòu)到文件db.sql

$dbschema-dyour_database_name-tyour_table_namedb.sql5)導(dǎo)出一個(gè)存儲(chǔ)過(guò)程定義到文件db.sql

$dbschema-dyour_database_name-fyour_procedure_namedb.sql6)如果導(dǎo)出更多的表的信息(EXTENT...)

$dbschema-dyour_database_name-ssdb.sql7)導(dǎo)出數(shù)據(jù)庫(kù)中對(duì)用戶(hù)或角色的授權(quán)信息

$dbschema-dyour_database_name-pall

$dbschema-dyour_database_name-rall8)導(dǎo)出數(shù)據(jù)庫(kù)中一個(gè)表的詳細(xì)結(jié)構(gòu)到文件db.sql

$dbschema-d【your_database_name】-t【your_table_name】-ss【db.sql】dbschema常用命令I(lǐng)nformix常見(jiàn)錯(cuò)誤處理思路共25頁(yè)，您現(xiàn)在瀏覽的是第20頁(yè)!Informix的應(yīng)用案例

接下來(lái)，我們以一個(gè)主機(jī)數(shù)