達夢6.0試用之架構篇

前幾天ITPUB的熊建國主編和我聯絡，希望我能參加國產資料庫達夢的適用活動，並寫幾篇使用感受。本來最近手工的事情比較多，本打算推辭的，不過熊主編再三邀請，而且強調並非是槍手文，只要寫出真實使用感受即可。既然如此，我就本著支援國產資料庫的原則，寫幾篇試用感受。

由於本人唯一熟悉的資料庫就是Oracle，因此所有的對比都是與Oracle資料庫進行對比，在這個過程中，將盡可能避免將對Oracle資料庫的喜愛之情帶進來，爭取站在一個比較公正的位置上來進行評價。

這一篇簡單介紹一下達夢資料庫的系統架構。

 

 

Oracle的資料庫分為兩個部分，例項和資料庫。例項由記憶體和程式組成，而資料庫部分由檔案組成。

而達夢資料庫在安裝過程中似乎並沒有配置什麼和記憶體相關的引數，莫非達夢資料庫並沒有獨立的記憶體管理機制。

Oracle、SQLSERVER、DB2等大型資料庫與ACCESS、EXCEL等小資料量資料庫之前的一個重大區別就是前者擁有獨立的記憶體管理功能，而後者只是一個作業系統上執行的應用程式，記憶體的分配和使用完全透過作業系統實現。

查詢了一下達夢的管理員文件，發現達夢還是存在記憶體管理功能的，不過達夢的記憶體管理顯得十分的簡單。

達夢資料庫總共包括3部分記憶體結構：資料緩衝區、日誌緩衝區和共享記憶體池。

其中資料緩衝區用來快取資料庫中讀取和修改的資料塊，這部分由3個連結串列結構組成，分別是自由連結串列、乾淨鏈和髒鏈。這部分的記憶體結構和Oracle中的DB_CACHE部分類似；

日誌緩衝區用於寫入系統日誌檔案的緩衝，型別於Oracle中的LOG_BUFFER部分；

而共享緩衝區和Oracle中SHARED_POOL並不相同，主要用於達夢資料庫小片記憶體的申請和釋放。似乎達夢中並沒有明確的共享池以及資料字典緩衝區的概念。如果是這樣，那麼顯然不存在SQL語句重用的情況，也就是說對於所有的語句都是硬解析，這勢必會對系統的併發性造成影響。

在達夢資料庫中處理一些大資料量的表，然後在Windows的任務管理區中觀察達夢資料庫使用記憶體的情況。開始的時候達夢佔用了50M的記憶體，當透過isql登陸資料庫後，資料庫使用記憶體增加，但是幅度很小。隨著處理表資料量的增大（僅包含一個NUMBER型別的表），插入資料量達到100000的時候，達夢使用記憶體增加到了90M，隨後資料量達到了1600000，而達夢使用的記憶體也達到了325M左右。當一段時間不再使用後，發現達夢資料庫使用記憶體的空間又下降到100M左右。看來達夢的記憶體管理並不是預分配定額的記憶體，而是隨著處理資料的增加而不斷分配的，而且當一段時間不使用後，達夢資料庫還會將部分記憶體釋放給作業系統。從這一點看，達夢雖然擁有自己的記憶體管理系統，比ACCESS、EXCEL之類的資料庫要專業一些，但是與當前的主流資料庫還是有較大的差距，一方面記憶體管理體系過於簡單，只能實現最簡單的資料緩衝功能；另一方面，記憶體管理機制與作業系統繫結過於緊密，頻繁的從作業系統分配記憶體，或釋放空閒記憶體給作業系統，勢必降低記憶體分配和管理的效率。

下面看看達夢資料庫的檔案部分。但是在開始之前，還是先要了解一下達夢資料庫的邏輯結構。

達夢資料庫的邏輯結構顯然和Oracle有很大區別，而於SQLSERVER、SYBASE等資料庫比較相似。在達夢資料庫中存在多個DATABASE的概念，每個DATABASE由一個或多個資料檔案組成。使用者和DATABASE之間沒有一一對應的關係。也就是說只要擁有許可權，使用者可以讀寫任何資料庫中任何資料檔案中的物件，因此DATABASE的概念和Oracle的TABLESPACE有十分類似。

達夢資料庫也是由資料檔案、日誌檔案、控制檔案和引數檔案組成的。

E:\>cd e:\dmdbms\data

