分散式資料庫及表格複製Table Replication

DBMaker有著另項強大的功能：「分散式資料庫」，但使用者往往忽略；本篇旨在說明，在什麼樣的環境需要使用這樣的功能，及這項功能能帶給使用者的好處。

1. 為什麼需要使用分散式資料庫

簡單地說，資料庫基本上是採集中式管理，但現實生活裏，使用者卻可能分佈在各地。若是使用者處於零散且無規律的地理位置，那麼使用Web或AP Server，來存取資料庫，宛如有個代理人幫您服務，這樣似乎是最好的解決方式，但現實生活中，使用者往往是聚集成數個大「群體」，常見的便是散佈在「分公司」的使用者。

那麼，若將資料庫放置到一個集中地點(例如：台北)，固然是管理上較為方便，但是台中、高雄的使用者，卻要忍受較慢的網路頻寬。

同時，有些地域性的資料，事實上存放在台北總行，並不見得合理，總行可能須要的是台中、高雄的統計性資料，而不需要知道台中分行的雜支費用、電話費用等細部費用。

以人事資料為例，台北有台北的人事資料，台中、高雄也都有各自的人事資料，若在設計表格時，可能會用以下這個方式來設計：

人事表格

姓名	員工編號	…	…	所在地
Sharon	001	…	…	台北
Alen	002	…	…	台中

或是：

台北人事表格

姓名	員工編號	…	…
Sharon	001	…	…

台中人事表格

姓名	員工編號	…	…
Sharon	001	…	…

想一想，所有的應用程式及使用者，必須從台中、高雄直接連接到台北來存取資料庫，可能會花上極為昂貴的時間成本，而所要得到的資料，可能竟是「台中」自己的人事資料!

「分散式資料庫」的設計理念便是：「將一個邏輯性的總體資料庫，分散成數個實體資料庫。」例如，上述公司資料庫，是一個邏輯的整體，我們可將它化整為零，用數個實體資料庫散佈在台中、高雄，如此一來，上述問題便可臨刃而解。

2. 分散式資料庫設計

(1)   橫向分割

橫向分割，即是台北、台中、高雄各地的資料庫，彼此有著相同的結構，而各自存放各自專屬的資料；例如：各地資料庫都有人事、會計、倉儲…等等表格，只是台中放台中的資料，台北放台北自己的資料。

(2)   垂直分割

縱向的垂直分割，便是功能別的切割，例如會計、人事資料放在台北總公司，但由於高雄是倉庫，故倉儲表格放在高雄，若廠商多在台中，那麼廠商、進貨等相關表格就放台中，主以功能別為導向。

(3)   綜合

現實考量上，上述結構未必符合實際需求，所以實際的例子中，往往是綜合上述兩種方式，調整出符合自身需求的架構，例如：倉儲資料可以分佈在各地，而人事、財務方面的資訊可以統一放在台北，方便管理；針對需求面，作兩方面綜合性設計。

1.        功能特性分析

以上圖來說明，實體有三個資料庫，但整個可視作一個邏輯上的資料庫。

在切割時，我們可先將整個系統的存取關係繪製成圖，然後檢視各個表格所含括的是何資料，各個功能又會去存取那些表格資料。

上圖中，以一個「訂貨-出貨」的功能來看，首先User必須先從「客戶-員工-產品」組成一張訂單，新增一筆應收帳款到會計表格、一張出貨單到出貨表格，及減少倉儲資料中存貨的數量。

客戶名單是否有地域性因素?若是台北的user，面對的幾乎都是台北的客戶，台中的user卻幾乎不會處理到台北的客戶，那麼客戶名單列成三份，各地處理各地的，就十分合理。

但是公司的員工，就沒有充分理由割成三地，所以三地的使用者，應該要用同一份的員工名單；同樣的，三地所面對的產品資料亦應一致。

接下來是組合成的訂單，參酌公司條件，在「訂貨-出貨」的動作中，台北下的訂單，與高雄下的訂單，三地資料可獨立，新增「應收帳款」到會計表格也是一樣，三地可各自獨立；(但如果現在總公司要進行「會計」相關的功能，使用者面對的應該是總體的訂單資料，分成台北、台中、高雄並沒有太大的意義)。

