I am trying to use a remote distributor and I think my settings are wrong
for RPC and mapping. How should these be mapped so that the publisher can
see the SQL Server Agent on the distributor?
--Kristy
Whats the error message?
"Kristy" <pleasepostreply@.here.com> wrote in message
news:OCz1FewMFHA.2736@.TK2MSFTNGP09.phx.gbl...
>I am trying to use a remote distributor and I think my settings are wrong
> for RPC and mapping. How should these be mapped so that the publisher can
> see the SQL Server Agent on the distributor?
> --Kristy
>
|||Publisher can not connect to ditributor because it is not configured for
remote access. I looked in the sysservers table and it is configured for rpc
and data access on both machines.
--Kristy
"ChrisR" <noemail@.bla.com> wrote in message
news:%23GX4QgHNFHA.1308@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Whats the error message?
> "Kristy" <pleasepostreply@.here.com> wrote in message
> news:OCz1FewMFHA.2736@.TK2MSFTNGP09.phx.gbl...
can
>
Showing posts with label distributor. Show all posts
Showing posts with label distributor. Show all posts
Tuesday, March 20, 2012
Monday, March 12, 2012
Remote Replication
Hi,
Now, I try doing remote replication between 2 pc(eg.pc A and B). Pc A as a server for publisher and distributor, and PC B is a normal pc to store data. I want replicate data from PC B to PC A. I used merge replication for this replication. I don't understanding something like:
1. is I need 2 servers for this replication? One server for publisher and distributor and others one server for subscriber?
2. What should I do if one server also can doing replication? What the step?
karencylIntroducing Replication Options
Options available with the types of replication allow you more replication solutions and greater flexibility and control in your applications. Replication options are:
Filtering published data
Publishing database objects
Publishing schema objects
Updatable subscriptions
Transforming published data
Alternate synchronization partners
Filtering Published Data
Filtering data during replication allows you to publish only the data or partitions of data that are needed at the Subscriber. You can filter data to create partitions that include only the columns and/or only the rows that you specify for replication.
With all types of replication, you can choose to copy and distribute complete tables, or data filtered horizontally or vertically with static filters. Merge replication is especially strong in filtering options, and you can use dynamic filters to customize the filter based on a property of the Subscriber receiving the data.
Filtering data horizontally allows you to publish only the data that is needed, partition data to different sites, avoid conflicts (because Subscribers will be viewing and updating different subsets of data), and manage publications based on user needs or applications.
Additionally, you have the option of employing user-defined functions in your static and dynamic filters and leveraging the power of customized functions.
Merge replication provides the added functionality of join filters and dynamic filters. Join filters enable you to extend filters created on one table to another. For example, if you are publishing customer data based on the state where the customer resides, you may want to extend that filter to the related orders and order details of the customers in a particular state. Dynamic filters allow you to create a merge publication and then filter data from the publishing table.. The filter value can be the user ID or login retrieved based on a Transact-SQL function, such as SUSER_SNAME() or HOSTNAME().
Publishing Database Objects
You can publish database objects including views, indexed views, user-defined functions, stored procedure definitions, and the execution of stored procedures. You can include data and database objects in the same publication or in different publications. Publishing database objects is available with all types of replication (snapshot replication, transactional replication, and merge replication).
Publishing Schema Objects
In addition to database objects, you can also specify if you want schema objects to be published such as declared referential integrity (primary key constraints, reference constraints, unique constraints), clustered indexes, nonclustered indexes, user triggers, extended properties, and collation. You can also change destination table owner names and data formats to optimize for SQL Server 2000 or heterogeneous Subscribers.
Updatable Subscriptions
Data at the Subscriber can be modified if you use merge replication or if you use snapshot replication or transactional replication with an updatable subscription option.
Updatable subscription options available with snapshot replication and transactional replication allow you to make changes to replicated data at the Subscriber and propagate those changes to the Publisher and to other Subscribers. Updatable subscription options include immediate updating, queued updating, and immediate updating with queued updating as a failover.
Immediate updating allows Subscribers to update data only if the Publisher will accept them immediately. If the changes are accepted at the Publisher, they are propagated to other Subscribers. The Subscriber must be continuously and reliably connected to the Publisher to make changes at the Subscriber.
Queued updating allows Subscribers to modify data and store those data modifications in a queue while disconnected from the Publisher for a period of time. When the Subscriber reconnects to the Publisher, the changes are propagated to the Publisher. If the Publisher accepts the changes, normal replication processes occur and the changes are propagated to other Subscribers from the Publisher. You can store data modifications in a SQL Server 2000 queue or use Microsoft Message Queuing.
Immediate updating with the queued updating option allows you to use immediate updating and switch to queued updating if a connection cannot be maintained between the Publisher and Subscribers. After switching to queued updating, reconnecting to the Publisher, and emptying the queue, you can switch back to immediate updating mode.
When using merge replication, data at the Subscriber is automatically updatable.
Transforming Published Data
With snapshot replication or transactional replication, you can leverage the transformation mapping and scripting capabilities of Data Transformation Services (DTS) when building a replication topology. Replication integrated with DTS allows you to customize and distribute data based on the requirements of individual Subscribers. For example, a Subscriber might need to have different table names, column names, or compatible data types.
By transforming published data, you can filter data and simulate dynamic partitions of data so that data from one snapshot or transactional publication can be distributed to Subscribers that require different partitions of data. With static partitions, you need to create and filter separate publications for each Subscriber based on the needs of the Subscriber.
Alternate Synchronization Partners
Subscribers to merge publications can synchronize with servers other than the Publisher at which the subscription originated. Synchronizing with alternate partners allows Subscribers to synchronize data even if the primary Publisher is unavailable. This feature is also useful when mobile Subscribers have access to a faster or more reliable network connection with an alternate Publisher.
See Also
Alternate Synchronization Partners
Filtering Published Data
Merge Replication or Updatable Subscriptions
Publishing Data and Database Objects
1988-2000 Microsoft Corporation. All Rights Reserved.
Now, I try doing remote replication between 2 pc(eg.pc A and B). Pc A as a server for publisher and distributor, and PC B is a normal pc to store data. I want replicate data from PC B to PC A. I used merge replication for this replication. I don't understanding something like:
1. is I need 2 servers for this replication? One server for publisher and distributor and others one server for subscriber?
2. What should I do if one server also can doing replication? What the step?
karencylIntroducing Replication Options
Options available with the types of replication allow you more replication solutions and greater flexibility and control in your applications. Replication options are:
Filtering published data
Publishing database objects
Publishing schema objects
Updatable subscriptions
Transforming published data
Alternate synchronization partners
Filtering Published Data
Filtering data during replication allows you to publish only the data or partitions of data that are needed at the Subscriber. You can filter data to create partitions that include only the columns and/or only the rows that you specify for replication.
With all types of replication, you can choose to copy and distribute complete tables, or data filtered horizontally or vertically with static filters. Merge replication is especially strong in filtering options, and you can use dynamic filters to customize the filter based on a property of the Subscriber receiving the data.
Filtering data horizontally allows you to publish only the data that is needed, partition data to different sites, avoid conflicts (because Subscribers will be viewing and updating different subsets of data), and manage publications based on user needs or applications.
Additionally, you have the option of employing user-defined functions in your static and dynamic filters and leveraging the power of customized functions.
Merge replication provides the added functionality of join filters and dynamic filters. Join filters enable you to extend filters created on one table to another. For example, if you are publishing customer data based on the state where the customer resides, you may want to extend that filter to the related orders and order details of the customers in a particular state. Dynamic filters allow you to create a merge publication and then filter data from the publishing table.. The filter value can be the user ID or login retrieved based on a Transact-SQL function, such as SUSER_SNAME() or HOSTNAME().
Publishing Database Objects
You can publish database objects including views, indexed views, user-defined functions, stored procedure definitions, and the execution of stored procedures. You can include data and database objects in the same publication or in different publications. Publishing database objects is available with all types of replication (snapshot replication, transactional replication, and merge replication).
Publishing Schema Objects
In addition to database objects, you can also specify if you want schema objects to be published such as declared referential integrity (primary key constraints, reference constraints, unique constraints), clustered indexes, nonclustered indexes, user triggers, extended properties, and collation. You can also change destination table owner names and data formats to optimize for SQL Server 2000 or heterogeneous Subscribers.
Updatable Subscriptions
Data at the Subscriber can be modified if you use merge replication or if you use snapshot replication or transactional replication with an updatable subscription option.
Updatable subscription options available with snapshot replication and transactional replication allow you to make changes to replicated data at the Subscriber and propagate those changes to the Publisher and to other Subscribers. Updatable subscription options include immediate updating, queued updating, and immediate updating with queued updating as a failover.
Immediate updating allows Subscribers to update data only if the Publisher will accept them immediately. If the changes are accepted at the Publisher, they are propagated to other Subscribers. The Subscriber must be continuously and reliably connected to the Publisher to make changes at the Subscriber.
Queued updating allows Subscribers to modify data and store those data modifications in a queue while disconnected from the Publisher for a period of time. When the Subscriber reconnects to the Publisher, the changes are propagated to the Publisher. If the Publisher accepts the changes, normal replication processes occur and the changes are propagated to other Subscribers from the Publisher. You can store data modifications in a SQL Server 2000 queue or use Microsoft Message Queuing.
Immediate updating with the queued updating option allows you to use immediate updating and switch to queued updating if a connection cannot be maintained between the Publisher and Subscribers. After switching to queued updating, reconnecting to the Publisher, and emptying the queue, you can switch back to immediate updating mode.
When using merge replication, data at the Subscriber is automatically updatable.
Transforming Published Data
With snapshot replication or transactional replication, you can leverage the transformation mapping and scripting capabilities of Data Transformation Services (DTS) when building a replication topology. Replication integrated with DTS allows you to customize and distribute data based on the requirements of individual Subscribers. For example, a Subscriber might need to have different table names, column names, or compatible data types.
By transforming published data, you can filter data and simulate dynamic partitions of data so that data from one snapshot or transactional publication can be distributed to Subscribers that require different partitions of data. With static partitions, you need to create and filter separate publications for each Subscriber based on the needs of the Subscriber.
Alternate Synchronization Partners
Subscribers to merge publications can synchronize with servers other than the Publisher at which the subscription originated. Synchronizing with alternate partners allows Subscribers to synchronize data even if the primary Publisher is unavailable. This feature is also useful when mobile Subscribers have access to a faster or more reliable network connection with an alternate Publisher.
See Also
Alternate Synchronization Partners
Filtering Published Data
Merge Replication or Updatable Subscriptions
Publishing Data and Database Objects
1988-2000 Microsoft Corporation. All Rights Reserved.
Wednesday, March 7, 2012
Remote Distributor question
sql2k sp3
BoxA Publisher.
BoxB Subscriber. To be used for reporting.
I want the processing drain of Replication to be done on
BoxB. So I was thinking of putting the Distributor on BoxB
and using a Push Subscription.
Do any of you gurus see any problems with my idea?
TIA, Chris?
Reporting services chews up a lot of cycles. You might find it better to
keep the distributor on the publisher.
The point you start to move the distributor off the publisher is when you
start to get significant locking on your distribution database.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:0a4701c46e74$e3ab90f0$a601280a@.phx.gbl...
> sql2k sp3
> BoxA Publisher.
> BoxB Subscriber. To be used for reporting.
> I want the processing drain of Replication to be done on
> BoxB. So I was thinking of putting the Distributor on BoxB
> and using a Push Subscription.
> Do any of you gurus see any problems with my idea?
> TIA, Chris?
|||>Reporting services chews up a lot of cycles.
My bad. I wont be using actual Reporting Services.
You might find it better to
>keep the distributor on the publisher.
>The point you start to move the distributor off the
publisher is when you
>start to get significant locking on your distribution
database.
>
Why is this? Why do people do it then?
>--Original Message--
>Reporting services chews up a lot of cycles. You might
find it better to
>keep the distributor on the publisher.
>The point you start to move the distributor off the
publisher is when you
>start to get significant locking on your distribution
database.
>--
>Hilary Cotter
>Looking for a book on SQL Server replication?
>http://www.nwsu.com/0974973602.html
>
>"ChrisR" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a4701c46e74$e3ab90f0$a601280a@.phx.gbl...
BoxB
>
>.
>
|||Well, most people do it to reduce the load on the Publisher. The question is
when should you do it, and there is no real rule of thumb, at least as far
as I am aware.
The deciding factor for me is when you experience locking in your
distribution database.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:0c4201c46e8a$e7dd03a0$a601280a@.phx.gbl...[vbcol=seagreen]
> My bad. I wont be using actual Reporting Services.
> You might find it better to
> publisher is when you
> database.
> Why is this? Why do people do it then?
> find it better to
> publisher is when you
> database.
> message
> BoxB
BoxA Publisher.
BoxB Subscriber. To be used for reporting.
I want the processing drain of Replication to be done on
BoxB. So I was thinking of putting the Distributor on BoxB
and using a Push Subscription.
Do any of you gurus see any problems with my idea?
TIA, Chris?
Reporting services chews up a lot of cycles. You might find it better to
keep the distributor on the publisher.
The point you start to move the distributor off the publisher is when you
start to get significant locking on your distribution database.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:0a4701c46e74$e3ab90f0$a601280a@.phx.gbl...
> sql2k sp3
> BoxA Publisher.
> BoxB Subscriber. To be used for reporting.
> I want the processing drain of Replication to be done on
> BoxB. So I was thinking of putting the Distributor on BoxB
> and using a Push Subscription.
> Do any of you gurus see any problems with my idea?
> TIA, Chris?
|||>Reporting services chews up a lot of cycles.
My bad. I wont be using actual Reporting Services.
You might find it better to
>keep the distributor on the publisher.
>The point you start to move the distributor off the
publisher is when you
>start to get significant locking on your distribution
database.
>
Why is this? Why do people do it then?
>--Original Message--
>Reporting services chews up a lot of cycles. You might
find it better to
>keep the distributor on the publisher.
>The point you start to move the distributor off the
publisher is when you
>start to get significant locking on your distribution
database.
>--
>Hilary Cotter
>Looking for a book on SQL Server replication?
>http://www.nwsu.com/0974973602.html
>
>"ChrisR" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:0a4701c46e74$e3ab90f0$a601280a@.phx.gbl...
BoxB
>
>.
>
|||Well, most people do it to reduce the load on the Publisher. The question is
when should you do it, and there is no real rule of thumb, at least as far
as I am aware.
The deciding factor for me is when you experience locking in your
distribution database.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:0c4201c46e8a$e7dd03a0$a601280a@.phx.gbl...[vbcol=seagreen]
> My bad. I wont be using actual Reporting Services.
> You might find it better to
> publisher is when you
> database.
> Why is this? Why do people do it then?
> find it better to
> publisher is when you
> database.
> message
> BoxB
Remote Distributor and Subscriber on same machine - is that OK?
Hi,
Server A houses the Production DB which services an OLTP system. Transactional replication is configured on this server which has two subscribers - on two separate servers (servers B and C). The Distribution database currently resides on Server A (which is also the Publisher).
Server B is on the same LAN as Server A (on the same rack). I'm considering moving the Distribution database from Server A to Server B to offload some of the processing overhead from Server A.
Are there any gotchas/performance problems associated with having the Distribution database (remote distributor) and the Subscriber on the same server (server B) in a transaction replication topology?
Please advise or point me to the appropriate documentation - I haven't found anything that addresses this specific question...thanks in advance,
Smitha
This is actually a rather popular configuration (at least the ones that I have seen) inside Microsoft as this allows you to upgrade the Distributor and Subscriber to a new release together and then use the Subscriber as a test bed for the new release while receiving continuous updates from the production system. You do need good network connectivity between the publisher and the distributor\subscriber as pulling snapshot data (or backup\restore for that matter) can easily saturate a 100Mbit Ethernet connection. So to minimize impact on the production system, you may want to get a dedicated connection between the two.
-Raymond
|||Thanks Raymond. I shouldn't have to worry about the snapshot/backup+restore because I've used this second server as the backup files' location in the past (and still perform copy-only FULL production DB backups to this server). The restore takes a while since it reads from and writes to the same drive but this is OK for an operation that may happen 2-3 times a year.
Thanks again,
Smitha
REMOTE DISTRIBUTOR / FTP SETTINGS
Hello.
I have this problem.
I have 2 servers X and Y.
X is only Publisher
Y is Publisher and Distributor for X and Y.
My question. When i make a publication in X, do i have to set the ftp server
parameter for the snapshot in X or Y.
I'm having errors on Connections.
Thanks in Advance
The ftp server can be anywhere, publisher, subscriber, distributor or
another server altogether. What you need to be able to do make sure the ftp
server has the snapshot files and the subscriber can resolve the ftp
servername. This is normally done by creating a snapshot share on the
distributor.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Jose Fernandez" <ppcuban@.hotmail.com> wrote in message
news:OJdjyFqLGHA.1180@.TK2MSFTNGP09.phx.gbl...
> Hello.
> I have this problem.
> I have 2 servers X and Y.
> X is only Publisher
> Y is Publisher and Distributor for X and Y.
> My question. When i make a publication in X, do i have to set the ftp
> server parameter for the snapshot in X or Y.
> I'm having errors on Connections.
> Thanks in Advance
>
|||Jose,
I'm not too sure I follow. The FTP settings are on a publication basis is
SQL 2000/2005. In SQL 7.0 they were done on a subscription basis.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
I have this problem.
I have 2 servers X and Y.
X is only Publisher
Y is Publisher and Distributor for X and Y.
My question. When i make a publication in X, do i have to set the ftp server
parameter for the snapshot in X or Y.
I'm having errors on Connections.
Thanks in Advance
The ftp server can be anywhere, publisher, subscriber, distributor or
another server altogether. What you need to be able to do make sure the ftp
server has the snapshot files and the subscriber can resolve the ftp
servername. This is normally done by creating a snapshot share on the
distributor.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Jose Fernandez" <ppcuban@.hotmail.com> wrote in message
news:OJdjyFqLGHA.1180@.TK2MSFTNGP09.phx.gbl...
> Hello.
> I have this problem.
> I have 2 servers X and Y.
> X is only Publisher
> Y is Publisher and Distributor for X and Y.
> My question. When i make a publication in X, do i have to set the ftp
> server parameter for the snapshot in X or Y.
> I'm having errors on Connections.
> Thanks in Advance
>
|||Jose,
I'm not too sure I follow. The FTP settings are on a publication basis is
SQL 2000/2005. In SQL 7.0 they were done on a subscription basis.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Subscribe to:
Posts (Atom)