Showing posts with label topology. Show all posts
Showing posts with label topology. Show all posts

Friday, March 30, 2012

Merge republish Schema changes

Hello,

I'm working on a replication topology that is completely merge. We have a single consolidated instance (SQL 2005 SP1 Standard) that holds all data and is a continuous push merge publication filtered by region to regional instances (SQL 2005 SP1 Standard). Then we have individual user instances (SQL Express SP1) that pulls from the republished regional instances which is filtered by user. Both publications have Replicate Schema Changes set to true.

I'm testing out changes to tables and sps on a test system I've been using this process:

1-Run Snapshot on the Consolidated instance

2-Verify all published articles have a status of 2 in sysmergearticles

3-Run Regional Snapshot

4-Verify all published articles have a status of 2 in sysmergearticles

5-Run alter table scripts

6-Once all three levels have the table changes, run the alter sp scripts

I've gotten to step 5 and and the changes get replicated to the regional instance just fine however only the existing column changes get replicated to the SQLExpress instance, not the new columns. Looking at the articles in the regional publication it shows the new columns, but they are not selected. I know I can manually select them (or probably write a script that adds them to the publication although sp_repladdcolumn has been depreciated), but isn't there a way to make this a completely automated process since it's just a republished database? Also is the process I'm using the correct one?

Thank you,

Aaron Lowe

Is your publication property replication_ddl set to true?|||I apologize for not being clearer in my original post. I had said that replicate schema changes was set to true, this is the replication_ddl property that I was referring to. Thanks, Aaron|||when you add a new column, the column should get replicated to all nodes in your topology. Is the new column not getting replicated at all? Where in your topology are you adding the new columns - publisher, republisher or subscriber?|||I'm adding the columns at my original publisher (the consolidated one). As I said it is pushed down to my subscribers that republish the data (the regional ones that are pushed from the consolidated one), it just doesn't get all the way down to my final subscribers (the individual sqlexpress ones that pull the data). Looking at the properties of the publication on the republisher it shows the columns in the publication but they are not selected.|||if replicate_ddl option is truly enabled at both the publisher and the republisher, then I'm not sure what the problem is. You verified the replicate_ddl column is set to 1 in sysmergepublications table in the published database at both the publisher and republisher?|||

Well, I believe it's correct, here's what is in the sysmergepublications:

Consolidated database (original publisher)

publication name, replicate_ddl

Consolidated, 1

Region, 0

Regional database (republisher)

publication name, replicate_ddl

Consolidated, 1

Region, 1

SQL Express database (subscriber)

publication name, replicate_ddl

Consolidated, 0

Region, 1

Also the status in sysmergearticles in the consolidated db is 2 (active). There are two sets of articles in the sysmergearticles table in the regional db, one for each the consolidated and regional publication. The records in sysmergearticles for the consolidated publication has a status of 1 (Unsynced) while the records for the regional publication have a status of 2 (active). The status in the SQLExpress pull subscriptions is all 1 (Unsynced).

Thanks,

Aaron

|||Can you try your scenario with SP2? We fixed somewhat similar issue in SP2.sql

Wednesday, March 28, 2012

Merge replication with dynamic filter

Brand new to SQL Server 2005 and replication, I was able to use online books info to get a replication topology set up (using wizards) and successfully replicate an article (a single table) to a SQL Server Express database.

I then cleared the subscription table and added a simple dynamic filter (colx = SUSER_SNAME()), which I can't get to work. Based on what I read, I'm thinking that SUSER_SNAME() is not returning the proper value because the merge agent is set to connect to the publisher and distributor by 'impersonating the process account'. This is on the subscription merge agent security form. However, 'using a SQL Server login' is greyed out and nothing I tried will enable it, including setting up logins and SQL user ids on the publisher and playing with entries on the publication properties data partitions page, etc.

I think that I have discovered only some of the pieces that I need and not enough details to find the rest and put them together. Any info on what to have set up where would be appreciated. Any suggestions for 'step by step' information that would help in addition to SQL Server 2005 Books Online would be great.

Thanks in advance.