倉儲資料應是最地域性的，只要新增一張出貨單到各地倉儲即可，現在以台中的使用者為例，接到台中客戶訂單，在高雄出貨，製圖如下：

再次強調，這樣的架構還是要依公司需求為主，有些公司就不認為客戶資料須要有特別的地域化，而是全公司都使用同一份客戶資料。

我們必須以「功能」(例如：上述的訂單動作)來評斷「分割」的理由性，例如：訂單資料，目前暫定為「分割」，台中組合成的訂單放在台中自己這裏，但是若是現在要作全公司的訂單統計時，這樣的分割反而不好。參酌公司的各項「功能」後，給予衡量權數，來評定「分割」的理由充分性，例如「倉儲資料」的理由性就很夠，因為任何一個倉儲功能(例如：盤點)，不太可能叫台北總公司的人去進行各分公司的盤點，而是交給各地倉管人員，所以在此已經確定倉儲必須分割。

2. 網路速度

接下來，在作這方面的規劃時，也要考量到網路的速度，因為地域性的遠近常伴隨著一個問題，便是網路速度無法像區域網路這般快速，若是集中式的資料(如圖中的會計、財務表格)需要常常被存取的話，那麼台中、高雄常常要到老遠的台北作資料存取、異動，這樣的規劃反而會拖跨效能，不見得好。

3. 因應需求及分析，折衷決定最後架構

3. DBMaker分散式資料庫的使用

(1)   分散式資料庫的設定步驟

在DBMaker中，要使用分散式資料庫非常的簡單，只要購買的授權範圍內許可，只要在dmconfig.ini中加上DD_DDBMD=1，重新啟動資料庫，便發生效果了。

使用者可以使用「select * from SYSUSER」，會發現多了一個GTRECO_D的daemon，這個Daemon主要的功用是用來作「全域交易」的管理(Global Transaction)，何謂「全域交易」呢??一般的交易多發生Local的資料庫內部，但是全域交易須要與外部的實體資料庫作連接，所以必須要考慮網路是否穩定、對方資料庫的constraint限制，這種機制多是用「二階段commit」來實作。

兩階段commit的意思是說，當應用程式連至DB_A要進行交易，同時此交易會去更動DB_B的資料庫內容，此時不會逕行對DB_B作commit的動作，而是先去詢問：「DB_B是否允許commit??」，當DB_B回答「可」時，才會在第二階段真正執行Commit，這當中，由於需要各個參與者，對協調者作出回應，故稱之為「全域交易」。GRECO_D便是在進行這樣的協調工作。

注意，在參與者的DB兩端，都需設定DD_DDBMD=1，但對於對方的設定，則無需設定此keyword(此keyword只在Server端發生效用)。但兩邊對當地的DB都需設定，如下例所示：

在Site A

[DB_A]

….

DB_DDBMD=1

[DB_B]

…

(無需設定)

Site B

[DB_B]

….

DB_DDBMD=1

[DB_A]

…

(無需設定)

兩邊重新開啟DB後，兩者就可說是已經同是參與者了。現在使用工具進入DB_A，若是想要知道DB_B的資料，只要下達：

select * from DB_B:OWNER_NAME.TABLE_NAME;

便可擷取遠方資料。

(2)   分散式資料庫的權限控管

另外要注意的是：由於這屬於「分散式資料庫」，儘管各個參與資料庫可能散落各地，但是邏輯上-「大家都是同一國」的。那麼在各地的使用者管理上，就要稍加留意。

例如：在DB_A中的「sharon」，當login進DB_A時，想要存取DB_B的資料時，DBMaker是以sharon在login DB_A時所用的UserName及Password來登入DB_B，所以若是在DB_B中無sharon其人時，便會出現錯誤訊息，表示該名使用者未通過驗證。

DmSQL>connecto to DB_A Sharon ******;

dmSQL> select * from DB_B:t1;

ERROR (6804): [DBMaker] (remote error occurred) invalid authorization specification (invalid password when connecting) at: DB_B@B [rmbind.c 70],0,0,6804

