replication

[krishna]

We have a publishing subscriber scenario.
Distribution server is on subscribing server.
Subscriber subscribes to itself and one more server.

The problem:
The record counts are not matching on Publication and Subscribing servers.
In fact, Subscriber has more records than Publisher.
And the record count from Dist/Subscriber to another subscriber is also different.
How to track this problem.
Where to look for and what to do?

Thanks.
Kirshna.

[Frank Garcia (DBA)]

Hi,
I don't understand the topology that you are describing, but I will try to
re-state your replication environment: You have serverA which is a publisher/distr/subscriber and server B which is a publisher/distributor. server A is subscribing to itself and subscribing to server B. Is this correct?

Until I have interpreted your topology correctly you may want to take a look at the replication tables that allow you to see the jobs that are awaiting to be replicated including other information. You can find these tables by doing a select on sysservers. Check out books on line on replication. There is a good article in there on this topic. Also, Professional SQL Server 6.5 Admin (Wrox Press) is also an excellent book and they have good informational chapters on replication and MSDTC. I use this book religiously. It is practically my goto source all the time around SQL 6.5.

I hope that I could be of further assistance. Good Luck.

On 11/19/98 9:52:33 AM, krishna wrote:
> We have a publishing subscriber scenario.
Distribution server is on
> subscribing server.
Subscriber subscribes to itself and one more
> server.

The problem:
The record counts are not matching on Publication
> and Subscribing servers.
In fact, Subscriber has more records than
> Publisher.
And the record count from Dist/Subscriber to another subscriber
> is also different.
How to track this problem.
Where to look for and what
> to do?

Thanks.
Kirshna.

[Krishna]

Hi Frank,
The replication scenario is like this:
Server A is Publisher. Server B is Distributor/Subscriber.
And Server C is another Subscriber.
Server B is subscribing to itself and to Server C.

Hope this will clear things. Thanks for any ideas.
Thanks for your suggestion about the book.
Any suggestions are welcome.
Thanks.
Krishna.



On 11/20/98 5:32:09 PM, Frank Garcia (DBA) wrote:
> Hi,
I don't understand the topology that you are describing, but I
> will try to
re-state your replication environment: You have serverA
> which is a publisher/distr/subscriber and server B which is a
> publisher/distributor. server A is subscribing to itself and subscribing to
> server B. Is this correct?

Until I have interpreted your topology
> correctly you may want to take a look at the replication tables that allow
> you to see the jobs that are awaiting to be replicated including other
> information. You can find these tables by doing a select on sysservers.
> Check out books on line on replication. There is a good article in there
> on this topic. Also, Professional SQL Server 6.5 Admin (Wrox Press) is
> also an excellent book and they have good informational chapters on
> replication and MSDTC. I use this book religiously. It is practically my
> goto source all the time around SQL 6.5.

I hope that I could be of
> further assistance. Good Luck.

On 11/19/98 9:52:33 AM, krishna wrote:
>
> We have a publishing subscriber scenario.
Distribution server is on
>
> subscribing server.
Subscriber subscribes to itself and one more
>
> server.

The problem:
The record counts are not matching on Publication
>
> and Subscribing servers.
In fact, Subscriber has more records than
>
> Publisher.
And the record count from Dist/Subscriber to another subscriber
>
> is also different.
How to track this problem.
Where to look for and
> what
> to do?

Thanks.
Kirshna.

[Frank Garcia (DBA)]

OK. The problem at hand is that the record count between A, B&C are out of sync. Is this correct? You state that server B is subscribing to itself and to server C. It seems to me that none of your servers are subscribing to server A? and Server B is subscribing to itself, but who's the publisher? and server B is subscribing to a subscriber? I may be misinterpreting the topology that you have set up, but it does not seem practical for a replication scenario. If you want server A, B & C to be in sync, then you must first: choose which server(s) will be your publisher/distributor/subscribers. Second: choose whether you will be using push/pull subscribing. Third: make sure that all of the tables in each database for each server have the same exact records to begin with. This will make it easier to sync all of your servers.

