戰(zhàn)：disable_jit參數(shù)與匿名塊數(shù)組越界異常處理)
前段時(shí)間在一臺 Linux 服務(wù)器上做 DM8 單機(jī)實(shí)例部署順手把表空間、用戶、權(quán)限、基礎(chǔ)表這些對象創(chuàng)建流程都走了一遍最后用匿名塊批量造數(shù)時(shí)撞上了一個(gè)數(shù)組越界異常。整個(gè)過程里讓我花時(shí)間最多的地方反而不是官方文檔寫得很全的部署步驟而是disable_jit這個(gè)參數(shù)和 JAVA 內(nèi)嵌函數(shù)之間的關(guān)系以及 DM 管理工具自身的 JAVA 運(yùn)行環(huán)境問題。這些內(nèi)容分散在文檔的不同章節(jié)里不實(shí)際跑一遍很難把它們串起來。這篇就當(dāng)一份實(shí)操問題記錄寫給正在做 DM8 初始化部署、準(zhǔn)備用 DM 管理工具建基礎(chǔ)對象或者想了解匿名塊異常處理寫法的同行。我盡量把排查路徑、SQL 示例和當(dāng)時(shí)踩坑的原因都交代清楚方便你直接照著復(fù)現(xiàn)或避開。1. 單機(jī)實(shí)例部署中官方文檔容易略過的 disable_jit1.1 先交代部署環(huán)境和基本流程我這次的部署環(huán)境是 Linux x86_648C16G 的虛擬機(jī)DM8 開發(fā)版系統(tǒng)賬號用的dmdba。整體流程和官方《DM8 單機(jī)部署》文檔基本一致解壓安裝包、用dminit初始化實(shí)例、注冊系統(tǒng)服務(wù)、啟動(dòng)實(shí)例、最后用disql驗(yàn)證連接。初始化實(shí)例時(shí)我用的是下面這組參數(shù)./dminit PATH/dm/data PAGE_SIZE8 EXTENT_SIZE16 CASE_SENSITIVEY CHARSET1 PORT_NUM5236這里提醒一下PAGE_SIZE、CASE_SENSITIVE、CHARSET這幾個(gè)參數(shù)一旦初始化完成后面基本改不動(dòng)或者要付出很大代價(jià)去改。CASE_SENSITIVEY表示數(shù)據(jù)庫對象名區(qū)分大小寫CHARSET1表示 UTF-8 字符集。很多從 Oracle 遷過來的同事習(xí)慣性認(rèn)為表名不區(qū)分大小寫恰恰會(huì)在這一步埋下隱患。所以部署階段就確認(rèn)好這些參數(shù)比事后查半天文檔要省事得多。服務(wù)注冊和啟動(dòng)就不多說了按文檔執(zhí)行DmServiceDMSERVER相關(guān)的注冊腳本即可。啟動(dòng)后先用最簡單的方式確認(rèn)實(shí)例狀態(tài)ps -ef | grep dmserver ss -lnt | grep 5236這兩條命令能快速確認(rèn)進(jìn)程是否存活、端口是否在監(jiān)聽。接著用disql SYSDBA/SYSDBAlocalhost:5236登錄能順利進(jìn)入 SQL 提示符說明單機(jī)實(shí)例的基本骨架已經(jīng)搭起來了。1.2 disable_jit 是怎么和 JAVA 內(nèi)嵌函數(shù)扯上關(guān)系的部署完成后我開始做功能驗(yàn)證想建一個(gè)測試用的存儲(chǔ)過程結(jié)果在 disql 里執(zhí)行到涉及 JAVA 靜態(tài)方法調(diào)用的語句時(shí)直接報(bào)錯(cuò)提示內(nèi)容大概是“JAVA 環(huán)境不可用”或“內(nèi)嵌 JAVA 函數(shù)執(zhí)行失敗”。我第一反應(yīng)是系統(tǒng)里 JDK 沒裝好可這臺服務(wù)器明明已經(jīng)裝了 JDK并且java -version完全正常。后來對照官方文檔逐項(xiàng)排查才發(fā)現(xiàn)問題出在dm.ini里的disable_jit參數(shù)。文檔里對它的描述很簡短大致意思是“是否禁用即時(shí)編譯啟用 JIT 后可提升部分復(fù)雜表達(dá)式的執(zhí)行效率”。它被歸在系統(tǒng)參數(shù)那一類部署章節(jié)里基本不會(huì)提到。但實(shí)際環(huán)境下JIT 開啟后會(huì)導(dǎo)致服務(wù)端內(nèi)嵌 JAVA 函數(shù)的執(zhí)行路徑出問題具體表現(xiàn)就是 SQL 里調(diào)用 JAVA 內(nèi)嵌函數(shù)時(shí)功能不可用或直接異常。處理方式很直接把這個(gè)參數(shù)改為 1也就是禁用 JITALTER SYSTEM SET disable_jit1;需要注意不同版本對參數(shù)是否動(dòng)態(tài)生效的定義不太一樣穩(wěn)妥做法是在dm.ini配置文件中直接修改該參數(shù)然后重啟實(shí)例。我這邊就是改完配置文件后重啟再執(zhí)行之前失敗的 SQL功能就恢復(fù)正常了。按官方文檔的說法這個(gè)參數(shù)的本意是性能優(yōu)化但它在某些版本下的實(shí)際影響已經(jīng)超出了性能范疇直接關(guān)系到 JAVA 內(nèi)嵌函數(shù)的可用性。這也是我為什么單獨(dú)把這個(gè)問題拎出來講文檔把參數(shù)歸類在“性能”里但你在功能驗(yàn)證階段就可能會(huì)碰到它。1.3 部署完成后立刻驗(yàn)證的三件事經(jīng)過這次教訓(xùn)我把部署完成后的驗(yàn)證清單固定成了三件事每次裝完 DM8 都會(huì)先跑一遍用disql正常登錄并執(zhí)行SELECT * FROM V$VERSION;確認(rèn)版本符合預(yù)期。調(diào)用一個(gè)簡單內(nèi)置包確認(rèn) JAVA 相關(guān)鏈路正常比如SELECT DBMS_RANDOM.VALUE FROM DUAL;。如果這一步拋出異常優(yōu)先回頭看disable_jit。檢查dm.ini里的CASE_SENSITIVE、CHARSET、disable_jit是否和初始化設(shè)計(jì)一致。這三件事看著簡單但都能在五分鐘內(nèi)幫你定位部署階段最典型的幾類問題實(shí)例沒起來、參數(shù)配置不對、JAVA 鏈路異常。2. DM 管理工具連接與 JAVA 運(yùn)行環(huán)境的連帶問題2.1 管理工具連不上實(shí)例時(shí)的排查順序?qū)嵗渴鸷昧私酉聛硪?DM 管理工具做圖形化操作。我第一次連的時(shí)候也踩了坑工具一直提示連接失敗。很多人的第一反應(yīng)是查網(wǎng)絡(luò)、查防火墻但實(shí)際上對于本機(jī)或同網(wǎng)段訪問網(wǎng)絡(luò)通常不是首要嫌疑。我的排查順序是這樣的先確認(rèn)實(shí)例服務(wù)和端口沒問題也就是前面提到的ps和ss兩條命令再確認(rèn)賬號口令是否正確然后看數(shù)據(jù)庫服務(wù)端字符集和客戶端字符集是否匹配最后才看網(wǎng)絡(luò)和防火墻。DM 管理工具的連接配置其實(shí)很簡單主機(jī)名、端口、用戶名、口令端口默認(rèn) 5236。如果連接時(shí)報(bào)“網(wǎng)絡(luò)通信失敗”之外的其他錯(cuò)誤比如登錄被拒絕、口令錯(cuò)誤那多半是賬號權(quán)限或密碼策略問題這類錯(cuò)誤信息已經(jīng)寫得很明確了照著改就行。真正容易忽略的是服務(wù)端和客戶端的字符集不一致導(dǎo)致的亂碼或連接異常這個(gè)在創(chuàng)建實(shí)例時(shí)就應(yīng)該提前想好。2.2 管理工具自身也是 JAVA 應(yīng)用資源不足會(huì)連坐這里要特別說一個(gè)容易和第一節(jié)問題混淆的地方DM 管理工具是 JAVA 寫的圖形客戶端它自身需要一套可用的 JAVA 運(yùn)行環(huán)境。如果服務(wù)器或本機(jī)的默認(rèn) JDK 版本比較亂工具可能啟動(dòng)不了、界面空白甚至連上后操作一會(huì)兒就卡死。我當(dāng)初把管理工具啟動(dòng)不了的問題誤判成數(shù)據(jù)庫實(shí)例問題排查了半天。后來發(fā)現(xiàn)是系統(tǒng)默認(rèn)的 JAVA 版本和管理工具自帶的 JRE 不一致導(dǎo)致。處理方式有兩種一是直接用安裝包自帶的 JRE二是在管理工具啟動(dòng)腳本里顯式指定 JAVA 路徑。如果你的管理工具在操作大對象或跑復(fù)雜 SQL 時(shí)卡頓也可以適當(dāng)調(diào)大啟動(dòng)腳本里的-Xmx參數(shù)給 JVM 分配更多內(nèi)存。這里和服務(wù)器端disable_jit參數(shù)是兩條獨(dú)立的 JAVA 鏈路服務(wù)器端管的是數(shù)據(jù)庫進(jìn)程內(nèi)嵌 JAVA 虛擬機(jī)管理工具管的是客戶端進(jìn)程自己的 JVM排查時(shí)不要混在一起。2.3 我的習(xí)慣管理工具建對象disql 跑腳本在實(shí)際操作中我通常把 DM 管理工具和 disql 分開用管理工具適合單對象創(chuàng)建、查看表結(jié)構(gòu)、圖形化授權(quán)、查看執(zhí)行計(jì)劃disql 適合跑批量腳本、反復(fù)執(zhí)行匿名塊、驗(yàn)證異常處理邏輯。原因很簡單管理工具雖然方便但在處理大量腳本時(shí)復(fù)制粘貼和錯(cuò)誤定位都不如命令行順手。特別是匿名塊這類帶異常處理的過程性代碼在 disql 里跑能看到更完整的錯(cuò)誤輸出出問題時(shí)也更容易復(fù)現(xiàn)。所以我接下來的基礎(chǔ)對象創(chuàng)建雖然都在管理工具里操作但關(guān)鍵 SQL 我都是先在文本編輯器里寫好后再粘貼到工具或 disql 里執(zhí)行。3. 基礎(chǔ)對象創(chuàng)建的標(biāo)準(zhǔn)順序表空間先行、用戶權(quán)限隨后3.1 為什么先建表空間而不是先建用戶達(dá)夢里創(chuàng)建用戶時(shí)需要指定默認(rèn)表空間所以建表空間必須先于用戶創(chuàng)建。這個(gè)順序如果搞反了后面再調(diào)整用戶默認(rèn)表空間會(huì)麻煩很多。我創(chuàng)建了一個(gè)獨(dú)立表空間MYTBS專門給業(yè)務(wù)用戶zm使用CREATE TABLESPACE MYTBS DATAFILE /dm/data/DMSERVER/MYTBS01.DBF SIZE 512 AUTOEXTEND ON NEXT 64 MAXSIZE 2048;這里SIZE 512表示初始大小 512MBAUTOEXTEND ON NEXT 64表示每次自動(dòng)擴(kuò)展 64MBMAXSIZE 2048表示上限 2048MB。如果你不建獨(dú)立表空間業(yè)務(wù)對象會(huì)默認(rèn)落在 MAIN 表空間和系統(tǒng)對象混在一起。一旦后續(xù)要遷移數(shù)據(jù)、清理表空間就會(huì)變得非常被動(dòng)。表空間建好之后建議用管理工具左側(cè)樹形菜單刷新一下確認(rèn)MYTBS狀態(tài)正常。如果數(shù)據(jù)文件路徑不存在創(chuàng)建會(huì)直接報(bào)錯(cuò)這種情況優(yōu)先檢查目錄權(quán)限確保dmdba用戶對目標(biāo)目錄有寫權(quán)限。3.2 創(chuàng)建業(yè)務(wù)用戶 zm 并做最小授權(quán)表空間就緒后創(chuàng)建用戶CREATE USER ZM IDENTIFIED BY ZhongWenPwd2024 DEFAULT TABLESPACE MYTBS;這里有一個(gè)細(xì)節(jié)DM 在CASE_SENSITIVEY的情況下用戶名和口令的大小寫都是敏感的。如果你把口令用雙引號包起來口令會(huì)嚴(yán)格按照大小寫存儲(chǔ)如果不加雙引號口令會(huì)被統(tǒng)一轉(zhuǎn)為大寫。很多連接失敗的問題就是口令大小寫沒有對上。創(chuàng)建用戶之后做權(quán)限授予我的原則是最小授權(quán)絕不直接給 DBA 角色。這次我只是用zm做基礎(chǔ)對象創(chuàng)建和造數(shù)測試所以給了以下權(quán)限GRANT RESOURCE TO ZM; GRANT CREATE TABLE TO ZM; GRANT CREATE VIEW TO ZM; GRANT CREATE PROCEDURE TO ZM; GRANT CREATE SEQUENCE TO ZM;RESOURCE角色在達(dá)夢里已經(jīng)包含了建表、建索引等基礎(chǔ)權(quán)限額外再顯式加CREATE VIEW、CREATE PROCEDURE是保證后續(xù)測試時(shí)不會(huì)因?yàn)槿睓?quán)限中斷。生產(chǎn)環(huán)境建議在業(yè)務(wù)用戶上只保留剛夠用的權(quán)限能不動(dòng)RESOURCE就不要?jiǎng)右驗(yàn)樗倪吔绯３１饶阆胂蟮拇蟆?.3 建一張用于后續(xù)驗(yàn)證的基礎(chǔ)表 ZS_RESULT_TEST有了用戶和權(quán)限接下來創(chuàng)建測試表。我建的是ZM.ZS_RESULT_TEST專門用于后面的批量造數(shù)和異常處理驗(yàn)證CREATE TABLE ZM.ZS_RESULT_TEST( ID INT PRIMARY KEY, COL_NAME VARCHAR(100), COL_SCORE NUMBER(6,2), CREATE_TIME TIMESTAMP DEFAULT SYSDATE );字段設(shè)計(jì)很簡單ID 主鍵COL_NAME 存隨機(jī)字符串COL_SCORE 存分?jǐn)?shù)CREATE_TIME 存插入時(shí)間。這里我特意讓 CREATE_TIME 有默認(rèn)值方便在造數(shù)時(shí)少寫一個(gè)字段。建表后記得查一下表的歸屬和表空間SELECT OWNER, TABLE_NAME, TABLESPACE_NAME FROM USER_TABLES WHERE TABLE_NAME ZS_RESULT_TEST;如果當(dāng)時(shí)連接的用戶不是 ZM看到的可能就是空結(jié)果。這個(gè)不需要驚訝是權(quán)限視角的問題。表默認(rèn)會(huì)創(chuàng)建在用戶默認(rèn)表空間 MYTBS 上如果你希望表和索引分開存放可以在建表語句里加上TABLESPACE MYTBS和INDEX TABLESPACE MYTBS_IDX之類的指定生產(chǎn)環(huán)境通常會(huì)把表和索引放在不同物理文件或者不同磁盤上以降低 IO 競爭。到這里基礎(chǔ)對象創(chuàng)建的流程就閉環(huán)了表空間 - 用戶 - 權(quán)限 - 表。每一步都依賴前一步的結(jié)果順序錯(cuò)了就會(huì)遇到“權(quán)限不足”或“默認(rèn)表空間不存在”這類問題。4. For 循環(huán)與關(guān)聯(lián)數(shù)組批量造數(shù)Good 案例復(fù)盤4.1 造數(shù)場景與常見寫法的差異基礎(chǔ)表建好后我需要往里插入大量測試數(shù)據(jù)大概十萬行左右。字段要求帶隨機(jī)字符串、隨機(jī)分?jǐn)?shù)和時(shí)間戳用來做后續(xù)查詢性能驗(yàn)證。很多人第一反應(yīng)是寫一個(gè)簡單的循環(huán)逐行 INSERT比如FOR I IN 1..100000 LOOP INSERT ...; END LOOP;。但如果你在循環(huán)里不做任何提交最后統(tǒng)一 COMMIT這種方式本身沒問題問題在于它不夠靈活而且邊界條件寫錯(cuò)時(shí)連異常都來不及處理。我當(dāng)時(shí)用的是 FOR 循環(huán)加關(guān)聯(lián)數(shù)組的寫法先把主鍵 ID 放進(jìn)一個(gè)數(shù)組里再遍歷數(shù)組執(zhí)行插入DECLARE TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_TOTAL INT : 100000; BEGIN FOR I IN 1..V_TOTAL LOOP V_IDS(I) : I; END LOOP; FOR IND IN 1..V_IDS.COUNT LOOP INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME, COL_SCORE) VALUES(V_IDS(IND), DBMS_RANDOM.STRING(U, 10), ROUND(DBMS_RANDOM.VALUE(60, 100), 2)); END LOOP; COMMIT; END; /這段代碼里DBMS_RANDOM.STRING(U, 10)生成 10 位大寫隨機(jī)字符串DBMS_RANDOM.VALUE(60, 100)生成 60 到 100 之間的隨機(jī)數(shù)外層再用ROUND(..., 2)保留兩位小數(shù)。4.2 為什么這是 Good 案例這個(gè)寫法好在三個(gè)地方。第一循環(huán)上界用的是V_IDS.COUNT不是硬編碼的 100000。數(shù)組元素是前面一個(gè)循環(huán)動(dòng)態(tài)填充的這樣即使總數(shù)變了遍歷邏輯也不需要改。第二先把所有 ID 準(zhǔn)備好再統(tǒng)一插入數(shù)據(jù)源可控適合后面追加其他隨機(jī)字段。第三整個(gè)匿名塊內(nèi)的事務(wù)邊界很清晰要么全部提交要么全部回滾不會(huì)出現(xiàn)插了一半數(shù)據(jù)再手工清理的尷尬局面。當(dāng)然如果你只是為了快速造數(shù)不管字段內(nèi)容多復(fù)雜SQL 層面還有更快的方法比如INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME, COL_SCORE) SELECT LEVEL, DBMS_RANDOM.STRING(U, 10), ROUND(DBMS_RANDOM.VALUE(60, 100), 2) FROM DUAL CONNECT BY LEVEL 100000;這種寫法比 FOR 循環(huán)要快不少因?yàn)樗谝淮?SQL 語句里完成所有數(shù)據(jù)生成。但它的短板也明顯一旦你要對每一條數(shù)據(jù)做不同的邏輯處理或者根據(jù)外部變量決定是否插入純 SQL 就力不從心了。FOR 循環(huán)加關(guān)聯(lián)數(shù)組的定位是“可編程的批量造數(shù)”適合那些數(shù)據(jù)生成規(guī)則復(fù)雜的場景。4.3 這個(gè)寫法最常見的隱患循環(huán)邊界越界回到 FOR 循環(huán)寫法的隱患最典型的就是數(shù)組下標(biāo)越界。達(dá)夢的關(guān)聯(lián)數(shù)組下標(biāo)默認(rèn)從 1 開始這一點(diǎn)和 Oracle 一致。如果你下意識寫了FOR IND IN 0..V_IDS.COUNT第一次循環(huán)就會(huì)訪問V_IDS(0)而數(shù)組里根本沒有這個(gè)下標(biāo)的元素直接觸發(fā)數(shù)組上界越界異常。還有一種更隱蔽的情況如果V_IDS是空數(shù)組V_IDS.COUNT等于 0此時(shí)FOR IND IN 1..0這種遞減區(qū)間在達(dá)夢里同樣是非法操作。這些邊界問題在沒有異常處理塊包裹時(shí)整個(gè)匿名塊會(huì)直接中斷之前已經(jīng)執(zhí)行成功的 INSERT 全部回滾。這也是為什么我每次寫匿名塊之前都會(huì)先提醒自己循環(huán)邊界和異常處理至少要有一個(gè)是靠譜的。最穩(wěn)的做法是兩個(gè)都做也就是接下來要講的內(nèi)容。5. 越界異常 NUO_ARRAY_EXCEPTION 的完整排查與異常處理塊改造5.1 先把錯(cuò)誤現(xiàn)場完整撈出來為了驗(yàn)證越界問題我故意寫了一個(gè)從 0 開始的循環(huán)DECLARE TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_IND INT; BEGIN FOR I IN 1..100 LOOP V_IDS(I) : I; END LOOP; FOR V_IND IN 0..V_IDS.COUNT LOOP NULL; END LOOP; END; /執(zhí)行后disql 給出的報(bào)錯(cuò)信息包含兩個(gè)關(guān)鍵內(nèi)容錯(cuò)誤碼和錯(cuò)誤描述。我這邊看到的是數(shù)組上界越界 NUO_ARRAY_EXCEPTION對應(yīng)的錯(cuò)誤碼為-4029。這個(gè)環(huán)節(jié)最重要的是先確認(rèn)錯(cuò)誤碼因?yàn)楹竺娴漠惓Ｌ幚韷K要根據(jù)錯(cuò)誤碼來做精確捕獲。定位時(shí)我先把循環(huán)體改成NULL最小化出錯(cuò)范圍確認(rèn)問題不在 INSERT 語句本身而是循環(huán)到達(dá)V_IDS(0)時(shí)才觸發(fā)。接著把起點(diǎn)改成 1異常立刻消失。這就能確認(rèn)是下標(biāo)越界而不是表結(jié)構(gòu)或權(quán)限問題。5.2 用 DECLARE...BEGIN...EXCEPTION...END 改造匿名塊達(dá)夢的 PLSQL 匿名塊和 Oracle 類似整體結(jié)構(gòu)是DECLARE 變量聲明、異常聲明 BEGIN 業(yè)務(wù)邏輯 EXCEPTION 異常處理邏輯 END;或DECLARE ... BEGIN ... EXCEPTION ... END; /EXCEPTION段就是專門承接異常處理的 SECTION。異常發(fā)生時(shí)控制權(quán)會(huì)跳到這一段。我先用最通用的WHEN OTHERS把錯(cuò)誤撈出來寫進(jìn)日志表先建一張錯(cuò)誤日志表CREATE TABLE ZM.ERR_LOG( ID BIGINT IDENTITY(1,1) PRIMARY KEY, ERR_CODE INT, ERR_MSG VARCHAR(500), OCCUR_TIME TIMESTAMP );然后是帶異常處理的匿名塊DECLARE TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_IND INT; V_ERR_CODE INT; V_ERR_MSG VARCHAR(500); BEGIN FOR I IN 1..10 LOOP V_IDS(I) : I; END LOOP; FOR V_IND IN 0..V_IDS.COUNT LOOP INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME) VALUES(V_IDS(V_IND), TEST_ || V_IND); END LOOP; COMMIT; EXCEPTION WHEN OTHERS THEN V_ERR_CODE : SQLCODE; V_ERR_MSG : SQLERRM; INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(V_ERR_CODE, V_ERR_MSG, SYSDATE); ROLLBACK; END; /執(zhí)行后雖然 INSERT 沒有成功但ERR_LOG表里會(huì)多一條記錄把-4029這個(gè)錯(cuò)誤碼和對應(yīng)的錯(cuò)誤消息完整記錄下來。這個(gè)習(xí)慣非常重要尤其是在匿名塊比較長、業(yè)務(wù)邏輯復(fù)雜時(shí)沒有日志幾乎等于瞎猜。5.3 PRAGMA EXCEPTION_INIT 綁定具名異常如果你想針對某個(gè)特定錯(cuò)誤碼做不同的處理可以在聲明段用PRAGMA EXCEPTION_INIT把錯(cuò)誤碼綁定到一個(gè)具名異常上DECLARE NUO_ARRAY_EXCEPTION EXCEPTION; PRAGMA EXCEPTION_INIT(NUO_ARRAY_EXCEPTION, -4029); TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_IND INT; BEGIN FOR I IN 1..10 LOOP V_IDS(I) : I; END LOOP; FOR V_IND IN 0..V_IDS.COUNT LOOP INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME) VALUES(V_IDS(V_IND), TEST_ || V_IND); END LOOP; COMMIT; EXCEPTION WHEN NUO_ARRAY_EXCEPTION THEN INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(-4029, 數(shù)組下標(biāo)越界請檢查循環(huán)起點(diǎn)和邊界, SYSDATE); ROLLBACK; WHEN OTHERS THEN INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(SQLCODE, SQLERRM, SYSDATE); ROLLBACK; END; /這里PRAGMA EXCEPTION_INIT(NUO_ARRAY_EXCEPTION, -4029)的含義是把錯(cuò)誤碼-4029綁定到自定義異常名NUO_ARRAY_EXCEPTION上。之后在EXCEPTION段就可以用WHEN NUO_ARRAY_EXCEPTION精確捕獲這個(gè)錯(cuò)誤而不會(huì)被WHEN OTHERS搶先接走。要注意PRAGMA EXCEPTION_INIT必須放在聲明段并且要在變量聲明之后、BEGIN之前。綁定時(shí)錯(cuò)誤碼要和實(shí)際報(bào)錯(cuò)一致不同小版本下錯(cuò)誤碼可能有差異保險(xiǎn)做法是先用WHEN OTHERS配合SQLCODE查一次實(shí)際錯(cuò)誤碼再?zèng)Q定綁定值。如果你不想用具名異常也可以直接在WHEN OTHERS里判斷SQLCODE -4029后做分支處理。兩種方式效果類似區(qū)別在于具名異常在代碼可讀性上更好適合同一段邏輯里對不同錯(cuò)誤做差異化響應(yīng)的場景。5.4 實(shí)際處理策略繼續(xù)執(zhí)行還是整體回滾最后一個(gè)關(guān)鍵問題異常發(fā)生后業(yè)務(wù)到底是繼續(xù)還是中斷。這取決于場景。如果是一次性造數(shù)任務(wù)推薦在EXCEPTION段記錄日志后整體回滾修正代碼再跑。因?yàn)闇y試數(shù)據(jù)要求完整性部分插入會(huì)導(dǎo)致后續(xù)統(tǒng)計(jì)結(jié)果失真。如果你在做批量數(shù)據(jù)加工希望跳過壞數(shù)據(jù)處理后續(xù)數(shù)據(jù)就不要在頂層用大而全的異常塊而是把異常處理下沉到循環(huán)內(nèi)部。在循環(huán)體里再套一個(gè)內(nèi)層 BEGIN...EXCEPTION 塊FOR V_IND IN 1..V_COUNT LOOP BEGIN INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME) VALUES(V_IDS(V_IND), TEST_ || V_IND); EXCEPTION WHEN OTHERS THEN INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(SQLCODE, SQLERRM, SYSDATE); CONTINUE; END; END LOOP;內(nèi)層捕獲異常后CONTINUE循環(huán)會(huì)繼續(xù)跑但外層不會(huì)感知到這條失敗記錄。如果你希望內(nèi)層失敗只記錄、最終整體仍然回滾可以在內(nèi)層異常處理中不做提交并在循環(huán)結(jié)束后判斷日志表是否有新增記錄再?zèng)Q定是否 ROLLBACK。這算是我實(shí)際項(xiàng)目中用得比較多的處理思路邏輯清晰也方便事后核對失敗數(shù)據(jù)。狀態(tài)比較理想的結(jié)構(gòu)是一個(gè)可重復(fù)執(zhí)行的匿名塊內(nèi)層負(fù)責(zé)單條數(shù)據(jù)的失敗跳過和數(shù)據(jù)記錄外層負(fù)責(zé)事務(wù)邊界和最終提交決策。這樣無論造數(shù)還是批量加工都能在出問題時(shí)快速定位到具體數(shù)據(jù)而不是整體黑屏。最后分享一個(gè)實(shí)際體會(huì)這一輪操作下來我最大的收獲是把部署檢查清單從“能啟動(dòng)就算成功”改成了“啟動(dòng)后必須驗(yàn)證關(guān)鍵功能鏈路”。disable_jit這種藏在性能參數(shù)里的開關(guān)不實(shí)際執(zhí)行 JAVA 內(nèi)嵌函數(shù)調(diào)用根本發(fā)現(xiàn)不了問題匿名塊也盡量從一開始就包好異常處理日志表提前建好不要等報(bào)錯(cuò)后再補(bǔ)。造數(shù)這種看起來簡單的需求往往就是循環(huán)邊界和異常處理這種小地方最容易翻車。 DM8部署實(shí)戰(zhàn)：disable_jit參數(shù)與匿名塊數(shù)組越界異常處理
前段時(shí)間在一臺 Linux 服務(wù)器上做 DM8 單機(jī)實(shí)例部署順手把表空間、用戶、權(quán)限、基礎(chǔ)表這些對象創(chuàng)建流程都走了一遍最后用匿名塊批量造數(shù)時(shí)撞上了一個(gè)數(shù)組越界異常。整個(gè)過程里讓我花時(shí)間最多的地方反而不是官方文檔寫得很全的部署步驟而是disable_jit這個(gè)參數(shù)和 JAVA 內(nèi)嵌函數(shù)之間的關(guān)系以及 DM 管理工具自身的 JAVA 運(yùn)行環(huán)境問題。這些內(nèi)容分散在文檔的不同章節(jié)里不實(shí)際跑一遍很難把它們串起來。這篇就當(dāng)一份實(shí)操問題記錄寫給正在做 DM8 初始化部署、準(zhǔn)備用 DM 管理工具建基礎(chǔ)對象或者想了解匿名塊異常處理寫法的同行。我盡量把排查路徑、SQL 示例和當(dāng)時(shí)踩坑的原因都交代清楚方便你直接照著復(fù)現(xiàn)或避開。1. 單機(jī)實(shí)例部署中官方文檔容易略過的 disable_jit1.1 先交代部署環(huán)境和基本流程我這次的部署環(huán)境是 Linux x86_648C16G 的虛擬機(jī)DM8 開發(fā)版系統(tǒng)賬號用的dmdba。整體流程和官方《DM8 單機(jī)部署》文檔基本一致解壓安裝包、用dminit初始化實(shí)例、注冊系統(tǒng)服務(wù)、啟動(dòng)實(shí)例、最后用disql驗(yàn)證連接。初始化實(shí)例時(shí)我用的是下面這組參數(shù)./dminit PATH/dm/data PAGE_SIZE8 EXTENT_SIZE16 CASE_SENSITIVEY CHARSET1 PORT_NUM5236這里提醒一下PAGE_SIZE、CASE_SENSITIVE、CHARSET這幾個(gè)參數(shù)一旦初始化完成后面基本改不動(dòng)或者要付出很大代價(jià)去改。CASE_SENSITIVEY表示數(shù)據(jù)庫對象名區(qū)分大小寫CHARSET1表示 UTF-8 字符集。很多從 Oracle 遷過來的同事習(xí)慣性認(rèn)為表名不區(qū)分大小寫恰恰會(huì)在這一步埋下隱患。所以部署階段就確認(rèn)好這些參數(shù)比事后查半天文檔要省事得多。服務(wù)注冊和啟動(dòng)就不多說了按文檔執(zhí)行DmServiceDMSERVER相關(guān)的注冊腳本即可。啟動(dòng)后先用最簡單的方式確認(rèn)實(shí)例狀態(tài)ps -ef | grep dmserver ss -lnt | grep 5236這兩條命令能快速確認(rèn)進(jìn)程是否存活、端口是否在監(jiān)聽。接著用disql SYSDBA/SYSDBAlocalhost:5236登錄能順利進(jìn)入 SQL 提示符說明單機(jī)實(shí)例的基本骨架已經(jīng)搭起來了。1.2 disable_jit 是怎么和 JAVA 內(nèi)嵌函數(shù)扯上關(guān)系的部署完成后我開始做功能驗(yàn)證想建一個(gè)測試用的存儲(chǔ)過程結(jié)果在 disql 里執(zhí)行到涉及 JAVA 靜態(tài)方法調(diào)用的語句時(shí)直接報(bào)錯(cuò)提示內(nèi)容大概是“JAVA 環(huán)境不可用”或“內(nèi)嵌 JAVA 函數(shù)執(zhí)行失敗”。我第一反應(yīng)是系統(tǒng)里 JDK 沒裝好可這臺服務(wù)器明明已經(jīng)裝了 JDK并且java -version完全正常。后來對照官方文檔逐項(xiàng)排查才發(fā)現(xiàn)問題出在dm.ini里的disable_jit參數(shù)。文檔里對它的描述很簡短大致意思是“是否禁用即時(shí)編譯啟用 JIT 后可提升部分復(fù)雜表達(dá)式的執(zhí)行效率”。它被歸在系統(tǒng)參數(shù)那一類部署章節(jié)里基本不會(huì)提到。但實(shí)際環(huán)境下JIT 開啟后會(huì)導(dǎo)致服務(wù)端內(nèi)嵌 JAVA 函數(shù)的執(zhí)行路徑出問題具體表現(xiàn)就是 SQL 里調(diào)用 JAVA 內(nèi)嵌函數(shù)時(shí)功能不可用或直接異常。處理方式很直接把這個(gè)參數(shù)改為 1也就是禁用 JITALTER SYSTEM SET disable_jit1;需要注意不同版本對參數(shù)是否動(dòng)態(tài)生效的定義不太一樣穩(wěn)妥做法是在dm.ini配置文件中直接修改該參數(shù)然后重啟實(shí)例。我這邊就是改完配置文件后重啟再執(zhí)行之前失敗的 SQL功能就恢復(fù)正常了。按官方文檔的說法這個(gè)參數(shù)的本意是性能優(yōu)化但它在某些版本下的實(shí)際影響已經(jīng)超出了性能范疇直接關(guān)系到 JAVA 內(nèi)嵌函數(shù)的可用性。這也是我為什么單獨(dú)把這個(gè)問題拎出來講文檔把參數(shù)歸類在“性能”里但你在功能驗(yàn)證階段就可能會(huì)碰到它。1.3 部署完成后立刻驗(yàn)證的三件事經(jīng)過這次教訓(xùn)我把部署完成后的驗(yàn)證清單固定成了三件事每次裝完 DM8 都會(huì)先跑一遍用disql正常登錄并執(zhí)行SELECT * FROM V$VERSION;確認(rèn)版本符合預(yù)期。調(diào)用一個(gè)簡單內(nèi)置包確認(rèn) JAVA 相關(guān)鏈路正常比如SELECT DBMS_RANDOM.VALUE FROM DUAL;。如果這一步拋出異常優(yōu)先回頭看disable_jit。檢查dm.ini里的CASE_SENSITIVE、CHARSET、disable_jit是否和初始化設(shè)計(jì)一致。這三件事看著簡單但都能在五分鐘內(nèi)幫你定位部署階段最典型的幾類問題實(shí)例沒起來、參數(shù)配置不對、JAVA 鏈路異常。2. DM 管理工具連接與 JAVA 運(yùn)行環(huán)境的連帶問題2.1 管理工具連不上實(shí)例時(shí)的排查順序?qū)嵗渴鸷昧私酉聛硪?DM 管理工具做圖形化操作。我第一次連的時(shí)候也踩了坑工具一直提示連接失敗。很多人的第一反應(yīng)是查網(wǎng)絡(luò)、查防火墻但實(shí)際上對于本機(jī)或同網(wǎng)段訪問網(wǎng)絡(luò)通常不是首要嫌疑。我的排查順序是這樣的先確認(rèn)實(shí)例服務(wù)和端口沒問題也就是前面提到的ps和ss兩條命令再確認(rèn)賬號口令是否正確然后看數(shù)據(jù)庫服務(wù)端字符集和客戶端字符集是否匹配最后才看網(wǎng)絡(luò)和防火墻。DM 管理工具的連接配置其實(shí)很簡單主機(jī)名、端口、用戶名、口令端口默認(rèn) 5236。如果連接時(shí)報(bào)“網(wǎng)絡(luò)通信失敗”之外的其他錯(cuò)誤比如登錄被拒絕、口令錯(cuò)誤那多半是賬號權(quán)限或密碼策略問題這類錯(cuò)誤信息已經(jīng)寫得很明確了照著改就行。真正容易忽略的是服務(wù)端和客戶端的字符集不一致導(dǎo)致的亂碼或連接異常這個(gè)在創(chuàng)建實(shí)例時(shí)就應(yīng)該提前想好。2.2 管理工具自身也是 JAVA 應(yīng)用資源不足會(huì)連坐這里要特別說一個(gè)容易和第一節(jié)問題混淆的地方DM 管理工具是 JAVA 寫的圖形客戶端它自身需要一套可用的 JAVA 運(yùn)行環(huán)境。如果服務(wù)器或本機(jī)的默認(rèn) JDK 版本比較亂工具可能啟動(dòng)不了、界面空白甚至連上后操作一會(huì)兒就卡死。我當(dāng)初把管理工具啟動(dòng)不了的問題誤判成數(shù)據(jù)庫實(shí)例問題排查了半天。后來發(fā)現(xiàn)是系統(tǒng)默認(rèn)的 JAVA 版本和管理工具自帶的 JRE 不一致導(dǎo)致。處理方式有兩種一是直接用安裝包自帶的 JRE二是在管理工具啟動(dòng)腳本里顯式指定 JAVA 路徑。如果你的管理工具在操作大對象或跑復(fù)雜 SQL 時(shí)卡頓也可以適當(dāng)調(diào)大啟動(dòng)腳本里的-Xmx參數(shù)給 JVM 分配更多內(nèi)存。這里和服務(wù)器端disable_jit參數(shù)是兩條獨(dú)立的 JAVA 鏈路服務(wù)器端管的是數(shù)據(jù)庫進(jìn)程內(nèi)嵌 JAVA 虛擬機(jī)管理工具管的是客戶端進(jìn)程自己的 JVM排查時(shí)不要混在一起。2.3 我的習(xí)慣管理工具建對象disql 跑腳本在實(shí)際操作中我通常把 DM 管理工具和 disql 分開用管理工具適合單對象創(chuàng)建、查看表結(jié)構(gòu)、圖形化授權(quán)、查看執(zhí)行計(jì)劃disql 適合跑批量腳本、反復(fù)執(zhí)行匿名塊、驗(yàn)證異常處理邏輯。原因很簡單管理工具雖然方便但在處理大量腳本時(shí)復(fù)制粘貼和錯(cuò)誤定位都不如命令行順手。特別是匿名塊這類帶異常處理的過程性代碼在 disql 里跑能看到更完整的錯(cuò)誤輸出出問題時(shí)也更容易復(fù)現(xiàn)。所以我接下來的基礎(chǔ)對象創(chuàng)建雖然都在管理工具里操作但關(guān)鍵 SQL 我都是先在文本編輯器里寫好后再粘貼到工具或 disql 里執(zhí)行。3. 基礎(chǔ)對象創(chuàng)建的標(biāo)準(zhǔn)順序表空間先行、用戶權(quán)限隨后3.1 為什么先建表空間而不是先建用戶達(dá)夢里創(chuàng)建用戶時(shí)需要指定默認(rèn)表空間所以建表空間必須先于用戶創(chuàng)建。這個(gè)順序如果搞反了后面再調(diào)整用戶默認(rèn)表空間會(huì)麻煩很多。我創(chuàng)建了一個(gè)獨(dú)立表空間MYTBS專門給業(yè)務(wù)用戶zm使用CREATE TABLESPACE MYTBS DATAFILE /dm/data/DMSERVER/MYTBS01.DBF SIZE 512 AUTOEXTEND ON NEXT 64 MAXSIZE 2048;這里SIZE 512表示初始大小 512MBAUTOEXTEND ON NEXT 64表示每次自動(dòng)擴(kuò)展 64MBMAXSIZE 2048表示上限 2048MB。如果你不建獨(dú)立表空間業(yè)務(wù)對象會(huì)默認(rèn)落在 MAIN 表空間和系統(tǒng)對象混在一起。一旦后續(xù)要遷移數(shù)據(jù)、清理表空間就會(huì)變得非常被動(dòng)。表空間建好之后建議用管理工具左側(cè)樹形菜單刷新一下確認(rèn)MYTBS狀態(tài)正常。如果數(shù)據(jù)文件路徑不存在創(chuàng)建會(huì)直接報(bào)錯(cuò)這種情況優(yōu)先檢查目錄權(quán)限確保dmdba用戶對目標(biāo)目錄有寫權(quán)限。3.2 創(chuàng)建業(yè)務(wù)用戶 zm 并做最小授權(quán)表空間就緒后創(chuàng)建用戶CREATE USER ZM IDENTIFIED BY ZhongWenPwd2024 DEFAULT TABLESPACE MYTBS;這里有一個(gè)細(xì)節(jié)DM 在CASE_SENSITIVEY的情況下用戶名和口令的大小寫都是敏感的。如果你把口令用雙引號包起來口令會(huì)嚴(yán)格按照大小寫存儲(chǔ)如果不加雙引號口令會(huì)被統(tǒng)一轉(zhuǎn)為大寫。很多連接失敗的問題就是口令大小寫沒有對上。創(chuàng)建用戶之后做權(quán)限授予我的原則是最小授權(quán)絕不直接給 DBA 角色。這次我只是用zm做基礎(chǔ)對象創(chuàng)建和造數(shù)測試所以給了以下權(quán)限GRANT RESOURCE TO ZM; GRANT CREATE TABLE TO ZM; GRANT CREATE VIEW TO ZM; GRANT CREATE PROCEDURE TO ZM; GRANT CREATE SEQUENCE TO ZM;RESOURCE角色在達(dá)夢里已經(jīng)包含了建表、建索引等基礎(chǔ)權(quán)限額外再顯式加CREATE VIEW、CREATE PROCEDURE是保證后續(xù)測試時(shí)不會(huì)因?yàn)槿睓?quán)限中斷。生產(chǎn)環(huán)境建議在業(yè)務(wù)用戶上只保留剛夠用的權(quán)限能不動(dòng)RESOURCE就不要?jiǎng)右驗(yàn)樗倪吔绯３１饶阆胂蟮拇蟆?.3 建一張用于后續(xù)驗(yàn)證的基礎(chǔ)表 ZS_RESULT_TEST有了用戶和權(quán)限接下來創(chuàng)建測試表。我建的是ZM.ZS_RESULT_TEST專門用于后面的批量造數(shù)和異常處理驗(yàn)證CREATE TABLE ZM.ZS_RESULT_TEST( ID INT PRIMARY KEY, COL_NAME VARCHAR(100), COL_SCORE NUMBER(6,2), CREATE_TIME TIMESTAMP DEFAULT SYSDATE );字段設(shè)計(jì)很簡單ID 主鍵COL_NAME 存隨機(jī)字符串COL_SCORE 存分?jǐn)?shù)CREATE_TIME 存插入時(shí)間。這里我特意讓 CREATE_TIME 有默認(rèn)值方便在造數(shù)時(shí)少寫一個(gè)字段。建表后記得查一下表的歸屬和表空間SELECT OWNER, TABLE_NAME, TABLESPACE_NAME FROM USER_TABLES WHERE TABLE_NAME ZS_RESULT_TEST;如果當(dāng)時(shí)連接的用戶不是 ZM看到的可能就是空結(jié)果。這個(gè)不需要驚訝是權(quán)限視角的問題。表默認(rèn)會(huì)創(chuàng)建在用戶默認(rèn)表空間 MYTBS 上如果你希望表和索引分開存放可以在建表語句里加上TABLESPACE MYTBS和INDEX TABLESPACE MYTBS_IDX之類的指定生產(chǎn)環(huán)境通常會(huì)把表和索引放在不同物理文件或者不同磁盤上以降低 IO 競爭。到這里基礎(chǔ)對象創(chuàng)建的流程就閉環(huán)了表空間 - 用戶 - 權(quán)限 - 表。每一步都依賴前一步的結(jié)果順序錯(cuò)了就會(huì)遇到“權(quán)限不足”或“默認(rèn)表空間不存在”這類問題。4. For 循環(huán)與關(guān)聯(lián)數(shù)組批量造數(shù)Good 案例復(fù)盤4.1 造數(shù)場景與常見寫法的差異基礎(chǔ)表建好后我需要往里插入大量測試數(shù)據(jù)大概十萬行左右。字段要求帶隨機(jī)字符串、隨機(jī)分?jǐn)?shù)和時(shí)間戳用來做后續(xù)查詢性能驗(yàn)證。很多人第一反應(yīng)是寫一個(gè)簡單的循環(huán)逐行 INSERT比如FOR I IN 1..100000 LOOP INSERT ...; END LOOP;。但如果你在循環(huán)里不做任何提交最后統(tǒng)一 COMMIT這種方式本身沒問題問題在于它不夠靈活而且邊界條件寫錯(cuò)時(shí)連異常都來不及處理。我當(dāng)時(shí)用的是 FOR 循環(huán)加關(guān)聯(lián)數(shù)組的寫法先把主鍵 ID 放進(jìn)一個(gè)數(shù)組里再遍歷數(shù)組執(zhí)行插入DECLARE TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_TOTAL INT : 100000; BEGIN FOR I IN 1..V_TOTAL LOOP V_IDS(I) : I; END LOOP; FOR IND IN 1..V_IDS.COUNT LOOP INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME, COL_SCORE) VALUES(V_IDS(IND), DBMS_RANDOM.STRING(U, 10), ROUND(DBMS_RANDOM.VALUE(60, 100), 2)); END LOOP; COMMIT; END; /這段代碼里DBMS_RANDOM.STRING(U, 10)生成 10 位大寫隨機(jī)字符串DBMS_RANDOM.VALUE(60, 100)生成 60 到 100 之間的隨機(jī)數(shù)外層再用ROUND(..., 2)保留兩位小數(shù)。4.2 為什么這是 Good 案例這個(gè)寫法好在三個(gè)地方。第一循環(huán)上界用的是V_IDS.COUNT不是硬編碼的 100000。數(shù)組元素是前面一個(gè)循環(huán)動(dòng)態(tài)填充的這樣即使總數(shù)變了遍歷邏輯也不需要改。第二先把所有 ID 準(zhǔn)備好再統(tǒng)一插入數(shù)據(jù)源可控適合后面追加其他隨機(jī)字段。第三整個(gè)匿名塊內(nèi)的事務(wù)邊界很清晰要么全部提交要么全部回滾不會(huì)出現(xiàn)插了一半數(shù)據(jù)再手工清理的尷尬局面。當(dāng)然如果你只是為了快速造數(shù)不管字段內(nèi)容多復(fù)雜SQL 層面還有更快的方法比如INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME, COL_SCORE) SELECT LEVEL, DBMS_RANDOM.STRING(U, 10), ROUND(DBMS_RANDOM.VALUE(60, 100), 2) FROM DUAL CONNECT BY LEVEL 100000;這種寫法比 FOR 循環(huán)要快不少因?yàn)樗谝淮?SQL 語句里完成所有數(shù)據(jù)生成。但它的短板也明顯一旦你要對每一條數(shù)據(jù)做不同的邏輯處理或者根據(jù)外部變量決定是否插入純 SQL 就力不從心了。FOR 循環(huán)加關(guān)聯(lián)數(shù)組的定位是“可編程的批量造數(shù)”適合那些數(shù)據(jù)生成規(guī)則復(fù)雜的場景。4.3 這個(gè)寫法最常見的隱患循環(huán)邊界越界回到 FOR 循環(huán)寫法的隱患最典型的就是數(shù)組下標(biāo)越界。達(dá)夢的關(guān)聯(lián)數(shù)組下標(biāo)默認(rèn)從 1 開始這一點(diǎn)和 Oracle 一致。如果你下意識寫了FOR IND IN 0..V_IDS.COUNT第一次循環(huán)就會(huì)訪問V_IDS(0)而數(shù)組里根本沒有這個(gè)下標(biāo)的元素直接觸發(fā)數(shù)組上界越界異常。還有一種更隱蔽的情況如果V_IDS是空數(shù)組V_IDS.COUNT等于 0此時(shí)FOR IND IN 1..0這種遞減區(qū)間在達(dá)夢里同樣是非法操作。這些邊界問題在沒有異常處理塊包裹時(shí)整個(gè)匿名塊會(huì)直接中斷之前已經(jīng)執(zhí)行成功的 INSERT 全部回滾。這也是為什么我每次寫匿名塊之前都會(huì)先提醒自己循環(huán)邊界和異常處理至少要有一個(gè)是靠譜的。最穩(wěn)的做法是兩個(gè)都做也就是接下來要講的內(nèi)容。5. 越界異常 NUO_ARRAY_EXCEPTION 的完整排查與異常處理塊改造5.1 先把錯(cuò)誤現(xiàn)場完整撈出來為了驗(yàn)證越界問題我故意寫了一個(gè)從 0 開始的循環(huán)DECLARE TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_IND INT; BEGIN FOR I IN 1..100 LOOP V_IDS(I) : I; END LOOP; FOR V_IND IN 0..V_IDS.COUNT LOOP NULL; END LOOP; END; /執(zhí)行后disql 給出的報(bào)錯(cuò)信息包含兩個(gè)關(guān)鍵內(nèi)容錯(cuò)誤碼和錯(cuò)誤描述。我這邊看到的是數(shù)組上界越界 NUO_ARRAY_EXCEPTION對應(yīng)的錯(cuò)誤碼為-4029。這個(gè)環(huán)節(jié)最重要的是先確認(rèn)錯(cuò)誤碼因?yàn)楹竺娴漠惓Ｌ幚韷K要根據(jù)錯(cuò)誤碼來做精確捕獲。定位時(shí)我先把循環(huán)體改成NULL最小化出錯(cuò)范圍確認(rèn)問題不在 INSERT 語句本身而是循環(huán)到達(dá)V_IDS(0)時(shí)才觸發(fā)。接著把起點(diǎn)改成 1異常立刻消失。這就能確認(rèn)是下標(biāo)越界而不是表結(jié)構(gòu)或權(quán)限問題。5.2 用 DECLARE...BEGIN...EXCEPTION...END 改造匿名塊達(dá)夢的 PLSQL 匿名塊和 Oracle 類似整體結(jié)構(gòu)是DECLARE 變量聲明、異常聲明 BEGIN 業(yè)務(wù)邏輯 EXCEPTION 異常處理邏輯 END;或DECLARE ... BEGIN ... EXCEPTION ... END; /EXCEPTION段就是專門承接異常處理的 SECTION。異常發(fā)生時(shí)控制權(quán)會(huì)跳到這一段。我先用最通用的WHEN OTHERS把錯(cuò)誤撈出來寫進(jìn)日志表先建一張錯(cuò)誤日志表CREATE TABLE ZM.ERR_LOG( ID BIGINT IDENTITY(1,1) PRIMARY KEY, ERR_CODE INT, ERR_MSG VARCHAR(500), OCCUR_TIME TIMESTAMP );然后是帶異常處理的匿名塊DECLARE TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_IND INT; V_ERR_CODE INT; V_ERR_MSG VARCHAR(500); BEGIN FOR I IN 1..10 LOOP V_IDS(I) : I; END LOOP; FOR V_IND IN 0..V_IDS.COUNT LOOP INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME) VALUES(V_IDS(V_IND), TEST_ || V_IND); END LOOP; COMMIT; EXCEPTION WHEN OTHERS THEN V_ERR_CODE : SQLCODE; V_ERR_MSG : SQLERRM; INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(V_ERR_CODE, V_ERR_MSG, SYSDATE); ROLLBACK; END; /執(zhí)行后雖然 INSERT 沒有成功但ERR_LOG表里會(huì)多一條記錄把-4029這個(gè)錯(cuò)誤碼和對應(yīng)的錯(cuò)誤消息完整記錄下來。這個(gè)習(xí)慣非常重要尤其是在匿名塊比較長、業(yè)務(wù)邏輯復(fù)雜時(shí)沒有日志幾乎等于瞎猜。5.3 PRAGMA EXCEPTION_INIT 綁定具名異常如果你想針對某個(gè)特定錯(cuò)誤碼做不同的處理可以在聲明段用PRAGMA EXCEPTION_INIT把錯(cuò)誤碼綁定到一個(gè)具名異常上DECLARE NUO_ARRAY_EXCEPTION EXCEPTION; PRAGMA EXCEPTION_INIT(NUO_ARRAY_EXCEPTION, -4029); TYPE T_ID_LIST IS TABLE OF INT INDEX BY INT; V_IDS T_ID_LIST; V_IND INT; BEGIN FOR I IN 1..10 LOOP V_IDS(I) : I; END LOOP; FOR V_IND IN 0..V_IDS.COUNT LOOP INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME) VALUES(V_IDS(V_IND), TEST_ || V_IND); END LOOP; COMMIT; EXCEPTION WHEN NUO_ARRAY_EXCEPTION THEN INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(-4029, 數(shù)組下標(biāo)越界請檢查循環(huán)起點(diǎn)和邊界, SYSDATE); ROLLBACK; WHEN OTHERS THEN INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(SQLCODE, SQLERRM, SYSDATE); ROLLBACK; END; /這里PRAGMA EXCEPTION_INIT(NUO_ARRAY_EXCEPTION, -4029)的含義是把錯(cuò)誤碼-4029綁定到自定義異常名NUO_ARRAY_EXCEPTION上。之后在EXCEPTION段就可以用WHEN NUO_ARRAY_EXCEPTION精確捕獲這個(gè)錯(cuò)誤而不會(huì)被WHEN OTHERS搶先接走。要注意PRAGMA EXCEPTION_INIT必須放在聲明段并且要在變量聲明之后、BEGIN之前。綁定時(shí)錯(cuò)誤碼要和實(shí)際報(bào)錯(cuò)一致不同小版本下錯(cuò)誤碼可能有差異保險(xiǎn)做法是先用WHEN OTHERS配合SQLCODE查一次實(shí)際錯(cuò)誤碼再?zèng)Q定綁定值。如果你不想用具名異常也可以直接在WHEN OTHERS里判斷SQLCODE -4029后做分支處理。兩種方式效果類似區(qū)別在于具名異常在代碼可讀性上更好適合同一段邏輯里對不同錯(cuò)誤做差異化響應(yīng)的場景。5.4 實(shí)際處理策略繼續(xù)執(zhí)行還是整體回滾最后一個(gè)關(guān)鍵問題異常發(fā)生后業(yè)務(wù)到底是繼續(xù)還是中斷。這取決于場景。如果是一次性造數(shù)任務(wù)推薦在EXCEPTION段記錄日志后整體回滾修正代碼再跑。因?yàn)闇y試數(shù)據(jù)要求完整性部分插入會(huì)導(dǎo)致后續(xù)統(tǒng)計(jì)結(jié)果失真。如果你在做批量數(shù)據(jù)加工希望跳過壞數(shù)據(jù)處理后續(xù)數(shù)據(jù)就不要在頂層用大而全的異常塊而是把異常處理下沉到循環(huán)內(nèi)部。在循環(huán)體里再套一個(gè)內(nèi)層 BEGIN...EXCEPTION 塊FOR V_IND IN 1..V_COUNT LOOP BEGIN INSERT INTO ZM.ZS_RESULT_TEST(ID, COL_NAME) VALUES(V_IDS(V_IND), TEST_ || V_IND); EXCEPTION WHEN OTHERS THEN INSERT INTO ZM.ERR_LOG(ERR_CODE, ERR_MSG, OCCUR_TIME) VALUES(SQLCODE, SQLERRM, SYSDATE); CONTINUE; END; END LOOP;內(nèi)層捕獲異常后CONTINUE循環(huán)會(huì)繼續(xù)跑但外層不會(huì)感知到這條失敗記錄。如果你希望內(nèi)層失敗只記錄、最終整體仍然回滾可以在內(nèi)層異常處理中不做提交并在循環(huán)結(jié)束后判斷日志表是否有新增記錄再?zèng)Q定是否 ROLLBACK。這算是我實(shí)際項(xiàng)目中用得比較多的處理思路邏輯清晰也方便事后核對失敗數(shù)據(jù)。狀態(tài)比較理想的結(jié)構(gòu)是一個(gè)可重復(fù)執(zhí)行的匿名塊內(nèi)層負(fù)責(zé)單條數(shù)據(jù)的失敗跳過和數(shù)據(jù)記錄外層負(fù)責(zé)事務(wù)邊界和最終提交決策。這樣無論造數(shù)還是批量加工都能在出問題時(shí)快速定位到具體數(shù)據(jù)而不是整體黑屏。最后分享一個(gè)實(shí)際體會(huì)這一輪操作下來我最大的收獲是把部署檢查清單從“能啟動(dòng)就算成功”改成了“啟動(dòng)后必須驗(yàn)證關(guān)鍵功能鏈路”。disable_jit這種藏在性能參數(shù)里的開關(guān)不實(shí)際執(zhí)行 JAVA 內(nèi)嵌函數(shù)調(diào)用根本發(fā)現(xiàn)不了問題匿名塊也盡量從一開始就包好異常處理日志表提前建好不要等報(bào)錯(cuò)后再補(bǔ)。造數(shù)這種看起來簡單的需求往往就是循環(huán)邊界和異常處理這種小地方最容易翻車。