通訊

Exchange Server 2007 Service Pack 1 中的待命連續複寫

Scott Schnoll

摘要:

• 設定待命連續複寫
• 備援的重要性
• SCR 如何縮短停機時間

Service Pack 1 提供數個 Exchange 2007 新增功能和增強功能。其中一項新功能 ─ 待命連續複寫 (SCR) ─ 就是專門為公司提供資料中心內部備援和站台復原能力而設計。正如其名，SCR 是針對

使用或促成使用待命復原伺服器的案例而設計。

如果您很熟悉 Exchange 2007 的量產發行版 (RTM)，就知道它也透過它的記錄傳送功能以及 Windows® 容錯移轉叢集，提供資料中心內部備援和站台復原能力。在 RTM 版當中，記錄傳送 (正式稱為連續複寫) 有兩種形式：本機連續複寫 (LCR) (如 [圖 1] 所示) 以及叢集連續複寫 (CCR) (如 [圖 2] 所示)。

Figure 1** Local continuous replication **

Figure 2** CCR is log shipping to a second server in a Windows failover cluster **

連續複寫容許系統管理員在線上啟用和維護每一個信箱資料庫的第二個複本，藉此提供資料的可用性和備援能力。這個資料庫複本是預防實際執行資料庫失敗、遺失或損毀的第一道防線。資料庫複本可在數分鐘內啟動，並成為實際執行的資料庫，省去了尋找備份磁帶來還原資料所浪費的時間。

SCR 把規模更進一步擴大，讓您達成貴公司資料和服務的可用性。新的案例可讓您將高可用性拓樸與站台復原拓樸分開，並且容許您在每一個區域部署專為貴公司量身訂做的設定。

雖然 Exchange 2007 RTM 版可以提供資料中心內部備援能力和站台復原能力，但是因為 LCR 和 CCR 只為每一個資料庫提供一份額外複本，所以您必須在復原能力和備援能力之間擇其一。以 CCR 所提供的資料和服務可用性功能為例。將主動和被動節點部署在同一個資料中心，雖然能夠提供資料中心內部服務與資料的可用性，但是卻不能提供站台復原能力 (因為這兩個節點是位於同一個實體站台)。將主動節點部署在一個資料中心，將被動節點部署在第二個資料中心，雖然能夠提供站台復原能力，卻不能提供資料中心內部可用性 (因為提供這些功能的被動節點是位於第二資料中心)。

但是當 Service Pack 1 附有 SCR 功能之後，在為每一個資料庫建立額外複本時，高可用性和站台復原能力兩者便互不相斥，而能同時達成這兩種能力。比方說，如 [圖 3] 所示，您可以結合 SCR 與 CCR，在主要資料中心本機複寫儲存群組 (使用 CCR 是為了達到高可用性)，以及在第二或備份資料中心從遠端複寫儲存群組 (使用 SCR 是為了達到站台復原能力)。第二資料中心含有待命叢集，您可以啟動該叢集，並且在站台復原案例快速準備一個替代叢集信箱伺服器。

Figure 3** CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter **(按影像可放大)

[圖 3] 描述了部署兩個資料中心的企業，每一個資料中心各有自己的 Active Directory® 站台：里德蒙和昆西。里德蒙站台位於主要 (實際執行) 資料中心，而昆西站台位於第二 (備份) 資料中心。將 CCR 部署在里德蒙，是為了達成資料中心內部備援能力。而將 SCR 目標連同 Exchange 2007 所需要的基礎結構元素，在昆西的待命叢集上設定，是為了達成站台復原能力。這些額外的基礎結構元素可能是專用或非專用的資源，它們包括 Client Access 和 Hub Transport Server、Active Directory 和 DNS 伺服器以及網際網路存取。專用資源是專門支援資源所在資料中心的使用者。非專用資源則是支援本機資料中心的使用者以及其他地方的使用者。您必須以對貴公司最有利的原則為前提，決定資源為專用還是非專用。如需專用和非專用資源的相關資訊，請參閱 Exchange Server 2007 說明檔主題「站台復原組態」，網址是 technet.microsoft.com/bb201662.aspx。另外在使用新型的多數節點組合 (MNS) 仲裁時也要多加注意。在 Exchange Server 2007 中，CCR 採用的是 MNS 仲裁和檔案共用見證 (FSW)，而不是傳統的票選 (Voter) 節點，如 [圖 3] 所示。

在 [圖 4] 當中，CCR 外加 SCR 環境具有復原能力，它為伺服器 EXCLUS1 上控管的信箱和服務提供了好幾層的備援，因此可以保護信箱，防止它們發生大小規模的嚴重失敗。

Figure 4** Standalone mailbox servers using SCR to replicate storage groups to each other **(按影像可放大)

另外，SCR 也嘉惠了中小型企業。以 [圖 4] 為例，一家公司可以部署兩部獨立的信箱伺服器 (EXMBX1 和 EXMBX2)，並且使用 SCR，把一部信箱伺服器的儲存群組，部分或全部複寫到另一部 Mailbox Server。

在這個範例當中，EXMBX1 和 EXMBX2 都是實際執行伺服器，並具有五個作用中的儲存群組。每一個儲存群組，都是另一個伺服器上相對應 SCR 目標的 SCR 來源。如果發生儲存失敗，或者發生其他事件，導致設定為 SCR 來源的作用中儲存群組無法使用，只要使用 Exchange 管理命令介面中一些的管理工作，很快就可以啟動 SCR 目標複本。有了 Microsoft® Office Outlook® 2007 以及 Exchange 2007 的資料庫可攜性和自動探索功能，即使因為遺失作用中儲存群組 (或是同一個情況下遺失多個作用中儲存群組) 而導致停機，停機時間頂多也只有幾分鐘而已。

SCR 來源和目標

跟 LCR 和 CCR 一樣，SCR 也採用主動和被動複本的儲存群組概念，但它分別稱之為 SCR 來源和目標。儘管如此，SCR 來源和目標都是儲存群組複本 (復原儲存群組無法用於 SCR)。

SCR 的起點 (SCR 來源) 是單一複本叢集或 CCR 環境中獨立信箱伺服器上，或叢集信箱伺服器上的任何一個儲存群組。請注意，SCR 來源可以是叢集信箱伺服器，但因為 SCR 本身不是叢集解決方案，所以不需要 Windows 叢集服務。SCR 的結束點 (SCR 目標) 可以是獨立的信箱伺服器，也可以是容錯移轉叢集當中的一個節點 (這個容錯移轉叢集有安裝 Mailbox role，但是在叢集當中沒有設定任何叢集信箱伺服器)。

來源和目標的關係

每一個 SCR 來源儲存群組都可以有無限量的 SCR 目標。舉個例說，來源的其中一個目標可能位於與來源同樣的資料中心，第二個目標則位於另一個資料中心。但是，Microsoft 建議每一個來源不要超過四個目標。如果您決定使用四個以上的目標，就必須接受 SCR 來源伺服器在記憶體、CPU 和磁碟資源方面可能受到的衝擊，並且根據這一點加以規劃。每一部 SCR 目標電腦都可以有多部來源伺服器。來源和目標電腦都必須執行 Service Pack 1 for Exchange 2007。作業系統必須是 Service Pack 1 for Exchange 2007 支援的作業系統 (例如，Windows Server® 2008 或 Windows Server 2003 SP2)。但是，無論您使用的是哪一個作業系統，SCR 都沒有跨作業系統支援，因此它要求 SCR 來源上的作業系統，必須與該來源所有 SCR 目標上的作業系統一樣。因此，如果 SCR 來源是執行 Windows Server 2003，那麼該來源所有的 SCR 目標，也都必須執行 Windows Server 2003。

SCR 是附隨在 Exchange 2007 標準版中。如果 SCC 或 CCR 環境中的叢集信箱伺服器用作為 SCR 來源，就必須採用 Exchange 2007 企業版。使用企業版時，每一個 SCR 目標最多可支援 50 個執行個體 (50 個複寫的儲存群組)；而使用標準版時，最多可支援 5 個執行個體。