E:\dmdbms\data>dir /oe
 驅動器 E 中的卷沒有標籤。
 卷的序列號是 9037-19E7

 E:\dmdbms\data 的目錄

2010-04-09  21:40   

          ..
2010-04-09  21:40              .
2010-03-30  20:48             4,096 dm.blt
2010-04-09  12:25            16,384 dm01.ctl
2010-04-09  12:25            32,768 BOOKSHOP01.ctl
2010-04-09  12:25            32,768 test02.ctl
2010-04-09  12:25            32,768 BOOKSHOP02.ctl
2010-04-09  12:25            32,768 test01.ctl
2010-04-09  12:25            32,768 SYSTEM01.ctl
2010-04-09  12:25            32,768 SYSTEM02.ctl
2010-04-09  12:25            16,384 dm02.ctl
2010-04-12  00:35        17,825,792 SYSTEM.DBF
2010-04-12  01:10        47,185,920 TMPDB001.dbf
2010-03-30  20:56        33,554,432 BOOKSHOP.DBF
2010-04-12  00:51        10,485,760 TMPDB000.dbf
2010-04-12  01:10       104,857,600 test.dbf
2010-04-12  01:10        67,108,864 SYSTEM01.log
2010-03-29  17:18        67,108,864 SYSTEM02.log
2010-04-12  01:06       293,601,280 test02.log
2010-04-12  01:10        67,108,864 BOOKSHOP01.log
2010-03-29  17:19        67,108,864 BOOKSHOP02.log
2010-04-12  07:56       486,539,264 test01.log
2010-04-09  12:25               613 dm_service.prikey
2010-03-30  01:03       134,217,728 BOOKSHOP.rol
2010-04-09  21:40       134,217,728 SYSTEM.rol
2010-04-12  07:56       187,695,104 test.rol
              24 個檔案  1,718,850,149 位元組
               2 個目錄  3,572,424,704 可用位元組

這是一個達夢資料庫的檔案組成，可以看到，字尾為CTL的是控制檔案，字尾為LOG的日誌檔案，而字尾為DBF是資料檔案，而字尾為ROL是回滾資料檔案。另外prikey結尾的顯然是註冊檔案。

資料庫的引數檔案dm.ini沒有儲存在當前目錄中，而是儲存在達夢資料庫的安裝目錄的可執行檔案路徑下C:\DMDBMS\BIN。

其中控制檔案又有全域性和區域性之分。全域性控制檔案是dm01.ctl和dm02.ctl，兩個檔案內容相同互為備份，裡面儲存所有區域性控制檔案的資訊。

對於資料庫中每個DATABASE，都會存在一個或多個資料檔案，一個或多個回滾資料檔案，一對控制檔案和一對日誌檔案。這顯然和Oracle中的結果大相徑庭，在Oracle中，控制檔案和日誌檔案以及UNDO表空間都是對應整個資料庫而言，而不是針對資料庫中的某個子結構。

在一個資料庫對應的控制檔案中，記錄資料庫的資料檔案的位置，回滾資料檔案的位置，以及日誌檔案的位置。

達夢中臨時檔案是針對整個系統，而不是每個資料庫都對應一個臨時資料檔案。在系統中存在一個臨時資料庫，這個資料庫並沒有對應的控制檔案、日誌檔案和回滾資料檔案，只是存在對應的臨時資料檔案。

在資料庫中總是存在一個SYSTEM資料庫，這和Oracle的SYSTEM表空間比較相似，都是用來儲存資料字典等資料庫正常執行所必須的結構和資料。

由於對於這種多資料庫的環境還不是很熟悉，也確實這種環境下的日常使用和維護經驗，因此現在不好評價這種對於每個DATABASE（相當於Oracle中的TABLESPACE）分別設定控制檔案、日誌檔案和回滾資料檔案的優缺點。不過根據當前這種結構可以推測一些優缺點。優點在於將業務資料和系統資料區分開，甚至不同的業務資料也可以分離開，這種分離比Oracle中的分離更加徹底，因為對應的日誌、控制檔案和回滾資訊都是分離的。至於這種分離能否帶來效能上的優勢，或者備份、遷移上的便利，還需要測試才能確定；而缺點也顯而易見，至少系統的複雜度被增加了。而且由於控制檔案、日誌檔案和回滾資料檔案對於每個DATABASE都單獨放置，很明顯會佔用更多的儲存空間，同時也使得備份和恢復會更加的複雜。