比較慚愧，在當上本版版主後一直沒有貢獻一篇有養分的帖子，因爲手上正好有達夢數據 DM6的版本，加上對ORACLE 10G比較熟悉，因此就這2種數據庫的異同點作一個對比，也請你們不吝賜教。 對於達夢數據庫，由於目前的工做是DBA，主要是對照了Oracle的一些概念來理解DM的，如下是我的的一些心得體會。 1.安裝與內存結構 環境是Red Hat 5.5,這個也是服務器比較經常使用的Linux系統。 DM沒有Oracle那麼多的系統參數要設定，並且也不須要創建專門的安裝用戶，直接把文件解包後就能夠安裝了，整個過程10分鐘左右就結束了，對於初學者來講仍是比較簡單的，而Oracle，當初剛學的時候，光是安裝就花了1天，要配置的參數比較多，還要新建用戶，對於不熟悉Oracle和Linux操做系統的人來講比較痛苦。 跟Oracle同樣，DM安裝完以後會把DM_HOME的路徑寫到用戶的.bash_profile文件裏面去，這樣在命令行打 cd $DM_HOME能夠直接進入DM的家目錄，不過DM並無把bin的命令路徑加到.bash_profile文件裏面，這樣要在命令行執行isql，dmcc這些命令就須要進入$DM_HOME/bin目錄下。爲了方便起見，能夠在root用戶根目錄下的.bash_profile文件裏面的PATH後面再加上 :$DM_HOME/bin，以下： Export DM_HOME=/opt/dmdbms PATH=$PATH:$HOME/bin:/opt/dmdbms/bin 這裏也能夠寫上絕對路徑，另外推薦一個小工具rlwrap，這個包是用來在命令行上下翻頁的，對於習慣了命令行操做的人來講非常方便，在Linux下安裝好以後一樣在bash_profile配置文件裏面加入一行以下： alias isql=`rlwrap isql` 這樣，在命令行執行isql命令時，實際上就至關於執行了rlwrap isql。 在DM安裝的時候選擇高級配置，會要求你選擇頁以及簇的大小，對於這個頁DM的文檔裏面說明是數據庫存放數據最小的單位，對應的就是Oracle裏的數據塊了，而簇是一組頁的集合，是存儲空間分配的最小單位，一個數據文件至少包含一個簇，單位是頁的個數，其對應的是Oracle裏面的extent，也就是區。 DM的邏輯存儲結構從上至下依次是：數據庫--文件組--簇--頁 oracle則是：表空間--段--區--塊 在這裏，表空間對應的是文件組了，而DM裏面我以爲應該也有一個段的概念，也就是用於存放一個數據庫對象的空間，好比表和存儲過程。一個段能夠包含多個簇或者區，在Oracle裏面，extent與extent之間的數據塊並不必定是連續的，可是單個extent內部的數據塊則必定是連續的，由於空間擴展的時候是按照連續的數據塊來分配的，我想對於DM的簇和頁的關係應該也是這樣設計的，這樣對應Oracle就很好理解了。 在內存方面，DM提供了MEMORY_POOL,BUFFER,LOG_BUFF和SORT_BUF_SIZE。 前面3個內存部分分別對應Oracle SGA裏面的shard_pool,buffer_cache和log_buffer. 其中MEMORY_POOL裏面存放的是SQL語句的執行計劃以及系統表和動態視圖。 BUFFER裏面則是存放DM所要讀取或者修改的數據，這裏DM提供2個機制，直接從硬盤讀取以及走文件緩衝，由參數direct_io來控制。經過BUFFER的好處就是DM不用頻繁地從硬盤讀取或者寫入數據，而是由DM的檢查點機制來控制寫數據的時機，這點也跟Oracle很相似，只是檢查點觸發的機制上有差別。 DM的BUFFER裏面也設計了3條鏈，自由鏈，乾淨鏈以及髒鏈 自由鏈上所記錄的是內存裏面還未使用過的內存塊。 乾淨鏈上所記錄的則是已經使用過但未作修改的內存塊，也就是進行select操做所讀入內存的數據塊。 而髒鏈則記錄讀入內存後通過修改而且尚未刷入到磁盤的數據內存塊。 Oracle的buffer_cache裏面也有相似的鏈，LRU鏈和髒鏈，LRU鏈對應的是DM的自由鏈和乾淨鏈的集合，全部可用的內存塊是在LRU鏈上進行查找的，髒鏈上所記錄的內存空間是不能被使用的。 DM的乾淨鏈也是採用的LRU算法進行管理的，當某個數據庫操做須要讀取數據進內存的時候，會先檢查自由鏈，看有沒可用的內存塊，若是有則直接使用，而且把這些內存塊移到乾淨鏈上，若是通過了修改則移動到髒鏈上。 若是在自由鏈上找不到可用的內存塊，則到乾淨鏈上根據LRU算法來決定哪些內存塊可被使用，若是在乾淨鏈上也找不到可用的內存塊，那麼就會觸發檢查點來把內存裏面的數據刷新到磁盤。 對於Oracle，是經過掃描LRU鏈的長度的百分比以及髒鏈上數據佔總的數據緩衝區大小的百分比來觸發刷新操做的，由於在實際的生產庫中，BUFFER_CACHE通常都設定的很大，掃描整個LRU鏈時間會比較長，因此Oracle就加了這麼一個機制。 DM有關這方面的參數控制我暫時還沒找到，有待進一步研究吧：）。 對於日誌緩衝區，log_buff，是用來記錄對於數據庫所進行的修改操做，也就是REDO，這點跟Oracle是一致的，其刷新的策略也跟Oracle一致，這個很好理解了。 對於Oracle的PGA部分，也就是用戶全局區，DM沒有專門的內存與之對應，應該是交由操做系統進行管理了，我只找到一個SORT_BUF_SIZE參數，是用來控制排序緩衝和索引重建的內存大小。 =============================================================================================================== 2.體系架構 跟Oracle同樣，DM的數據文件也分控制文件，日誌文件，數據文件三種，其中日誌文件又分爲*.rol和*.log，分別對應undo和redo。 跟oracle不同的是DM的控制文件分爲全局控制文件和局部控制文件，全局控制文件裏面存放的是當前DM的全部數據庫的控制文件的存放位置，在linux下可用strings命令來查看其內容，例如： [root@tiger database]# strings dm01.ctl CM11 -KgU SYSTEM /soft/dmdatabase/database/SYSTEM01.ctl /soft/dmdatabase/database/SYSTEM02.ctl test /soft/dmdatabase/database/test01.ctl /soft/dmdatabase/database/test02.ctl htyro /soft/dmdatabase/database/htyro01.ctl /soft/dmdatabase/database/htyro02.ctl 以上輸出表示當前的控制文件中一共記錄了3個庫，SYSTEM，test，htyro。其中SYSTEM是系統默認的庫，是在安裝軟件的時候系統默認創建的，其記錄一些全局的信息，對應Oracle的SYSTEM表空間。 這個庫很是重要，不能被脫機，一旦損壞，dmserverd服務將沒法啓動。 下面來看看局部控制文件中所記錄的信息吧，以上面的test01.ctl爲例，輸出以下： CD11 %s%t.log /soft/dmdatabase/database /soft/dmdatabase/database PRIMARY /soft/dmdatabase/database/test01.dbf ROLL /soft/dmdatabase/database/test.rol RLOG /soft/dmdatabase/database/test01.log /soft/dmdatabase/database/test02.log 能夠看到，其記錄的是當前數據庫test裏面的數據文件，日誌文件的存放位置。 全局控制文件和局部控制文件通常都有2個以上，互爲鏡像，內容都是同樣的，就是防止單個控制文件損壞了數據庫沒法啓動的狀況，建議存放在不一樣的磁盤。 另外須要注意的是，全局控制文件dm.ctl裏面所記錄的控制文件一旦有任何一個損壞，那麼dmserver則沒法啓動，而局部控制文件裏面所記錄的文件有損壞的話，只是其對應的數據庫沒法聯機，但並不影響其餘數據庫的正常運轉，因此無論是全局控制文件仍是局部控制文件都是至關重要的 在運行機制上，Oracle是一個實例對應一個庫，也只能對應一個庫，而DM則是一個實例對應多個庫。DM的每一個數據庫都有本身單獨的控制文件，日誌文件以及回滾段文件，這個也與Oracle的單實例的結構相同，所不一樣的是臨時文件TEMP是全局的，也就是多個庫都是使用的同一個臨時文件。 ============================================================================================================== 3.用戶登陸 在DM的使用方面，剛開始確實很不習慣，一個首要的緣由就是DM把傳統的用戶拆分爲登陸＋用戶，致使我在登陸數據庫的時候老是習慣性的寫上用戶名而不是登陸名。 同oracle同樣，DM的權限賦予以及回收也是在用戶層面上的，實際操做數據庫的仍然是用戶，可是把鏈接這個環節單獨拿出來作成了一個登陸（login)的概念，一個用戶必需要與一個登陸相關聯才能夠正常使用數據庫，不然即便你是DBA沒有與之關聯的登陸也是操做不了數據庫的，就比如你住在某個高檔小區，下面的門須要一把鑰匙，進你家的門也須要一把鑰匙，登陸就至關於進入公共區的鑰匙，只有住在這個單元的人或者管理人員纔有，而用戶則至關於私有區也就是你家大門的鑰匙，只有你纔有。 不知道這個比方是否夠清楚：），反正我也是繞了很久。 DM使用這樣的機制，是對應其三權分立的權限管理模式，除了sysdba ,還有syssso和sysaudit 2個用戶，其中syssso就是管理登陸的，這樣的管理機制對於單純的DBA管理安全性要高。而sysaudit則是安全審計員，專門用於記錄及監視對數據庫所進行的操做，在Oracle裏面audit（審計）也是DBA的工做，DM則單獨把這個權限獨立了出來，從必定程度上也減輕了DBA的負擔。 與Oracle同樣，DM除了能夠把單獨的權限賦給用戶以外，還能夠創建一個角色(role)，而後先把權限賦予角色，再把角色總體權限賦給用戶，這種在生產庫裏面比較經常使用，特別是開發庫中，要新增一個user的話，要賦不少權限，若是事先定義好其對應的角色，經過角色授予權限則會簡單的多。 ============================================================================================================== 4.數據庫啓動以及系統日誌 數據庫的啓動信息以及系統的日誌記錄信息是DBA重點關注的內容，這裏也結合一下Oracle的機制來學習DM。 Oracle的啓動是分3個階段的： nomount: 此階段加載配置文件以及啓動本實例的後臺進程 mount: 此階段加載配置文件裏面所記錄的控制文件 open: 此階段則是打開控制文件裏面所記錄的數據文件 Dm的啓動則只有一個過程，這點經過監視DM的後臺日誌能夠看到，如下是我在啓動階段監視$DM_HOME/log/dm_00.log系統日誌的內容： tail -f $DM_HOME/log/dm_00.log 2010-09-29 09:31:21 database T-1208297792 DM Database Server startup... 2010-09-29 09:31:21 database T-1208297792 check point start (1, 0, 100) ... 2010-09-29 09:31:21 database T-1208297792 redo log flush ... 2010-09-29 09:31:21 database T-1208297792 system buffer flush ... 2010-09-29 09:31:21 database T-1208297792 check point end. 從上面內容能夠看到，DM只有startup這個過程，接下來就會觸發一個檢查點來刷新內存。但實際上，DM也是有本身的參數文件的，在$DM_HOME/bin目錄下，名稱是dm.ini，其記錄數據庫的一些全局的參數，前面三行內容以下： #files location CTL_PATH1 = /soft/dm6/dmdatabase CTL_PATH2 = /soft/dm6/dmdatabase TEMP_PATH = /soft/dm6/dmdatabase 這個是指明全局控制文件以及臨時文件TEMP的存放路徑，而Oracle的pfile/spfile裏面也存放了控制文件的路徑，因此這個dm.ini參數能夠參考Oracle的pfile來學習。 注意爲何是pfile而不是spfile呢？由於spfile是Oracle爲了能讓某些修改在數據庫運行的狀況下就能夠進行即動態修改，而專門從pfile轉換而來的一個二進制文件，其內容跟pfile是同樣的，可是若是使用pfile就只能靜態修改，即修改以後須要重啓數據庫才能生效。DM目前還不支持動態的全局參數修改，須要先停庫，而後再修改，因此說dm.ini和pfile是很相似的。 由於手上沒有DM內部運行機制的資料，因此無從瞭解DM的完整的啓動機制，可是從DM的參數結構配置來看，我的猜想DM啓動也是先讀取dm.ini參數文件爲數據庫實例搭建好啓動環境，指明全局控制文件和臨時文件的位置，而後再讀取全局控制文件找到局部的控制文件，最後讀取局部的控制文件找到數據文件，而後再OPEN。這樣理解起來就很快了，也沒什麼障礙。 關於系統日誌文件，我目前只在$DM_HOME/log下面找到了，相比Oracle種類繁多的日誌，DM就簡單許多了，總之把$DM_HOME/log/dm_00.log當作是Oracle的後臺日誌alert_sid.log就對了，數據庫啓動以及恢復以及檢查點的信息都記錄在這個日誌文件裏面，經過監控能夠看到，備份的信息也會記錄到DM的日誌文件。 =============================================================================================================== 5.數據庫的基本操做以及系統視圖 DM的SQL是兼容SQL92標準的，因此絕大多數操做與Oracle沒什麼區別，我測試了幾條select,update,delete語句，與Oracle的是徹底一致的，這點上沒什麼問題。 命令行的登陸方式也比較相似： Oracle: sqlplus user/password@host DM: isql user/password@host 若是是本機，則host能夠省去，若是是遠端服務器，則HOST須要指明遠端的服務器名或者IP地址。 在這裏須要說明的是Oracle若是是本機直接用Oracle登陸，那麼不須要用戶名和密碼便可使用DBA模式，而登入遠程服務器時才須要使用密碼驗證。而DM則無論是本機仍是遠端的機器，都須要提供登陸名/密碼，並且我查看了相關的文檔，也沒有看到有能夠在命令行修改SYSDBA密碼的命令，也就是說DM的登陸密碼修改必須進入數據庫系統以後才能操做，若是忘記了DBA的登陸密碼會比較麻煩，暫時我還沒想到好的解決辦法，而Oracle則提供有orapwd命令用於從新設定DBA用戶的密碼。 對於執行過程的建立以及執行DM跟Oracle的語法基本一致，DM也兼容PL/SQL,因此在這個上面倒不須要另外花時間來掌握。爲了兼容Oracle, DM也提供了exec 來調用procedure的方式，可是推薦用call的方式來調用。 另外Oracle的信息打印輸出是用的其自帶的系統執行過程 dbms_output.put_line()來實現的，而DM 則是經過 print的方式，瞭解清楚了這個，對於之後Oracle的移植頗有幫助。 Oracle在邏輯上提出了模式(schema)的概念，但實際上並無schema關鍵字的視圖，可是有user_object的視圖，實際就是用戶下面的全部對象的集合，好比下面的操做： select * from scott.emp; 表示查詢scott用戶下的emp表，實際也能夠理解爲訪問scott模式（集合）下的emp表。 Oracle默認是每一個用戶在建立的時候會同時再創建一個schema（集合），也能夠理解爲一個容器，裏面存放的是全部屬於該用戶的對象，好比表，索引，存儲過程，函數，包等等。在Oracle裏面不能單首創建schema,一個用戶只有一個schema(模式）。 而DM則把schema的概念更加清晰化了，系統在建立用戶的時候會默認建立一個與該用戶同名的schema，而且還提供了create schema at database authorization user命令來單獨的建立屬於某個用戶的schema，也就是說一個用戶能夠擁有多個schema，這樣就便於用戶把不一樣的對象放到不一樣的可是屬於本身的schema裏面，方便管理。 相對於Oracle,DM所提供的系統視圖並很少，不過關鍵的視圖都有了，好比systables,sysindexes這些。 Oracle的系統視圖結構比較龐大，不只僅dba能夠查看全局的視圖，普通用戶也能夠查看本身所擁有的對象的視圖好比user_tables,user_indexes等等。 而DM對於單個用戶則沒有提供這些視圖，DM的視圖和系統表是針對數據庫實例（全局）和單個數據庫（局部）的，而動態性能視圖如v$buffer則是隻有SYSTEM數據庫纔有的，用於查看整個數據庫實例的動態信息，而其餘一些系統表好比systables,sysindexes等等則是每一個數據庫本身會生成一份，存放在各個數據庫的sysdba模式下面，默認的擁有者是系統管理員DBA。 我的但願DM在後面的版本里面可以增長更多的系統表和視圖，以及對現有關鍵視圖的信息更加完善，從DBA的角度來講，這些系統視圖也是維護數據庫的一個很重要的信息來源。 =============================================================================================================== 6.數據庫的備份與恢復 做爲一個DBA，數據庫的備份是其最重要也是最常要作的操做，這裏我也結合一下Oracle的備份恢復機制來講一下對DM的備份恢復機制的理解。 Oracle和DM的數據庫運行模式都有歸檔模式和非歸檔模式，通常狀況下數據庫都運行在歸檔模式下，由於在歸檔模式下全部的聯機日誌都是有備份的，這樣能夠最大可能的保證數據庫數據的完整性，而非歸檔模式則不會備份聯機日誌，通常只在不過重要的數據庫上才使用非歸檔模式，如下的備份恢復均是在歸檔模式下進行的。 Oracle的備份可分爲操做系統層面的備份（直接COPY）和用數據庫工具的備份（rman),而操做系統層面的備份又分爲冷備和熱備，即在停庫狀況下的備份和數據庫運行狀況下的備份。 rman備份則手段更多，也更靈活，而且管理起來也更加方便。 DM的備份也分爲聯機備份和脫機備份，實際都是利用DM的數據庫命令來完成的。DM目前不支持操做系統層面的備份，即冷備，我作了一下測試： a. 在T1時刻中止數據庫服務，把數據庫TEST所對應的TEST01.dbf文件複製一份到備份目錄中，從新啓動數據庫。 b. 在T2時刻創建測試表T1於數據庫TEST上（T2>T1),而後嘗試插入若干條數據，再提交。 c. 在T3時刻中止數據庫服務，把 a 步驟所備份的TEST0.dbf從新複製回來，覆蓋T2時刻創建了表T1的數據文件。 d. 從新啓動數據庫服務，發現數據庫TEST也能夠正常啓動，可是查詢表T1發現不存在此表，可是T1時刻的數據都在，可是T1－T2這個時間段的數據就丟失了。 我查了一下DM的文檔中有關備份恢復的部分，DM的恢復也是分restore和recover兩步的，但只提供了restore命令，recover動做是跟restore綁定在一塊兒的，經過在restore命令裏面設定archivedir的路徑來讓數據庫自動應用歸檔日誌來對數據庫進行恢復。因此對於冷備份的數據文件，DM沒有提供單獨recover的機制來應用日誌到數據文件上，因此在目前的DM體系架構中，使用操做系統的COPY命令來備份數據庫意義不大，推薦使用DM的backup命令來進行備份，這樣備份才能跟歸檔日誌結合在一塊兒進行恢復。 另外須要註明的是，DM的SYSTEM數據庫不能經過脫機恢復，因此此數據庫損壞的話，只能中止數據庫，而後經過DM所提供的restore命令來進行恢復，該命令位於$DM_HOME/bin目錄下，此命令與聯機方式下的普通數據庫恢復的restore命令功能不同，其使用方法以下： RESTORE ini_path bak_path [-T | -t res_type] [-U | -u until_time] [R | -r arch_num arch_dirs] [-A | -a arch_flag arch_style arch_dir] [-B | -b bak_dir] [-D | -d db_name] 其中，dm.ini 文件和備份文件的地址是必需要指定的，然後面的參數是可選的。 而在Oracle中，restore和recover是兩個操做步驟，是分開的，因此冷備份數據文件也是有意義的，把冷備的數據文件COPY回來以後，只要備份時間到當前的歸檔齊全，就能夠執行recover動做來使得數據庫一致。 跟oracle同樣，經過數據庫所提供的工具/命令來對數據庫進行備份的時候，數據庫能夠在online狀態下，而對數據庫進行恢復的時候，則要使被恢復的數據庫處於offline狀態，恢復完畢以後再把數據庫置於online狀態。 在DM中，能夠動態修改數據庫的歸檔模式，命令以下： alter database test archivelog; --------------設置爲歸檔模式 alter database test noarchivelog; --------------設置爲非歸檔模式 這個參數在Oracle裏須要在數據庫mount的狀態下進行修改，是記錄在控制文件裏面的，DM裏面我暫時還沒發現這個參數記錄在哪裏，可能也是記錄在控制文件裏面的。總之DM修改數據庫的歸檔模式不須要重啓，而Oracle修改歸檔模式則須要重啓庫。 下面我在命令行對測試庫TEST來進行一次備份以及恢復的操做以便綜合掌握DM的備份恢復機制。 1.命令行登陸DM，對TEST作一次全備，備份名爲test_bak: [root@chris dmserver]# isql sysdba/728911@localhost isql V6.0.2.72-Build(2010.08.02) login success SQL>backup database test to test_bak bakfile '/soft/dm6/test001.bak'; backup database test to test_bak bakfile '/soft/dm6/test001.bak'; time used: 7352.304(ms). 2.刪除數據庫TEST的數據文件，聯機日誌文件以及UNDO文件，重啓數據庫服務，在後臺日志裏面發現以下信息： 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST.rol, code: 2 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST01.log, code: 2 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST02.log, code: 2 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST03.log, code: 2 2010-09-29 14:02:22 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST.rol, code: 2 2010-09-29 14:02:22 database T-1208138048 fail to open db file /soft/dm6/dmdatabase/TEST.rol 數據庫服務仍然能夠啓動，只不過TEST數據庫是脫機的，沒法訪問。 3.對數據庫TEST進行恢復，命令以下： SQL>restore database test from '/soft/dm6/test001.bak' set archivedir to '/soft/dm6'; restore database test from '/soft/dm6/test001.bak' set archivedir to '/soft/dm6'; time used: 7371.193(ms). 同時，在後臺日志裏面也能夠發現以下信息。 2010-09-29 14:08:23 database S-1233137636 restore using /soft/dm6/test001.bak with 0 2010-09-29 14:08:31 database S-1233137636 restore end. 恢復成功後再使用命令alter database test set online來把數據庫TEST啓動起來便可。 整個備份以及恢復的過程跟Oracle很類似，Oracle經過RMAN備份格式以下： rman> backup database full format '$ORACLE_BASE/backup/bak_%U'; 而oracle恢復的過程也是先把須要恢復的表空間或者數據文件offline,而後進行restore和recover操做，最後再執行online動做。 DM與Oracle都提供了完整備份和增量備份的方式，不過說實話增量備份在生產庫中用的很少，拿我以前的庫來講，由於用到了DATA GUARD，我是每週末在備庫上進行一次完整的備份，同時刪除2周以前的備份以及歸檔，保證整個數據庫有2份可用的備份以及能夠銜接的歸檔日誌便可。 DM目前版本的備份只包含了數據文件，日誌文件以及UNDO文件，對於在歸檔模式下所生成的歸檔日誌以及控制文件和DM.INI參數文件還沒法備份，因此歸檔日誌的存放路徑必定要規劃好，在大的數據庫裏面必定要留足夠的空間來存放歸檔，控制文件和參數文件則可經過腳本的方式按期備份。 總的來講，DM的備份與恢復仍是要比Oracle要方便的，特別是利用管理工具，操做很直觀，不過這裏使用命令行來進行操做印象會更加深入。 以上是我在初步使用了達夢數據庫的一點體會吧，整體上來講DM的體系架構綜合了Oracle和Mysql，運做方式上來看跟Oracle更加類似，從內存結構到數據文件的類型再到備份恢復的機制均可以在Oracle裏面找到熟悉的部分，若是對Oracle的系統架構很熟悉的話，學習DM也是水到渠成的事了。 另外，對於DM的集羣以及主備機的機制則跟Oracle有較大的不一樣了，我目前也還在看相關的文檔，雖然DM的主備與Oracle的DG模式都是利用的日誌傳遞的方式來保持主備機器的數據一致性，可是由於DM多了一個登陸的概念，因此在具體的實現機制上仍是有所差別的，而DM的集羣則跟Oracle結構徹底不同了，DM的集羣是在主備機的基礎上加以改進，讓主機和備機都能跟外界通訊，主備之間採起的環形消息傳遞機制，而且每一臺機器都是獨立的數據庫，而Oracle則採用把數據文件存放在共享存儲上面，多臺服務器對共享存儲及同一份數據文件進行操做的方式來運做的，機制是徹底不同了。 數據庫, Oracle, 數據, 版本, 工做