(3)   應用程式調整

當要存取各地資料時，只要指明資料所在位置(如圖中台北)即可，例如前面所說的訂單動作，若是要將存貨(分散在各地)減少，同時增加會計的應收帳款(假設為集中式)，程式可以寫成：

update 存貨 set …….;

insert into 台北:應收帳款 values (….);

這兩句SQL指令，第一句所指的，都是在地的資料庫，但第二句都會去集中地台北的資料庫的應收帳款作新增適用；故應用程式到各地皆可一體適用(想一想，由於應收帳款只存在於台北，所以可設定synonym，將「應收帳款」設定成「台北:應收帳款」即可，那麼上述第二句指令又可再簡化)。

(4)   資料庫鏈(Database Link)

分散式資料庫需要兩邊都有相同的使用者與密碼，但這個動作卻會對各地的資料庫管理員產生許多管理工作，所以「資料庫鏈」就應運而生；所謂的「資料庫鏈」，可以視作使用某特定身份去連接遠端資料庫的固定連接，將這個「鏈結」視作是某種代理人，那麼應用程式連接到DB_A時，可能是使用User_A的身份，當透過DB_A連接到DB_B時，可使用DB_B_Link(這個鏈結可能是DB_A這裏的DBA設定完成，統一使用User_B、Password_B去連接DB_B)，那麼User_A可用自己的身份登入DB_A，但在使用DB_B_Link時，就變成了User_B、Password_B了。(同樣地，若User_C登入DB_A，使用DB_B_Link時，仍是使用User_B)

設定的方式十分容易，首先將DB_A、DB_B設定成「分散式資料庫」的環境，接著，以DBA的身份登入DB_A，鍵入以下命令：

create [private|public] database link Link_Name connect to DB_B identified by User_B Password_B;

其中private或public是設定該DB_LINK是私人使用，或是可開放給其他人使用，預設是private，為了能讓其他人能享用到這條資料鏈結，最好是設定成「public」較好。

接著，當其他人要存取遠端DB_B的資料時，只要使用：

select * from Link_Name:[Owner_Name.]Table_Name;

便可存取，但一般在撰寫這樣的SQL指令時，未免有些麻煩，所以更簡便的方式，是建立一個synonym，這樣一來，使用者連上來時，連DB_Link是什麼都可以不用知道：

create synonym Table_Name for Link_Name:[Owner_Name.]Table_Name;

當使用者下：select * from Table_Name; 時，這個Table_Name可能是遠在他方的另一個資料庫。

資料庫鏈的觀念十分好用，可使用這個方式來避免掉分散式資料庫一定得在兩邊有相同的使用者及密碼的麻煩，故讀者應多加練習及熟悉。

4. 表格複製與分散式資料庫的搭配

(1) 同步及非同步表格複製簡介

在集中式資料量小的情形下，上面的分散式資料庫架構，尚可運作得順利，若是集中式資料量大，地域性資料量小，那麼各地的應用程式還是拼命地將資料異動往集中地傳送，只有少數的資料可在近端得到，效能的低落是可以預期的。

DBMaker另有一項強大的功能，稱之為表格複製；這項功能是可將各地資料庫，同步或非同步地複製到其他資料庫，甚至可跨越到其他廠牌資料庫。

先重新瀏覽一次原始架構：

在第(2)、(3)步驟中，都需要向集中式的表格查詢，這兩者的表格特性，最好是屬於少量、少變動；否則總公司在查詢訂單資料、應收帳款時，由於資料散佈在遠端的台北、台中、高雄，效率會十分的緩慢；但若是因此改採集中式，又變成了台中、高雄每新增一筆資料或查詢也變得很緩慢。無論是集中、分散都有一方需要忍受緩慢的效能。

當產品資料的量很大時，若是每次查詢要到台北去查，似乎太遠了點，在此例中，我們可以將產品資料放一份在各地，之後各地的應用程式就無須千里迢迢到台北總公司去找了，而台北總公司一旦有最新變動(產品價格、廠商)，必須儘速將新資訊往各分公司傳送。

