Đề tài Tìm hiểu các chức năng hổ trợ lập trình trên môi trường mạng của SQL Server

ản , sự quản lí cơ sở dữ liệu phải được liên quan tới việc điều chỉnh giới hạn sự leo thang lock . Làm tăng tính thực thi vì khi dùng lock thích hợp thì làm tăng sự tối thiểu hóa chi phí hệ thống . Người phát triển ứng dụng có thể tập trung trên phát triển đó vì SQLServer tự điều chỉnh khóa . Deadlock Deadlock là trường hợp xảy ra trong bất kì hệ thống nhiều người sử dụng không chỉ trong hệ quản trị cơ sỡ dữ liệu quan hệ . Deadlock xuất hiện khi hai user khóa những đối tượng riêng biệt và mỗi user lại muốn lock những đối tượng của user khác . Mỗi user phải chờ user khác trả lại đối tượng mà chúng đang khóa . Ví dụ : Giao dịch một T1 có khóa loại trừ vào bảng Supplier . Giao dịch hai T2 tạo khóa loại trừ trên bảng Park và rồi nó muốn lock bảng Supplier . Giao dịch T2 không thể tạo lock vì giao dịch T1 đang giữ nó . Giao dịch hai bị dừng lại (block) chờ giao dịch T1 . Giao dịch T1 lại muốn lock bảng Park nhưng giao dịch T2 đang giữ nó . Cả hai giao dịch không thể bỏ lock cho tới khi chúng commit hay roll back nên chúng bị block , cả hai giao dịch không thể hoàn tất giao dịch . Phát hiện và kết thúc deadlock SQL Server định kì sẽ quét những vùng đang chờ yêu cầu lock . Trong suốt quá trình quét , SQl Server sẽ ra hiệu cho mỗi vùng đang chờ . Nếu vùng đã được ra hiệu vẫn đang chờ thì việc tìm kiếm deadlock đệ qui sẽ được khởi động . Nếu việc tìm kiếm deadlock đệ qui phát hiện sự yêu cầu khóa gây ra liên kết vòng thì những giao dịch có chi phí ít nhất được chọn như là nạn nhân của deadlock( deadlock victim). SQL Server kết thúc một deadlock bằng cách chọn tự động deadlock victim mà có thể hủy deadlock . SQL Server sẽ roll back những giao dịch deadlock victim , thông báo cho ứng dụng của user , hủy những yêu cầu hiện thời của user và cho phép các giao dịch khác tiếp tục . Deadlock chỉ ảnh hưởng một số lượng nhỏ giao dịch nên kỹ thuật phát hiện định kì này sẽ làm giảm chi phí của việc phát hiện deadlock . Tránh deadlock Mặc dù deadlock không thể hoàn toàn tránh được nhưng số lượng deadlock có thể được tối thiểu .Sự tối thiểu deadlock làm tăng số lượng deadlock đưa vào và làm giảm tổng phí hệ thống vì rất ít giao dịch bị : Roll back , hủy bỏ tất cả công việc đã thực hiện trong giao dịch . Xem xét lại bởi ứng dụng bởi vì chúng đã được roll back khi xảy ra deadlock . Để giúp tối thiểu deadlock , user cần thực hiện : Truy cập đối tượng có cùng thứ tự : Nếu tất cả giao dịch đồng thời cùng truy cập vào những đối tượng có cùng thứ tự deadlock sẽ ít xuất hiện . Ví dụ :Nếu hai giao dịch đồng thời chứa một khóa trên bảng Supplier và sau đó trên bảng Part thì một giao dịch bị block trên bảng Supplier cho đến khi giao dịch khác hoàn thành . Sau khi giao dịch đầu tiên commit hay roll back thì giao dịch hai tiếp tục . Không có deadlock xảy ra .Sử dụng stored procedure có thể chuẩn hóa trật tự của sự truy cập các đối tượng . Tránh dùng những tác vụ bên trong 2.7 > SHARE 2.7.1. Kết nối đến SQL Server thông qua Internet Bạn có thể kết nối vào Mcrosoft SQL Server trên Internet bằng cách sử dụng SQL Query Analyzer hoặc dùng một client cơ sở ứng dụng trên ODBC hay DB-Library. Để chia sẻ dữ liệu trên Internet thì client và server phải được kết nối vào Internet. Thêm vào dó, bạn phải sử dụng giao thức TCP/IP hay Multiprotocol Net-Libraries. Nếu sử dụng Multiprotocol Net-Library, phải chắc chắn rằng chế độ hỗ trợ củaTCP/IP được bật lên . Nếu như server đã đăng kí với Domain Name System (DNS), bạn có thể kết nối với tên đã đăng kí đó. Mặc dầu kết nối này ít an toàn hơn một Mcrosoft Proxy Server kết nối, nhưng nếu sử dụng firewall (tường lửa) hay một kết nối được mã hóa sẽ giúp những dữ liệu nhạy cảm được an toàn hơn. Sử dụng một hệ thống firewall với SQL Server Nhiều công ty sử dụng hệ thống firewall để cô lập các mạng của họ khỏi các sự truy cập từ Internet. Một Firewall có thể được sử dụng để hạn chế truy cập ứng dụng Internet từ mạng của bạn bằng chuyển tiếp duy nhất yêu cầu đối tượng vào địa chỉ TCP/IP đặc biệt trên mạng cục bộ. Các yêu cầu cho tất cả các địa chỉ mạng khác được block ( bị chặn ) bởi firewall. Bạn có thể cho phép các ứng dụng Internet truy cập một instance (trường) của SQL Server trên mạng cục bộ bằng cách cấu hình firewall chuyển tiếp yêu cầu mạng đó đến thẳng địa chỉ mạng của instance của SQL Server. Để làm việc hiệu quả với firewall, phải chắc chắn rằng instance của SQL Server luôn luôn đáp ứng những địa chỉ mạng mà firewall được cấu hình để chuyển tiếp. Địa chỉ TCP/IP của SQL Server gồm 2 phần : phần địa chỉ IP được kết hợp với một hay nhiều card mạng trong một máy vi tính. Và một port TCP/IP định địa chỉ cụ thể đến một instance của SQL Server . Instance mặc định của SQL Server sử dụng cổng TCP 1433 mặc định. Instance được đặt tên tự động , được gán vào một cổng TCP khi Instance khởi động lần đầu tiên. Named Instance có thể tự động thay đổi địa chỉ của port TCP sau khi được khởi động nếu số của port TCP đang được sử dụng bởi một ứng dụng khác . SQL Server chỉ tự động thay đổi port TCP không sử dụng nếu port đó đang lắng nghe . Nếu port đó được chọn thủ công, SQL Server sẽ hiển thị lỗi và tiếp tục lắng nghe các port khác. Nó không giống như các ứng dụng khác sẽ cố gắng sử dụng port 1433 trước khi port đó được ghi nhận là một địa chỉ đã được nhận biết của SQL Server. Khi sử dụng một named Instance của SQL Server với một firewall, ta sử dụng công cụ Server Network Utility thiết lập Instance đó lắng nghe một port TCP được chỉ định. Bạn phải chọn một port TCP không bị sử bởi một ứng dụng khác đang chạy trên cùng một máy tính hay một cluster. Danh sách port đã được ghi nhận để nhiều ứng dụng khác nhau sử dụng, có thể xem tại địa chỉ Người quản trị mạng phải cấu hình một firewall để chuyển tiếp địa chỉ IP và port TCP Instance của SQL Server đang lắng nghe (instance mặc định sử dụng port 1433, hoặc port TCP mà bạn cấu hình để “lắng nghe”). Cũng vậy cấu hình firewall để chuyển tiếp các yêu cầu cho port UDP1434 trên cùng một địa chỉ IP. SQL Server 2000 sử dụng cổng UDP 1434 để thiết lập kết nối truyền thông từ các ứng dụng. Ví dụ, so sánh một máy tính đang chạy một Instance mặc định và hai named instance của SQL Server. Máy tính được thiết lập như là địa chỉ mạng mà 3 instance “lắng nghe” này có địa chỉ IP tương tự nhau. Instance default sẽ đợi trên port TCP 1433, một named instance sẽ đăng ký port TCP 1434 và named instance còn lại là port 1954. Sau đó cấu hình firewall chuyển tiếp yêu cầu mạng đến port UDP 1434 và port TCP 1433,1434 và 1954 trên địa chỉ IP đó. Đường dẫn các tập tin của SQL Server Trong Microsoft SQL Server 2000, vị trí mặc định của các files cài đặt đã thay đổi. Cho instance mặc định của SQL Server, thư mục mặc định của cả chương trình và các file dữ liệu là \Program Files\Microsoft SQL Server\Mssql. Bạn có thể chỉ định một đường dẫn khác file mặc định của chương trình và files dữ liệu. Share Tools được cài đặt mặc định tại \Program Files\Microsoft SQL Server Server\80\Tools. Thư mục này chứa các file dùng chung của tất cả các instance của SQL Server 2000, cả default và named. Các công cụ bao gồm SQL Books Online,Dev Tools và các thành phần khác. Setup cũng cài đặt các file trong thư mục hệ thống . Vị trí của thư mục hệ thống không được phép thay đổi. Vị trí của SQL Server Program File Các file program của SQL Server được đặt tại \Program Files\Microsoft SQL Server\Mssql\Binn . Vị trí của program file là thư mục gốc mà Setup tao ra các thư mục chứa database và log files, cũng như thư mục chứa system log, lưu trữ và mô hình dữ liệu. Setup tạo ra cơ sở dự liệu và log files cho các master, model, tempdb, msdb, pubs và cơ sở dữ liệu Northwind . Các file dữ liệu của SQL Server nên được đặt ở ổ đĩa có dung lượng lớn đủ để các file đó phát triển. Specifying File Paths Trong SQL Server ,vì có nhiều sự lựa chọn instance, instance named được sử dụng khi thêm các chương trình và dữ liệu vào vị trí được chỉ định dành cho người sử dung. Tuy nhiên named instance không yêu cầu đối với các công cụ và các file dùng chung . Đường dẫn của các instance file mặc định cho chương trình và các file dữ liệu Đối với instance mặ định của SQL Server, tên thư mục SQL Server mặc định được là tên của instance mặc định, Song song với thư mục mà bạn chỉ định. Ví dụ, nếu bạn chỉ định instance mặc định của SQL Server sẽ cài đặt ở D:\MySQLDir, thì các đường dẫn là: D\MySQLDir\Mssql\Binn ( Cho các file chương trình). D\MySQLDir\Mssql\Data ( Cho các file dữ liệu ). Đường dẫn của các instance file cho chương trình và các file dữ liệu Đối với bất kỳ instance named nào, tên của các instance được sử dụng với thư mục được chỉ định. Ví dụ, nếu bạn chỉ định instance named MyInstance được cài đặt ở D:\MySqlDir, đường dẫn sẽ là: D:\MySqlDir\MSSQL$MyInstanceA\Binn ( cho các file chương trình ). D:\MySqlDir\MSSQL$MyInstanceA\Data ( cho các file dữ liệu ). Sharing Meta Data Data Trasformation Services (DTS) Designer cung cấp những đặc tính để lưu trữ gói dữ liệu biến đổi và dòng thông tin đến Micosoft SQL Server 2000 Meta Data Services . Bạn có thể lưu trữ danh mục dữ liệu biến đổi vào cơ sở dữ liệu tham chiếu trong một gói và trương mục thông tin về gói lược sử phiên bản của một hàng riêng biệt của dữ liệu riêng hay kho dữ liệu. DTS Designer sử dụng kiểu thông tin riêng , DTS Information Model, cho cấu trúc gói dữ liệu biến đổi và dòng thông tin dữ liệu và lưu nó vào Mete Data Services. Để duyệt qua dòng dữ liệu và thông tin dữ liệu biến đổi tạo ra bằng DTS Designer, sử dụng DTS Browser tìm trên SQL Server Enterprise Manager. Công cụ này cho phép bạn tìm kiếm dữ liệu biến đổi và lược sử phiên bản của một gói và tra cứu gói phiên bản đặc biệt để tạo ra một hàng dữ liệu. Fn_serverchareddrives() Cú pháp Fn_serverchareddrives() Trả về tên của ổ đĩa dùng chung được sử dụng bởi clustered server. Bảng trả về _ Nếu server instance hiện hành không có clustered server, fn_serversharedddrives trả về một hàng trống. _ Nếu server hiện hành là một clustered server, fn_servershareddrives trả về thông tin sau: Name Data type Description DriveName nchar(1) Name of the shared drive Nhận xét: Fn_servershareddrives trả về một danh sách các ổ đĩa dùng chung được sử dụng bởi clustered server. Các ổ đĩa dùng chung này thuộc về cùng nhóm cluster như là tài nguyên SQL Server. Hơn nữa tài nguyên SQL Server cũng phụ thuộc vào các ổ đĩa này. Hàm này giúp người sử dụng nhận dạng ổ đĩa hiện có . CHƯƠNG 3 NHÂN BẢN TRONG SQL SERVER 3.1 > KIẾN TRÚC NHÂN BẢN TRONG SQL SERVER. Nhân bản là một kĩ thuật quan trọng và hữu hiệu trong việc phân bố cơ sở dữ liệu (CSDL) và thực thi các stored procedure. Kĩ thuật nhân bản trong MS SQL Server cho phép bạn tạo ra những bản sao dữ liệu giống hệt nhau, di chuyển các bản sao này đến những vùng khác nhau và đồng bộ hoá dữ liệu 1 cách tự động để tất cả các bản sao có cùng giá trị dữ liệu.Nhân bản có thể thực thi giữa những CSDL trên cùng một server hay những server khác nhau được kết nối bởi mạng LANs,WANs hay Internet. SQL Server đã đưa ra nhiều cơ chế nhân bản để đáp ứng các yêu cầu khác nhau của ứng dụng. Mỗi loại cung cấp các khả năng và thuộc tính khác nhau nhằm đạt đến mục tiêu của tính độc lập site và sự nhất quán các giao dịch. > MỤC TIÊU CHÍNH TRONG NHÂN BẢN SQL Server đã đưa ra nhiều cơ chế nhân bản để đáp ứng các yêu cầu khác nhau của ứng dụng. Mỗi loại cung cấp các khả năng và thuộc tính khác nhau nhằm đạt đến mục tiêu của tính độc lập site và sự nhất quán dữ liệu. Nhất quán dữ liệu (data consistency) Có 2 cách để đạt được tính nhất quán dữ liệu: Nhất quán giao dịch (Transactional Consistency) Hội tụ dữ liệu (Data Convergence Nhất quán giao dịch - Bảo đảm tất cả dữ liệu giống nhau tại mọi site ở bất kì thời điểm. - Tất cả giao dịch thực hiện tại một site duy nhất. Có 2 loại : Nhất quán lập tức (Immediate Transactional Consistency hay Tight Consistency trong MS SQL Server 6.0) Ở kiểu này, tất cả các site được bảo đảm là luôn thấy cùng giá trị dữ liệu tại cùng một thời điểm. Cách duy nhất để đạt được nhất quán giao dịch (transactional consistency) trong môi trường cập nhật phân bố (distributed update environment) là sử dụng 2-phase commit protocol giữa tất cả site tham gia (participating site). Mỗi site phải commit đồng thời mọi thay đổi hoặc không site nào commit những thay đổi. Giải pháp này rõ ràng không khả thi khi số lượng site quá lớn. Nhất quán ngầm (Latent Transactional Consistency hay Loose Consistency trong MS SQL Server 6.0) Có một sự nhất quán ngầm giữa các site tham gia do cóù một sự trì hoãn trong việc phản ánh các giá trị dữ liệu đến các site tham gia và vào lúc này các site không bảo đảm có cùng giá trị dữ liệu. Việc sửa đổi các giá trị dữ liệu có thể bị trì hoãn đủ lâu để tất cả các site cùng cập nhật, sau đó tất cả các site sẽ có cùng giá trị dữ liệu. Ngoài ra các giá trị dữ liệu này cũng phải giống với những giá trị đạt được khi thực hiện các công việc tại một site.Sự khác nhau duy nhất giữa nhất quán giao dịch lập tức và nhất quán giao dịch ngầm là dữ liệu có nhất quán tại cùng một lúc hay không? Hội tụ dữ liệu Với sự hội tụ dữ liệu, tất cả các site có thể quy về cùng 1 giá trị dữ liệu nhưng không nhất thiết là giá trị dữ liệu này bị gây ra bởi những tác vụ được làm trên một site duy nhất. User có thể tự do thao tác trên các site theo các cách khác nhau. Khi các nút (node) đồng bộ, tất cả các site sẽ hội tụ về cùng 1 giá trị. Nếu đụng độ gây ra bởi sự sửa đổi cùng 1 dữ liệu tại những site khác nhau thì những sửa đổi này sẽ được giải quyết một cách tự động( chọn site có độ ưu tiên cao hơn hay site đưa sửa đổi đến trước...). Độc lập site (site autonomy) Độc lập site xét đến ảnh hưởng của những thao tác trên một site đến các site khác. Thường độc lập site càng tăng thì tính nhất quán dữ liệu giảm. Nhân bản kết hợp (Merge replication) có mức độc lập site cao nhất, tạo ra sự hội tụ nhưng lại không đảm bảo tính nhất quán dữ liệu. 2PC (two phase commit) có tính nhất quán dữ liệu cao nhưng lại không có tính độc lập site. Những giải pháp khác thì thường ở giữa 2 tính này. > KIẾN TRÚC NHÂN BẢN Các thành phần chính của nhân bản Publisher: Là 1 server tạo dữ liệu để nhân bản đến các server khác. Nó xác định dữ liệu nào được nhân bản, dữ liệu nào thay đổi và duy trì những thông tin về các công bố tại site đó. Subscriber: Là 1 server lưu giữ nhân bản và nhận các tác vụ cập nhật. SQL Server 7.0 cho phép Subsriber cập nhật dữ liệu nhưng quá trình cập nhập ở Subscriber không giống như ở Publisher. Một Subscriber có thể là một Publisher của các Subscriber khác. Distributor: Là một server mà chứa CSDL phân bố (distribution database) và lưu trữ metadata, history data và transaction. SQL Server sử dụng CSDL phân bố để lưu và chuyển (store_and_forward) dữ liệu nhân bản từ Publisher đến các Subscriber. Có 2 loại Distributor : local Distributor và remote Distributor. Publication: Đơn giản là một tập hợp các mẩu dữ liệu (article). Một mẩu là một nhóm dữ liệu được nhân bản. Một mẩu có thể bao gồm một table hay chỉ là một vài hàng (horizontal fragment) hay cột (vertical fragment). Một Publication thường gồm nhiều mẩu. Pulisher Subcriber Maintains source databases Makes data available for replication Receives data changes Hold copy of data Distributor Receives and stores changes Forwards changes to subscibers Chiều di chuyển dữ liệu Có 2 kiểu di chuyển dữ liệu: Push subscription Publisher đẩy (push) những thay đổi đến Subscriber mà không quan tâm Subscriber có cập nhật hay không. Push subscription được sử dụng trong những ứng dụng mà yêu cầu gởi những thay đổi đến Subscriber ngay khi những thay đổi này xảy ra ở Publisher. - Push Subscription giúp việc quản lý các Subcsriber đơn giản và tập trung hơn, đồng thời giúp bảo mật tốt hơn vì qúa trình khởi động (initialization process) sẽ được quản lý tại một chỗ . Nhưng vì thế, Distributor có thể phải đảm nhận nhiều quá trình phân bố subscription đến các Subscriber cùng một lúc . Điều này dễ dẫn đến hiện tượng thắt cổ chai (bottleneck) . - Mô hình này không thích hợp khi số lượng các Subscriber trở nên quá lớn. - Push subscription gây ra 1 phí xử lý cao hơn tại Publisher. Để tránh hiện tượng này, những thay đổi có thể được đẩy đến Subscriber theo một lịch định kì. Pull subscription - Subsciber kéo (pull) những thay đổi tại Publisher về theo một khoảng thời gian định kì. - Tốt cho những user độc lập thay đổi bởi vì chúng cho phép user xác định khi nào thì những thay đổi dữ liệu được đồng bộ - Ngược với push subscription ,pull subscription bảo mật thấp nhưng cho phép số lượng Subsriber cao hơn . Một publication có thể sử dụng cảû hai push và pull subscription. > TÁC NHÂN (AGENT) Việc thiết kế các nhân bản có thể tạo ra 1 hay nhiều agent. Snapshot agent: - Chuẩn bị lược đồ, data file, stored procedure - Lưu snapshot lên Distributor và ghi lại những thông tin về trạng thái đồng bộ vào CSDL phân bố (distribution database) . - Mỗi publication có 1 snapshot agent riêng chạy trên Distributor và liên kết với Publisher. Log Reader agent: - Di chuyển những transaction cần nhân bản từ transaction log trên Publisher đến CSDL phân bố . - Mỗi publication dùng nhân bản transaction có 1 log reader agent ,chạy trên Distributor và liên kết (connect) đến Publisher. Distribution Agent: - Di chuyển transaction và những tác vụ sao chép giữ trong CSDL phân bố đến Subscriber. - TH: Nhân bản transaction hay snapshot mà đồng bộ lập tức ( immediate synchronization): khi 1 push subscription được tạo, mỗi publication có 1 distribution agent riêng, chạy trên Distributor và liên kết với Subscriber. - TH: Nhân bản transaction và snapshot không đồng bộ lập tức : Publisher và Subscriber sẽ dùng chung distribution agent , chạy trên Distributor và liên kết với Subscriber. - TH: pull subscription đến snapshot publication hay transactional publication: có distribution agent, chạy trên Subscriber - Nhân bản kết hợp (merge replication) không có distribution agent. Merge agent: Di chuyển và điều hòa những thay đổi dữ liệu xảy ra sau khi 1 snapshot khởi động (initial snapshot) được tạo. Mỗi merge publication có 1 merge agent ,liên kết và cập nhật được với cả hai Publisher và Subscriber. Mỗi loại cung cấp các khả năng và thuộc tính khác nhau nhằm đặt đến mục tiêu của tính độc lập site và sự nhất quán dữ liệu. > NHÂN BẢN SNAPSHOT ( snapshot replication ) Giới thiệu Nhân bản snapshot là loại nhân bản đơn giản nhất, nhân bản snapshot sao chép toàn bộ dữ liệu cần nhân bản (còn gọi là quá trình làm tươi dữ liệu) từ Publisher đến các Subscriber. Nó đảm bảo sự nhất quán tiềm ẩn (Latent Transactional Consistency) giữa Publisher và Subscriber. Nhân bản snapshot được đánh giá cao trong các ứng dụng chỉ đọc như tìm kiếm hay các hệ thống không yêu cầu dữ liệu mới nhất và dung lượng dữ liệu không lớn. Nhân bản Snapshot gửi tất cả dữ liệu đến cho Subscriber thay vì chỉ gửi những thay đổi. Nếu mẫu dữ liệu rất lớn nó phải cần đến hệ thống mạng đủ mạnh để truyền dữ liệu. Khi sử dụng nhân bản snapshot cần phải tính đến tỉ lệ giữa kích cỡ của toàn bộ dữ liệu và những thay đổi của nó. Tác nhân (agent) Cập nhật snapshot được thực hiện bởi snapshot agent và distribution agent. Snapshot agent chuẩn bị những snapshot file (snapshot file là file sao chép lược đồ và dữ liệu của những table phân bố) chứa lược đồ và dữ liệu của những table phân bố, lưu những file này vào snapshot folder trên Distributor và ghi lại những công việc đồng bộ trong CSDL phân bố (distribution database). Distribution agent gởi những snapshot job (tác vụ sao chép dữ liệu) giữ trong bảng dữ liệu phân bố đến Subsciber. CSDL phân bố ( distribution database) chỉ được sử dụng trong nhân bản, không chứa user table. Snapshot agent Snapshot agent thực hiện theo các bước sau: Thiết lập một share-lock lên tất cả table (article) trong publication. Share-lock ngăn không cho các user khác cập nhật lên table đó. Sao chép lược đồ dữ liệu của mỗi article ( .sch file) và các index, các ràng buộc ( .idx file) lên Distributor. Các file này được lưu vào 1 thư mục con trong thư mục làm việc của Distributor. Nếu tất cả các Subsciber đều là MS SQL Server thì bản sao của dữ liệu được lưu thành .bcp file. Nếu các Subscriber không đồng nhất ( các Subsciber chứa nhiều loại CSDL khác nhau , ví dụ: Access, Oracle) thì bản sao của dữ liệu được lưu thành .txt file. Cuối cùng agent gỡ bỏ share-lock trên mỗi table phân bố và hoàn tất việc viết vào 1 log history file ( log history file ghi lại quá trình làm việc của các agent). Distribution agent Tác nhân áp dụngï những lược đồ và những dữ liệu vào CSDL của Subscriber. Nếu Subscriber không phải là SQL Server, distribution agent sẽ chuyển đổi kiểu dữ liệu trước khi những dữ liệu này được áp dụng vào Subsciber. Ví dụ: Publisher sử dụng SQL Server ,Subscriber sử dụng Oracle. Trước khi những dữ liệu được áp dụng lên Subscriber , nó sẽ được chuyển đổi kiểu từ SQL Server sang Oracle. Snapshot có thể được áp dụng khi subscription được tạo hay theo 1 khoảng thời gian nhất định. > NHÂN BẢN GIAO DỊCH (Transactional Replication) Giới thiệu Sử dụng nhân bản giao dịch để nhân bản 2 kiểu đối tượng khác nhau: table và stored procedure. Bạn có thể chọn tất cả hay 1 phần của 1 table được nhân bản như là 1 article trong publication. Tương tự, bạn cũng có thể chọn 1 hay nhiều stored procedure được nhân bản như là 1 article trong cùng hay khác publication. Nhân bản giao dịch sử dụng transaction log để giữ những thay đổi được làm trên dữ liệu trong 1 article. SQL Server giám sát những lệnh insert, update, delete hay những sửa đổi trên dữ liệu và lưu những thay đổi đó lên CSDL phân bố (distribution database). Những thay đổi đó sẽ được gởi đến Subscriber và tuân theo một trật tự nhất định. Với nhân bản giao dịch, bất cứ yếu tố dữ liệu nào cũng có 1 publication. Những thay đổi được làm tại Publisher tiếp tục chảy đến 1 hay nhiều các Subsciber hay theo những khoảng thời gian định trước. Tác nhân (agent) Nhân bản giao dịch được thực hiện bởi Snapshot agent, Log Reader agent và Distribution agent. Log Reader agent giám sát transaction log của mỗi CSDL được thiết lập để nhân bản và sao chép những transaction cần nhân bản từ transaction log vào CSDL phân bố (distribution database) . Distribution agent di chuyển những transaction và những tác vụ khởi tạo snapshot được giữ trong table của CSDL phân bố. Snapshot agent Trước khi 1 Subscriber mới có thể nhận những thay đổi từ Publisher, nó phải chứa những table có cùng lược đồ và dữ liệu với những table tại Publisher. Quá trình copy toàn bộ publication từ Publisher qua Subsciber được gọi là initial snapshot. Việc nhân bản những dữ liệu thay đổi chỉ xảy ra sau khi nhân bản giao dịch chắc chắn rằng Subscriber có snapshot (bản sao của những lược đồ và dữ liệu). Khi những snapshot đó được phân bố và áp dụng lên các Subsciber thì chỉ những Subsciber chờ để khởi tạo snapshot mới bị ảnh hưởng. Những Subsciber khác ứng với publication đó mà nhận insert, delete, update hay những thay đổi dữ liệu rồi thì không bị ảnh hưởng. Những hàm mà Snapshot agent thực thi để khởi tạo snapshot trong nhân bản giao dịch tương tự như các hàm được sử dụng trong nhân bản Snapshot. Log Reader agent Log reader agent chạy tiếp tục hay theo 1 khoảng thời gian xác định mà bạn thiết lập vào lúc publication được tạo. Khi thực thi, đầu tiên Log reader agent đọc transaction log của publication và xác định lệnh (insert, delete, update) hay những sửa đổi làm trên dữ liệu được đánh dấu nhân bản. Kế tiếp agent sao chép những transaction đó vào CSDL phân bố tại Distributor. CSDL phân bố (distribution database) trở thành hàng lưu và đẩy (store-and-forward queue) những thay đổi dữ liệu đến Subscriber. Chỉ có commit transaction mới được gởi đến CSDL phân bố. Có sự tương ứng 1-1 giữa transaction trên Publisher và transaction được nhân bản trong CSDL phân bố. Một transaction có thể bao gồm nhiều lệnh. Sau khi toàn bộ transaction được viết vào CSDL phân bố 1 cách thành công, nó sẽ được commit. Sau đó những transaction này sẽ được đẩy đến các Subscriber. Cuối cùng, agent đánh dấu những hàng (row) đã được công bố đến Subscriber trong transaction log để sẵn sàng loại bỏ. Điều này đảm bảo những hàng (row) còn chờ để nhân bản sẽ không bị loại bỏ. Vì thế, transaction log trên Publisher có thể được đổ xuống mà không cản trở việc nhân bản bởi vì chỉ những transaction bị đánh dấu mới bị loại bỏ. Log read agent thực thi trên Distributor. Distribution agent Những transaction được lưu trong CSDL phân bố cho đến khi distribution agent “đẩy” chúng đến tất cả các Subscriber (hoặc 1 distribution agent tại Subscriber “kéo” những thay đổi về). CSDL phân bố chỉ được sử dụng bởi nhân bản và không chứa bất cứ user table. Trong bất kì trường hợp nào bạn cũng không nên tạo những object khác vào trong CSDL phân bố. Những tác vụ làm thay đổi dữ liệu tại Publisher sẽ chảy đến Subscriber và Subscriber sẽ thay đổi dữ liệu theo cùng cách chúng được thay đổi tại Publisher. Điều này đảm bảo rằng các Subscriber sẽ nhận những transaction theo một trật tự như là chúng được làm tại Publisher . Thu dọn trong nhân bản transaction: ( tương tự cho nhân bản snapshot) Khi CSDL phân bố ( distribution database ) được tạo, SQL Server sẽ tự động thêm vào 3 tác vụ tại Distributor: Agent checkup Transaction cleanup History cleanup Những tác vụ này giúp cho việc nhân bản hiệu quả hơn trong môi trường long_running. Tác vụ cleanup giữ lại những transaction của mỗi publication trong 1 giai đoạn xác định sau khi tất cả Subscriber đã nhận chúng. Trong suốt giai đoạn này những transaction sẽ được giữ trong CSDL phân bố. Thiết lập 1 giai đoạn giữ lại kết hợp với lịch backup có thể được sử dụng khôi phục CSDL đích 1 cách tự động khi xảy ra sự cố. Các dạng nhân bản giao dịch Có hai dạng: Cập nhật Subscriber lập tức (Immediate_Updating Subscriber): Trong trường hợp đơn giản nhất, cả hai nhân bản snapshot và giao dịch làm việc dựa trên mô hình nhân bản một chiều ( dữ liệu chỉ được nhân bản từ Publisher đến Subscriber). Tuy nhiên MS SQL Server cung cấp thêm một mô hình mới cho phép Subscriber sửa đổi dữ liệu nhân bản, tùy chọn Immediate_Updating Subscriber sẽ cung cấp sự nhất quán giao dịch ngầm (latent transactional consistency) giữa các Subscriber (những sửa đổi sẽ xảy ra lập tức giữa Subscriber thực hiện tác vụ cập nhật và Publisher) mà không yêu cầu cập nhật chỉ được làm tại Publisher site. Tùy chọn này được thiết lập vào lúc publication được tạo và cho phép Subscriber cập nhật bản sao dữ liệu cục bộ của nó và những thay đổi đó sẽ được phản ánh lập tức đến Publisher bằng cách sử dụng two-phase commit protocol (2PC). 2PC được quản lý bởi Microsoft Distributed Transaction Coordinator (MS DTC). Nếu cập nhật có thể được thực hiện bằng 2PC thì Publisher sẽ phổ biến những thay đổi đến tất cả các Subscriber khác theo lịch làm việc của distribution agent (hay là theo lần làm tươi snapshot kế tiếp). Bởi vì Subscriber gốc đã cập nhật những thay đổi dữ liệu rồi, nên user có thể tiếp tục làm việc với những dữ liệu đó và đảm bảo những thay đổi đó sẽ được cập nhật tại Publisher. Mô hình này đảm bảo tính toàn vẹn giao dịch. Với mô hình này, tính độc lập site sẽ giảm, nhưng vẫn cao hơn khi tất cả các Subscriber cập nhật lập tức. Tuỳ chọn Immediate-updating Subscribers được hỗ trợ sử dụng những công cụ : Triggers Stored procedues Microsoft Distributed Transaction Coordinator (MS DTC) Phát hiện tranh chấp Phát hiện Loopback Triggers Triggers tại Subcriber theo dõi các transaction và báo về cho các publication bằng cách sử dụng những stored procedure gọi từ xa (remote stored procedure call) trong 2- phase commit protocol (2PC) mà được điều khiển bởi MS DTC . Trigger sẽ thực hiện các công việc: Trích giá trị từ những bảng insert hay delete Gọi lệnh BEGIN DISTRIBUTED TRAN{SACTION} Thực thi một remote procedure để gọi stored procedure thích hợp tại Publisher, thông qua những giá trị từ những bảng insert hay delete. Điều khiển cập nhật giá trị timestamp & indentity mới tại Subcriber Nếu gọi những stored procedure từ xa thành công, thì commit transaction phản ánh chính xác cùng những thay đổi tại cả hai Publisher và Subcriber. Sau đó, Publisher bảo đảm rằng những thay đổi được phổ biến đến tất cả các Subcriber khác. Ngược lại nếu không được Subscriber sẽ hủy bỏ (rollback) giao dịch và trả về những lỗi cho user. Stored procedures Stored procedure tại Publisher thực thi những giao dịch khi giao dịch đó không tranh chấp với những thay đổi được làm tại Publisher. Nếu một tranh chấp được phát hiện, giao dịch bị hủy bỏ (roll back) ở cả 2 site. Mỗi article có 3 hàm insert, delete, update. Mỗi hàm tại Publisher sẽ thực hiện các công việc sau: Insert procedure : Cố gắng insert hàng (row). Sau đó kiểm tra giá trị @@ROWCOUNT/@@ERROR và trả về tín hiệu thành công hay sự cố cho lời gọi trigger đó của Subscriber. Delete procedure : Cố gắng xóa hàng . Sau đó kiểm tra giá trị @@ROWCOUNT/@@ERROR và trả về tín hiệu thành công hay sự cố cho lời gọi trigger đó của Subscriber. Update procedure : cố gắng cập nhật hàng có cùng giá trị khoá và timestamp với hàng trong bảng delete. Kiểm tra@@ROWCOUNT / @@ERROR. Nếu thành công, trả về một giá trị timestamp mới. SQL Server tổ chức 2 bảng (table) : delete và insert để lưu những dữ liệu thay đổi được làm trên một bảng (table) mà chưa được commit. Thực tế lệnh update bao gồm 1 hàng trong bảng insert và 1 hàng trong bảng delete. Chú ý : một giao dịch mà ảnh hưởng lên nhiều hàng thì giao dịch đó chỉ được commit khi tất cả các hàng đều được cập nhật lên cả 2 site . MS DTC (Microsoft Distributed Transaction Coordinator) MS DTC quản lý những tác vụ 2-phase commit giữa một Subcriber và Publisher trong một lệnh gọi từ xa ( BEGIN DISTRIBUTED TRANSACTION trong Transact-SQL ). Phát hiện tranh chấp Những stored procedure của Publisher sử dụng cột timestamp để phát hiện một hàng có thay đổi hay không sau khi nó được nhân bản đến Subcriber. Khi Subcriber yêu cầu một giao dịch cập nhật lập tức (immdediate-update transaction), nó gởi giá trị timestamp đến Publisher với tất cả những cột khác trong hàng. Khi đó stored procedure của Publisher so sánh giá trị này với giá trị timestamp hiện tại của hàng. Nếu giá trị này giống nhau thì hàng không được sửa đổi sau khi nó được nhân bản đến Subcriber và vì thế giao dịch này được chấp nhận. Timestamp là một giá trị tự động tăng và duy nhất trong một cơ sở dữ liệu. Phát hiện loopback Nếu một transaction được thực thi thành công lên một Subcriber và Publisher, không cần thiết phổ biến những thay đổi trở về cho Subcriber gốc ( Subscriber đưa những thay đổi đến Publisher ). SQL Server có một cơ chế gọi là phát hiện loopback (loopback detection ) để xử lý tình huống này. Những thông tin sử dụng để phát hiện loopback đựoc lưu thành một transaction bởi cơ sở transaction. Những bảng mà định cư trong những cơ sở dữ liệu khác nhau tại immediate updating Subcriber hay những bảng mà định cư trong những cơ sở dữ liệu khác nhau ở phía bên kia của immediate-updating Subcriber không nên được update trong cùng 1 transaction. Nhân bản những thực thi của Stored procedure SQL server không những cho phép bạn nhân bản dữ liệu trong bảng mà còn hỗ trợ bạn nhân bản stored procedure một trong 2 cách. Nếu bạn có một hay nhiều stored procedure như là những article trong một snapshot publication, SQL server sao chép toàn bộ store procedure từ Publisher đến Subcriber. Nếu bạn gồm một hay nhiều stored procedure như là article trong một nhân bản giao dịch , SQL Server sẽ nhân bản thực thi của stored procedure hơn là những dữ liệu thay đổi gây ra bởi sự thực thi những stored procedure đó. Cách làm này đặc biệt hữu ích trong nhân bản mà kết quả của những stored procedure có thể ảnh hưởng một số lượng lớn dữ liệu. Nhân bản những thay đổi như thực thi một lệnh đơn làm tăng hiệu quả ứng dụng của bạn. Có 2 loại : Procedure execution Serializable Procedure execution Procedure execution Nhân bản procedure execution đến tất cả Subcriber. Điều này xảy ra bất chấp những lệnh đơn trong stored procedure có thành công hay không. Bởi vì những thay đổi dữ liệu được làm bởi stored procedure có thể xảy ra trong nhiều giao dịch, nên dữ liệu tại Subcriber không thể bảo đảm là sẽ nhất quán với dữ liệu tại Publisher. Serializable Procedure execution Chỉ thực hiện nhân bản procedure execution khi procedure được thực thi trong môt chuỗi giao dịch tuần tự. Cách này đảm bảo dữ liệu tại Subscriber nhất quán với dữ liệu tại Publisher. 3.7 > NHÂN BẢN KẾT HỢP ( Merge Replication ) 3.7.1. Giới thiệu Nhân bản kết hợp có tính độc lập site (site autonomy) cao nhất. Publisher và Subscriber có thể làm việc hoàn toàn độc lập và sẽ kết nối với nhau theo những khoảng thời gian để hội tụ các kết quả lại. Nếu đụng độ gây ra bởi các site cùng sửa đổi trên cùng một phần tử dữ liệu thì những đụng độ này sẽ được giải quyết một cách tự động. Khi đụng độ xảy ra, bộ giải quyết đụng độ sẽ chọn site có độ ưu tiên cao hơn hay site sửa đổi dữ liệu đó trước. Các xung đột này có thể được phát hiện và giải quyết theo cấp độ hàng hay cột của bảng dữ liệu. Nhân bản kết hợp nhận biết những thay đổi trong một CSDL nguồn và đồng bộ những giá trị giữa Publisher và Subscriber. Cả hai Publisher và Subscriber đều có thể cập nhật dữ liệu. Trong nhân bản kết hợp, Publisher là server tạo publication. Mặc dù Publisher tạo publication nhưng nó không tự động “thắng” 1 tranh chấp với 1 Subscriber. "Người thắng cuộc" được xác định bởi tiêu chuẩn do bạn thiết lập và những thay đổi dữ liệu tại CSDL đích sẽ được phổ biến đến CSDL nguồn. Tác nhân (agent) Nhân bản kết hợp được thực hiện bởi snapshot agent và merge agent. Snapshot agent chuẩn bị những snapshot file chứa lược đồ và dữ liệu của những table phân bố, lưu những file này vào snapshot folder trên Distributor và ghi lại những công việc đồng bộ trong publication. Merge agent thực hiện những công việc khởi tạo snapshot được tổ chức trong bảng (table) của publication đến Subscriber. Nó cũng kết hợp những dữ liệu thay đổi xảy ra tại Publisher sau khi initial snapshot được tạo và giải quyết tranh chấp theo những luật mà bạn đặt ra hay sử dụng bộ giải quyết tranh chấp (conflict resolver). Snapshot agent Tương tự như Snapshot agent của nhân bản transaction. Merge agent Khi 1 hàng được cập nhật trong một mẩu (article) một trigger tạo cột generation cho hàng đó và gán nó bằng 0. Khi merge agent được thực thi nó sẽ thu thập tất cả những hàng có generation bằng 0 thành một hay nhiều nhóm và gán cho generation một giá trị lớn hơn tất cả những generation trước đó. Merge agent tại mỗi site sẽ theo dõi generation cao nhất mà nó gởi đến các site khác và các generation cao nhất mà các site khác đã gởi đến nó. Những generation này được lưu trong hàng (row) có thể khác nhau giữa các site bởi vì generation tại một site phản ánh thứ tự những thay đổi được xử lý tại site đó. Vào lúc đồng bộ, merge agent gởi tất cả những dữ liệu thay đổi đến site khác. Tại CSDL nguồn, những giá trị đến được kết hợp với những giá trị đã tồn tại. Merge agent ước lượng cả 2 giá trị dữ liệu đến và hiện có và bất cứ tranh chấp nào giữa 2 giá trị cũ và mới cũng được giải quyết 1 cách tự động dựa theo độ ưu tiên hay user thay đổi dữ liệu trước hay kết hợp giữa 2 cách trên (dùng với nhóm site có độ ưu tiên tương đương nhau). Bạn cũng có thể thực thi những chiến lược giải quyết tranh chấp thông qua COM hay bộ giải quyết stored procedure (stored procedure resolver). Những dữ liệu thay đổi được nhân bản đến những site khác chỉ khi 1 đồng bộ xảy ra và việc đồng bộ này có thể mất vài phút, vài ngày hay thậm chí vài tuần. Nhân bản kết hợp có tính độc lập site rất cao. Tất cả site dều có thể thực hiện update, delete, insert trên dữ liệu phân bố trên site của nó và độc lập với những thay đổi được làm trên những site khác. Tuy nhiên nhân bản kết hợp không đảm bảo tính toàn vẹn giao dịch. Thay vì vậy nó đẩy mạnh sự hội tụ dữ liệu. Tất cả những thay đổi được làm tại tất cả các site sẽ hội tụ về cùng một giá trị, mặc dù giá trị đó không đảm bảo là giống nhau như là tất cả những thay đổi đó được áp dụng lên một site. Vì vậy kiểu này không thích hợp cho những ứng dụng yêu cầu toàn vẹn giao dịch. Merger agent là một công cụ của SQL Server Agent và có thể được quản lý trực tiếp bằng cách sử dụng SQL Server Enterprise Manager. Snapshot agent thực thi trên Distribution. Merge agent thực thi trên Distribution khi dùng push subsciption hay thực thi trên Subsciber khi dùng pull subsciption. Giải quyết tranh chấp trong nhân bản kết hợp MA phát hiện tranh chấp thông qua một cột hệ thống gọi là lineage trong bảng MSmerge-contents, đại diện cho quá trình thay đổi trong một hàng. Agent cập nhật cột lineage trong MS merge-contents một cách tự động khi một user cập nhật hàng. Mỗi cột chứa một mục (entry) cho mỗi site mà cập nhật lên hàng. Mỗi entry kết hợp giữa chỉ số (id) của site và version cuối cùng của hàng được tạo bởi site đó. Khi MA kết hợp những thay đổi, và nó đụng phải một hàng mới thay đổi, nó sẽ xem xét cột lineage của hàng trên mỗi site để xác định có tranh chấp hay không ? Khi tranh chấp xảy ra, agent khởi động một bộ hoà giải tự động. “Người thắng” tranh chấp có thể dựa theo độ ưu tiên hoặc giải pháp chọn người đến trước nhất hay phương pháp truyền thống sử dụng bộ giải quyết tranh chấp COM hay store procedure. Tranh chấp dữ liệu trong table có thể được nhận biết ở cấp độ cột hoặc cấp độ hàng. Chọn lựa (option) mặc định là cột (column-tracked articles). Chọn lựa này cho phép những thay đổi được làm trên từng cột riêng biệt nhau, chỉ những thay đổi trên cùng một cột bị đánh dấu như là một tranh chấp. Tuy nhiên trong một vài ứng dụng, những luật của ứng dụng của bạn có thể đối xử đồng thời những thay đổi đến toàn bộ hàng như là một tranh chấp. Trong trường hợp này, cấp độ hàng là một chọn lựa. Khi tranh chấp xảy ra, một bộ giải quyết tranh chấp (conflict resolver) sẽ xác định tranh chấp được giải quyết như thế nào. Resolver áp dụng một tập luật qui định lên dữ liệu tranh chấp và chọn tác vụ thích hợp. Conflict resolver tạo ra những bảng conflict-usertablename để lưu những thông tin về tranh chấp. Bảng này được giữ tại Publisher cho những ứng dụng sử dụng centralized conflict logging và tại Subcriber đối với những ứng dụng sử dụng decentralized conflict logging. Bảng này có cùng cấu trúc với bảng gốc, và conflict reslover sao chép phiên bản (version) gần nhất của hàng vào bảng. Version “thắng cuộc” của hàng định cư trong user table thật sự. Những cột trong bảng hệ thống sysmergearticles giữ những thông tin về những bảng có liên quan đến bảng tranh chấp, và tên của những bảng đó. Xoá bỏ những tranh chấp sẽ lần theo bảng MSmerge-delete-conflicts. Với một vài tranh chấp bạn không thể phổ biến những thay đổi từ một site đến các site khác. Ví dụ hai site cùng insert một hàng có cùng một khoá dẫn đến xảy ra tranh chấp. Nếu mỗi lệnh insert đều thành công, thì những ràng buộc vi phạm sẽ không được biết cho đến khi quá trình đồng bộ site xảy ra. Lúc này MS SQL Server tự động xoá một trong hai hàng có cùng khóa chính đó. Những thông tin lỗi này cũng được lưu trong bảng tranh chấp. Những vấn đề khác như là vi phạm ràng buộc duy nhất yêu cầu một vài tác vụ user để khôi phục sự hội tụ. Vi phạm tính toàn vẹn hay gặp nhất là insert một hàng với một khoá ngoại trong khi site khác thì đang xoá hàng với khoá chính tương ứng. SQL Server cũng tự xoá những hàng vi phạm các ràng buộc này. SQL Server nhận ra sự cần thiết cho những ứng dụng để có một lược đồ giải quyết tranh chấp mà xảy ra trong suốt quá trình kết hợp. Khi xây dựng ứng dụng, bạn có 3 thay đổi theo cơ chế giải quyết tranh chấp : Giải quyết tranh chấp dựa trên độ ưu tiên là mặc định khi bạn tạo ra ứng dụng. Giải quyết theo những store procedure mà bạn xây dựng theo những luật hay theo những dữ liệu xác định của bạn. Bộ giải quyết COM. SQL server cho phép bạn xây dựng một bộ giải quyết tranh chấp (conflict resolver). Tuy nhiên, sử dụng bộ giải quyết tranh chấp COM thì phức tạp hơn là thực thi một custom store procedure resolver. Bạn bên sử dụng store procedure conflict resolver bất cứ khi nào có thể. CHƯƠNG 4 TOPOLOGY 4.1 > THIẾT KẾ TOPOLOGY Trong mạng máy tính, khuôn (dạng) kết nối giữa các thiết bị goị là liên lạc topology (communication topology). Một communication topology định nghĩa quan hệ tồn tại giữa những replica và xác định quá trình đồng bộ xảy ra như thế nào giữa các replica này. Một phần quan trọng của việc thực hiện nhân bản trong ứng dụng của bạn là lập kế hoạch cho communication topology để thiết lập vai trò của các server tham gia vào nhân bản: Chọn mô hình nhân bản thích hợp. Xác định Distributor cục bộ(local) hay từ xa (remote)? Xác định cơ sở dữ liệu phân bố có dùng chung hay không? Nếu bạn có nhiều Publisher dùng chung 1 Distributor thì mỗi Publisher nên có 1 cơ sở dữ liệu phân bố riêng hay không ? Hay là chúng sẽ dùng chung một 1 cơ sở dữ liệu phân bố? Mô hình topology đơn giản nhất là một Publisher và Distributor trên cùng một server và một Subcriber trên một server khác. Tuy nhiên trong hầu hết các hệ thống thường có nhiều Publisher, nhiều Distributor và hàng trăm (thậm chí hàng ngàn) Subcriber. > CÁC KIỂU TOPOLOGY MS SQL Server chỉ hỗ trợ một hub-and-spoke topology. Trong một hub-and-spoke topology , dữ liệu chảy giữa các Subcriber thông qua một Publisher hay Distributor. Liên lạc trực tiếp không tồn tại giữa các Subcriber. Một Subcriber bị “chết” không ảnh hưởng đến các Subcriber khác cập nhật dữ liệu nhưng Publisher hoặc Distributor bị “chết” sẽ làm cho hệ thống hoàn toàn mất khả năng Hub-and-spoke topology chứa 1 điểm yếu : hub. Nếu hub (hub đóng vai trò như Publisher và là nơi tập trung điều khiển các quá trình đồng bộ dữ liệu) điều khiển đồng bộ bị “chết” thì qui trình đồng bộ không thể tiếp tục giữa các satellite (1 Subscriber là 1 satellite). Vấn đề này có thể được điều khiển bằng cách gán một trong các satellite đóng vai trò như một hub mới nếu hub cũ bị “chết” (SQL Server không hỗ trợ việc này) . Hub-and-spoke topology là một khởi điểm tốt cho nhiều nhân bản và có thể cung cấp những mô hình nhân bản khác nhau. Có 4 dạng topology: Central Publisher Central publisher with remote Distributor Publishing Subcriber Central Subcriber Central publisher Đây là mô hình đơn giản nhất, bao gồm một Publisher và một Distributor trên cùng server và một Subcriber trên một server khác. Mô hình này trở nên phức tạp hơn nếu bạn tăng số lượng Subcriber. Mô hình này thích hợp để phân bố master data, list hay report từ một Central Publisher đến các Subcriber Chú ý : Vai trò của Publisher và Subcriber không loại trừ nhau, chúng có thể thực hiện đồng thời cả 2 vai trò. Ví dụ : Server A công bố publication 1 và server B công bố publication 2. Trong trường hợp này server A vừa đóng vai trò Publisher của publication 1, vừa đóng vai trò Subscriber của publication 2. Tương tự server B vừa đóng vai trò Publisher của publication 2, vừa đóng vai trò Subscriber của publication 1. Central publisher with remote Distributor Mô hình này được dùng để giảm những quá trình cục bộ và gỉam việc sử dụng không gian đĩa trên Publisher mặc dù nó sẽ làm tăng số lượng tải trên đường truyền mạng . Mỗi máy sẽ thực hiện những tác vụ riêng. Publisher nên được kết nối đến Distributor bởi một đường truyền tốc độ cao và tin cậy. > PUBLISHER SUBCRIBER Mô hình này sử dụng 2 server để phân bố cùng một dữ liệu. Publisher gởi dữ liệu đến một Subcriber và sau đó Subcriber này sẽ gửi tiếp dữ liệu đến các Subcriber khác. Mô hình này hữu ích khi một Publisher phải gởi dữ liệu đến Subcriber theo một đường truyền chậm hay quá tốn kém .Nếu Publisher và Subcriber xa nhau thì chọn một Subcriber làm trung gian giữa Publisher và các Subcriber còn lại, như vậy chi phí về đường truyền sẽ giảm một cách đáng kể. Nếu có một số Subcriber ở xa, sử dụng publishing Subcriber để dời việc lấy dữ liệu đến Subcriber đó. Bởi vì một server có thể đóng 2 vai trò Publisher và Subcriber, nên thiết lập cấu hình này thì đơn giản. 4.4 > CENTRAL SUBCRIBER Trong mô hình này, một số Publisher cùng nhân bản những thông tin vào một bảng đích chung tại một Subcriber. Bảng dữ liệu đích được phân mảnh ngang và phải chứa khóa chính. Mô hình này có thể rất hữu ích, như trong hệ thống cần tập hợp tất cả các bảng thống kê dữ liệu từ 1 số server vào 1 server trung tâm hay cần phải thống nhất dữ liệu từ những server độc lập ở những nơi khác nhau.