SUSER_NAME is the account that replication connects to the publisher with. You can override it with the -PublisherLogon property. By chance is this subscriber SQL Server Express? There are some limitations of SQL Server Express with replication, and I suspect that you are bumping into one of them. -- Hilary Cotter Director of Text Mining and Database Strategy RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. This posting is my own and doesn't necessarily represent RelevantNoise's positions, strategies or opinions. 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 wrote in message news:740eab10-6268-4aff-9dc9-56651ebc9d3d@.discussions.microsoft.com... Brand new to SQL Server 2005 and replication, I was able to use online books info to get a replication topology set up (using wizards) and successfully replicate an article (a single table) to a SQL Server Express database. I then cleared the subscription table and added a simple dynamic filter (colx = SUSER_SNAME()), which I can't get to work. Based on what I read, I'm thinking that SUSER_SNAME() is not returning the proper value because the merge agent is set to connect to the publisher and distributor by 'impersonating the process account'. This is on the subscription merge agent security form. However, 'using a SQL Server login' is greyed out and nothing I tried will enable it, including setting up logins and SQL user ids on the publisher and playing with entries on the publication properties data partitions page, etc. I think that I have discovered only some of the pieces that I need and not enough details to find the rest and put them together. Any info on what to have set up where would be appreciated. Any suggestions for 'step by step' information that would help in addition to SQL Server 2005 Books Online would be great. Thanks in advance.|||Yes, the subscriber is on SQL Express. In the mean time, I am trying to get it to work with HOST_NAME(). That doesn't seem to have the login/user/rights issues that SUSER_SNAME() does?|||You could override the -HostName parameter with what you normally use for the SUSER_NAME. For example if you want to filter on users, you could use a -HostName parameter of Fred. -- Hilary Cotter Director of Text Mining and Database Strategy RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. This posting is my own and doesn't necessarily represent RelevantNoise's positions, strategies or opinions. 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 wrote in message news:927b07a9-77e7-4a97-b7f5-14f5f9b9a496@.discussions.microsoft.com... Yes, the subscriber is on SQL Express. In the mean time, I am trying to get it to work with HOST_NAME(). That doesn't seem to have the login/user/rights issues that SUSER_SNAME() does?|||

There are three situations related to your scenario:

1. if the merge subscription is push, there is a known Yukon bug, which tells there is no way to input a SQL Authentication user to login in Publisher/Distributor. Please refer to the below description of the bug.

In dynamic filter merge pub, if filter is like SUSER_SNAME(), and SUSER_SNAME is a SQL user, there is no way to input a SQL Authentication user to connect Pub/Dist in Merge Agent Security Page of CreateSub wizard.

For push sub, Publisherlogin and DistributorLogin can only be process account in UI.

2. If merge subscription is pull. It will be fine.

3. If subscriber is based on SQL Express and merge subscription is pull, it won't be supported. Since SQL Express doesn't support Merge agent at all, sync can only be done through Windowns Synchronization.

Hope the above information will help.

-Yunjing

|||

I got rid of everything that I had and started over this time using HOST_NAME(). Everything went smoothly and it worked the first time!

I'm not sure why the MS online books appear to focus on SUSER_SNAME() and mention HOST_NAME(). The use of SUSER_SNAME() looks to be way more complicated in accomplishing the same thing despite the bug mentioned.

Thanks for helping a new guy get going. The merge replication tool with filtering is going to save a bunch of additional application development.

|||

It's glad to see your scenario worked. SUSER_SNAME() is used more often than HOST_NAME(), since it can implement partitional filtering for different user instead of for different machine. The bug I mentioned is only for configuration through UI, if replication is set up through SP, everything still works fine.

Hope these information will help as well.

Thanks

Yunjing

Monday, March 26, 2012

Merge Replication Topology

Hi everyone,
Is it possible to have three publishers who also subscribe to
publications from each other? All are pull subscriptions participating
in merge replication. The physical design is represented by a triangle.
My understanding of the suppported replication topology precludes such
a design - is this the case?
Paul
Hey Paul,
Triangle, or Peer To Peer Topologies are not supported in SQL2000.
You can 'fake' it with some heavy duty partitioning if you need to.
Take a peek at SQL2005 for that kind of functionality out of the box.
Donna Lambert
"Waterfall" wrote:

> Hi everyone,
> Is it possible to have three publishers who also subscribe to
> publications from each other? All are pull subscriptions participating
> in merge replication. The physical design is represented by a triangle.
> My understanding of the suppported replication topology precludes such
> a design - is this the case?
> Paul
>
|||Thanks Donna. It is good to know that SQL2005 will support peer-to-peer
replication topology.
I have another question. Is it possible to replicate to a table
containing an identity column and a natural key using merge or
transactional replication, where the identity values are not preserved?
Paul
*** Sent via Developersdex http://www.codecomments.com ***

Friday, March 23, 2012

Merge Replication Snapshot Generation - Need Best Practice