Is server A your primary server? I mean is this the server that most of your users will be pointing to? If you would like, write out your specs (exactly what do you want to accomplish (i.e., server a is my primary where all users will update databases, server b will be a replica that will subscribe to server a) and I will try to help you come up with a topology.

Otherwise, you should get the book that I suggested. This will help immensely.

hope this helps.
Hi Frank,
The replication scenario is like this:
Server A is
> Publisher. Server B is Distributor/Subscriber.
And Server C is another
> Subscriber.
Server B is subscribing to itself and to Server C.

Hope
> this will clear things. Thanks for any ideas.
Thanks for your suggestion
> about the book.
Any suggestions are welcome.
Thanks.
Krishna.



On
> 11/20/98 5:32:09 PM, Frank Garcia (DBA) wrote:
> Hi,
I don't
> understand the topology that you are describing, but I
> will try to
>
re-state your replication environment: You have serverA
> which is a
> publisher/distr/subscriber and server B which is a
>
> publisher/distributor. server A is subscribing to itself and subscribing to
>
> server B. Is this correct?

Until I have interpreted your topology
>
> correctly you may want to take a look at the replication tables that
> allow
> you to see the jobs that are awaiting to be replicated including
> other
> information. You can find these tables by doing a select on
> sysservers.
> Check out books on line on replication. There is a good
> article in there
> on this topic. Also, Professional SQL Server 6.5
> Admin (Wrox Press) is
> also an excellent book and they have good
> informational chapters on
> replication and MSDTC. I use this book
> religiously. It is practically my
> goto source all the time around SQL
> 6.5.

I hope that I could be of
> further assistance. Good Luck.

On
> 11/19/98 9:52:33 AM, krishna wrote:
>
> We have a publishing subscriber
> scenario.
Distribution server is on
>
> subscribing
> server.
Subscriber subscribes to itself and one more
>
>
> server.

The problem:
The record counts are not matching on Publication
>
>
> and Subscribing servers.
In fact, Subscriber has more records than
>
>
> Publisher.
And the record count from Dist/Subscriber to another
> subscriber
>
> is also different.
How to track this problem.
Where to
> look for and
> what
> to do?

Thanks.
Kirshna.

[Krishna]

Hi Frank,

Here, the server 'A' is publisher and server 'B' is distributor/subscriber
and server 'C' is another subscriber which gets replicated data from server 'B'.
Somebody has already set this scenario up.
Server 'B' is subscribing to Server 'A'(the publisher).
And server 'A'(publisher) is our primary server.

With this information, if you can clarify it's fine. Otherwise I would be grateful if you can suggest a new topology.
(The problem: From Publisher(A), some tables are to be replicated to one subscriber(B) which is also a distributor and from this subscriber some tables are replicated to another subscriber 'C'. From A, you need to replicate say 10 tables to B and from B you need to replicate say 5 tables)


One more question:
The record count of all replicated tables is same except in one table.
Is it possible to resync that particular table?
What are the steps?

Thanks a lot.
Krishna.


On 11/24/98 9:44:43 AM, Frank Garcia (DBA) wrote:
> OK. The problem at hand is that the record count between A, B&C are out of
> sync. Is this correct? You state that server B is subscribing to itself
> and to server C. It seems to me that none of your servers are subscribing
> to server A? and Server B is subscribing to itself, but who's the
> publisher? and server B is subscribing to a subscriber? I may be
> misinterpreting the topology that you have set up, but it does not seem
> practical for a replication scenario. If you want server A, B & C to be
> in sync, then you must first: choose which server(s) will be your
> publisher/distributor/subscribers. Second: choose whether you will be using
> push/pull subscribing. Third: make sure that all of the tables in each
> database for each server have the same exact records to begin with. This
> will make it easier to sync all of your servers.

Is server A your
> primary server? I mean is this the server that most of your users will be
> pointing to? If you would like, write out your specs (exactly what do you
> want to accomplish (i.e., server a is my primary where all users will
> update databases, server b will be a replica that will subscribe to server
> a) and I will try to help you come up with a topology.

Otherwise, you
> should get the book that I suggested. This will help immensely.

hope
> this helps.
Hi Frank,
The replication scenario is like this:
Server A is
>
> Publisher. Server B is Distributor/Subscriber.
And Server C is another
>
> Subscriber.
Server B is subscribing to itself and to Server C.

Hope
>
> this will clear things. Thanks for any ideas.
Thanks for your
> suggestion
> about the book.
Any suggestions are
> welcome.
Thanks.
Krishna.



On
> 11/20/98 5:32:09 PM, Frank Garcia
> (DBA) wrote:
> Hi,
I don't
> understand the topology that you are
> describing, but I
> will try to
>
re-state your replication
> environment: You have serverA
> which is a
>
> publisher/distr/subscriber and server B which is a
>
>
> publisher/distributor. server A is subscribing to itself and subscribing to
>
>
> server B. Is this correct?

Until I have interpreted your
> topology
>
> correctly you may want to take a look at the replication
> tables that
> allow
> you to see the jobs that are awaiting to be
> replicated including
> other
> information. You can find these tables
> by doing a select on
> sysservers.
> Check out books on line on
> replication. There is a good
> article in there
> on this topic.
> Also, Professional SQL Server 6.5
> Admin (Wrox Press) is
> also an
> excellent book and they have good
> informational chapters on
>
> replication and MSDTC. I use this book
> religiously. It is practically
> my
> goto source all the time around SQL
> 6.5.

I hope that I could
> be of
> further assistance. Good Luck.

On
> 11/19/98 9:52:33 AM,
> krishna wrote:
>
> We have a publishing subscriber
>
> scenario.
Distribution server is on
>
> subscribing
>
> server.
Subscriber subscribes to itself and one more
>
>
>
> server.

The problem:
The record counts are not matching on Publication
>
>
>
> and Subscribing servers.
In fact, Subscriber has more records
> than
>
>
> Publisher.
And the record count from Dist/Subscriber to
> another
> subscriber
>
> is also different.
How to track this
> problem.
Where to
> look for and
> what
> to do?

Thanks.
Kirshna.

[Alvaro Bodero Semiglia]

On 11/23/98 9:12:17 AM, Krishna wrote:
>

Hello,

A few ideas that might help you:

1.- ¿How did you synchronize the data? ¿Did you make sure the data was exactly a mirror of the distributor before starting replication?
2.- The first thing I look for when I have a problem in Replication is its tasks. ¿ Did the distribution tasks run succesfully ? The same for the Log Reader.
3.- You might want to take a look at the table MSlast_job_info , see if the job_id of this table in the Suscribing databases is the same as the last job_id to replicate( try this query in the distribution database

select MAX(job_id) from MSjobs
where publisher_db=db_name
)
4.- Finally, there si a way to know exactly which transactions have been applied to each suscriber. You need to work with the tables:

MSjobs: job_id's
MSjob_commands :gives you the command for each job_id
MSsubscriber_jobs : tells you which jobs have been applied to each suscriber

Note:This can only be done if you have not run the cleanup task for the suscriber

hope it helps..
Alvaro


Hi Frank,
The replication scenario is like this:
Server A is
> Publisher. Server B is Distributor/Subscriber.
And Server C is another
> Subscriber.
Server B is subscribing to itself and to Server C.

Hope
> this will clear things. Thanks for any ideas.
Thanks for your suggestion
> about the book.
Any suggestions are welcome.
Thanks.
Krishna.



On
> 11/20/98 5:32:09 PM, Frank Garcia (DBA) wrote:
> Hi,
I don't
> understand the topology that you are describing, but I
> will try to
>
re-state your replication environment: You have serverA
> which is a
> publisher/distr/subscriber and server B which is a
>
> publisher/distributor. server A is subscribing to itself and subscribing to
>
> server B. Is this correct?

Until I have interpreted your topology
>
> correctly you may want to take a look at the replication tables that
> allow
> you to see the jobs that are awaiting to be replicated including
> other
> information. You can find these tables by doing a select on
> sysservers.
> Check out books on line on replication. There is a good
> article in there
> on this topic. Also, Professional SQL Server 6.5
> Admin (Wrox Press) is
> also an excellent book and they have good
> informational chapters on
> replication and MSDTC. I use this book
> religiously. It is practically my
> goto source all the time around SQL
> 6.5.

I hope that I could be of
> further assistance. Good Luck.

On
> 11/19/98 9:52:33 AM, krishna wrote:
>
> We have a publishing subscriber
> scenario.
Distribution server is on
>
> subscribing
> server.
Subscriber subscribes to itself and one more
>
>
> server.

The problem:
The record counts are not matching on Publication
>
>
> and Subscribing servers.
In fact, Subscriber has more records than
>
>
> Publisher.
And the record count from Dist/Subscriber to another
> subscriber
>
> is also different.
How to track this problem.
Where to
> look for and
> what
> to do?

Thanks.
Kirshna.