Microsoft SQL Server 2008 R2 Unleashed- P62 pps

ptg 554 Customer (Sales) CustomerID TerritoryID AccountNumber CustomerType rowguid ModifiedDate 1345 1356 2354 3346 7643 7901 8921 1 2 1 2 3 5 4 AW1345 AW1356 AW2354 AW3346 AW7643 AW7901 AW8921 CustomerID 120203 051605 106705 022305 122205 041506 0321206 ModifiedDate I I S I S I I CustomerTypeTerritoryID X69G9 W211G 7SQ78K W12DV WZ8R4 S2345X RT66Y rowguidAccountNumber 43661 43663 7/1/2001 7/1/2001 2354 7643 CustomerID 1345 1356 2354 3346 7643 7901 8921 43659 43660 43661 43662 43663 43664 43665 1 1 1 2 1 1 1 7/1/2001 7/1/2001 7/1/2001 7/1/2001 7/1/2001 7/1/2001 7/1/2001 SalesOrderID CustomerID 7/13/2001 7/13/2001 7/13/2001 7/13/2001 7/13/2001 7/13/2001 7/13/2001 DueDateRevisionNumber 5 5 5 5 5 5 5 StatusOrderDate 2354 7643 SalesOrderHeader (Sales) Only the orders for customer type “S” join SalesOrderID RevisionNumber OrderDate DueDate ShipDate Status OnlineOrderFlag SalesOrderNumber PurchaseOrderNumber AccountNumber CustomerID ContactID SalesPersonID TerritoryID BillToAddressID ShipToAddressID AW_H_and_J (Publication) CustomerH (Article) OrdersHJ (Article) SalesOrderID OrderDate CustomerID FIGURE 19.8 Horizontal and Join publication: Joining customers that are stores (type “S”) to corresponding SalesOrderHeader rows. For instance, if you wanted to update the Customer table for every customer via an UPDATE SQL statement, the resulting Customer table updates would be replicated as a large multi- step transaction involving at least 5,000 separate UPDATE statements at a minimum. This number of statements would significantly bog down your network. However, with stored procedure execution articles, only the execution of the stored procedure is replicated to the subscription server, and the stored procedure—not the numerous update statements— is executed on that subscription server. Figure 19.9 illustrates the difference in execution described earlier. Some subtleties when utilizing this type of data replication processing can’t be overlooked, such as making sure the published stored procedure behaves the same on the subscribing server side. Many more data replication terms are presented in this chapter, but it is essential that you first learn about the different types of replication scenarios that can be built and the reasons any of them would be desired over the others. It is also worth noting that Microsoft SQL Server 2008 supports replication to and from many different “heteroge- neous” data sources. In other words, OLE DB and ODBC data sources can subscribe to SQL Server publications, and they can receive data replicated from a number of data sources, including Microsoft Exchange, Microsoft Access, Oracle, and DB2. CHAPTER 19 Replication Download from www.wowebook.com ptg 555 SQL Server 2008 Publisher Adventure Works translog SQL Server 2008 Subscriber Adventure Works translog Customer (Sales) CustomerID TerritoryID AccountNumber CustomerType rowguid ModifiedDate AdventureWorks (Publication) UPDATE Customers set AccountNumber=null where CustomerID >=1 and CustomerID <=5000 UPDATE customers set AccountNumber=null where customerID=1 UPDATE customers set AccountNumber=null where customerID=1 … UPDATE customers set AccountNumber=null where customerID=1 Exec PRC_Cust_Updt 1,5000 Exec PRC_Cust_Updt 1,5000 (on subscription server) is replicated as: PRC_Cust_Updt (Article) Customers (Article) distribution Distributor FIGURE 19.9 Comparison of stored procedure execution and standard SQL statement replica- tion. Replication Scenarios 19 Replication Scenarios In general, depending on your business requirements and hardware or network constraints, one of several different data replication models can be implemented, includ- ing the following: . Central publisher . Central publisher with a remote distributor . Publishing subscriber . Central subscriber . Multiple publishers with multiple subscribers . Updating subscribers . Peer-to-peer The Central Publisher Replication Model The central publisher replication model, shown in Figure 19.10, is Microsoft’s default scenario and a common model used if your primary server has plenty of spare CPU cycles and you want a simple replication model. In this scenario, one SQL Server performs the function of both publisher and distributor. The publisher/distributor can have any number Download from www.wowebook.com ptg 556 CHAPTER 19 Replication SQL Server 2008 Subscription Server Adventure Works translog SQL Server 2005 Subscription Server Adventure Works translog Oracle Subscription Server Adventure Works SQL Server 2000 Subscription Server Adventure Works translog Central Publisher (default option) distribution SQL Server 2008 Adventure Works translog Publication Server Distribution Server FIGURE 19.10 The central publisher scenario is fairly simple and is a replication model used often. The central publisher scenario can be used in the following situations: . Creation of a copy of a database for ad hoc queries and report generation (classic use) . Publication of master lists to remote locations, such as master customer lists or master price lists . Maintenance of a remote copy of an online transaction processing (OLTP) database that could be used by the remote sites during communication outages . Maintenance of a spare copy of an OLTP database that could be used as a “hot spare” in case of server failure However, it’s important to consider the following for this replication model: . If your OLTP server’s activity is substantial and affects greater than 10% of your total data per day, this scenario is not for you. Other scenarios or configurations will better fit your needs. . If your OLTP server is maximized on CPU, memory, and disk utilization, you should also consider another data replication scenario because this one is not for you either. of subscribers. These subscribers can come in many different varieties, such as SQL Server 2008, SQL Server 2005, SQL Server 2000, SQL Server 7.0, and Oracle. Download from www.wowebook.com ptg 557 Replication Scenarios 19 SQL Server 2008 Subscription Server Adventure Works translog SQL Server 2005 Subscription Server Adventure Works translog Oracle Subscription Server Adventure Works SQL Server 2000 Subscription Server Adventure Works translog SQL Server 2008 Adventure Works translog Publication Server distribution SQL Server 2008 Remote Distribution Server Central Publisher Remote Remote Distributor FIGURE 19.11 You use the central publisher with remote distributor scenario when you need to offload the distribution work to another server (to minimize the impact to the publishing server). The Central Publisher with Remote Distributor Replication Model The central publisher with remote distributor scenario, as shown in Figure 19.11, is similar to the central publisher scenario and would be used in the same general situations. The major difference between the two is that in the central publisher with remote distributor scenario, a second server is used to perform the role of distributor. This is highly desirable when you need to free the publishing server from having to perform the distribution task from a CPU, disk, and memory point of view. This is also the best scenario from which to expand the number of publishers and subscribers. Remember that a single distribution server can distribute changes for several publishers. The publisher and distributor must be connected to each other via a reliable, high-speed data link. This remote distributor scenario is proving to be one of the best data replication configurations due to its minimal impact on the publication server and maximum distribution capability to any number of subscribers. As mentioned previously, the central publisher/remote distributor approach can be used for all the same purposes as the central publisher scenario, and it also provides the added benefit of having minimal resource impact on the publication servers. If your OLTP server’s activity affects more than 10% of your total data per day, this scenario can usually handle it without much issue. If your OLTP server has overburdened CPU, memory, and disk utilization, implementing this model easily solves these issues as well. The central Download from www.wowebook.com ptg 558 CHAPTER 19 Replication SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog SQL Server 2008 ServerServerServer SubscriptionPublicationDistribution distribution Adventure Works translog SQL Server 2008 Subscription Server Adventure Works translog SQL Server 2005 Subscription Server Adventure Works translog Oracle Subscription Server Adventure Works SQL Server 2000 Subscription Server Adventure Works translog Publishing Subscriber FIGURE 19.12 The publishing subscriber scenario works well when you have to deal with slow, unpredictable, or expensive network links in diverse geographic situations. publisher/remote distribution model is useful for the vast majority of all the data replica- tion configurations due to its optimal characteristics. Nine out of ten replication scenarios that this author has implemented used the remote distributor replication model. The Publishing Subscriber Replication Model In the publishing subscriber scenario, as shown in Figure 19.12, the publication server also has to act as a distribution server to one subscriber. This subscriber, in turn, immedi- ately publishes the data to any number of other subscribers. The configuration depicted here does not use a remote distribution configuration option but serves the same distribu- tion model purpose. This scenario is best used when a slow or expensive network link exists between the original publishing server and all the other potential subscribers. This allows the initial (critical) publication of the data to be distributed from the original publishing server to that single subscriber across the slow, unpredictable, or expensive network line. Then, each of the many other subscribers can subscribe to the data, using faster, more predictable, “local” network lines than they would have with the publishing subscriber server. A classic example of this model is a company whose main office is in San Francisco and has several branch offices in Europe. Instead of replicating changes to all the branch offices in Europe, it replicates the updates to a single publishing subscriber server in Paris. This publishing subscriber server in Paris then replicates the updates to all other subscriber servers around Europe. Download from www.wowebook.com ptg 559 Replication Scenarios 19 SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog Subscription Server SQL Server 2008 Adventure Works Central Subscriber SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog FIGURE 19.13 With the central subscriber scenario, several publishers send data to a single, central subscriber. The Central Subscriber Replication Model In the central subscriber scenario, as shown in Figure 19.13, several publishers replicate data to a single, central subscriber. Basically, this supports the concept of consolidating data at a central site. An example of this might be consolidating all new orders from regional sales offices to company headquarters. In such a situation, you now have several publishers of the Orders table, and you need to take some form of precaution, such as filtering by region. This would guarantee that no one publisher could update another region’s orders. The Multiple Publishers with Multiple Subscribers Replication Model In the multiple publishers with multiple subscribers scenario, as shown in Figure 19.14, a common table (such as the Customer table) is maintained on every server participating in the scenario. Each server publishes a particular set of rows (for example, the customer rows in a customer’s own territory) that pertain to it—usually via filtering on something that identifies that site to the data rows it owns—and subscribes to the rows that all the other servers are publishing. The result is that each server has all the data at all times and can make changes to its data only. You must be careful when implementing this scenario to ensure that all sites remain synchronized. The most frequently used applications of this system are regional order processing systems and reservation tracking systems. When setting up this type of system, you need to make sure that only local users update local Download from www.wowebook.com ptg 560 CHAPTER 19 Replication SQL Server 2008 ServerServerServer SubscriptionPublicationDistribution Multiple Publishers of a Single Table Customers Table Territory 1 Territory 2 distribution Adventure Works translog SQL Server 2008 ServerServerServer SubscriptionPublicationDistribution distribution Adventure Works translog 1345 1356 2354 3346 7643 7901 8921 1 2 1 2 2 2 1 AW1345 AW1356 AW2354 AW3346 AW7643 AW7901 AW8921 CustomerID 120203 051605 106705 022305 122205 041506 031206 ModifiedDate I I S I S I I CustomerTypeTerritoryID X69G9 W211G 7SQ78K W12DV WZ8R4 S2345X RT66Y rowguidAccountNumber FIGURE 19.14 In the multiple publishers of a single table scenario, every server in the scenario maintains a common table. data. This check can be implemented through the use of stored procedures, restrictive views, or a check constraint. The Updating Subscribers Replication Model SQL Server 2008 has built-in functionality that allows the subscriber to update data in a table to which it subscribes and have those updates automatically made back to the publisher through either immediate or queued updates. This model, called the updating subscribers model, utilizes a two-phase commit process to update the publishing server as the changes are made on the subscribing server. These updates are then replicated to any other subscribers, but not to the subscriber that made the update. Immediate updating allows subscribers to update data only if the publisher will accept these updates immediately. If the changes are accepted at the publisher, they are propa- gated to the other subscribers. The subscribers must be continuously and reliably connected to the publisher to make changes at the subscriber. Queued updating allows subscribers to update data and then store those updates in a queue while disconnected from the publisher. When the subscriber reconnects to the publisher, the updates are propagated to the publisher. This functionality utilizes SQL Server 2008 queues and the queue reader agent or Microsoft Message Queuing (MSMQ). A combination of immediate updating with queued updating allows the subscriber to use immediate updating but switch to queued updating if a connection cannot be maintained Download from www.wowebook.com ptg 561 Replication Scenarios 19 SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog Subscription Server SQL Server 2008 Updating Subscriber SQL Server Queue (Queue Reader Agent) Update Customers set AccountNumber=null where CustomerID=12345 Adventure Works translog Subscription Server SQL Server 2008 Adventure Works translog FIGURE 19.15 An updating subscriber updating its copy of a customer table and queuing the changes back to the publisher. between the publisher and subscribers. After switching to queued updating, reconnecting to the publisher, and emptying the queue, the subscriber can switch back to immediate updating mode. An updating subscriber is shown in Figure 19.15. The Peer-to-Peer Replication Model In SQL Server 2008, the peer-to-peer replication model can provide a simpler way for all nodes to have the same data and also gives them the capability to update this data inde- pendently. Peer-to-peer replication is different from subscriber updating in that there is no publisher/subscriber hierarchical relationship. Each peer is equal in level. They establish peer originator IDs so that each can keep track of where updates are coming from and can be utilized if conflicts arise. Peers do not subscribe to each other’s data; they share each other’s data. There are several limitations with peer-to-peer replication, most of which are to protect this peer-to-peer relationship from being corrupted or from having major data conflicts arise. There are no queues or immediate updating mechanisms involved, thus making this approach very useful when you need to have the same data in more than one place and need to update your local data to your heart’s content. If your peers typically do not update the same rows (as in regional data peer-to-peers), this replication model can be very reliable with minimal issues. This type of replication model also allows for any number of peers and provides a separate, very graphic wizard to configure each node in the topology. NOTE New peer nodes can also be added to the topology without having to quiesce the topol- ogy, thus increasing the availability of the entire replication model. Download from www.wowebook.com ptg 562 CHAPTER 19 Replication SQL Server 2008 Publication Server Peer-to-Peer Customers Table North American Server Peer Originator id: 1 Asia Server Peer Originator id: 2 Adventure Works translog SQL Server 2008 Publication Server Adventure Works translog distribution 1345 1356 2354 3346 7643 7901 8921 1 2 1 2 3 5 4 AW1345 AW1356 AW2354 AW3346 AW7643 AW7901 AW8921 CustomerID 120203 051605 106705 022305 122205 041506 031206 ModifiedDate I I S I S I I CustomerTypeTerritoryID X69G9 W211G 7SQ78K W12DV WZ8R4 S2345X RT66Y rowguidAccountNumber SQL Server 2008 Distribution Server FIGURE 19.16 Peer-to-peer replication. Figure 19.16 illustrates a typical peer-to-peer configuration with each peer using a remote distribution server. Also note that with peer-to-peer replication, you might decide to prohibit updates to the other nodes’ data by putting into place some type of stored proce- dure or view restrictions that allow the local node to update only its own local data. The example in Figure 19.16 shows that North American users can update customers with customer IDs between 1 and 3000, whereas Asian users can update customers with customer IDs between 3001 and 9000. Subscriptions A subscription is essentially a formal request and registration of that request for data that is being published. By definition, you subscribe to all articles of a publication. When a subscription is being set up, you have the option of either having the data “pushed” to the subscriber server or “pulling” the data to the subscription server when it is needed. This is referred to as either a push subscription or pull subscription. As shown in Figure 19.17, a pull subscription is set up and managed by the subscription server. The biggest advantage here is that pull subscriptions allow the system administra- tors of the subscription servers to choose what publications they will receive and when they receive them. With pull subscriptions, publishing and subscribing are separate acts and are not necessarily performed by the same user. In general, pull subscriptions are best Download from www.wowebook.com ptg 563 Subscriptions 19 SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog Subscription Server SQL Server 2008 Subscriber Publisher PUSH: initiated by Publisher (agent will be on the Publisher if local distribution, or on the Distributor if remote distribution) PULL: initiated by Subscriber (agent will be on the subscriber) Adventure Works translog AW (Publication) Customers (Article) PULL PUSH FIGURE 19.17 Push or pull subscriptions. when the publication does not require high security or if subscribing is done intermittently when the subscriber’s data needs to be periodically brought up to date. As you can also see in Figure 19.17, a push subscription is created and managed by the publication and distribution server. In effect, the distribution server and all the agents that do the work are pushing the publication to the subscription server. The advantage of using push subscriptions is that all the administration takes place in a central location (on the publication/distribution server side). In addition, publishing and subscribing happen at the same time, and many subscribers can be set up at once. This type of subscription is also recommended when dealing with heterogeneous subscribers because of the lack of pull capability on the subscription server side. Anonymous Subscriptions (Pull Subscriptions) It is possible to have “anonymous” subscriptions. An anonymous subscription is a special type of pull subscription that can be used in the following circumstances: . When you are publishing data to the Internet . When you have a huge number of subscribers . When you don’t want the overhead of maintaining extra information at the publisher or distributor . When all the rules of your pull subscriptions apply to all your anonymous subscribers Normally, information about all the subscribers, including performance data, is stored on the distribution server. Therefore, if you have a large number of subscribers or you do not want to track detailed information about the subscribers, you might want to allow anony- mous subscriptions to a publication. Then little is kept at the distribution server, but it then becomes the responsibility of the subscriber to initiate the subscription and to keep synchronized. Download from www.wowebook.com . such as SQL Server 2008, SQL Server 2005, SQL Server 2000, SQL Server 7.0, and Oracle. Download from www.wowebook.com ptg 557 Replication Scenarios 19 SQL Server 2008 Subscription Server Adventure. Scenarios 19 SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog SQL Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog SQL Server. Server 2008 ServerServer PublicationDistribution distribution Adventure Works translog Subscription Server SQL Server 2008 Adventure Works Central Subscriber SQL Server 2008 ServerServer PublicationDistribution distribution Adventure