Microsoft SQL Server 2008 R2 Unleashed- P62 pps

SQL Server 2008 Publisher Adventure Works translog SQL Server 2008 Subscriber Adventure Works translog Customer Sales CustomerID TerritoryID AccountNumber CustomerType rowguid Modi

Trang 1

Customer (Sales)

CustomerID

TerritoryID

AccountNumber

CustomerType

rowguid

ModifiedDate

1345

2354

3346

7901

8921

1

2

5

4

AW1345

AW2354

AW3346

AW7901

AW8921

CustomerID

120203

106705

022305

041506 0321206

ModifiedDate

I I S

I

I I

CustomerType TerritoryID

X69G9

W211G

7SQ78K

W12DV

WZ8R4

S2345X

RT66Y

rowguid AccountNumber

43661 43663 7/1/2001 7/1/2001

2354

7643

CustomerID

1345

2354

7643

8921

43659

43661

43663

43665

1

7/1/2001

7/13/2001

DueDate RevisionNumber

5

Status OrderDate

2354 7643

SalesOrderHeader (Sales)

Only the orders for 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

Trang 2

SQL Server

2008

Publisher

Adventure Works translog

SQL Server 2008

Subscriber

Customer (Sales)

CustomerID

TerritoryID

AccountNumber

CustomerType

rowguid

ModifiedDate

AdventureWorks (Publication)

UPDATE Customers

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

(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

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 followinclud-ing:

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

Trang 3

SQL Server

2008

Subscription

Server

Adventure

Works

translog

SQL Server 2005

Subscription Server

Oracle

Subscription

Server

Adventure

Works

SQL Server 2000

Central Publisher (default option)

distribution

SQL Server 2008

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

Trang 4

SQL Server

2008

Subscription

Server

Adventure

Works

translog

SQL Server 2005

Oracle

Subscription

Server

Adventure

Works

SQL Server 2000

SQL Server 2008

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

Trang 5

SQL Server 2008

distribution

SQL Server 2008

distribution

SQL Server

2008

Subscription

Server

Adventure

Works

translog

SQL Server 2005

Oracle

Subscription

Server

Adventure

Works

SQL Server 2000

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 configurareplica-tions due to its optimal characteristics Nine out of ten replicareplica-tion 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

Trang 6

SQL Server

2008

Distribution distribution

Adventure

Works

translog

SQL Server

2008

Adventure

Works

translog

SQL Server 2008

Subscription Server SQL Server 2008

Adventure Works

Central Subscriber

SQL Server 2008

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

Trang 7

SQL Server

2008

Multiple Publishers

of a Single Table

Customers Table

distribution

Adventure

Works

translog

SQL Server 2008

1345

1356

2354

3346

7643

7901

8921

1

2

1

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

X69G9

W211G

7SQ78K

W12DV

WZ8R4

S2345X

RT66Y

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

Trang 8

SQL Server 2008

Subscription

Server

SQL Server

2008

Updating Subscriber

SQL Server Queue (Queue Reader Agent)

Update Customers set AccountNumber=null where CustomerID=12345

Adventure

Works

translog

SQL Server 2008

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

Trang 9

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

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

X69G9

W211G

7SQ78K

W12DV

WZ8R4

S2345X

RT66Y

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

Trang 10

SQL Server

2008

distribution

Adventure

Works

translog

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)

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 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

Định dạng
Số trang	10
Dung lượng	544,83 KB