DBMaker提供了「同步」與「非同步」表格複製的功能，便可「立即」或是「定期」地，將某些表格的資料，同步到各地資料庫去。

所謂的「同步表格複製」，是指一旦資料輸入到DB_A中，DB_B會馬上隨之更新，由於這兩個動作視作同一筆「交易」，所以若是同步到DB_B的動作失敗，會相對的連DB_A的輸入動作也失敗。

(2) 同步與非同步表格適用情形

「同步表格複製」適用於需要即時的資料更新、網路品質是可信賴、且傳送的資料量不大的情況。若是網路品質本身有問題，那麼不單是對DB_B的更新會有問題，連帶的會使DB_A也無法輸入，反而對正常業務帶來更大的不便。

而「非同步表格複製」，則適用於可忍受資料更新速度在一定的期限(例：一天、三天、一星期)，且傳送的資料量較大的狀況。在上述例子中，DB_A的輸入將不會被DB_B及網路所影響。實際例子中，若是傳輸的資料量大，多指定某些冷門時間，將資料在該時段同步到DB_B中，而使用者能夠忍受在尚未同步前，資料不一致的問題。

無論是同步、非同步表格複製，DB_B都是單純的受方，使用者若對DB_B進行update、delete的動作的話，將會造成兩邊不一致，且DB_A是無法消弭此種不一致的現象。

有些使用者則想要讓DB_A、DB_B能互相複製，這種要求看來合理，細探之下，卻又有其困難處。例如：若要求DB_A的Table1的「新增」資料，必須要複製到DB_B的Table1去，同時又要求DB_B的Table1資料，也要能複製到DB_A去，在T0(第一次同步排程)，DB_A的資料過去了DB_B，在T1(第二次同步排程)時，DB_B由於也新增了資料(由DB_A過來的)，所以又再複製回去DB_A(這個動作應該會失敗，原因是複製是用primary key來設定，容後再述)；結果變成了一個循環，所以類似此種DB_AóDB_B的需求，並不是達成不了，但兩邊的表格必須錯開，或是配合on cascade的命令，以避免上述的狀況。

5. 同步表格複製

DBMaker的同步表格複製，嚴格地說，是使用了DDB及Trigger的機制，由於DDB(分散式資料庫)，可讓我們存取遠端的資料庫，而Trigger則是可讓資料新增、刪除、修改時，同時觸發某些動作，這兩個動作加在一起，便是「新增、刪除、修改資料時，同時觸發某些動作，來新增、刪除、修改某個遠端資料庫表格」。

(1) 同步表格複製設定方式

首先要將DB_A、DB_B設定成DDB模式，設定方式請看前述，當設定完成後，利用dmsql下達以下指令：

create replication replication_name with primary as table_name replicate to DB_B:table_name;

其中replication_name是Replication的名稱，而DB_A:table_name與DB_B:table_name則是兩邊的表格名稱(table name)，注意!!兩邊表格一定要設定Primary Key，因為同步的機制是利用Primary Key來作依據，所以，當我們修改、刪除DB_A的Record時，它才有依據去對DB_B的table_name作相同動作。

(一樣要注意的，在DDB模式中，使用者/密碼必須兩邊相同，因為它會用Login DB_A的使用者/密碼去Login DB_B)

我們也可以不用複製全部的欄位，而只複製部份；如下：

create replication replication_name with primary as table_name (c1,c2,c3) replicate to DB_B:table_name (c1,c2,c3);

甚至給予一個條件，當這個條件為真時，才進行同步：

create replication replication_name with primary as table_name (c1,c2,c3) where c3=’台中’ replicate to DB_B:table_name (c1,c2,c3);

在初始階段，我們還可用下面命令，直接讓兩邊同步：

create replication replication_name with primary as table_name (c1,c2,c3) where c3=’台中’ replicate to DB_B:table_name (c1,c2,c3) clear and flush data;

clear代表進行同步前，先刪除遠端表格所有資料；flush則是將DB_A的所有資料倒到DB_B去，故這個動作，將會使得DB_B的table資料，整個被刪掉再從DB_A複製一份過來。

6. 非同步表格複製