SQL Server 2005 & Express
All,
What is a best practice for generating snapshots in my merge
replication topology?
In my topology subscriptions will be coming and going over time.
There will be @.150 users with new employees coming online over time.
Some of the users share hardware and so they may have a subscription
on one machine for several months and then stop using the system for a
few months, and then start a new subscription on a different machine.
In such a scenario would it be better for me to expire subscriptions
on a regular basis?
I would evaluate using anonymous subscribers with dynamic filtering based on
user_name.
I think you will find a smaller retention period will mean shorted sync
times especially if your users are off line for appreciable amounts of time.
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
"Crash" <sourcenexus@.san.rr.com> wrote in message
news:1174326055.221629.90730@.n76g2000hsh.googlegro ups.com...
> SQL Server 2005 & Express
> All,
> What is a best practice for generating snapshots in my merge
> replication topology?
> In my topology subscriptions will be coming and going over time.
> There will be @.150 users with new employees coming online over time.
> Some of the users share hardware and so they may have a subscription
> on one machine for several months and then stop using the system for a
> few months, and then start a new subscription on a different machine.
> In such a scenario would it be better for me to expire subscriptions
> on a regular basis?
>
sql

Wednesday, March 21, 2012

Merge Replication Problem (Private,Public Data - Security Issue)

Hello,
We plan to establish a merge replication topology in which several servers
(subscribers) have "public" data – data that have to be propagated to the
other servers, and private data - data reside only at original servers.
Private and public data are marked with one table column (1/0). Those servers
are at local branches in different countries. We have one server on the
Internet, which can be publisher and hold all public data, besides its own
private data. Subscriptions will be anonymous pull subscriptions. Subscribers
would periodicaly make dialup connections and merge data. Article filter
would be something like "Public=1". The problem is that subscribers' private
data will go to the publisher in merge replication. As far as we understand,
filter is only checked at the publisher and not at the subscriber. Only
public data goes from publisher to the subscribers, but all data goes from
subscriber to the publisher.
Our client is to happy about the fact that data marked as private is
available on the Internet server.
Is there any possibility to prevent private data going to the publisher?
Many thanks in advance.
Mirza
The easiest solution is to partition the data - have 2 tables, one for
private and one for public. This way, the data is protected and can be
selectively replicated. To show the data to the user on teh subscriber you
could use partitioned views, or standard views with an instead-of trigger.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Friday, March 9, 2012

Merge Replication error while applying Snapshot

Hi,

i am getting the below error while applying running the Synchronization agent for the Subscriber. I have created replication topology with one central server and one subscriber. Here central server has windows server 2003 and subscriber has windows XP. Both are having SQL server 2005. After creating the merge subscriber, i am runnnig the Synchronization agent manually for the first time. While running that i am getting below error. Anybody aware of this error.

2006-06-24 00:26:00.175 Applying the snapshot to the Subscriber
2006-06-24 00:26:02.722 The schema script 'D_NUM_7.sch' could not be propagated to the subscriber.
2006-06-24 00:26:02.784 Category:NULL
Source: Merge Replication Provider
Number: -2147201001
Message: The schema script 'D_NUM_7.sch' could not be propagated to the subscriber.
2006-06-24 00:26:02.816 Category:AGENT
Source: WMBT-07
Number: 0
Message: The process could not read file '\\WMBT-01\repldata\unc\LTR-IN001_TEST_PUB\20060624034804\D_NUM_7.sch' due to OS error 1265.
2006-06-24 00:26:02.831 Category:OS
Source:
Number: 1265
Message: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

does the account under which the agent is running under have access to the share?|||

Greg,

Thanks for giving me the response...

Actually i am not clear about the Account... How to see the Account under which Agent is running?

I still dont understand where we are linking the Account and Agent.

Can you help on this ?

Thanks in advance.

|||

Greg,

Are you asking the about Agent in Central Server or in the Subscriber.

Thanks.

|||When you setup replication, you are asked to specify security credentials for the Snapshot agent, Log Reader Agent, Distribution Agent, Merge Agent, Queued Reader Agent. (Which agents you need to specify credentials for vary based on the method of replication.) The account that you specified for either the distribution agent (for snapshot or transactional replication) or the merge agent (for merge replication) needs to have the authority to access the snapshot folder in order for this to work successfully.|||

There are two places you may need to check.

1. Since snapshot files are saved under distributor, in your case, it may be the central server, which is both publisher and distributor, so make sure your publication snapshot files are saved under an alternate folder, UNC folder, which can be accessed by merge agent running on the subscriber.

