前段時(shí)間在一臺(tái) Linux 服務(wù)器上做 DM8 單機(jī)實(shí)例部署順手把表空間、用戶、權(quán)限、基礎(chǔ)表這些對(duì)象創(chuàng)建流程都走了一遍最后用匿名塊批量造數(shù)時(shí)撞上了一個(gè)數(shù)組越界異常。整個(gè)過(guò)程里讓我花時(shí)間最多的地方反而不是官方文檔寫得很全的部署步驟而是disable_jit這個(gè)參數(shù)和 JAVA 內(nèi)嵌函數(shù)之間的關(guān)系以及 DM 管理工具自身的 JAVA 運(yùn)行環(huán)境問(wèn)題。這些內(nèi)容分散在文檔的不同章節(jié)里不實(shí)際跑一遍很難把它們串起來(lái)。這篇就當(dāng)一份實(shí)操問(wèn)題記錄寫給正在做 DM8 初始化部署、準(zhǔn)備用 DM 管理工具建基礎(chǔ)對(duì)象或者想了解匿名塊異常處理寫法的同行。我盡量把排查路徑、SQL 示例和當(dāng)時(shí)踩坑的原因都交代清楚方便你直接照著復(fù)現(xiàn)或避開。1. 單機(jī)實(shí)例部署中官方文檔容易略過(guò)的 disable_jit1.1 先交代部署環(huán)境和基本流程我這次的部署環(huán)境是 Linux x86_648C16G 的虛擬機(jī)DM8 開發(fā)版系統(tǒng)賬號(hào)用的dmdba。整體流程和官方《DM8 單機(jī)部署》文檔基本一致解壓安裝包、用dminit初始化實(shí)例、注冊(cè)系統(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ù)庫(kù)對(duì)象名區(qū)分大小寫CHARSET1表示 UTF-8 字符集。很多從 Oracle 遷過(guò)來(lái)的同事習(xí)慣性認(rèn)為表名不區(qū)分大小寫恰恰會(huì)在這一步埋下隱患。所以部署階段就確認(rèn)好這些參數(shù)比事后查半天文檔要省事得多。服務(wù)注冊(cè)和啟動(dòng)就不多說(shuō)了按文檔執(zhí)行DmServiceDMSERVER相關(guān)的注冊(cè)腳本即可。啟動(dòng)后先用最簡(jiǎn)單的方式確認(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 提示符說(shuō)明單機(jī)實(shí)例的基本骨架已經(jīng)搭起來(lái)了。1.2 disable_jit 是怎么和 JAVA 內(nèi)嵌函數(shù)扯上關(guān)系的部署完成后我開始做功能驗(yàn)證想建一個(gè)測(cè)試用的存儲(chǔ)過(guò)程結(jié)果在 disql 里執(zhí)行到涉及 JAVA 靜態(tài)方法調(diào)用的語(yǔ)句時(shí)直接報(bào)錯(cuò)提示內(nèi)容大概是“JAVA 環(huán)境不可用”或“內(nèi)嵌 JAVA 函數(shù)執(zhí)行失敗”。我第一反應(yīng)是系統(tǒng)里 JDK 沒(méi)裝好可這臺(tái)服務(wù)器明明已經(jīng)裝了 JDK并且java -version完全正常。后來(lái)對(duì)照官方文檔逐項(xiàng)排查才發(fā)現(xiàn)問(wèn)題出在dm.ini里的disable_jit參數(shù)。文檔里對(duì)它的描述很簡(jiǎn)短大致意思是“是否禁用即時(shí)編譯啟用 JIT 后可提升部分復(fù)雜表達(dá)式的執(zhí)行效率”。它被歸在系統(tǒng)參數(shù)那一類部署章節(jié)里基本不會(huì)提到。但實(shí)際環(huán)境下JIT 開啟后會(huì)導(dǎo)致服務(wù)端內(nèi)嵌 JAVA 函數(shù)的執(zhí)行路徑出問(wèn)題具體表現(xiàn)就是 SQL 里調(diào)用 JAVA 內(nèi)嵌函數(shù)時(shí)功能不可用或直接異常。處理方式很直接把這個(gè)參數(shù)改為 1也就是禁用 JITALTER SYSTEM SET disable_jit1;需要注意不同版本對(duì)參數(shù)是否動(dòng)態(tài)生效的定義不太一樣穩(wěn)妥做法是在dm.ini配置文件中直接修改該參數(shù)然后重啟實(shí)例。我這邊就是改完配置文件后重啟再執(zhí)行之前失敗的 SQL功能就恢復(fù)正常了。按官方文檔的說(shuō)法這個(gè)參數(shù)的本意是性能優(yōu)化但它在某些版本下的實(shí)際影響已經(jīng)超出了性能范疇直接關(guān)系到 JAVA 內(nèi)嵌函數(shù)的可用性。這也是我為什么單獨(dú)把這個(gè)問(wèn)題拎出來(lái)講文檔把參數(shù)歸類在“性能”里但你在功能驗(yàn)證階段就可能會(huì)碰到它。1.3 部署完成后立刻驗(yàn)證的三件事經(jīng)過(guò)這次教訓(xùn)我把部署完成后的驗(yàn)證清單固定成了三件事每次裝完 DM8 都會(huì)先跑一遍用disql正常登錄并執(zhí)行SELECT * FROM V$VERSION;確認(rèn)版本符合預(yù)期。調(diào)用一個(gè)簡(jiǎn)單內(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ì)一致。這三件事看著簡(jiǎn)單但都能在五分鐘內(nèi)幫你定位部署階段最典型的幾類問(wèn)題實(shí)例沒(méi)起來(lái)、參數(shù)配置不對(duì)、JAVA 鏈路異常。2. DM 管理工具連接與 JAVA 運(yùn)行環(huán)境的連帶問(wèn)題2.1 管理工具連不上實(shí)例時(shí)的排查順序?qū)嵗渴鸷昧私酉聛?lái)要用 DM 管理工具做圖形化操作。我第一次連的時(shí)候也踩了坑工具一直提示連接失敗。很多人的第一反應(yīng)是查網(wǎng)絡(luò)、查防火墻但實(shí)際上對(duì)于本機(jī)或同網(wǎng)段訪問(wèn)網(wǎng)絡(luò)通常不是首要嫌疑。我的排查順序是這樣的先確認(rèn)實(shí)例服務(wù)和端口沒(méi)問(wèn)題也就是前面提到的ps和ss兩條命令再確認(rèn)賬號(hào)口令是否正確然后看數(shù)據(jù)庫(kù)服務(wù)端字符集和客戶端字符集是否匹配最后才看網(wǎng)絡(luò)和防火墻。DM 管理工具的連接配置其實(shí)很簡(jiǎn)單主機(jī)名、端口、用戶名、口令端口默認(rèn) 5236。如果連接時(shí)報(bào)“網(wǎng)絡(luò)通信失敗”之外的其他錯(cuò)誤比如登錄被拒絕、口令錯(cuò)誤那多半是賬號(hào)權(quán)限或密碼策略問(wèn)題這類錯(cuò)誤信息已經(jīng)寫得很明確了照著改就行。真正容易忽略的是服務(wù)端和客戶端的字符集不一致導(dǎo)致的亂碼或連接異常這個(gè)在創(chuàng)建實(shí)例時(shí)就應(yīng)該提前想好。2.2 管理工具自身也是 JAVA 應(yīng)用資源不足會(huì)連坐這里要特別說(shuō)一個(gè)容易和第一節(jié)問(wèn)題混淆的地方DM 管理工具是 JAVA 寫的圖形客戶端它自身需要一套可用的 JAVA 運(yùn)行環(huán)境。如果服務(wù)器或本機(jī)的默認(rèn) JDK 版本比較亂工具可能啟動(dòng)不了、界面空白甚至連上后操作一會(huì)兒就卡死。我當(dāng)初把管理工具啟動(dòng)不了的問(wèn)題誤判成數(shù)據(jù)庫(kù)實(shí)例問(wèn)題排查了半天。后來(lái)發(fā)現(xiàn)是系統(tǒng)默認(rèn)的 JAVA 版本和管理工具自帶的 JRE 不一致導(dǎo)致。處理方式有兩種一是直接用安裝包自帶的 JRE二是在管理工具啟動(dòng)腳本里顯式指定 JAVA 路徑。如果你的管理工具在操作大對(duì)象或跑復(fù)雜 SQL 時(shí)卡頓也可以適當(dāng)調(diào)大啟動(dòng)腳本里的-Xmx參數(shù)給 JVM 分配更多內(nèi)存。這里和服務(wù)器端disable_jit參數(shù)是兩條獨(dú)立的 JAVA 鏈路服務(wù)器端管的是數(shù)據(jù)庫(kù)進(jìn)程內(nèi)嵌 JAVA 虛擬機(jī)管理工具管的是客戶端進(jìn)程自己的 JVM排查時(shí)不要混在一起。2.3 我的習(xí)慣管理工具建對(duì)象disql 跑腳本在實(shí)際操作中我通常把 DM 管理工具和 disql 分開用管理工具適合單對(duì)象創(chuàng)建、查看表結(jié)構(gòu)、圖形化授權(quán)、查看執(zhí)行計(jì)劃disql 適合跑批量腳本、反復(fù)執(zhí)行匿名塊、驗(yàn)證異常處理邏輯。原因很簡(jiǎn)單管理工具雖然方便但在處理大量腳本時(shí)復(fù)制粘貼和錯(cuò)誤定位都不如命令行順手。特別是匿名塊這類帶異常處理的過(guò)程性代碼在 disql 里跑能看到更完整的錯(cuò)誤輸出出問(wèn)題時(shí)也更容易復(fù)現(xiàn)。所以我接下來(lái)的基礎(chǔ)對(duì)象創(chuàng)建雖然都在管理工具里操作但關(guān)鍵 SQL 我都是先在文本編輯器里寫好后再粘貼到工具或 disql 里執(zhí)行。3. 基礎(chǔ)對(duì)象創(chuàng)建的標(biāo)準(zhǔn)順序表空間先行、用戶權(quán)限隨后3.1 為什么先建表空間而不是先建用戶達(dá)夢(mèng)里創(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ù)對(duì)象會(huì)默認(rèn)落在 MAIN 表空間和系統(tǒng)對(duì)象混在一起。一旦后續(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用戶對(duì)目標(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的情況下用戶名和口令的大小寫都是敏感的。如果你把口令用雙引號(hào)包起來(lái)口令會(huì)嚴(yán)格按照大小寫存儲(chǔ)如果不加雙引號(hào)口令會(huì)被統(tǒng)一轉(zhuǎn)為大寫。很多連接失敗的問(wèn)題就是口令大小寫沒(méi)有對(duì)上。創(chuàng)建用戶之后做權(quán)限授予我的原則是最小授權(quán)絕不直接給 DBA 角色。這次我只是用zm做基礎(chǔ)對(duì)象創(chuàng)建和造數(shù)測(cè)試所以給了以下權(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á)夢(mèng)里已經(jīng)包含了建表、建索引等基礎(chǔ)權(quán)限額外再顯式加CREATE VIEW、CREATE PROCEDURE是保證后續(xù)測(cè)試時(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)限接下來(lái)創(chuàng)建測(cè)試表。我建的是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ì)很簡(jiǎn)單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)限視角的問(wèn)題。表默認(rèn)會(huì)創(chuàng)建在用戶默認(rèn)表空間 MYTBS 上如果你希望表和索引分開存放可以在建表語(yǔ)句里加上TABLESPACE MYTBS和INDEX TABLESPACE MYTBS_IDX之類的指定生產(chǎn)環(huán)境通常會(huì)把表和索引放在不同物理文件或者不同磁盤上以降低 IO 競(jìng)爭(zhēng)。到這里基礎(chǔ)對(duì)象創(chuàng)建的流程就閉環(huán)了表空間 - 用戶 - 權(quán)限 - 表。每一步都依賴前一步的結(jié)果順序錯(cuò)了就會(huì)遇到“權(quán)限不足”或“默認(rèn)表空間不存在”這類問(wèn)題。4. For 循環(huán)與關(guān)聯(lián)數(shù)組批量造數(shù)Good 案例復(fù)盤4.1 造數(shù)場(chǎng)景與常見寫法的差異基礎(chǔ)表建好后我需要往里插入大量測(cè)試數(shù)據(jù)大概十萬(wàn)行左右。字段要求帶隨機(jī)字符串、隨機(jī)分?jǐn)?shù)和時(shí)間戳用來(lái)做后續(xù)查詢性能驗(yàn)證。很多人第一反應(yīng)是寫一個(gè)簡(jiǎn)單的循環(huán)逐行 INSERT比如FOR I IN 1..100000 LOOP INSERT ...; END LOOP;。但如果你在循環(huán)里不做任何提交最后統(tǒng)一 COMMIT這種方式本身沒(méi)問(wèn)題問(wèn)題在于它不夠靈活而且邊界條件寫錯(cuò)時(shí)連異常都來(lái)不及處理。我當(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 語(yǔ)句里完成所有數(shù)據(jù)生成。但它的短板也明顯一旦你要對(duì)每一條數(shù)據(jù)做不同的邏輯處理或者根據(jù)外部變量決定是否插入純 SQL 就力不從心了。FOR 循環(huán)加關(guān)聯(lián)數(shù)組的定位是“可編程的批量造數(shù)”適合那些數(shù)據(jù)生成規(guī)則復(fù)雜的場(chǎng)景。4.3 這個(gè)寫法最常見的隱患循環(huán)邊界越界回到 FOR 循環(huán)寫法的隱患最典型的就是數(shù)組下標(biāo)越界。達(dá)夢(mèng)的關(guān)聯(lián)數(shù)組下標(biāo)默認(rèn)從 1 開始這一點(diǎn)和 Oracle 一致。如果你下意識(shí)寫了FOR IND IN 0..V_IDS.COUNT第一次循環(huán)就會(huì)訪問(wèn)V_IDS(0)而數(shù)組里根本沒(méi)有這個(gè)下標(biāo)的元素直接觸發(fā)數(shù)組上界越界異常。還有一種更隱蔽的情況如果V_IDS是空數(shù)組V_IDS.COUNT等于 0此時(shí)FOR IND IN 1..0這種遞減區(qū)間在達(dá)夢(mèng)里同樣是非法操作。這些邊界問(wèn)題在沒(méi)有異常處理塊包裹時(shí)整個(gè)匿名塊會(huì)直接中斷之前已經(jīng)執(zhí)行成功的 INSERT 全部回滾。這也是為什么我每次寫匿名塊之前都會(huì)先提醒自己循環(huán)邊界和異常處理至少要有一個(gè)是靠譜的。最穩(wěn)的做法是兩個(gè)都做也就是接下來(lái)要講的內(nèi)容。5. 越界異常 NUO_ARRAY_EXCEPTION 的完整排查與異常處理塊改造5.1 先把錯(cuò)誤現(xiàn)場(chǎng)完整撈出來(lái)為了驗(yàn)證越界問(wè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對(duì)應(yīng)的錯(cuò)誤碼為-4029。這個(gè)環(huán)節(jié)最重要的是先確認(rèn)錯(cuò)誤碼因?yàn)楹竺娴漠惓Ｌ幚韷K要根據(jù)錯(cuò)誤碼來(lái)做精確捕獲。定位時(shí)我先把循環(huán)體改成NULL最小化出錯(cuò)范圍確認(rèn)問(wèn)題不在 INSERT 語(yǔ)句本身而是循環(huán)到達(dá)V_IDS(0)時(shí)才觸發(fā)。接著把起點(diǎn)改成 1異常立刻消失。這就能確認(rèn)是下標(biāo)越界而不是表結(jié)構(gòu)或權(quán)限問(wèn)題。5.2 用 DECLARE...BEGIN...EXCEPTION...END 改造匿名塊達(dá)夢(mèng)的 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ò)誤撈出來(lái)寫進(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 沒(méi)有成功但ERR_LOG表里會(huì)多一條記錄把-4029這個(gè)錯(cuò)誤碼和對(duì)應(yīng)的錯(cuò)誤消息完整記錄下來(lái)。這個(gè)習(xí)慣非常重要尤其是在匿名塊比較長(zhǎng)、業(yè)務(wù)邏輯復(fù)雜時(shí)沒(méi)有日志幾乎等于瞎猜。5.3 PRAGMA EXCEPTION_INIT 綁定具名異常如果你想針對(duì)某個(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)越界請(qǐng)檢查循環(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ū)別在于具名異常在代碼可讀性上更好適合同一段邏輯里對(duì)不同錯(cuò)誤做差異化響應(yīng)的場(chǎng)景。5.4 實(shí)際處理策略繼續(xù)執(zhí)行還是整體回滾最后一個(gè)關(guān)鍵問(wèn)題異常發(fā)生后業(yè)務(wù)到底是繼續(xù)還是中斷。這取決于場(chǎng)景。如果是一次性造數(shù)任務(wù)推薦在EXCEPTION段記錄日志后整體回滾修正代碼再跑。因?yàn)闇y(cè)試數(shù)據(jù)要求完整性部分插入會(huì)導(dǎo)致后續(xù)統(tǒng)計(jì)結(jié)果失真。如果你在做批量數(shù)據(jù)加工希望跳過(guò)壞數(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)目中用得比較多的處理思路邏輯清晰也方便事后核對(duì)失敗數(shù)據(jù)。狀態(tài)比較理想的結(jié)構(gòu)是一個(gè)可重復(fù)執(zhí)行的匿名塊內(nèi)層負(fù)責(zé)單條數(shù)據(jù)的失敗跳過(guò)和數(shù)據(jù)記錄外層負(fù)責(zé)事務(wù)邊界和最終提交決策。這樣無(wú)論造數(shù)還是批量加工都能在出問(wèn)題時(shí)快速定位到具體數(shù)據(jù)而不是整體黑屏。最后分享一個(gè)實(shí)際體會(huì)這一輪操作下來(lái)我最大的收獲是把部署檢查清單從“能啟動(dòng)就算成功”改成了“啟動(dòng)后必須驗(yàn)證關(guān)鍵功能鏈路”。disable_jit這種藏在性能參數(shù)里的開關(guān)不實(shí)際執(zhí)行 JAVA 內(nèi)嵌函數(shù)調(diào)用根本發(fā)現(xiàn)不了問(wèn)題匿名塊也盡量從一開始就包好異常處理日志表提前建好不要等報(bào)錯(cuò)后再補(bǔ)。造數(shù)這種看起來(lái)簡(jiǎn)單的需求往往就是循環(huán)邊界和異常處理這種小地方最容易翻車。