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