SCR 目標也有它必須符合的需求。首先，無論來源和目標電腦是在相同或不同的 Active Directory 站台上，都必須位於同一個 Active Directory 網域。另外，來源及其所有目標上的資料庫和記錄檔路徑，都必須與以 SCR 複寫的每一個儲存群組相符。最後，如果節點或伺服器是設定為 SCR 目標，您就不能在 SCR 目標電腦上的任何儲存群組啟用 LCR，也不能把任何叢集信箱伺服器加入獨立的容錯移轉叢集當中。

比較 SCR 與 CCR 和 LCR

SCR (如 [圖 5] 所示) 是採用 LCR 和 CCR 所用的同一種記錄傳送和轉送技術，來提供新的部署選項和設定。採用 SCR 的儲存群組與 LCR 和 CCR 一樣，都不能有超過一個資料庫。同樣的，如果 Exchange 組織結構當中的公用資料夾資料庫不只一個，SCR 也不能用於公用資料夾資料庫。

Figure 5** SCR is log shipping to another server or a passive node in a failover cluster **

兩者的主要差別在於，SCR 在每一個儲存群組支援多個目標，而 LCR 和 CCR 只支援一個目標 (被動複本)。另一個主要差異是，SCR 複本無法備份，這一點與 CCR 和 LCR 不同。使用 SCR 時，若是向 SCR 來源儲存群組取得支援的備份 (或者，若是使用 CCR 和 LCR，則是向 SCR 來源儲存群組的主動或被動複本取得備份)，則會更新 SCR 目標的資料庫標頭，而且會截斷記錄檔。

與 LCR 和 CCR 一樣，透過 SCR 的記錄傳送會連續進行，並且是使用提取模式。 當新的記錄檔一關閉，並且以下一代序列記錄檔案號碼命名時，在 SCR 目標電腦上執行的 Microsoft Exchange 複寫服務，就會從 SCR 來源電腦提取關閉的交易記錄檔，檢查並驗證它們，然後將它們移到它們在 SCR 目標電腦上的對應儲存群組記錄檔案資料夾。

轉送延遲時間

當記錄檔複製到 SCR 目標電腦之後，SCR 會採取一些動作，但 LCR 和 CCR 不會。SCR 不會立刻將記錄檔轉送到資料庫複本中，而是強制執行內建延遲功能，將 50 個記錄檔延遲 24 小時。除了這些內建延遲功能之外，SCR 也容許您另外指定其他時間延遲。在很多情況下，延遲轉送活動都能派上用場。舉個例說，如果作用中資料庫發生邏輯損毀，延遲便能防止 SCR 目標資料庫發生邏輯損毀。

由系統管理員控制的轉送延遲，是利用一個稱為 ReplayLagTime 的參數所設定，它負責指定 Exchange 複寫服務應該等待多久，才能轉送被複製到 SCR 目標電腦上的記錄檔。其格式是 Days.Hours:Minutes:Seconds，預設值是 24 小時。此值的設定上限是七天，下限是零秒，如果將此值設為零秒，就能有效刪除記錄轉送活動中任何超過預設 50 個記錄檔的延遲活動。

無論 ReplayLagTime 的值為何，除了 ReplayLagTime 之外，Exchange 還有一個內建限定 50 個記錄檔的延遲。Exchange 是使用較大的 ReplayLagTime 或 x 個記錄檔 (x=50)，來判斷何時轉送記錄檔。萬一使用連續複寫的 SCR 來源 (例如，CCR 環境中的叢集信箱伺服器) 遭遇容錯移轉，而必須以 Restore-StorageGroupCopy 指令程式讓其中一或多個儲存群組上線，為了避免在這些情況下重新植入儲存群組，於是多這麼一層安全保護 (所謂植入 (Seeding)，是指使用 Extensible Storage Engine (ESE) 串流備份 API，在 SCR 目標電腦上製作 SCR 來源資料庫的線上複本)。延遲 SCR 目標轉送活動的好處是，萬一 SCR 來源發生失真容錯移轉時，可以盡可能減少重新植入 SCR 複本的需要，因為一旦 SCR 來源遺失資料，此舉會及時將兩個複本放在一起。