2. Check merge agent account which is used to connect to distributor, it must have read permissions on the snapshot share. You can check it through open merge agent job properties.

Hope the above will be helpful.

Thanks

Yunjing

|||

Hi All,

Thanks for all you replies. I solved the problem i faced.

Normally when i create a Subscriber for Account under which Merge Agent will run i used to give as "Run Under SQL Server Agent Service Account" . It was working for me all these days. In all the machines where I created Replication was having windows XP. But when i was trying to create the Replication with systems with windows Server 2003, i have got the above said error.

To solve that error i have created one windows account in the Publisher and Subscriber with same name and same password. Then while creating the Publisher and Subscriber I was using this windows account as process Account for all the Agents. After that it was working fine. Here the windows account has to be there is both Publisher and Subscriber with same name and same Password. It was working for me. I have added that windows account as part of Administrator Group.

Thanks,

Thams.

Merge Replication error while applying Snapshot

Hi,

i am getting the below error while applying running the Synchronization agent for the Subscriber. I have created replication topology with one central server and one subscriber. Here central server has windows server 2003 and subscriber has windows XP. Both are having SQL server 2005. After creating the merge subscriber, i am runnnig the Synchronization agent manually for the first time. While running that i am getting below error. Anybody aware of this error.

2006-06-24 00:26:00.175 Applying the snapshot to the Subscriber
2006-06-24 00:26:02.722 The schema script 'D_NUM_7.sch' could not be propagated to the subscriber.
2006-06-24 00:26:02.784 Category:NULL
Source: Merge Replication Provider
Number: -2147201001
Message: The schema script 'D_NUM_7.sch' could not be propagated to the subscriber.
2006-06-24 00:26:02.816 Category:AGENT
Source: WMBT-07
Number: 0
Message: The process could not read file '\\WMBT-01\repldata\unc\LTR-IN001_TEST_PUB\20060624034804\D_NUM_7.sch' due to OS error 1265.
2006-06-24 00:26:02.831 Category:OS
Source:
Number: 1265
Message: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

does the account under which the agent is running under have access to the share?|||

Greg,

Thanks for giving me the response...

Actually i am not clear about the Account... How to see the Account under which Agent is running?

I still dont understand where we are linking the Account and Agent.

Can you help on this ?

Thanks in advance.

|||

Greg,

Are you asking the about Agent in Central Server or in the Subscriber.

Thanks.

|||When you setup replication, you are asked to specify security credentials for the Snapshot agent, Log Reader Agent, Distribution Agent, Merge Agent, Queued Reader Agent. (Which agents you need to specify credentials for vary based on the method of replication.) The account that you specified for either the distribution agent (for snapshot or transactional replication) or the merge agent (for merge replication) needs to have the authority to access the snapshot folder in order for this to work successfully.|||

There are two places you may need to check.

1. Since snapshot files are saved under distributor, in your case, it may be the central server, which is both publisher and distributor, so make sure your publication snapshot files are saved under an alternate folder, UNC folder, which can be accessed by merge agent running on the subscriber.

2. Check merge agent account which is used to connect to distributor, it must have read permissions on the snapshot share. You can check it through open merge agent job properties.

Hope the above will be helpful.

Thanks

Yunjing

|||

Hi All,

Thanks for all you replies. I solved the problem i faced.

Normally when i create a Subscriber for Account under which Merge Agent will run i used to give as "Run Under SQL Server Agent Service Account" . It was working for me all these days. In all the machines where I created Replication was having windows XP. But when i was trying to create the Replication with systems with windows Server 2003, i have got the above said error.

To solve that error i have created one windows account in the Publisher and Subscriber with same name and same password. Then while creating the Publisher and Subscriber I was using this windows account as process Account for all the Agents. After that it was working fine. Here the windows account has to be there is both Publisher and Subscriber with same name and same Password. It was working for me. I have added that windows account as part of Administrator Group.

Thanks,

Thams.

Wednesday, March 7, 2012

Merge replication doubt

It's possible in a merge replication topology to deny subscribers
updates ?
Thx,
Ruy
Ruy,
in SQL Server 2005 there is @.subscriber_upload_options which can be used for
this (value = 2). In SQL Server 2000 there is the -EXCHANGETYPE parameter
but this doesn't actually prevent changes - this has to be done at the
permissions level.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||That is called download only articles:
http://msdn2.microsoft.com/en-us/library/ms151748.aspx