DBMaker在設定非同步表格上，比起「同步」算得上是複雜許多，但是只要能掌握住要要訣，事實上非同步複製也是十分容易設定的。

(1) 非同步表格複製的原理

現在假設一樣要從DB_A複製到DB_B：

在這個情境下，DB_A稱之為Primary DB，而DB_B為Slave DB，這兩者是實體的資料庫，但另有負責派送的一個process，稱之為Distributor(發送者)，就像發報紙一樣，送報生(Distributor)到報社(Primary DB)，將報紙發送到訂閱者(Slave DB)的手上，其關係圖如下圖所示：

非同步表格複製(ATR)的機制，便是首先資料庫會將所有針對某特定表格(設為Table_ATR)的所有動作，記錄下來，存成LOG(TRPLOG)，當設定的時間到了，Distributor就會啟動，將這個記錄下來的LOG變成相對應的ODBC Call，去更動遠端的Slave DB，並將這個過程，記錄在ATRP.LOG檔，若發生錯誤，也會記錄在ATRERROR這個LOG檔。

為了能確使每一個動作能正確無誤，建議讀者在設定時，能依照下列步驟一步一步操作。

(2) 非同步表格的設定步驟

1. 開啟DDB設定

此項動作可在dmconfig.ini中，加入以下一行：

DD_DDBMD=1;

當加入了這項指令後，重新啟動資料庫，此時若下達「select * from SYSUSER」的指令，將會發現多了一個使用者為：GTRECO_D，這個Daemon便是負責作Global Transaction的，只要將DDB打開，預設便會將此Daemon啟動。

2. 啟動Distributor

接下來，設定讓Distributor能夠正常啟動，請在dmconfig.ini加入

DD_ATRMD=1;

表示要使用非同步表格複製，儲存後，重新啟動資料庫，並使用dmsqlc，下「select * from SYSUSER」指令

3. 設定放置Replication Log的目錄

請回頭看ATR的關係圖，圖中，我們可以看到：Distributor只是負責將TRPLOG的資料，變成一個個的ODBC指令，去update遠端資料庫，所以我們可以先到dmconfig.ini，去設定要放置TRPLOG的目錄。

RP_LGDIR=k:\alendb\TRPLOG_X(依自己所需設定)

重新啟動資料庫，以便這個新設定能夠發生作用。

在取出TRPLOG後，Distributor會變成一個個ODBC指令，update到遠端資料庫，若是此時網路斷線，或是遠端資料庫未開啟，導致ODBC呼叫失敗時，該怎麼辦??

為了讓使用者能掌握ATR實際執行的成功、失敗情況，Distributor會將整個過程記錄在ATRP.LOG(過程)、ATRERROR.LOG(失敗原因)。預設這兩個檔案會放在DBDIR的目錄下；使用者現在可以先打開DBDIR，先檢視看看目前有沒有類似的目錄及檔案，由於現在我們並未開始表格複製的動作，所以現在相關的檔案都尚未建立，請將此目錄保持開啟狀態，在下面操作過程，可時時用以觀察相對應的變化。

4. 開啟己端及彼端DDB模式

現在A端的設定已經設定完畢，請至B端，將其DB_DDBMD=1，開啟分散式資料庫。

現在讓我們試試看是否DDB Mode成功啟動，資料間可互相透通，請在A端中的dmsqlc，查詢B端的資料：

select * from DB@B:SYSINFO;

若是能正確連接到的話，表示DDB Mode已經開啟且運作正常

5. 設定排程(Schedule)

由於我們要設定的是「非同步表格複製」，所以在表格複製的設定上，分成「設定排程 (Schedule)」及「設定表格複製」，在非同步表格複製中，這兩個步驟是獨立分開而缺一不可的。

首先，先設定排程，其指令如下：

CREATE SCHEDULE FOR REPLICATION TO remote-db-name

[{ORACLE | INFORMIX | SYBASE | MICROSOFT}]

BEGIN AT yy/mm/dd hh:mm:ss

{EVERY n DAYS | EVERY hh:mm:ss | EVERY n DAYS AND hh:mm:ss}

[RETRY n TIMES [AFTER n SECONDS]]

[STOP ON ERROR]