截斷延遲時間

在 Exchange 2007 RTM 版中，連續複寫環境強制規定除非記錄檔已經備份，並且已轉送到資料庫複本中，否則不會將它們刪除。但在使用 SCR 時，這個規則已經過修改。只要 SCR 來源電腦上的記錄檔經過所有 SCR 目標電腦的檢查，SCR (介紹了多資料庫複本的概念) 便容許截斷這些記錄檔。SCR 來源伺服器不會等到所有的記錄都轉送到所有的 SCR 目標之後才截斷記錄，因為您可以用很高的記錄轉送延遲時間來設定 SCR 目標複本。

您也可以使用一個稱為 TruncationLagTime 的新參數，在記錄截斷另外加入延遲，這個參數會指定 Exchange 複寫服務要等待多久 (採用 Days.Hours:Minutes:Seconds 格式)，再截斷已複製到 SCR 目標電腦上、且轉送到資料庫複本中的記錄檔。只要記錄檔一經順利轉送到資料庫複本，就表示該時段開始了。此值的上限是七天，而下限是零秒 (不過零秒便能有效去除記錄截斷活動中的任何延遲動作)。

在 SCR 環境中，每三分鐘就會執行一個背景執行緒，以判定是否有記錄檔需要截斷。如果記錄檔產生順序是低於儲存群組的記錄檔檢查點，而且這個記錄檔早於 ReplayLagTime + TruncationLagTime，那麼 SCR 目標上就會有一個記錄檔被截斷。

在以 SCR 延伸的 LCR 或 CCR 環境中，如果符合下列四個條件，就會截斷 SCR 目標上的一個記錄檔：記錄檔已經備份、記錄檔產生順序低於儲存群組的記錄檔檢查點、儲存群組的被動複本容許記錄檔被截斷，而且所有 SCR 目標都已經檢查過這個記錄檔。

啟用和管理 SCR

SCR 是以 Exchange 管理命令介面中的 Enable-StorageGroupCopy 指令程式來啟用，這個指令程式在 SP1 中已經過更新並加入一些新參數。如前所述，ReplayLagTime 和 TruncationLagTime 可讓您控制 SCR 目標的一些行為。另一個參數 SeedingPostponed 則可用來跳過初次植入 SCR 目標的動作。在許多情況下，延遲植入都能派上用場。舉個例說，假設儲存群組中 SCR 所用的資料庫有 100GB，您應該不希望在尖峰執行時間時，讓所有 100GB 的資料都在網路上周遊。SeedingPostponed 參數可以讓您選擇立即啟用 SCR，稍後再執行植入工作。只要等您準備就緒，就可以使用 Update-StorageGroupCopy Cmdlet，手動植入 SCR 目標。

上面提及的參數都是選擇性參數，但是其中一個 Enable-StorageGroupCopy 參數，卻是 SCR 的必要參數：StandbyMachine。它會指定含有 SCR 目標的電腦的名稱。這個參數的值，是設為 SCR 所用的 msExchStandbyCopyMachines 屬性值一部分。msExchStandbyCopyMachines 屬性是一種多值的 Unicode 字串，它是在 Exchange 2007 SP1 引進 Exchange 組織結構時，加入到 Active Directory 結構描述中，這也是 SP1 需要更新 Active Directory 結構描述的原因之一。

StandbyMachine 參數是 SCR 的核心，SP1 當中有好幾個指令程式經過更新都是為了使用這個參數來啟用和管理 SCR 目標。[圖 6] 說明更新的 Cmdlet。

Figure 6 Cmdlets that use the Stand­by­Machine parameter

啟動 SCR 目標

SCR 提供一或多個最新資料複本，可以在原始資料遺失或無法使用時派上用場。採用 SCR 目標複本，將它重新作為實際執行資料庫的程序，舊稱為啟動。啟動是修復程序的一部分，它是以資料庫可攜性，或是其中一種安裝復原選項的形式存在 (/m:RecoverServer 是用於修復獨立伺服器，或者 /RecoverCMS 是用於修復叢集信箱伺服器)。

運用 SCR

