簡介InterBase 6.0 數(shù)據(jù)庫安裝包與開發(fā)示例合集面向使用 Delphi 6 構(gòu)建客戶端/服務(wù)器數(shù)據(jù)庫應(yīng)用的開發(fā)者及數(shù)據(jù)庫學(xué)習(xí)者可用于搭建本地測試環(huán)境、研究早期 RDBMS 的部署結(jié)構(gòu)與 API 調(diào)用方式。壓縮包共 130 個文件約 4.86MB含 33 個 C 源碼、15 個可執(zhí)行程序、8 個動態(tài)庫以及頭文件、庫文件、幫助文檔、SQL 腳本和 gdb、gbk 示例數(shù)據(jù)庫覆蓋安裝、卸載、運(yùn)行配置與基礎(chǔ)數(shù)據(jù)操作。已有 341 人學(xué)習(xí)下載對遺留系統(tǒng)維護(hù)和舊版 Delphi 數(shù)據(jù)訪問研究仍有參考價值。讀者可獲得較完整的安裝組件、數(shù)據(jù)庫引擎依賴文件、編程接口示例和初始數(shù)據(jù)庫樣本便于理解 BDE、ODBC 等連接方式背后的文件組成也可用于排查舊項目運(yùn)行環(huán)境缺失、數(shù)據(jù)庫初始化與許可配置等問題。1. 接手一個只剩 .GDB 文件的老系統(tǒng)才明白 InterBase 6.0 是什么形態(tài)交付包里沒有安裝手冊只有一個 4MB 出頭的.GDB文件和一堆 Delphi 控件源碼這是不少人第一次接觸 InterBase 6.0 時的真實(shí)場景。它并不是那種需要獨(dú)立 DBA 運(yùn)維的數(shù)據(jù)庫服務(wù)整個庫就是一個文件拷到目標(biāo)機(jī)器、配好連接串、把控件拖到窗體上就能讀寫。這份資源的價值也在這里服務(wù)端、客戶端連接庫、控件源碼和示例應(yīng)用湊成一套拿下來就能把一個數(shù)據(jù)庫應(yīng)用從前端到存儲層全部跑通。這篇按我拆包的順序?qū)懴戎v清 InterBase 6.0 的事務(wù)模型和文件組織再把它在本機(jī)跑起來然后把生成器、觸發(fā)器、存儲過程、UDF 這幾塊核心實(shí)現(xiàn)逐段拆開最后落在「拿到控件源碼之后改哪里」這個實(shí)際問題上。手里攥著老項目要維護(hù)的人和想拿一個輕量嵌入式數(shù)據(jù)庫練手的人都能照著走一遍。2. 技術(shù)底座MGA 架構(gòu)下的事務(wù)版本與頁面組織2.1 多代版本架構(gòu)讀不擋寫寫不擋讀先糾正一個很容易帶偏的認(rèn)知InterBase 6.0 不是靠回滾段做并發(fā)的。執(zhí)行 UPDATE 時它不原地覆蓋那一行而是把記錄的新版本寫進(jìn)數(shù)據(jù)頁舊版本留在原處只在記錄頭里把「替換事務(wù)號」標(biāo)成當(dāng)前事務(wù)。別的讀事務(wù)只要自己的快照事務(wù)號比這個替換號小就繼續(xù)讀到舊版本一點(diǎn)都不會被卡住。這就是所謂多代版本架構(gòu)MGA它的直接結(jié)果是讀事務(wù)永遠(yuǎn)不用等寫事務(wù)寫事務(wù)也不會因?yàn)橛腥嗽趻弑矶抨牎]有回滾段帶來的另一個差別在回滾語義上。執(zhí)行 ROLLBACK 時數(shù)據(jù)庫并不做「反向補(bǔ)償」它只是把那個事務(wù)在事務(wù)清單里標(biāo)記為已死這個事務(wù)寫下的所有版本立刻變成垃圾數(shù)據(jù)等著被回收。所以回滾一個剛插了十萬行的事務(wù)幾乎瞬間完成不會像日志型數(shù)據(jù)庫那樣還要回放一遍。這套設(shè)計的代價也很明確垃圾版本不會自動消失需要靠 sweep 機(jī)制回收而 sweep 能不能推進(jìn)取決于「最老活躍事務(wù)」OIT和「最老事務(wù)」OAT這兩個水位線能不能往前走。這就引出了老項目里最典型的一類故障。只要有一個連接開著事務(wù)不提交——哪怕它只是SELECT了一下——OAT 就被釘在原地比它新的所有垃圾版本都回收不了庫文件只漲不縮查詢越來越慢。我在一個工控項目上見過庫文件從 200MB 漲到 3GB最后查出來是一個報表模塊的TIBTransaction忘了Commit掛了半個月。所以看一個 InterBase 庫健不健康第一件事不是看數(shù)據(jù)量是看 OIT 和 OAT 差了多遠(yuǎn)。還有一點(diǎn)要注意事務(wù)隔離級別在 InterBase 里是通過 TPB事務(wù)參數(shù)塊傳的isc_tpb_concurrency是快照隔離最常用isc_tpb_read_committed配isc_tpb_rec_version是讀已提交而isc_tpb_consistency會加表級鎖除非你在做批處理維護(hù)否則別碰它一旦用錯整個系統(tǒng)的并發(fā)直接降到單線程。2.2 單文件、頁與事務(wù)計數(shù)器的物理組成.GDB文件內(nèi)部是按頁組織的頁大小在建庫時定死可選 1024、2048、4096、8192 字節(jié)。第 0 頁是數(shù)據(jù)庫頭記錄了頁大小、事務(wù)水位、影子文件信息往后是頁分配頁、事務(wù)清單頁TIP、指針頁、數(shù)據(jù)頁、索引頁和 BLOB 頁。理解這套分層最實(shí)用的工具是gstat它不做任何修改只讀取元信息。# 只看庫頭頁大小、OAT/OIT、下一個事務(wù)號、影子文件 gstat -h /opt/data/demo.gdb # 看數(shù)據(jù)頁的填充率和高水位判斷是不是碎片太多 gstat -d /opt/data/demo.gdb | more # 看索引深度深度從 3 變成 4 通常意味著索引膨脹 gstat -i /opt/data/demo.gdb-h的輸出里有幾個參數(shù)值得記住Page size決定了單頁能放多少行也間接決定了 BLOB 的讀取效率Oldest transaction就是 OATOldest active是 OIT兩者相差幾百以內(nèi)算正常差到幾十萬說明有長事務(wù)在拖后腿Next transaction是一直遞增的事務(wù)號漲到 20 億附近會有溢出風(fēng)險正規(guī)做法是做一次備份還原把事務(wù)號重置回低位。-d看的是數(shù)據(jù)頁的填充率如果大量頁只填了 30%說明刪除和更新留下的空洞多該做一次gbak備份還原把空間收回來。頁大小定下來之后想改唯一的辦法是gbak備份再gbak -c -p 8192還原沒有在線改的路徑。所以建庫前要想清楚如果表里有一堆VARCHAR(200)加上幾個 BLOB 字段用 4096 或 8192 能少很多跨頁讀如果只是幾百張配置表、單行很小1024 反而更省內(nèi)存。單個文件大到一定程度就得拆成多文件-- 追加第二個數(shù)據(jù)文件起始頁號接在主文件之后 ALTER DATABASE ADD FILE /opt/data/demo_02.gdb STARTING AT PAGE 200000 LENGTH 200000;這條語句里的STARTING AT PAGE是主文件的頁號邊界不是字節(jié)數(shù)寫錯會導(dǎo)致新文件永遠(yuǎn)用不上。我一般只在受文件系統(tǒng)單文件上限限制的場景下才拆拆完一定要用gstat -h確認(rèn)Database files那一行變成了兩個否則等于白寫。2.3 服務(wù)形態(tài)本地直連還是 TCP 遠(yuǎn)程InterBase 6.0 的一個特點(diǎn)是同一個客戶端庫既能連本地文件也能連遠(yuǎn)程服務(wù)區(qū)別只在連接串怎么寫。這一點(diǎn)經(jīng)常被忽略然后在部署時踩坑——因?yàn)檫h(yuǎn)程連接里那個路徑是「服務(wù)端視角」的不是你自己機(jī)器上的路徑。連接串寫法走的協(xié)議適用場景C:\data\demo.gdb本地直連單機(jī)工具、免裝服務(wù)端、數(shù)據(jù)不外發(fā)localhost:C:\data\demo.gdbTCP 回環(huán)本機(jī)調(diào)試但要驗(yàn)證服務(wù)端權(quán)限和鎖192.168.1.20:C:\data\demo.gdbTCP 遠(yuǎn)程多人共用一臺庫服務(wù)器srv01:/opt/data/demo.gdbTCP 遠(yuǎn)程跨平臺部署服務(wù)端是 Linux本地直連省掉了網(wǎng)絡(luò)往返和權(quán)限校驗(yàn)啟動快、部署簡單很適合隨應(yīng)用程序一起分發(fā)的單機(jī)版。但它的并發(fā)模型比遠(yuǎn)程弱得多多個進(jìn)程同時寫同一個文件時鎖沖突會很難排查所以只要業(yè)務(wù)里有第二個人同時寫就別圖省事老老實(shí)實(shí)裝服務(wù)端走 TCP。遠(yuǎn)程連接的另一個前提是服務(wù)名要能解析。客戶端庫默認(rèn)用gds_db這個服務(wù)名去找端口主機(jī)上必須有一行登記# 服務(wù)端和客戶端的 services 文件里都要有這行端口默認(rèn) 3050 gds_db 3050/tcp # InterBase 服務(wù)名與監(jiān)聽端口 # 改完確認(rèn)端口真的在監(jiān)聽 netstat -an | grep 3050注意客戶端報unavailable database時先別懷疑庫文件損壞八成是這行沒登記或者被防火墻攔了。3. 跑起來從服務(wù)啟動到控件發(fā)出第一個查詢3.1 安裝與最小可用配置服務(wù)端裝完之后要先確認(rèn)三件事進(jìn)程在跑、端口在聽、SYSDBA能登進(jìn)去。很多人卡在第一步是因?yàn)榘芽蛻舳撕头?wù)端裝混了——客戶端只需要一個連接庫Windows 上是gds32.dll服務(wù)端才有后臺進(jìn)程。# 1) 確認(rèn)服務(wù)端進(jìn)程存在 ps -ef | grep -i interbase # 2) 確認(rèn) 3050 端口處于 LISTEN netstat -anp | grep 3050 # 3) 用命令行工具直連驗(yàn)證 SYSDBA 能過 isql -user SYSDBA -password masterkeyisql是隨服務(wù)端一起提供的命令行客戶端它同時也是一個 SQL 腳本執(zhí)行器后面建庫、灌表結(jié)構(gòu)、跑遷移腳本都靠它。第三步如果提示用戶名口令錯誤說明安裝時設(shè)的SYSDBA口令不是默認(rèn)值得找當(dāng)時的部署記錄如果提示unavailable database回到 2.3 節(jié)查服務(wù)名登記。Windows 上還有一個常見問題應(yīng)用程序目錄里的gds32.dll和系統(tǒng)目錄里的版本不一致?？蛻舳藥斓陌姹颈仨毢头?wù)端大致匹配混用不同版本時表現(xiàn)是能連上、能查詢但一取 BLOB 或者一調(diào)存儲過程就崩排查成本極高。我的習(xí)慣是把服務(wù)端自帶的那份客戶端庫直接拷到 exe 同目錄讓它優(yōu)先加載別指望系統(tǒng)的搜索路徑。3.2 isql 建庫建表跑通第一個庫CREATE DATABASE是客戶端工具語句不是服務(wù)端 SQL所以必須在isql里執(zhí)行。路徑同樣按服務(wù)端視角寫。# 建庫頁大小和字符集在這里定死后面改不了 isql -user SYSDBA -password masterkey EOF CREATE DATABASE /opt/data/demo.gdb USER SYSDBA PASSWORD masterkey PAGE_SIZE 8192 DEFAULT CHARACTER SET UNICODE_FSS; EOF # 灌表結(jié)構(gòu)腳本開頭先 CONNECT保證連的是目標(biāo)庫 isql -user SYSDBA -password masterkey -i schema.sqlschema.sql里第一句必須是CONNECT /opt/data/demo.gdb;后面才是 DDL。PAGE_SIZE和DEFAULT CHARACTER SET建庫時定死UNICODE_FSS是 6.0 里能存多字節(jié)字符的字符集存中文就別用NONE否則排序和長度計算都會出問題。建表這塊有兩個 6.0 時代特有的寫法值得用上DEFAULT NOW這種上下文變量以及 64 位整型主鍵。CONNECT /opt/data/demo.gdb; CREATE TABLE T_ORDER ( ID BIGINT NOT NULL, ORDER_NO VARCHAR(32) NOT NULL, AMOUNT NUMERIC(18,2) DEFAULT 0 NOT NULL, STATUS SMALLINT DEFAULT 0 NOT NULL, CREATED_AT TIMESTAMP DEFAULT NOW NOT NULL, CONSTRAINT PK_T_ORDER PRIMARY KEY (ID) ); -- 訂單號唯一單獨(dú)建索引查詢走索引而不是全表 CREATE UNIQUE INDEX IDX_ORDER_NO ON T_ORDER (ORDER_NO);DEFAULT NOW是服務(wù)端求值的取的是數(shù)據(jù)庫服務(wù)器時間不是客戶端時間這一點(diǎn)在跨時區(qū)的多客戶端場景里很關(guān)鍵——用客戶端賦時間會出現(xiàn)同一批數(shù)據(jù)時間倒掛。BIGINT是 64 位整型只在 dialect 3 下可用用它做主鍵是為了避免幾百萬行之后INTEGER溢出。NUMERIC(18,2)在 dialect 3 下映射到 64 位整型存儲精度不會丟做金額字段比DOUBLE PRECISION靠譜得多。3.3 控件對接連接、事務(wù)邊界與參數(shù)化查詢Delphi 那套控件里連 InterBase 最直接的是 IBXInterBase Express它不依賴 BDE直連客戶端庫部署時少一層中間件。核心是三個控件TIBDatabase管連接TIBTransaction管事務(wù)TIBQuery管數(shù)據(jù)集。// 數(shù)據(jù)庫連接路徑前綴決定走本地直連還是 TCP IBDB.DatabaseName : localhost:/opt/data/demo.gdb; IBDB.Params.Clear; IBDB.Params.Add(user_nameSYSDBA); IBDB.Params.Add(passwordmasterkey); IBDB.Params.Add(lc_ctypeUNICODE_FSS); // 必須和建庫時一致 IBDB.SQLDialect : 3; // dialect 對不上會報類型轉(zhuǎn)換錯 IBDB.LoginPrompt : False; IBDB.Connected : True; // 事務(wù)顯式控制別指望自動提交 IBTrans.DefaultDatabase : IBDB; IBTrans.Params.Clear; IBTrans.Params.Add(isc_tpb_write); // 讀寫事務(wù) IBTrans.Params.Add(isc_tpb_concurrency); // 快照隔離讀不阻塞寫 IBTrans.Params.Add(isc_tpb_wait); // 遇鎖等待而不是立刻拋異常 IBTrans.StartTransaction;lc_ctype是客戶端字符集它必須和服務(wù)端建庫時的DEFAULT CHARACTER SET對上對不上的表現(xiàn)是中文變問號或者VARCHAR(32)明明只存了 20 個漢字卻報超長。isc_tpb_wait和isc_tpb_nowait的選擇直接影響用戶體驗(yàn)nowait遇到鎖沖突立刻拋lock conflict on no wait transaction適合后臺批處理快速失敗wait會掛起等待適合交互界面。查詢部分建議全部走參數(shù)化別拼字符串IBQuery1.Close; IBQuery1.SQL.Text : SELECT ID, ORDER_NO, AMOUNT FROM T_ORDER WHERE STATUS :S AND CREATED_AT :D ORDER BY ID; IBQuery1.ParamByName(S).AsInteger : 1; IBQuery1.ParamByName(D).AsDateTime : Date - 7; IBQuery1.Open; while not IBQuery1.Eof do begin // 讀字段用 FieldByName別用下標(biāo)后面加字段不會崩 Memo1.Lines.Add(IBQuery1.FieldByName(ORDER_NO).AsString); IBQuery1.Next; end; IBQuery1.Close; IBTrans.Commit; // 讀事務(wù)也要提交不然 OAT 卡住最后那句Commit是重點(diǎn)。IBX 里TIBTransaction默認(rèn)不自動提交一個TIBQuery打開又關(guān)掉事務(wù)仍然是活的它對應(yīng)的快照事務(wù)號就一直掛在 OIT 上。前面說的庫文件瘋長源頭往往就是這種「只讀了一下」的代碼。如果一次操作要寫多張表用TIBUpdateSQL配合TIBQuery的緩存更新把提交點(diǎn)收在業(yè)務(wù)動作結(jié)束那一刻比一條 SQL 一次提交安全得多。4. 核心模塊拆解生成器、觸發(fā)器、存儲過程與 UDF4.1 生成器與主鍵發(fā)號GEN_ID 的正確用法生成器Generator是 InterBase 里的獨(dú)立計數(shù)器和表無關(guān)專門用來發(fā)號。CREATE GENERATOR GEN_ORDER_ID; SET GENERATOR GEN_ORDER_ID TO 0; -- 取下一個號第二個參數(shù)是步長 SELECT GEN_ID(GEN_ORDER_ID, 1) FROM RDB$DATABASE;GEN_ID的第二個參數(shù)是增量正常情況下傳 1需要一次預(yù)留一段號比如批量導(dǎo)入時傳 N。RDB$DATABASE是系統(tǒng)表永遠(yuǎn)只有一行用來把函數(shù)當(dāng)查詢跑。這里有一個必須記住的性質(zhì)生成器不受事務(wù)控制。取號這個動作在事務(wù)回滾后不會退回所以號一定有空洞。很多人拿它直接當(dāng)訂單號展示給用戶看結(jié)果發(fā)現(xiàn)編號不連續(xù)被業(yè)務(wù)方追著問。我的做法是生成器只做物理主鍵業(yè)務(wù)單號單獨(dú)用「日期 序列」拼序列另有自己的表去維護(hù)。反過來如果業(yè)務(wù)真的要求連號那就不能靠生成器得在一張T_SEQ表上做UPDATE ... SET CUR CUR 1并配合行鎖代價是并發(fā)性能直線下降這個取舍要提前跟業(yè)務(wù)說清楚。4.2 觸發(fā)器把業(yè)務(wù)約束下沉到數(shù)據(jù)庫層觸發(fā)器在 InterBase 里分 BEFORE 和 AFTER還分行級和語句級。行級觸發(fā)器里能用NEW和OLD兩個上下文變量分別代表新值和舊值。-- 自定義異常拋出時客戶端能拿到這條消息 CREATE EXCEPTION E_AMOUNT_INVALID 訂單金額必須大于 0; -- 主鍵發(fā)號BEFORE INSERT在約束檢查之前把 ID 填上 CREATE TRIGGER TR_ORDER_BI FOR T_ORDER ACTIVE BEFORE INSERT POSITION 0 AS BEGIN IF (NEW.ID IS NULL) THEN NEW.ID GEN_ID(GEN_ORDER_ID, 1); END; -- 業(yè)務(wù)校驗(yàn)POSITION 1 保證排在發(fā)號之后執(zhí)行 CREATE TRIGGER TR_ORDER_BIU FOR T_ORDER ACTIVE BEFORE INSERT OR UPDATE POSITION 1 AS BEGIN IF (NEW.AMOUNT 0) THEN EXCEPTION E_AMOUNT_INVALID; END;POSITION決定同一個表上多個同類觸發(fā)器的執(zhí)行順序編號小的先跑。上面這兩個觸發(fā)器必須按 0、1 排否則校驗(yàn)里拿到的NEW.ID還是空。EXCEPTION拋出去之后客戶端TIBQuery會收到一條EIBErrorMessage里帶的就是E_AMOUNT_INVALID那條文本這是把校驗(yàn)規(guī)則放在數(shù)據(jù)庫層最實(shí)際的好處——不管前端是 Delphi、Java 還是命令行工具規(guī)則都跑不掉。需要注意BEFORE 觸發(fā)器里改NEW的字段是有效的AFTER 觸發(fā)器里改就沒有意義了因?yàn)橛涗浺呀?jīng)落盤。另外語句級觸發(fā)器FOR EACH STATEMENT在行級操作里拿不到NEW/OLD它主要用來POST_EVENT做業(yè)務(wù)邏輯時千萬別用它。4.3 可選中存儲過程與事件通知存儲過程分兩種一種用EXECUTE PROCEDURE調(diào)用、只做副作用另一種帶SUSPEND可以被SELECT當(dāng)表查叫可選中存儲過程。CREATE PROCEDURE SP_ORDER_LIST (P_STATUS SMALLINT) RETURNS (ID BIGINT, ORDER_NO VARCHAR(32), AMOUNT NUMERIC(18,2)) AS BEGIN FOR SELECT O.ID, O.ORDER_NO, O.AMOUNT FROM T_ORDER O WHERE O.STATUS :P_STATUS ORDER BY O.ID INTO :ID, :ORDER_NO, :AMOUNT DO SUSPEND; -- 每處理一行掛起一次客戶端才能逐行取到 END;SUSPEND是這段代碼的核心。沒有它存儲過程會把所有行算完只返回最后一組值有了它服務(wù)端每算出一行就掛起客戶端取一行再喚醒內(nèi)存占用是常數(shù)級別的。FOR SELECT ... INTO里的變量名前必須加冒號這是 PSQL 里區(qū)分「字段名」和「變量名」的語法漏了冒號會報「列名不明確」。客戶端調(diào)用有兩種// 方式一當(dāng)表查最靈活能帶排序和過濾 IBQuery1.SQL.Text : SELECT * FROM SP_ORDER_LIST(:S) ORDER BY ID; IBQuery1.ParamByName(S).AsInteger : 1; IBQuery1.Open; // 方式二TIBStoredProc適合無返回集的存儲過程 IBSP.StoredProcName : SP_ORDER_CLOSE; IBSP.ParamByName(P_ID).AsLargeInt : 1024; IBSP.ExecProc;配套的還有事件機(jī)制用來做「數(shù)據(jù)變了通知所有客戶端刷新」。服務(wù)端在觸發(fā)器里POST_EVENT客戶端注冊同名事件CREATE TRIGGER TR_ORDER_EVENT FOR T_ORDER ACTIVE AFTER INSERT OR UPDATE POSITION 0 AS BEGIN POST_EVENT ORDER_CHANGED; END;IBEvents1.Database : IBDB; IBEvents1.Events.Text : ORDER_CHANGED; // 多個事件名用換行分隔 IBEvents1.OnEventAlert : DoOrderChanged; IBEvents1.Registered : True; // 注冊之后服務(wù)端才會推POST_EVENT的名字建議用大寫短名老版本對事件名長度限制得比較緊不要寫成一句描述。更關(guān)鍵的是OnEventAlert回調(diào)是在客戶端庫的后臺線程里觸發(fā)的在里面直接操作 VCL 控件會因?yàn)榭缇€程訪問出玄學(xué)崩潰正確做法是TThread.Queue或者PostMessage把刷新動作丟回主線程。我第一次用事件通知時就在這里翻過車表現(xiàn)為「偶爾」崩查了兩天才定位到線程上。4.4 UDF拿到源碼后自己編一個外部函數(shù)庫內(nèi)置函數(shù)不夠用時InterBase 支持外部函數(shù)UDF把 C 函數(shù)編成動態(tài)庫在數(shù)據(jù)庫里聲明之后就能在 SQL 里調(diào)用。/* myudf.c —— 編成動態(tài)庫后由服務(wù)端加載 */ #include string.h /* 參數(shù)用 CSTRING 聲明時收到的是以 \0 結(jié)尾的字符串指針 */ long STRLEN_UDF(char *s) { if (s NULL) return 0; return (long) strlen(s); }# Linux 下編成 .so位數(shù)必須和服務(wù)端一致32 位服務(wù)端只認(rèn) 32 位庫 gcc -shared -fPIC -O2 -o myudf.so myudf.c # Windows 下編成 DLL cl /LD myudf.c /Fe:myudf.dll編出來之后丟到服務(wù)端的 UDF 目錄然后在庫里聲明DECLARE EXTERNAL FUNCTION STRLEN_UDF CSTRING(256) RETURNS INTEGER BY VALUE ENTRY_POINT STRLEN_UDF MODULE_NAME myudf;三個參數(shù)各有講究CSTRING(256)告訴服務(wù)端按定長字符串傳參如果用VARCHAR(256)聲明傳進(jìn)去的是帶長度前綴的結(jié)構(gòu)體指針函數(shù)簽名就得跟著改BY VALUE表示返回值按值傳整型必須加這個漏了會讀到一個野指針ENTRY_POINT是導(dǎo)出符號名MODULE_NAME是不帶擴(kuò)展名的庫名。改完庫之后必須重啟服務(wù)端連接才會重新加載改完函數(shù)不重啟是最常見的「明明改了卻沒生效」。5. 避坑與排查五個把項目拖進(jìn)坑里的細(xì)節(jié)5.1 恢復(fù)之后主鍵沖突集中爆發(fā)現(xiàn)象從生產(chǎn)庫備份出來恢復(fù)到測試環(huán)境應(yīng)用一插數(shù)據(jù)就報violation of PRIMARY or UNIQUE KEY constraint但表里明明只有幾百行。原因gbak做完整備份還原時會把生成器的當(dāng)前值一起帶過去但如果這次恢復(fù)用的是只導(dǎo)結(jié)構(gòu)的 DDL 腳本或者用-m只恢復(fù)元數(shù)據(jù)生成器的值就回到了建庫時的初始狀態(tài)。而數(shù)據(jù)行是從別處灌進(jìn)來的ID已經(jīng)用到了幾千兩邊一撞就沖突。解決恢復(fù)完之后先對齊每個生成器再讓應(yīng)用跑起來。-- 把生成器重置到當(dāng)前最大 ID批量做的時候用腳本生成這段 SET GENERATOR GEN_ORDER_ID TO 0; SELECT GEN_ID(GEN_ORDER_ID, COALESCE(MAX(ID), 0)) FROM T_ORDER;第二句借GEN_ID的步長參數(shù)一次性把計數(shù)器頂?shù)組AX(ID)比SET GENERATOR ... TO 具體數(shù)字少一次人工查數(shù)。我現(xiàn)在的習(xí)慣是恢復(fù)腳本最后必須帶這一段每個生成器一行缺一個就等著線上報沖突。5.2 庫文件只漲不縮sweep 跑不動現(xiàn)象刪了幾百萬行歷史數(shù)據(jù)磁盤占用一點(diǎn)沒降查詢一天比一天慢跑gfix -sweep跑了幾個小時還在跑。原因刪除在 MGA 里只是把版本標(biāo)記成死真正回收要靠 sweep。而 sweep 能推進(jìn)的前提是 OAT 能往前走只要有一個長事務(wù)不提交回收立刻停擺。第二個原因是 sweep 本身是協(xié)作式的它和正常業(yè)務(wù)搶資源業(yè)務(wù)壓力大時會一直退讓。解決先查 OIT 和 OAT 的差距定位長事務(wù)再決定是手動 sweep 還是干脆做一次備份還原。# 看水位線差距差幾十萬說明有長事務(wù) gstat -h /opt/data/demo.gdb | grep -i oldest # 手動觸發(fā)回收最好放在業(yè)務(wù)低峰 gfix -sweep /opt/data/demo.gdb -user SYSDBA -password masterkey # 徹底方案備份還原空間能真正收回來 gbak -b /opt/data/demo.gdb /tmp/demo.fbk -user SYSDBA -password masterkey -v gbak -c -p 8192 /tmp/demo.fbk /opt/data/demo_new.gdb -user SYSDBA -password masterkey -vsweep只回收頁內(nèi)空間文件大小不會縮只有備份還原才會重寫整個文件、把空間真正交還給文件系統(tǒng)。所以計劃里應(yīng)該把「定期備份還原」當(dāng)成運(yùn)維動作而不是只當(dāng)災(zāi)備。5.3 Dialect 混用DATE 變成 TIMESTAMP雙引號變成標(biāo)識符現(xiàn)象客戶端查出來的日期字段多出了時間部分一條WHERE NAME ABC忽然報「列名不明確」NUMERIC(18,2)的金額在小數(shù)位上丟精度。原因這是 dialect 1 和 dialect 3 的語義差異。dialect 1 里DATE實(shí)際是帶時間的 TIMESTAMP雙引號包起來的是本文還有配套的精品資源點(diǎn)擊獲取