[WITH NO CHECK]

IDENTIFIED BY user-name [password]

以實例來作說明：

create schedule for replication to DB@B begin at 01/01/01

00:00:00 every 00:00:30 identified by alen alen;

(為說明故，我們將schedule設成只有30秒)

首先，在建立schedule時，是不指定table的，對這個階段而言，重要的是確立使用者對遠方資料庫是否有權限。再回到關係圖瀏覽一遍，Distributor是把Log化成一個個的ODBC指令，所以被複製的表格是可以跨異質資料庫的(只要該資料庫支援ODBC，且在DSN正確設定)。

在指令中，必須指明要用什麼身份去Login遠端資料庫，來進行資料表格複製，但其實還有另外一種認證方式；本章前半段曾提及DB_LINK，它可以用特定使用者的身份去登入遠端資料庫，若設定好DB_LINK的User:Password，這邊的再認證就是多此一舉；事實上，DBMaker在遇到DB_LINK時，會先用DB_LINK的認證，而不管create schedule指令的認證。

一旦指令成功建立schedule後，可到DBDIR的目錄去找找看有無ATRP.LOG這個檔案，這是一個文字檔，記載了Distributor的活動。注意，ATRP.LOG是位於DBDIR底下，而不是RP_LGDIR，ATRP.LOG記錄的是Distributor的「活動」，而不是Distributor搬動的「內容」，你可以開啟這個檔案，查看它記錄的資料：

2001/12/03 10:37:00 : start up

2001/12/03 10:37:30 : start up

2001/12/03 10:38:00 : start up

2001/12/03 10:38:30 : start up

接下來，我們就要設定Distributor要搬移的內容，也就是表格複製中的「表格」，來源資料庫與目的資料庫兩邊要複製的表格，首先，schema最好要相似，以避免表格搬動後，發生資料轉換不過去的問題。其次，兩邊的表格一定要有Primary Key，資料複製時，是以PK為搬動時的依據。

6. 設定表格複製

現在進行設定表格複製，命令格式如下：

CREATE [ASYNC] REPLICATION replication-name

WITH PRIMARY AS base-table-name

[(column-identifier [, column-identifier] ...)]

[WHERE search-condition]

REPLICATE TO