接下來我們要看看一家虛構的公司，如何使用 SCR 和資料庫可攜性來復原信箱資料庫的失敗。當您發現實際執行資料庫損毀之後，系統管理員會使用資料庫可攜性來啟動 SCR 目標資料庫。

該公司部署了附隨 SP1 的 Exchange 2007，並且決定運用 SCR，在遠端信箱伺服器提供一份儲存群組的複本。來源和目標信箱伺服器都位於同一個 Active Directory 站台，並且都經過設定採用與 Active Directory 整合的 DNS 伺服器。Active Directory 複寫間隔是設定為 15 分鐘。

啟用 SCR 和接移復原

SCR 的設定方式，是針對含有單一資料庫 MBX1 的單一儲存群組 SG1 來複寫交易記錄檔。儲存群組檔案和資料庫檔案的路徑是 C:\SG1 和 C:\SG1\MBX1.EDB。在本例中，EXMBX1 是 SCR 來源，EXMBX2 是 SCR 目標。其設定如下所示：

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

啟用 SCR 之後，SG1 所用的 SCR 的健康與狀態，是由 Get-StorageGroupCopyStatus 指令程式負責驗證：

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2

為了節省 SCR 目標啟動程序的時間，EXMBX2 以儲存群組 SG1PORT 和資料庫 MBX1PORT 經過預先設定，作為資料庫可攜性作業的一部分。SG1PORT 和 MBX1PORT 則獨立於 SCR 目標的儲存群組和資料庫檔案之外。因此，SG1PORT 和 MBX1PORT 的路徑，是以與 SCR 目標路徑不衝突的暫時路徑加以設定。SG1PORT 和 MBX1PORT 將只作為資料庫可攜性物件使用；SG1PORT 的實際儲存群組和資料庫檔案則不需要。因此，系統管理員會卸載 MBX1PORT，並刪除儲存群組中所有的檔案。儲存群組和資料庫物件則留在 Active Directory 中，因為它們會在稍後進行復原程序時用到，以達到資料庫可攜性。

啟動和復原

根據應用程式事件記錄項目指出，SCR 來源資料庫實際上已經毀損。由於 SCR 是用於 SG1，因此決定手動啟動 SG1 的 SCR 目標資料庫，並且利用資料庫可攜性來還原資料庫可用性。要啟動 SCR 目標複本，就必須先以下面這個指令程式來卸載 SG1 中的 MBX1。

Dismount-Database EXMBX1\SG1\MBX1

接著再啟用 SCR 目標資料庫進行裝載，並且使原先在 MBX1 的信箱重新隸屬於 MBX1PORT。

在停用 SCR 以及啟用 SCR 目標資料庫進行裝載時，會執行 Restore-StorageGroupCopy Cmdlet。這項工作會將儲存群組的資料庫標示為可以裝載，並且提供因為在儲存群組中裝載資料庫而導致資料遺失的相關報告 (如果有的話)。同時它也會驗證所有由儲存群組主動複本所產生的記錄檔，的確是出現在被動複本的儲存群組檔案位置。如果有任何記錄檔遺漏，這個作業也會想辦法加以複製。下面這個指令程式的目的，是讓 SCR 目標資料庫進行裝載：

Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

在本例中，您可以複製來自 SCR 來源儲存群組的記錄檔。如果這些檔案無法使用 (比方說，因為 SCR 來源電腦當機)，就必須將 Force 參數加到 Restore-StorageGroupCopy 工作中。否則 Restore-StorageGroupCopy 就會不斷地想辦法連接 SCR 來源，來複製任何遺漏的記錄檔，而且如果 SCR 來源無法使用，Restore-StorageGroupCopy 工作就會失敗，資料庫也就無法進行裝載。加入 Force 參數的用意，只是告訴 Restore-StorageGroupCopy 工作來源檔無法使用，並不會處理連線動作，而是直接讓 SCR 目標資料庫進行裝載。

