Go To TechNet Home Page
| Updated: March 13,1996 | Go To TechNet Home Page |
This paper provides an orientation to SQL Server 6.0 replication, describing its essential features, components, and capabilities. It also provides a replication glossary that defines many replication-related terms.
Replication Overview
The Publishing/Subscribing Metaphor
Replication Components
Replication Is Log-Based
Server Roles in Replication
Data Distribution Options
Synchronization
Push and Pull Subscriptions
Graphical Administration
Replication Security
Replication and SQL Executive
Replication and ODBC
Replication Scenarios
Frequently Asked Questions
Replication Terminology
Replication is the duplication of table schema and data from a source database to a destination database. There are two basic replication models, tight consistency and loose consistency.
Tight consistency is a replication model that guarantees that all copies will be constantly identical to the original. It requires a high-speed LAN, reduces database availability, and is a less scalable model than one based on loose consistency. This is implemented today through the use of two-phase commit. (For information on implementing two-phase commit for SQL Server 6.0, see Microsoft SQL Server Programming DB-Library for C.)
Loose consistency is a replication model that allows a time lag between the moment when original data is altered and when the replicated copies of that data are updated. It does not guarantee that all copies will be constantly identical to the original. An advantage of loose consistency is that it supports LANs, WANs, fast and slow communication links, and intermittently connected databases. It allows better database availability and is much more scalable than a tight consistency model. SQL Server 6.0 replication is based on a loose consistency model.
SQL Server 6.0 replication has these fundamental characteristics:
See the topics that follow for more information about each of these features.
SQL Server 6.0 replication terminology is based on a publishing/subscribing metaphor:
Note that all articles within a publication are guaranteed to be initially synchronized as a single logical unit. This helps to maintain integrity relationships originating from the underlying tables.
Replicated data moves in only one direction ¾ from the publication server to the subscription servers. You will usually treat replicated data residing in destination tables on subscription servers as read-only. (Note that this means the data should be treated as read-only for the users of the subscription databases. Do not set the Read Only database option, or that subscription database will be unable to receive replicated data.)
This is not so limiting as it might as first sound, since each server can act as both subscriber and a publisher and secondary copies of data can be locally processed on the subscriber.
The log reader process, the synchronization process, the distribution database, and the distribution process are the main components of replication.
The log reader process moves transactions marked for replication from the publication server transaction log into the distribution database, where the transactions wait for distribution to subscription servers.
The synchronization process prepares initial synchronization files containing schema and data of published tables, stores the files in the SQL Server working directory on the distribution server, and records synchronization jobs in the distribution database. Synchronization affects new subscribers only.
The distribution database is a store-and-forward database that holds all transactions waiting to be distributed to subscription servers. The distribution database receives transactions sent to it from the publication server by the log reader process and holds them until the distribution process moves them to the subscription servers. The distribution database is used only by replication and does not contain any user tables.
The distribution process moves to subscription servers the transactions and initial synchronization jobs held in the distribution database tables. They are applied at the subscribers to the destination tables in the destination databases.
All three processes (log reader, synchronization, and distribution) exist on the server that performs distribution, are subsystems of SQL Executive, and are not started or directly administered by users.
Note
To best depict functionality, the illustration shows the publication and distribution servers as separate computers. However, any SQL Server 6.0 server can perform both roles. The publication and distribution servers are typically the same physical machine. However, when appropriate, two separate servers can perform those roles. For more information, see "Server Roles in Replication," later in this paper.
The following illustration provides a functional overview of the replication components.
SQL Server replication components are implemented by using a modular design. Because of this, if you are running high-activity production systems, you will be able to install components of replication on separate computers, balancing workload and helping to minimize SQL Server replication's impact on the production server's performance.
In a typical replication situation, the log reader process, the synchronization process, the distribution process, and the distribution database are installed on the publication server. However, these components can be installed on a separate server, which in some configurations can improve performance.
After servers have been configured for replication and the source and destination data tables have been synchronized, a replication process (the log reader) monitors the transaction log of each database set up for replication. When a transaction occurs on a published table, it is marked for replication. When the log reader finds transactions marked for replication, it applies them to the distribution database. The transactions are held in the distribution database until they can be distributed to the appropriate destination servers and applied to the destination databases.
Only committed transactions are sent to destination servers. Replicated changes to a table are guaranteed to be sent to the destination servers in the order in which they are committed. This ensures the subscribers receive transactions in the same order in which they were applied at the publisher. Because this is a log-based solution, maximum concurrent access to data is maintained. Replication does not exclude user access to destination tables during the associated inserts, deletes, and updates.
During normal operation, transactions marked for replication are preserved in a publication database's transaction log until they have been moved into the distribution database by the log reader. After this occurs, the transaction log of the publication database can be truncated using normal procedures. Records still waiting to be replicated are not truncated. (The transaction log on the publisher can be dumped without interfering with replication, since only transactions not marked for replication are purged.)
Servers can have three roles in SQL Server replication. All SQL Server 6.0 servers are capable of performing all of these roles.
In most cases, the first two roles are combined in one computer; the publication server also acts as the distribution server, as shown in this illustration:
Note that the publishing and subscribing roles are not exclusive: servers can simultaneously perform both. For example, suppose Server A publishes Publication 1, and Server B publishes Publication 2. In this case, Server A could act both as a publication server (of Publication 1) and a subscription server (to Publication 2).
As an option, the distribution server can be installed on a separate computer, as shown in the following illustration. This might be an appropriate configuration when high loads are present, such as when a busy online transaction processing (OLTP) server is configured as a publication server. Using a separate distribution server reduces local processing and disk usage on the publication server, although it somewhat increases overall network traffic.
Note that using a separate distribution server requires separate SQL Server installations (two licenses), one for the publication server and one for the distribution server.
SQL Server replication offers great flexibility in determining exactly what sets of replicated data each subscriber receives:
Before a new subscriber can receive replicated transactions from a publication, the publication and destination tables must contain the same schema and data. The process that accomplishes this is called initial synchronization.
Initial synchronization ensures that the table schema and the table data in the publication and destination databases are made identical. Replication ensures that updates are applied to a subscriber only after the subscriber is synchronized. Initial synchronization affects new subscribers only.
When a publication is first created a copy of the table schema is written to a file for transfer. If an index is requested, the index is created as part of this schema. When synchronization begins, a "snapshot" is taken of the table data of the published article, and that snapshot is also written to a file. If an index is requested, the index is created as part of the schema. The table schema is written to an .SCH file, and the table data is written to a .TMP file. These files are stored in the working directory of the distribution database (by default, \SQL60\REPLDATA). The .SCH and .TMP files are a synchronization set that represent a snapshot in time of that article. There is a synchronization set for each article within a publication.
After the synchronization set is created, subsequent inserts, updates, deletes, or modifications to the published data are captured but will be replicated to each subscriber only after its initial synchronization is complete. Thus, SQL Server ensures that updates are applied to a subscriber only after the subscriber has a current snapshot of the table schema and data.
When synchronization sets are distributed and applied to subscribers, only those subscribers waiting for initial synchronization are affected. Other subscribers to that publication or article-those that are already synchronized and have been receiving inserts, updates, deletes, or modifications to the published data-are unaffected.
Initial synchronization can be accomplished automatically or manually (as described in the topics that follow). Synchronization of all new subscribers can be scheduled to occur either frequently (every few minutes) or on a specified day at a specified time.
All components of a publication-all the articles-are synchronized simultaneously, preserving referential integrity between the underlying tables.
Automatic synchronization is accomplished by SQL Server. A snapshot is taken of the table schema and data of the published article, and that snapshot is written to files for transfer.
The synchronization process also creates a synchronization job and places it in the distribution database. When distributed, this job applies the files in the synchronization set to all subscription databases that are waiting for synchronization. The job to copy the table schema and data is transferred to the waiting subscribers as with any other replication job, via the distribution database. No operator intervention is required.
Automatic synchronization occurs on a scheduled basis. Since automatic synchronization of databases or even individual tables requires a fairly high amount of system overhead, a benefit of scheduling automatic synchronization for less frequent intervals is that it allows the synchronization snapshot to be scheduled for a period of low activity on the publication server.
When a scheduled initial synchronization time arrives, synchronization occurs only for those subscribers that have requested synchronization since the last sync event occurred (not for all subscribers to that publication). This minimizes the impact on the publication server.
Important
A scheduled synchronization is based on the date and time at the distribution server (not the date and time at the subscription servers).
Manual synchronization is carried out by the user. As with automatic synchronization, the publication server produces files containing a snapshot of the table schema and data from the published table, but with manual synchronization, it is applied to the subscriber by a user, from tape or other storage medium. After manual synchronization is accomplished, the user must inform SQL Server that the synchronization is complete.
The user can obtain the table schema script (an .SCH file) and the table data file (a .TMP file) for each synchronization job from the working directory of the distribution database (by default, \SQL60\REPLDATA).
Manual synchronization is particularly useful when the publication and subscription servers are connected by a slow, expensive, or low-quality network connection, and when a table being published is very large.
For example, if a publication server in Boston is connected over an expensive communications link to a subscription server in Stockholm, a manual synchronization could be accomplished by physically sending a tape containing the .SCH and .TMP file to Stockholm. The table schema script and the table data file could be manually applied to the database, and then SQL Server could be informed that the manual synchronization is complete. This avoids sending the files over the communications link.
Manual synchronization events can affect all the replicated data being sent to a subscriber's database. When a manual synchronization event is set up, a placeholder is put in the distribution database. All transactions in the distribution database continue to be sent to the destination database until that placeholder is encountered; at that point, distribution to that destination database stops, even for other publications and articles in that destination database that are not waiting for a manual synchronization. Replication to the entire database is paused until the manual synchronization is carried out and SQL Server is informed that the synchronization is complete.
As an option, when setting up a subscription, you can specify that SQL Server will not synchronize the published articles with the destination tables. SQL Server assumes that they are already synchronized, and inserts, updates, deletes, or modifications to the published data are replicated to each subscriber as soon as the subscription are established.
In this case, it is the responsibility of the user setting up replication to ensure that the table schema and data are identical for the published article and the destination table. The advantage of this option is that it allows changes to replicated data to be immediately distributed to subscribers, without incurring the system overhead associated with synchronization. It is intended for advanced users who will be implementing a custom replication solution.
When setting up a subscription, you can specify that SQL Server will synchronize the published articles with the destination tables, and that the synchronization will repeat at defined intervals. Inserts, updates, deletes, or modifications to the published data will not be provided to the subscribers. This is called a Scheduled Table Refresh. In effect, it is a repeating automatic synchronization, with replication of subsequent transactions turned off.
For example, a scheduled table refresh could be useful if you need to completely refresh the data on a particular subscriber once a day, once a week, or once a month.
For a subscription server to receive published data, it must subscribe to one or more articles or publications. This can be accomplished by performing either a push subscription or a pull subscription. The type of subscription is determined by the administrative focus, that is, on whether you are administering the publication server or the subscription server.
A push subscription is carried out when administrative focus is set on the publication server. As part of the process of creating or managing a publication, subscriptions are created by "pushing" out a publication or an article to one or more subscription servers.
One advantage of using push subscriptions is that they simplify and centralize subscription administration. The act of publishing is combined with the act of subscribing, and one person can perform both in the same administrative session. The need to separately administer each subscriber is eliminated. Another advantage is that for each publication, many subscribers can be set up at once.
A pull subscription is carried out when administrative focus is set on the subscription server. A subscription is created by "pulling" in a publication or an article from a publication server.
One advantage of using pull subscriptions is that they provide a degree of replication autonomy for a subscription server. The SA or DBO of the subscription server can decide which publications will be received. The subscriber avoids receiving unwanted data from a publication server. Another advantage is that for each subscription server, subscriptions from many publication servers can be set up during one administrative session.
With pull subscriptions, the act of publishing is separate from the act of subscribing, and the user administering the subscription server need not be the same person who administers the publication server.
SQL Enterprise Manager allows SQL Server administrators and database owners to manage SQL Server via a powerful yet easy-to-use interface. SQL Server replication particularly benefits from SQL Enterprise Manager. From a single server or workstation that has the SQL Server 6.0 utilities installed, you can use SQL Enterprise Manager to reach across your enterprise and set up a complete replication environment spanning as many servers as necessary. Replication can be completely set up and managed by using SQL Enterprise Manager.
SQL Server replication expands the security available from Windows NT and SQL Server 6.0 by limiting which users can set up and administer replication and which subscription servers can subscribe to (or even see) certain publications.
Replication permits SAs, database owners (DBOs), and others (public) to perform these replication tasks:
Replication task SA DBO Public Install a distribution X database Configure a publication X server View publication servers X X X Manage publications X X* View publications X X X Manage subscriptions X X* View subscription servers X X X Configure a database for X publishing
* Must be set up by the SA.
On a publication-by-publication basis, you can control the access that subscription servers have to a publication by marking the publication as either unrestricted or restricted.
A publication marked as unrestricted is visible to and can be subscribed to by any subscription server known to the publication server.
A publication marked as restricted is visible to only those subscription servers authorized for access. Servers not authorized for access cannot subscribe to the publication; they cannot even see it. As a result, users setting up subscriptions at servers not authorized for access will not even know of a restricted publication. At those servers, it will not appear in any list.
SQL Executive has a scheduling engine that controls scheduled replication tasks and is used to implement replicated data transfer. This scheduling engine has three subsystems: the log reader process, the distribution process, and the synchronization process. Together they provide the functionality that, administered through SQL Enterprise Manager, allows you to set the frequency of each replication task. For example, you could set up replication so that the publisher's log is continuously read, transactions are distributed to subscribers every ten minutes, and initial synchronization events occur every night at midnight. For more information on these processes, see "Replication Components," earlier in this paper.
SQL Executive maintains a task list, a task queue, and a task history that can be useful for troubleshooting replication. These can be viewed and managed by using SQL Enterprise Manager.
Events in the task history can also be written to the Windows NT application log-if the task is set to use Windows NT logging-and can be viewed by using Event Viewer. For information on using Event Viewer, see your documentation for Windows NT.
SQL Executive also has an alerts engine that provides an easy way to set alerts on replication events. When the event occurs, SQL Executive responds automatically, either by executing a task that you have defined or by sending an e-mail and/or a pager message to an operator you have specified.
A distribution server connects to all subscription servers as an Open Database Connectivity (ODBC) client. Replication requires that the ODBC 32-bit driver be installed on all distribution servers. The SQL Server 6.0 setup program automatically installs the necessary driver on Windows NT-based computers. You do not need to preconfigure ODBC Data Sources for SQL Server 6.0 subscription servers, because the distribution process will simply use the subscriber's network name to establish the connection.
By default, regardless of the security mode the servers are set for, a distribution server connects to a subscription server using a trusted connection. To support this connection, the SQL Client Configuration Utility on a distribution server (either a combined publisher/distributor or a remote distributor) must be set to use Named Pipes or Multi-Protocol as the default network.
Following are scenarios depicting a few of the many possible replication configurations. These are provided to help orient you to the capabilities of SQL Server 6.0 replication. You are not limited to these configurations-many others are possible.
The basic replication scenario is a central publisher replicating data to any number of subscribers. The publication server is the primary owner of the replicated data, and the subscription server will usually treat this as read-only data. (Note that this means the data should be treated as read-only for the users of the subscription databases. Do not set the Read Only database option, or that subscription database will be unable to receive replicated data.) In this scenario, the publication server also acts as the distribution server.
This scenario might be used, for example, to distribute master data, lists, or reports from a central server to any number of subscription servers.
This scenario is similar to the central publisher scenario, except that separate computers perform the publication and distribution tasks. This is useful when the publication server-for example, a heavily used online transaction processing (OLTP) server-should be freed from the distribution role because of performance and storage space considerations. The publication server must be connected to the distribution server by a reliable, high-speed communications link.
This scenario uses two servers to publish the same data. The publication server sends data to a subscription server, which then republishes the data to any number of subscribers. This is useful when a publication server must send data to subscribers over a slow or expensive communications link. If there are a number of subscribers on the far side of that link, using a publishing subscriber shifts the bulk of the distribution load to that side of the link.
Note that in this illustration, both the publication server and the publishing subscriber are acting as their own local distribution servers. If each was set up to use a remote distribution server, each distribution server would need to be on the same side of the slow or expensive communications link as its publication server. Publication servers must be connected to remote distribution servers by reliable, high-speed communications links.
In this scenario, a number of publication servers replicate information into a common destination table. The destination table is horizontally partitioned and contains a location-specific column as part of the primary key. Each publication server replicates rows containing location-specific data.
This replication configuration might be useful, for example, for rolling up inventory data from a number of servers at local warehouses into a central subscriber at corporate headquarters. It could also be used to roll up information from autonomous business divisions within a company, or to consolidate order processing from dispersed locations.
This scenario shows a single table that is maintained on three servers. The table is horizontally partitioned, and each server is the publisher of the data in particular rows and the subscriber to data in the remaining rows. Each server controls its own data and has a view of the other data. Stored procedures can be used to allow updates to locally owned data only.
This replication configuration might be useful, for example, for maintaining common information at regionally dispersed centers, such as warehouses or divisional offices. It could also support regional order processing.
In this example, data is downloaded from a legacy database on a mainframe computer into a SQL Server 6.0 database on a server and is replicated to any number of subscription servers. This might be used, for example, in a large retail environment where sales and inventory information is entered at point-of-sale terminals and maintained on the mainframe but data is analyzed and management reports are created on the server and distributed to regional offices using SQL Server replication.
Here are answers to some frequently asked questions about replication.
Only SQL Server 6.0 servers can participate in replication. SQL Server 6.0 servers can publish, distribute, and subscribe to replicated data. However, replication is designed to support-in the future-other types of ODBC-enabled subscribers.
Not replicated are system tables and changes to the schema of a published table.
When the identity property has been applied to a column, data from that column can be replicated, but the identity property cannot. The identity property will not be applied to that column on subscription servers. For information about the identity property, see the Microsoft SQL Server TransactSQL Reference.
All datatypes are replicated, with these exceptions:
Note Text and image columns can be replicated via the table refresh mechanism. See "How are text and image columns handled?"
Also, when setting up a publication, you can choose to pass user-defined datatypes or convert them to their base datatypes.
Transaction-based replication of text and image columns is not supported. However, scheduled table refresh of text and image columns is supported.
For example, you could publish an article that contains text and image columns and do a table refresh of the subscribers at a defined interval (for example, every hour). You could then join the text and image destination table with a transaction log-based destination table. To ensure proper consistency, you would probably need to publish a timestamp column.
SQL Server replication permits each subscription server to subscribe only once to a particular article. Note that if a subscriber subscribes at the publication level, it is automatically subscribed to each article in that publication.
However, it is possible for a subscription server to use multiple copies of replicated data, since secondary copies of data can be locally processed on the subscription server.
For example, if database_1 subscribes to table_a, then database_2 on the same server cannot subscribe to the same article. However, you could, for example, create a trigger on the destination table_a in database_1 that does an insert, update, or delete into a table in database_2 every time destination table_a is updated. Or you could create a cross-database view using the replicated data.
In most cases, data will be modified only on the publication server. It is recommended that you maintain all replicated data residing in destination tables on subscription servers as read-only. (This means the data should be treated as read-only for the users of the subscription databases. Do not set the Read Only database option, or that subscription database will be unable to receive replicated data.)
This is not as limiting as it might at first sound, since each server can act as both subscriber and publisher and since secondary copies of data can be locally processed on the subscriber.
Yes. It possible to have one server distributing from a number of publication servers to a number of subscription servers. However, this increases the hardware requirements for the distribution server. In such a configuration, the distribution server will require additional memory and available disk space. A multiprocessor machine would be beneficial in this environment because it would take full advantage of the multithreaded architecture of the replication processes.
The replication capability of SQL Server 6.0 is not specifically designed to accomplish hot backups, and it does not allow the subscriber to be automatically updated on changes that affect system tables (such as schema changes or permission changes).
To help you understand the information presented in this paper, here are some replication-related definitions. This is a brief list of definitions and is not intended to serve as a comprehensive SQL Server glossary. It is provided as a quick reference, to help you understand some of the replication elements that are discussed throughout this paper. You may find it useful to refer to this list of replication definitions as you read through this paper.
article
The basic unit of replication. An article contains data originating from a table that has been marked for replication. One or more articles are grouped within a publication.
automatic synchronization
Synchronization that is accomplished automatically by SQL Server. A snapshot is taken of the table data, and along with the table schemas that snapshot is written to files for transfer. The job to copy the table schema and data is transferred, as is any other replication job, via the distribution database. No operator intervention is required.
destination database
The subscribing database. The database that receives tables and data replicated from a publication database.
destination server
See subscription server.
destination table
The subscribing table, created as a replicated image of a published table. A destination table in a destination database is synchronized with and contains data derived from the published table in a publication database.
distribute
To move transactions from the distribution database tables to subscription servers, where they are applied to the destination tables in the destination databases.
distribution database
A store-and-forward database that holds all transactions that are waiting to be distributed to subscription servers. The distribution database receives transactions sent to it from the publication server by the log reader process and holds them until the distribution process moves them to the subscription servers.
distribution process
Moves transactions from the distribution database tables to subscription servers, where they are applied to the destination tables in the destination databases. The distribution process is a subsystem of the scheduling engine in SQL Executive.
distribution server
The server containing the distribution database. The distribution server receives all changes to published data, stores the changes in its distribution database, and, when appropriate (depending on scheduling and other variables), transmits them to subscription servers. The distribution server can be the same computer that is acting as the publication server, or a different computer. Also referred to as a distributor. See also local distribution server, remote distribution server.
distributor
See distribution server.
filtering
The method by which only selected rows or only selected columns of a table are designated for replication; the method by which partitioning is accomplished. See also partitioning.
horizontal filtering
See horizontal partitioning.
horizontal partitioning
Creating an article that replicates only selected rows from the base table. Subscription servers receive only that horizontally partitioned subset of data.
initial synchronization
See synchronization.
latency
The amount of time that elapses between a transaction being logged on the publication server and being successfully delivered to the destination database on the subscription server.
Latency consists of two components: duration in the transaction log, and duration in the distribution database.
local distribution server
When a publication server also acts as its own distribution server, it is sometimes called a local distribution server. In this case, the publication database and the distribution database reside on the same computer. Compare with remote distribution server.
log reader process
Moves transactions from the publication server transaction log into the distribution database. The log reader process is a subsystem of the scheduling engine in SQL Executive.
loose consistency
A replication model that allows a time lag between the moment original data is altered and the replicated copies of that data are updated-it does not guarantee that all copies will be constantly identical to the original. An advantage of loose consistency is that it supports LANs, WANs, fast and slow communication links, and intermittently connected databases. It also allows better database availability and scales much better in its implementation as compared to tight consistency. SQL Server 6.0 replication is based on a loose consistency model.
manual synchronization
Synchronization that is accomplished by a user. As with automatic synchronization, the publication server produces files containing the schema and a snapshot of the data from the published table, but with manual synchronization, it is applied to the subscriber manually, using tape or an other medium. After a manual synchronization is accomplished, the user must inform SQL Server that the synchronization is complete. The user can obtain the table schema script (an .SCH file) and the table data file (a .TMP file) for each synchronization job from the working directory of the distribution database, which is set by default to \SQL60\REPLDATA.
no synchronization
A replication option sometimes used when a destination database subscribes to a publication. Synchronization is not accomplished by SQL Server. It is the responsibility of the user setting up replication to ensure that the table schema and data are identical for the published article and the destination table. This option allows changes to replicated data to be immediately distributed to subscribers, without delay for synchronization. See also automatic synchronization, manual synchronization.
partitioning
Creating an article that replicates only selected information from the base table. Subscription servers receive only that subset of data from the source table. Note that the replicated columns must include the primary key column(s). Sometimes referred to as filtering. See also horizontal partitioning, vertical partitioning.
publication
The term for a group of tables that have been made available for replication as a unit. A publication can contain one or more published tables-articles-from one user database. Each user database can have one or more publications.
publication database
A database that is the source of replicated data. A database containing tables that have been made available for replication.
publication server
A server that has made data available for replication. A publication server maintains publication databases, makes published data from those databases available for replication, and sends copies of all changes to the published data to the distribution server. Also referred to as a publisher.
publish
Make data available for replication.
publisher
See publication server.
pull subscription
A subscription performed while administrative focus is set on the subscription server. A subscription is created by "pulling" in a publication or an article from a publication server.
One advantage of a pull subscription is that it provides a degree of replication autonomy for a subscription server. The SA or DBO of the subscription server decides which publications will be received. In this way, the subscriber avoids receiving unwanted data from a publication server. Another advantage is that for each subscription server, subscriptions from many publication servers can be set up during one administrative session.
With a pull subscription, the act of publishing is separate from the act of subscribing, and the user administering the subscription server need not be the same person who administers the publication server. See also push subscription.
push subscription
A subscription performed while administrative focus is set on the publication server. As part of the process of creating or managing a publication, subscriptions are created by "pushing" out an article to one or more subscription servers.
One advantage of a push subscription is that it simplifies and centralizes subscription administration. The act of publishing is combined with the act of subscribing, and one person can perform both in the same administrative session. The need to separately administer each subscriber is eliminated. Another advantage is that for each article, many subscribers can be set up at once.
remote distribution server
When a publication server does not act as its own distribution server but instead is configured to send transactions that are marked for replication to a distribution database on another computer, then that other computer is called a remote distribution server. In this case, the publication database and the distribution database reside on separate computers. Compare with local distribution server.
replication
Duplication of table schema and data from a source database to a destination database, usually (but not necessarily) on separate servers.
restricted publication
A security status. A publication marked restricted is displayed to and can be subscribed to only those servers that have been granted access. See also unrestricted publication.
retention
The period of time that a transaction is maintained in the distribution database after it has been successfully delivered to the destination database on the subscription server.
schema script
See table schema script.
source database
See publication database.
subscribe
Agreeing to receive a publication or an article. A destination database on a subscription server subscribes to replicated data from a publication database on a publication server.
subscriber
See subscription server.
subscription database
See destination database.
subscription server
A subscription server maintains destination databases, which receive and maintain copies of published data. Also referred to as a subscriber.
synchronization
Before a subscription server can receive replicated transactions from an article or a publication, the publication and destination tables must contain the same schema and data. The process that accomplishes this normally occurs once and is called synchronization. Synchronization ensures that the table schema and the table data in the publication and destination databases are made identical.
SQL Server 6.0 replication ensures that updates are applied to a subscriber only after the subscriber is synchronized (has a current snapshot of the table schema and data). Synchronization affects new subscribers only.
synchronization process
Creates synchronization files containing data from published tables and applies these files, along with table schema files, to destination database tables. The synchronization process is a subsystem of the scheduling engine in SQL Executive.
synchronize
See synchronization.
table creation script
See table schema script.
table data file
A file containing a snapshot of the data of a published table, and used during synchronization as the source of data inserted into the destination table. The data snapshot is written to a file ending in the .TMP filename extension. The file is stored in the working directory of the distribution database, which is set by default to \SQL60\REPLDATA. See also table schema script.
table schema script
A script containing the schema of a published table, and used during synchronization to create the destination table. The schema script is written to a file ending in the .SCH filename extension. The file is stored in the working directory of the distribution database, which is set by default to \SQL60\REPLDATA. See also table data file.
tight consistency
A replication model that guarantees that all copies will be constantly identical to the original. It is usually implemented using two-phase commit, and it requires a high-speed LAN. It also reduces database availability and is less scalable in its implementation as compared to loose consistency.
unrestricted publication
A security status. A publication marked unrestricted (the default) is displayed to and can be subscribed to by any registered subscription server. See also restricted publication.
vertical filtering
See vertical partitioning.
vertical partitioning
Creating an article that replicates only selected columns from the base table. Subscription servers receive only that vertically partitioned subset of data. Note that the replicated columns must include the primary key column(s).
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |