用了多年通用數(shù)據(jù)庫突然接到一整套“國產(chǎn)數(shù)據(jù)庫技術(shù)”課程配套達夢 DM8 的學習任務(wù)時我第一反應(yīng)其實是有點不屑的。畢竟習慣了成熟生態(tài)的外來數(shù)據(jù)庫總覺得國產(chǎn)庫大概率就是改個殼、抄點語法。真正啃完這套《國產(chǎn)數(shù)據(jù)庫技術(shù)》的全程筆記自己動手把 DM8 從安裝、建庫、SQL 適配、應(yīng)用接入一直到備份恢復全部走了一遍之后我必須承認之前那種預判多少帶點偏見。達夢 DM8 在架構(gòu)上是完整的關(guān)系型數(shù)據(jù)庫并且在 Oracle 兼容性上花了大功夫同時在 MySQL 遷移、運維工具鏈、高可用方案上都有可落地的東西。本文就是我從零開始摸 DM8 的完整記錄把每一個決策背后的邏輯、踩過的坑、可以直接照抄的命令全部整理出來給正在評估國產(chǎn)數(shù)據(jù)庫或者要接手 DM8 項目的同行一個真實參考。無論你是 DBA、后端開發(fā)還是技術(shù)選型負責人這套筆記應(yīng)該都能幫你少走幾天彎路。1. 先看全局達夢 DM8 到底是什么樣的數(shù)據(jù)庫1.1 自研內(nèi)核但兼容性做了雙軌很多人的疑問是第一位的達夢 DM8 到底是自己寫的還是基于某個開源分支改的我在學習過程中查了不少架構(gòu)資料從官方技術(shù)白皮書和實際安裝后的文件結(jié)構(gòu)來判斷DM8 的底層執(zhí)行引擎、存儲管理、事務(wù)處理都是獨立實現(xiàn)不是 MySQL 或者 PostgreSQL 的分支產(chǎn)物。這個判斷層面的問題很重要因為它決定了后續(xù)所有操作的思維方式。如果是基于開源庫做的二次開發(fā)那我用開源社區(qū)的經(jīng)驗就能直接套但 DM8 不是所以它的初始化工具、配置文件、系統(tǒng)視圖、備份命令等都有自己的一套命名和邏輯。比如它沒有 MySQL 那種my.cnf而是用dm.ini作為實例配置文件默認端口是5236管理工具有獨立的manager圖形界面和disql命令行工具。這些都是自成一體的體系。但兼容性方面它確實參考了主流數(shù)據(jù)庫的生態(tài)習慣。官方文檔里明確提到兼容 Oracle 語法和 MySQL 語法兩種模式實際體驗下來Oracle 模式的完成度明顯更高。很多 PL/SQL 風格的包、存儲過程、數(shù)據(jù)類型在 DM8 里能找到對應(yīng)物這對從 Oracle 遷移過來的團隊極其友好。MySQL 模式更多是提供一些常用函數(shù)的別名和系統(tǒng)行為上的模擬畢竟 MySQL 生態(tài)也有大量用戶。1.2 它適合放在什么場景里學完整個課程我對 DM8 的定位有了自己的判斷它不是想在所有場景里跟主流數(shù)據(jù)庫硬碰硬而是重點解決“基礎(chǔ)軟件供應(yīng)鏈安全”環(huán)境下政企、金融、電力、制造等行業(yè)的核心業(yè)務(wù)替換需求。這些場景有個共同特征并發(fā)事務(wù)量大、數(shù)據(jù)一致性要求高、需要嚴格的權(quán)限管控和審計能力。DM8 的行級鎖、MVCC 機制、完備的備份恢復體系、支持共享存儲集群都是沖著這些需求設(shè)計的。如果你只是做一個個人博客或者小網(wǎng)站那它確實沒必要但如果你面對的是一個需要固定預算內(nèi)完成國產(chǎn)化替代的正式項目DM8 是非?，F(xiàn)實的選擇。我學習時的判斷框架是先看它能不能把原業(yè)務(wù)平滑接住再看運維和學習成本能不能承受。答案是在兼容層做得足夠好的前提下DM8 的上手難度并沒有想象中高尤其是有 Oracle 經(jīng)驗的人適應(yīng)周期會非常短。1.3 目錄結(jié)構(gòu)與關(guān)鍵進程安裝完 DM8 之后有件事建議第一時間做把安裝目錄結(jié)構(gòu)和進程關(guān)系搞清楚。以我用的 Linux 環(huán)境為例默認安裝目錄是/opt/dmdbms。/opt/dmdbms/ ├── bin/ # 可執(zhí)行文件包含 disql、dmserver、dmrman 等 ├── data/ # 默認數(shù)據(jù)文件目錄包含實例目錄 ├── dm.ini # 默認實例配置文件 ├── log/ # 日志目錄 ├── tool/ # 管理工具dmmanger、dmmonitor 等 └── web/ # 部分圖形工具使用啟動實例時核心進程是dmserver它會讀取dm.ini里的參數(shù)完成初始化。整個數(shù)據(jù)庫實例和一個操作系統(tǒng)進程強綁定這點要記住因為做啟停操作的時候經(jīng)常會需要用到進程管理命令來確認狀態(tài)。我習慣用ps -ef | grep dmserver來快速判斷實例是否正常。提示DM8 對目錄權(quán)限比較較真尤其是數(shù)據(jù)目錄如果使用非 root 用戶安裝務(wù)必保證該用戶對數(shù)據(jù)目錄有完整權(quán)限否則啟動時會報各種奇怪的權(quán)限錯誤。2. 環(huán)境搭建與初始化把第一個實例跑起來2.1 安裝前的前置檢查我在這步踩過一個典型的坑沒檢查系統(tǒng)依賴庫就開裝結(jié)果圖形界面起不來只能重新補包。在 Linux 上安裝 DM8需要先確認幾個基礎(chǔ)條件操作系統(tǒng)架構(gòu)x86_64 還是 ARM不同架構(gòu)要下載對應(yīng)安裝包。內(nèi)存建議至少 2GB 可用磁盤預留 10GB 以上因為安裝包本身和解壓后的文件都不小。需要 glibc 等基礎(chǔ)庫如果是精簡版系統(tǒng)建議用ldd檢查一下安裝盤里的可執(zhí)行文件依賴是否齊全。另外官方有圖形安裝、命令行安裝和靜默安裝三種方式。我在虛擬機里第一次用的是圖形安裝畢竟交互性強適合學習真正要批量部署的時候靜默安裝才是王道。2.2 靜默安裝其實更實用圖形安裝沒什么好說的下一步下一步就行。靜默安裝的好處是參數(shù)化、可重復適合以后在多臺機器上部署。官方提供了一個配置文件模板我按照模板改了關(guān)鍵路徑和端口后執(zhí)行./DMInstall.bin -q /path/to/install_conf.xml配置模板里核心是這幾個參數(shù)INSTALL_PATH/opt/dmdbms/INSTALL_PATH INSTALL_TYPEDATABASE/INSTALL_TYPE PORT5236/PORT DB_NAMEDAMENG/DB_NAME DB_INSTANCE_NAMEDMSERVER/DB_INSTANCE_NAME SYSDBA_PWDSYSDBA001/SYSDBA_PWD注意這里的SYSDBA_PWD是數(shù)據(jù)庫超級管理員密碼不是操作系統(tǒng)密碼。安裝完成之后一定要立刻改默認密碼這屬于最基本的安全習慣課程里反復強調(diào)實際生產(chǎn)也是如此。注意靜默安裝完成后默認會創(chuàng)建一個名為 DAMENG 的數(shù)據(jù)庫實例初始化參數(shù)是默認的。如果你對頁大小、字符集有特殊要求后面建庫時要用工具重新創(chuàng)建實例。2.3 初始化實例的關(guān)鍵參數(shù)選擇DM8 的實例創(chuàng)建可以用圖形化的“數(shù)據(jù)庫配置助手”也可以用命令行。我更推薦命令行方便記錄和復現(xiàn)。初始化實例時有兩個參數(shù)必須提前想清楚因為建庫之后很難修改第一個是PAGE_SIZE頁大小。DM8 支持 4K、8K、16K、32K 的頁大小。頁大小會直接影響單行最大長度、表空間文件最大大小以及數(shù)據(jù)庫的整體 I/O 行為。默認 8K 對絕大多數(shù)業(yè)務(wù)是合適的但如果你的業(yè)務(wù)涉及大字段、超長字符串建議直接上 16K。我在模擬項目 X 里因為一開始用了默認 8K后面設(shè)計表時發(fā)現(xiàn)某些 VARCHAR 長度組合放不下只能重建庫非常折騰。第二個是字符集。DM8 默認是 GB18030這是在中文 Windows 等環(huán)境下的老傳統(tǒng)但對現(xiàn)代業(yè)務(wù)來說UTF-8 是更通用且避免亂碼的選擇。我建議直接選UTF-8。命令行方式創(chuàng)建實例如下cd /opt/dmdbms/bin ./dminit PATH/opt/dmdbms/data DM_INI/opt/dmdbms/data/DAMENG/dm.ini \ PAGE_SIZE16 CHAR_CODEUTF8 CASE_SENSITIVE0這里我額外設(shè)置了CASE_SENSITIVE0意思是標識符大小寫不敏感。這個參數(shù)很影響使用體驗。默認情況下 DM8 是大小寫敏感的如果你從 MySQL 遷過來表名字段名習慣用大寫或者小寫很容易被這個坑到。對大多數(shù)業(yè)務(wù)應(yīng)用關(guān)掉大小寫敏感會更順手。2.4 服務(wù)注冊與啟停初始化完成后需要把數(shù)據(jù)庫注冊成系統(tǒng)服務(wù)或者至少知道怎么手動啟停。手動方式最簡單直接調(diào)dmservercd /opt/dmdbms/bin ./dmserver /opt/dmdbms/data/DAMENG/dm.ini前臺運行的方式適合調(diào)試因為日志會直接打到終端能第一時間看到啟動錯誤。確認正常后我習慣注冊成服務(wù)用項目里提供的腳本cd /opt/dmdbms/script/root ./dm_service_installer.sh -t dmserver -p DMSERVER -dm_ini /opt/dmdbms/data/DAMENG/dm.ini之后就能用systemctl start DmServiceDMSERVER這類命令管理了。3. 用戶的創(chuàng)建與權(quán)限體系邁過入門第一道坎3.1 DM8 的默認用戶不能只會用 SYSDBADM8 安裝后自帶幾個默認用戶這是很多新手最容易懵的地方。默認用戶里最重要是下面這幾個用戶名作用說明SYSDBA超級管理員擁有數(shù)據(jù)庫幾乎所有權(quán)限SYSSSO安全管理員管理安全策略、審計SYSAUDITOR審計員查看審計記錄SYS系統(tǒng)用戶持有系統(tǒng)表、字典SYSTEM系統(tǒng)用戶部分系統(tǒng)對象我第一次學的時候習慣性拿 SYSDBA 開干所有事后來課程里特別提醒正式項目不能這么干。DM8 的三權(quán)分立設(shè)計本質(zhì)是讓 DBA、安全管理員、審計員角色分離避免一個人權(quán)力過大。雖然小項目不一定要分這么細但至少應(yīng)該給應(yīng)用建獨立的業(yè)務(wù)賬號而不是拿 SYSDBA 連接業(yè)務(wù)應(yīng)用。建用戶的標準操作CREATE USER app_user IDENTIFIED BY App123456; GRANT CREATE SESSION, CREATE TABLE TO app_user; GRANT SELECT, INSERT, UPDATE, DELETE ON schema_name.business_table TO app_user;3.2 表空間從創(chuàng)建到配額表空間是數(shù)據(jù)庫存儲的邏輯單位每個用戶最好都指定默認表空間。我在課程中養(yǎng)成的習慣是一個業(yè)務(wù)域一個表空間數(shù)據(jù)文件獨立這樣后續(xù)做備份恢復的粒度會很清晰。CREATE TABLESPACE TS_APP DATAFILE /opt/dmdbms/data/DAMENG/TS_APP.DBF SIZE 2048 AUTOEXTEND ON NEXT 128 MAXSIZE 8192; ALTER USER app_user DEFAULT TABLESPACE TS_APP;這里要提醒一個細節(jié)DM8 表空間數(shù)據(jù)文件大小受頁大小影響頁大小 8K 時單個數(shù)據(jù)文件最大約 32GB16K 頁時最大約 64GB。如果建庫時就預期數(shù)據(jù)量很大直接選 16K 或 32K 頁后面省心。3.3 角色與最小權(quán)限原則DM8 內(nèi)置了幾種常用角色比如DBA、RESOURCE、CONNECT。這些角色解決的是批量授權(quán)問題但我實際操作后強烈建議寧可多寫幾條GRANT語句也不要圖省事直接給業(yè)務(wù)用戶DBA角色。國產(chǎn)化項目通常對安全審計有要求最小權(quán)限原則既是規(guī)范也是自保。課程里有個生動的例子某項目因為給報表賬號開了 DBA 權(quán)限后來排查數(shù)據(jù)問題時審計記錄里分不清是誰動了表責任界定的麻煩遠遠大于臨時授權(quán)的便利。4. SQL 實戰(zhàn)從建表到業(yè)務(wù)邏輯遷移4.1 數(shù)據(jù)類型和建表習慣DM8 數(shù)據(jù)類型整體上非常接近 OracleNUMBER、VARCHAR2、CLOB、BLOB都能直接用。同時它也支持 MySQL 風格的類型寫法比如INT、VARCHAR。這給遷移帶來了極大的方便但也會造成一個問題相同名稱的類型底層行為可能不完全一致比如VARCHAR的默認長度單位、是否支持 0 長度等。我建表時采用的策略是從 Oracle 遷移的表保持原類型不動從 MySQL 遷過來的表全部統(tǒng)一改成 DM8 的 Oracle 風格類型。雖然前期要花點時間做轉(zhuǎn)換但這能避免后續(xù) SQL 寫法出現(xiàn)隱式行為不一致。一個典型的建表示例CREATE TABLE T_ORDER ( ORDER_ID NUMBER(18) PRIMARY KEY, ORDER_NO VARCHAR2(32) NOT NULL, CUSTOMER_ID NUMBER(12), ORDER_AMOUNT NUMBER(12,2), STATUS CHAR(1) DEFAULT 0, CREATE_TIME TIMESTAMP DEFAULT CURRENT_TIMESTAMP, REMARK VARCHAR2(500) ); CREATE INDEX IDX_ORDER_CUST ON T_ORDER(CUSTOMER_ID); CREATE INDEX IDX_ORDER_TIME ON T_ORDER(CREATE_TIME);注意DM8 的注釋語句是COMMENT ON COLUMN T_ORDER.ORDER_NO IS 訂單號;和 MySQL 那種行內(nèi)COMMENT 訂單號不同做遷移腳本的時候要轉(zhuǎn)換。4.2 常用 SQL 寫法差異對照這部分是干貨中的干貨。我把自己平時最常用的一些 SQL 寫法在 DM8 和其他主流數(shù)據(jù)庫之間做了對照功能MySQL/其他寫法DM8 寫法分頁查詢LIMIT 10 OFFSET 20SELECT ... LIMIT 10 OFFSET 20; 也支持 ROWNUM 寫法字符串拼接CONCAT(a, b) 或當前日期NOW()SYSDATE 或 NOW()自增列AUTO_INCREMENTIDENTITY(1,1) 或序列觸發(fā)器空值排序NULLS FIRST/LAST 取決于數(shù)據(jù)庫默認 NULL 最大批量插入INSERT INTO ... VALUES (...), (...)支持多表值 INSERT也支持 INSERT ALL實際操作中分頁查詢我傾向于直接用LIMIT/OFFSET風格因為很多從互聯(lián)網(wǎng)業(yè)務(wù)轉(zhuǎn)過來的開發(fā)熟悉這種寫法。但如果 SQL 已經(jīng)用了 Oracle 的ROWNUMDM8 也兼容。4.3 存儲過程遷移大頭存儲過程是 DM8 兼容性的主力戰(zhàn)場。我建議拿一個真實的存儲過程做測試比看十頁文檔都有效。以我測試的一個示例存儲過程為例CREATE OR REPLACE PROCEDURE P_UPDATE_ORDER_STATUS( v_order_id IN NUMBER, v_new_status IN CHAR ) AS v_cnt NUMBER; BEGIN SELECT COUNT(*) INTO v_cnt FROM T_ORDER WHERE ORDER_ID v_order_id; IF v_cnt 0 THEN RAISE_APPLICATION_ERROR(-20001, 訂單不存在); END IF; UPDATE T_ORDER SET STATUS v_new_status WHERE ORDER_ID v_order_id; COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK; RAISE; END;這個寫法從 Oracle 遷移過來幾乎不用改。DM8 支持RAISE_APPLICATION_ERROR、EXCEPTION、自治事務(wù)PRAGMA AUTONOMOUS_TRANSACTION等PL/SQL 的大部分能力都有對應(yīng)實現(xiàn)。這也是為什么很多 Oracle 背景的項目選擇 DM8 時存儲過程遷移成本極低。4.4 數(shù)據(jù)裝載與導出dmfldr 和 disql數(shù)據(jù)遷移繞不開批量導入導出。DM8 提供了圖形工具“數(shù)據(jù)遷移工具”可以從其他數(shù)據(jù)庫直接遷。但我的經(jīng)驗是大批量數(shù)據(jù)在場內(nèi)做裝載時用命令行工具dmfldr更高效。dmfldr的作用類似 Oracle 的sqlldr用法也很直白。假設(shè)我有一個/tmp/order_data.csv字段之間用逗號分隔cd /opt/dmdbms/bin ./dmfldr USERIDapp_user/App123456 CONTROL/tmp/load.ctl DATA/tmp/order_data.csv控制文件load.ctl內(nèi)容示例LOAD DATA INTO TABLE T_ORDER FIELDS TERMINATED BY , TRAILING NULLCOLS ( ORDER_ID, ORDER_NO, CUSTOMER_ID, ORDER_AMOUNT, STATUS )這個工具我實測下來百萬行級別的數(shù)據(jù)導入是分鐘級比用圖形界面或者逐條 INSERT 好了太多。導出方面dexp和dimp是邏輯備份導入導出工具類似于 Oracle 的exp/imp后面?zhèn)浞菡鹿?jié)會說。5. 備份恢復與一致性DBA 能力的關(guān)鍵試金石5.1 備份方式全景DM8 的備份體系完整物理備份、邏輯備份都有。我建議按場景區(qū)分使用需求推薦工具說明數(shù)據(jù)庫全量物理備份DMRMAN 或 disql 內(nèi) BACKUP 命令恢復速度快適合正式環(huán)境增量物理備份DMRMAN可以基于某個備份集做增量邏輯導出dexp適合遷移、小數(shù)據(jù)量邏輯備份邏輯導入dimp對應(yīng) dexp 的導入端物理備份推薦用DMRMAN工具這是 DM8 的備份恢復命令行工具功能比較全。做了全量備份和增量備份之后它能維護一個備份集恢復時可以基于這個備份集做完整恢復。5.2 備份實操記錄我第一次做備份時圖形界面點了幾下就完事了后來發(fā)現(xiàn)命令行下更可控。全量備份命令如下cd /opt/dmdbms/bin ./dmrman CTLFILE/opt/dmdbms/data/DAMENG/dm.ini進入 dmrman 交互界面后執(zhí)行BACKUP DATABASE /opt/dmdbms/data/DAMENG/dm.ini FULL BACKUPSET /backup/dm_full_20250101;這條命令生成一個全量備份集。增量備份則是在全量基礎(chǔ)上執(zhí)行BACKUP DATABASE /opt/dmdbms/data/DAMENG/dm.ini INCREMENT BACKUPSET /backup/dm_inc_20250102;增量備份必須指定在上一次備份之后執(zhí)行DMRMAN 會自動追蹤備份鏈。這里有一個踩坑記錄備份路徑所在文件系統(tǒng)剩余空間不夠會導致備份失敗而且 DM8 的報錯提示信息在早期版本里不夠直觀只提示“磁盤空間不足”。所以做備份前先df -h檢查磁盤是職業(yè)習慣。5.3 恢復流程把實例恢復到指定時間點恢復的思路是先還原數(shù)據(jù)文件再恢復日志或增量備份。用 DMRMAN 恢復到某個時間點的操作大致如下RESTORE DATABASE /opt/dmdbms/data/DAMENG/dm.ini FROM BACKUPSET /backup/dm_full_20250101; RECOVER DATABASE /opt/dmdbms/data/DAMENG/dm.ini FROM BACKUPSET /backup/dm_inc_20250102; RECOVER DATABASE /opt/dmdbms/data/DAMENG/dm.ini UPDATE DB_INFO;完整恢復流程的執(zhí)行順序很重要如果順序反了DMRMAN 會報備份集不匹配可能還需要重新還原。我的練習方法是先備份然后往庫里塞一堆測試數(shù)據(jù)再模擬刪庫最后完整走一遍恢復流程檢查數(shù)據(jù)是否回到了備份點。這樣整套流程跑順之后心里才真正有底。5.4 高可用主備與共享存儲集群課程里還簡單介紹了 DM8 的高可用方案。主備架構(gòu)下主庫負責讀寫備庫通過日志同步保持數(shù)據(jù)一致安裝配置比裸跑實例復雜一些但核心思想并不難理解。做容災演練的時候我學到最重要的一句話是“備份是最后一道防線高可用是縮短恢復時間的手段兩者不能互相代替。”不管用主備還是共享集群日常備份都不能省。6. 實戰(zhàn)中的疑難雜癥與調(diào)優(yōu)記錄6.1 連接不上數(shù)據(jù)庫先別急著懷疑密碼我一共遇到過三次連接失敗其中兩次都是實例沒起來。DM8 的dmserver進程崩掉或未啟動時客戶端會報“網(wǎng)絡(luò)通信異常”但這容易讓人誤以為 IP、端口或者防火墻問題。排查順序建議是ps -ef | grep dmserver ss -lntp | grep 5236先確認進程和端口都在再去檢查連接串。這個順序能省大量排查時間。如果進程死掉了去看實例目錄下的日志重點搜ERROR關(guān)鍵字多半能直接定位問題。6.2 中文亂碼字符集不匹配是元兇亂碼問題在國產(chǎn)數(shù)據(jù)庫課程里幾乎必被提到。根源通常出在兩端數(shù)據(jù)庫字符集和客戶端字符集不一致。我之前在 DM8 建庫時選了 GB18030但應(yīng)用端連接的字符集是 UTF-8插入中文后查詢直接出亂碼。解決方案有兩種第一種最直接重建庫時把字符集改成 UTF-8一勞永逸第二種是在 JDBC 連接串上指定encodingGBK或者UTF-8參數(shù)但這是治標不治本。涉及多套系統(tǒng)協(xié)作時標準做法就是全局統(tǒng)一 UTF-8。6.3 慢 SQL 分析與執(zhí)行計劃DM8 查看執(zhí)行計劃的方式和 Oracle 很像可以在 disql 里打開執(zhí)行計劃開關(guān)SET AUTOTRACE ON; SELECT * FROM T_ORDER WHERE CUSTOMER_ID 12345;也可以在 SQL 前加EXPLAIN關(guān)鍵字查看計劃。我調(diào)優(yōu)時最常用的幾個方向確認索引是否被正確使用有沒有發(fā)生不必要的全表掃描。確認條件字段的類型與索引字段類型是否一致類型隱式轉(zhuǎn)換會導致索引失效。確認統(tǒng)計信息是否過期。DM8 在某些自動更新統(tǒng)計信息方面沒有主流數(shù)據(jù)庫積極大表數(shù)據(jù)量明顯變化后我會手動執(zhí)行DBMS_STATS.GATHER_TABLE_STATS(APP_USER, T_ORDER);來更新統(tǒng)計信息。一個真實記錄生產(chǎn)環(huán)境某條查詢之前毫秒級響應(yīng)后來數(shù)據(jù)量漲了百倍后直接秒級。排查發(fā)現(xiàn)舊統(tǒng)計信息里表行數(shù)還停留在一萬級別優(yōu)化器選擇了錯誤執(zhí)行計劃。分析后手動收集統(tǒng)計信息并重建了一個組合索引查詢恢復到了 50 毫秒以內(nèi)。6.4 內(nèi)存參數(shù)調(diào)整DM8 實例的內(nèi)存參數(shù)分成了很多池比如緩沖區(qū)BUFFER_SIZE、日志緩沖區(qū)等。最影響性能的一個是數(shù)據(jù)緩沖區(qū)BUFFER_SIZE。配置在dm.ini中修改后需要重啟實例生效。我一般先看監(jiān)控數(shù)據(jù)如果緩沖區(qū)命中率持續(xù)過低再逐步調(diào)大cd /opt/dmdbms/bin ./disql SYSDBA/SYSDBA001 SQL SELECT name, VALUE FROM V$PARAMETER WHERE NAME LIKE %BUFFER%;調(diào)整策略是讓數(shù)據(jù)庫整體緩沖區(qū)命中率保持在 95% 以上。如果命中率很低先別急著加內(nèi)存可能更應(yīng)該優(yōu)化 SQL 和索引邏輯。7. 一些值得長期堅持的習慣整套課程學完我有一個很深的體會達夢 DM8 不缺功能缺的是使用者的心態(tài)轉(zhuǎn)換。習慣了 MySQL 的人會覺得它部分系統(tǒng)表的寫法別別扭扭習慣了 Oracle 的人又會拿它跟正版 Oracle 比較覺得這里不如那里不熟。但實際上評價一個國產(chǎn)數(shù)據(jù)庫是否可用關(guān)鍵不在它與某一款數(shù)據(jù)庫的相似度有多高而在于它在你具體的業(yè)務(wù)場景里能不能穩(wěn)定、安全、可控地運轉(zhuǎn)。我在學習后期的做法是把 DM8 當成一個獨立產(chǎn)品來對待而不是某個數(shù)據(jù)庫的仿制品。遇到不熟悉的語法先查官方手冊遇到遷移問題先用小數(shù)據(jù)量測試遇到性能瓶頸認真分析執(zhí)行計劃而不是盲目加內(nèi)存。數(shù)據(jù)庫沒有什么玄學所有問題最后都能落到架構(gòu)、配置、SQL、數(shù)據(jù)分布這幾個硬因素上。如果你正準備學 DM8我個人強烈建議把課程里每一個練習都動手操作一遍尤其是備份恢復和權(quán)限管理光看不練容易眼高手低。另外用達夢的遷移工具做一次真實的業(yè)務(wù)庫遷移實驗比看十篇對比文章都管用。這東西說到底就是個工具判斷一個工具好不好拿起來干一把活最直接。