Restore-StorageGroupCopy 命令完成之後，系統管理員必須驗證資料庫是否處於正常關機狀態。如果資料庫是處於不正常關機的狀態 (請參閱 technet.microsoft.com/aa996757.aspx)，就必須將它正常關機。如果儲存群組的記錄檔前置詞 (例如，E00 或 E01) 與 SCR 來源 (EXMBX1\SG1) 一樣，同時也與 SCR 目標 (SG1PORT) 上為了達成資料庫可攜性 (EXMBX2\SG1PORT) 所用的儲存群組相同，那麼就不需要以復原模式執行 Eseutil，而且最後的資料庫裝載作業，會在所有複寫的記錄檔全部轉送之後，將資料庫正常關機。如果資料庫不是處於正常關機狀態，則必須對該資料庫執行 Exchange Server 資料庫公用程式 (Eseutil) 復原模式 (Eseutil /r)。

一旦資料庫處於正常關機狀態，您就可以執行兩個命令，將 Active Directory 更新儲存群組檔案和資料庫檔案的新位置。這些命令會將 SG1PORT 和 MBX1 的路徑，從原始路徑改為接移儲存群組和資料庫的路徑 (SG1PORT 和 MBX1PORT)：

Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly

上述命令必須包含 –ConfigurationOnly 參數，因為這麼一來，就只會在 Active Directory 中更新這些物件的設定。任何資料或檔案都不會移動，也不必移動，因為 SCR 已將資料複寫到 EXMBX2 的 C:\SG1 了。

接下來就是設定資料庫 (MBX1PORT)，容許它本身在復原作業時被覆寫。這個動作可以藉由兩種方式完成，一是在 Exchange 管理主控台中，勾選資料庫物件屬性上 [此資料庫可被還原覆寫] 設定的核取方塊，一是使用 Exchange 管理命令介面中的下面這個命令：

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true

一旦設定資料庫容許本身被覆寫之後，下一步就是以下述命令裝載資料庫：

Mount-Database EXMBX2\SG1PORT\MBX1PORT

資料庫裝載之後，必須使位於 SCR 來源資料庫上的信箱 (SG1\MBX1) 重新隸屬，並指向 EXMBX2 上的 MBX1PORT。做法很簡單，只要執行 Get-Mailbox cmdlet，並且將輸出傳送至 Move-Mailbox 指令程式即可。在這個過程當中，絕不可將 Exchange 系統服務員和系統信箱包含在從 Get-Mailbox 指令程式傳送到 Move-Mailbox 指令程式的輸出中。因為那些信箱物件不需要重新隸屬，也不應該這麼做。下面這個命令的目的是重新隸屬所有的使用者信箱，並且排除系統信箱：

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}|Move-Mailbox-ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT

這時候，用戶端就可以存取 MBX1PORT 了。但是，信箱從 EXMBX1\SG1\MBX1 移到 EXMBX2\SG1PORT\MBX1PORT 之後，使用者是否能夠實際存取他們的信箱，還得視 Active Directory 複寫延遲而定；也就是說，在環境中傳播更新可能要花點時間，而花多少時間則要根據目錄伺服器的數目而定。此外，用戶端存取的方法也有關係：當使用者用戶端存取伺服器所用的目錄伺服器更新路徑之後，執行 Outlook 2007 的郵件用戶端以及非 Outlook 的用戶端就有權存取使用者的信箱了。執行 Outlook 2003 及舊版 Outlook 的郵件用戶端，會要求使用者的桌面郵件服務設定檔更新伺服器的名稱。

最後步驟

當用戶端有權存取他們的信箱和信箱資料之後，接下來只要重新啟用 SCR 來建立備援即可。做法是從 EXMBX1 移除所有剩下的儲存群組和資料庫檔案。檔案被移除之後，可以將 EXMBX1\SG1\MBX1 的路徑移到暫時位置，而 EXMBX1 則成為 EXMBX2 的 SCR 目標。

Scott Schnoll 是 Microsoft Exchange Server 小組的首席技術文件作者，負責撰寫 Exchange Server 2007 方面的文章。在加入 Microsoft 之前，Scott 曾寫過《Exchange Server 2003 Distilled》(Addison-Wesley Professional，2004 年)，而且是《Exchange 2000 Server: The Complete Reference》(McGraw-Hill/OsborneMedia，2001 年) 的主要作者。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.