{ remote-table-name

[(column-identifier [, column-identifier] ...)]

[CLEAR DATA | FLUSH DATA | CLEAR AND FLUSH DATA]

[NO CASCADE]

[, remote-table-name

[(column-identifier [,column-identifier,] ...)]

[CLEAR DATA | FLUSH DATA | CLEAR AND FLUSH DATA]

[NO CASCADE]]

其實這個命令與前面同步表格複製只差了一個關鍵字「ASYNC」，其他都相同，為了要讓一開始兩邊資料相同，我們使用了下面的指令：

create async replication rp1 where primary as t1 replicate to DB@B:t1 clear and flush data;

其中的clear and flush，指的是說將目的資料先清除(clear)後再寫入(flush)，如此一來，兩邊的資料便吻合了；使用者可以作過這個動作以後，馬上檢查一下兩邊資料，查看是否相同。

7. 檢查各元件是否正確產生

接著，我們將欲複製的表格加入幾筆資料，此時可以去查看RP_LGDIR目錄下，是否產生了如1.TRP之類的檔案，這個檔案記錄欲複製表格所作的所有更動，所以一旦對t1有動作，1.TRP就會產生出來，接著，便是等待時程設定的時間過去，Distributor開始搬動資料。

此時若是查看ATRP.LOG的話，會有如下記錄：

2001/12/03 17:52:00 : replicate transactions before 2001/12/03 17:51:51 (log:1.364) to ATRTEST@B

2001/12/03 17:52:30 : start up

但是ATRP只是記錄Distributor起來、搬動的過程，若是失敗的話，會記錄在ATRERROR.LOG，ATRP.LOG本身是不記錄錯誤的!

異質資料庫的搬動與DBMaker的搬動，設定上幾乎完全一樣，只是此時設定的DB@B要用ODBC DSN來取代，如此即可。

(3) 快速非同步表格複製(Express ATR)

除此之外，DBMaker在3.7之後，為了加快Replication速度，又加上另一項功能，稱之為「快速資料表格複製」(Express ATR)，這項功能有兩個特性，首先是它不像原來的ATR可透通異質性資料庫，它使用了DBMaker原生的網路及ODBC呼叫，並將指令「批次」(batch)打包後再一次送出；它的第二個特性，便是故速度上比原來的ATR快上許多。

1. Express ATR的架構

Express ATR的觀念，與之前的ATR幾乎完全相同，唯一不同的是，要複製的資料庫，必須先有一個Daemon作「傾聽」的動作，請看下面的關係圖：

圖中，DB_A這段的架構，幾乎完全沒變，但是DB_B卻多了一個「Subscriber」的Daemon，這個daemon的任務便是將傳過來的命令，一一解開，並在DB_B中執行。

2. Express ATR的設定

在設定上，首先在DB_A中，它必須知道DB_B的Subscriber所「傾聽」的埠位。一般說來，當我們在設定DB_PtNum時，指的是DB_B的Server在傾聽的埠位，而任何一個客戶端，都可連至Server此埠位來操作資料庫。前面所說的ATR，基本上也是在到達時程時，由DB_A產生一個Connection連至DB_B的Server埠位，對DB_B而言，DB_A的這個connection，其實與一般的client connection，並沒有什麼太大的不同。

在Express ATR中，就不是如此，Server Process還是繼續處理其他Client端的請求，但Subscriber則是傾聽另一埠位中「非同步表格」複製的請求。設定這個特定埠位的關鍵字為DB_ETRPT，在DB_A=>DB_B的狀況時，必須設定如下：

DB_A:

[DB_A]

DB_DBDIR=..

DD_DDBMD=1

DB_ATRMD=1

….

[DB_B]

DB_SvAdr=192.168.1.20

DB_PtNum=10000

DB_ETRPT=20000

DB_B

[DB_A]

….

[DB_B]

DB_DBDIR=..

DD_DDBMD=1

DB_ETRPT=20000

請注意，在DB_A的dmconfig.ini的 [DB_B]項下的DB_ETRPT，指的是遠端Subscriber啟動的埠位；但在DB_B端的dmconfig.ini下，寫在[DB_B]項下的DB_ETRPT，DBMaker會在檢查發現DB_B是在己端時，啟動Subscriber Daemon，並開始傾聽DB_ETRPT的埠位；故本機端與遠方端的DB_ETRPT，所產生的影響，差異頗大。(讀者可試試，只要是在自己機械上的資料庫，加上DB_ETRPT後，再用select * from SYSUSER來觀察，就會發現多了一個Listener的Daemon。

但DB_A本身只有設定ATRMD=1(表示啟動Distributor)，它可以用一般ATR去連DB_B，也可以用Express ATR；那麼要如何指定使用那一類的ATR呢?關鍵點在建立Schedule時，必須指明：

create schedule for replication to DB@B begin at 01/01/01

00:00:00 every 00:00:30 identified by alen alen; 使用一般ATR

create schedule for express replication to DB@B begin at 01/01/01

00:00:00 every 00:00:30 identified by alen alen; 使用Express ATR

至此之後，就與之前的ATR流程相仿，請參考上面相關步驟。

7. 後語

實例：使用者希望資料庫Loading不要太大，故使用兩個資料庫，一個是內部人員利用應用程式來增加、修改資料，另一個資料庫提供外部人員查閱，內部使用的DB在每日晚間會將所有表格(除了一個Log屬性的表格)複製過去外部DB，而外部DB是供Web查詢，同時ASP會將登入記錄寫在一Log Table，也是會在每日晚間將此表格複製回內部DB。

DDB與ATR是屬於Enterprise級的功能，所以初學者往往視為畏途，但若是能活用此項功能，不單能為使用者的系統架構提供更大的彈性，也可提供系統更大的功能，管理者可不再被傳統集中式的Client-Server架構給綁死，甚至可用此設計更精細的Fail-Over、遠地備援等功能，例如上述實例，只要原則掌握住，DDB及Table Replication的運用存乎一心，是可天馬行空發揮地。