Sorry, this is a long winded post I know. But all help is appreciated as me
and my managers need to explain all this to our CEO on Monday.
sql2k sp3
Transactional, non immediate Updating, continuous, no Transformations
Replication.
This last Tuesday morning a report against was run against the same
Replicated db that it is every morning. It is run automatically at the same
time Monday thru Friday. With the exception of errors on my end, Replication
has been purring along just fine with absolutely no problems for the 3
months its been up and running. However, this last Tuesday the report was
run and the numbers generated didn't match the numbers the end user was
expecting to see. They ran it again 10 minutes later and the numbers were
more to they're liking. As a group, our IT dept has ruled out pretty much
everything we can think of. So our only theory is that Replication was
having problems. We have narrowed down all possibilities to 1 table. This
table is imported into the Publisher from a file using BCP every morning
before this report is run. This table has a column with a GETDATE() function
on it so we know what time the data made it into the Publisher for sure. The
time it says is 45 minutes before the report was run. So the theory is that:
(finally)
There was about a 50 minute lag in Replication.
That the first time the report was run, not all of the data was in the
Subscriber.
That the second time it was run (10 minutes later) all of the data made it
in and life was good.
There is nothing supporting anything like this in the error log. Nor is
there anything supporting this theory in either the Log/ Distribution Agents
history. (although on Thursday I did stop/ restart both Agents for unrelated
reasons and I dont know if that clears them.)
So, does anyone have any way I can prove/ disprove these theories? It seems
a bit far stretched to me since Ive got a fair amount of Replication
experience under my belt and the only time I got anything like a "lag" was
along the lines of "cant exec sp_repldone" and then it blew up totally
untill fixed manually.
All ideas are greatly appreciated.
TIA, ChrisR
You might want to query msrepl_errors to find out if there was any errors in
this time period, like a general network error, or query the
msdistribution_history table to see how many commands were replicated in
this time period. Unfortunately these tables are pruned by default every 2
days so you might not see anything there.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <ChrisR@.noEmail.com> wrote in message
news:O6qegci2EHA.3244@.TK2MSFTNGP11.phx.gbl...
> Sorry, this is a long winded post I know. But all help is appreciated as
> me
> and my managers need to explain all this to our CEO on Monday.
> sql2k sp3
> Transactional, non immediate Updating, continuous, no Transformations
> Replication.
> This last Tuesday morning a report against was run against the same
> Replicated db that it is every morning. It is run automatically at the
> same
> time Monday thru Friday. With the exception of errors on my end,
> Replication
> has been purring along just fine with absolutely no problems for the 3
> months its been up and running. However, this last Tuesday the report was
> run and the numbers generated didn't match the numbers the end user was
> expecting to see. They ran it again 10 minutes later and the numbers were
> more to they're liking. As a group, our IT dept has ruled out pretty much
> everything we can think of. So our only theory is that Replication was
> having problems. We have narrowed down all possibilities to 1 table. This
> table is imported into the Publisher from a file using BCP every morning
> before this report is run. This table has a column with a GETDATE()
> function
> on it so we know what time the data made it into the Publisher for sure.
> The
> time it says is 45 minutes before the report was run. So the theory is
> that:
> (finally)
> There was about a 50 minute lag in Replication.
> That the first time the report was run, not all of the data was in the
> Subscriber.
> That the second time it was run (10 minutes later) all of the data made it
> in and life was good.
> There is nothing supporting anything like this in the error log. Nor is
> there anything supporting this theory in either the Log/ Distribution
> Agents
> history. (although on Thursday I did stop/ restart both Agents for
> unrelated
> reasons and I dont know if that clears them.)
> So, does anyone have any way I can prove/ disprove these theories? It
> seems
> a bit far stretched to me since Ive got a fair amount of Replication
> experience under my belt and the only time I got anything like a "lag" was
> along the lines of "cant exec sp_repldone" and then it blew up totally
> untill fixed manually.
> All ideas are greatly appreciated.
> TIA, ChrisR
>
|||Hillary do you know if theres adjust these settings to keep the history for
a longer time period? Im guessing the proc in the "dist cleanup" job?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:#Rigw1i2EHA.3468@.TK2MSFTNGP14.phx.gbl...
> You might want to query msrepl_errors to find out if there was any errors
in[vbcol=seagreen]
> this time period, like a general network error, or query the
> msdistribution_history table to see how many commands were replicated in
> this time period. Unfortunately these tables are pruned by default every 2
> days so you might not see anything there.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> "ChrisR" <ChrisR@.noEmail.com> wrote in message
> news:O6qegci2EHA.3244@.TK2MSFTNGP11.phx.gbl...
as[vbcol=seagreen]
was[vbcol=seagreen]
were[vbcol=seagreen]
much[vbcol=seagreen]
This[vbcol=seagreen]
it[vbcol=seagreen]
was
>
|||Right click on Replication Monitor, select distributor properties. I believe
you set it there.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ChrisR" <bla@.noemail.com> wrote in message
news:e0vQb3j2EHA.304@.TK2MSFTNGP11.phx.gbl...
> Hillary do you know if theres adjust these settings to keep the history
> for
> a longer time period? Im guessing the proc in the "dist cleanup" job?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:#Rigw1i2EHA.3468@.TK2MSFTNGP14.phx.gbl...
> in
> as
> was
> were
> much
> This
> it
> was
>
Showing posts with label explain. Show all posts
Showing posts with label explain. Show all posts
Friday, March 30, 2012
Monday, March 26, 2012
replication conflict when use BEGIN TRANSACTION COMMIT TRANSACTION
Ok let me explain my problem
I update table abc to SERVER A
SERVER A push a replication to SERVER B
and SERVER B push to SERVER A and SERVER C
SERVER A and C are configure to replicate to SERVER B and
SERVER B is configure to replicate to SERVER A and SERVER C
(same tables are replicate)
I have no problem while I not use BEGIN TRANSACTION UPDATE... COMMIT
TRANSACTION
When I use BEGIN TRANSACTION UPDATE... COMMIT TRANSACTION I got a conflict
error
supp info:
2 Queued update conflict. Subscriber wins. Updating Publisher ...
"rl" <rlavoie@.lgs.com> wrote in message
news:%23jnEqEGjFHA.1232@.TK2MSFTNGP15.phx.gbl...
> Ok let me explain my problem
> I update table abc to SERVER A
> SERVER A push a replication to SERVER B
> and SERVER B push to SERVER A and SERVER C
> SERVER A and C are configure to replicate to SERVER B and
> SERVER B is configure to replicate to SERVER A and SERVER C
> (same tables are replicate)
> I have no problem while I not use BEGIN TRANSACTION UPDATE... COMMIT
> TRANSACTION
> When I use BEGIN TRANSACTION UPDATE... COMMIT TRANSACTION I got a conflict
> error
>
I update table abc to SERVER A
SERVER A push a replication to SERVER B
and SERVER B push to SERVER A and SERVER C
SERVER A and C are configure to replicate to SERVER B and
SERVER B is configure to replicate to SERVER A and SERVER C
(same tables are replicate)
I have no problem while I not use BEGIN TRANSACTION UPDATE... COMMIT
TRANSACTION
When I use BEGIN TRANSACTION UPDATE... COMMIT TRANSACTION I got a conflict
error
supp info:
2 Queued update conflict. Subscriber wins. Updating Publisher ...
"rl" <rlavoie@.lgs.com> wrote in message
news:%23jnEqEGjFHA.1232@.TK2MSFTNGP15.phx.gbl...
> Ok let me explain my problem
> I update table abc to SERVER A
> SERVER A push a replication to SERVER B
> and SERVER B push to SERVER A and SERVER C
> SERVER A and C are configure to replicate to SERVER B and
> SERVER B is configure to replicate to SERVER A and SERVER C
> (same tables are replicate)
> I have no problem while I not use BEGIN TRANSACTION UPDATE... COMMIT
> TRANSACTION
> When I use BEGIN TRANSACTION UPDATE... COMMIT TRANSACTION I got a conflict
> error
>
Wednesday, March 7, 2012
Replication
Hello,
Can anybody explain me here or can recommend me a good literature how the
replication works with its corresponding compononents and the course of
events of the replication?
thanks in advance
yours sincerely,
robert
with components i mean the virtual directory, publication, snapshot folder,
subscription, repldata folder in the SQL Server directory, etc...
yours sincerely,
patrick
|||Patrick,
currently books on line (BOL) is the best resource for
this sort of data. I have some links on
www.replicationanswers.com you might find useful.
Finally, keep an eye out for Hilary's book:
http://www.nwsu.com/0974973602p.html.
As for the snapshot folder and the repldata folder -
usually they are one and the same. The repldata folder is
an installation folder and is usually made available as a
share to subscribers. This is the folder that stored the
initial configuration textfiles, and datafiles if
selected. ODBCBCP is used to transfer the data to this
file. On initialization the contents of this folder are
applied to the subscriber by the distribution/merge agent.
Alternative snapshot locations are possible - removable
media such as removable disks, CD-ROMs, or in locations
other than in the default snapshot folder on the
Distributor, such as File Transfer Protocol (FTP) servers
which may be compressed, however the above is the default
behaviour.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||are we talking SQL CE or SQL Server? SQL CE has a virtual directory which an
isapi filter runs in. The only other virtual directory used in replication
is when you are downloading a publication using ftp and have defined a
virtual directory on your ftp server.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"robert" <robert@.discussions.microsoft.com> wrote in message
news:553B67F1-EF21-480B-99EF-7EFE5B431313@.microsoft.com...
>
> with components i mean the virtual directory, publication, snapshot
folder,
> subscription, repldata folder in the SQL Server directory, etc...
> yours sincerely,
> patrick
Can anybody explain me here or can recommend me a good literature how the
replication works with its corresponding compononents and the course of
events of the replication?
thanks in advance
yours sincerely,
robert
with components i mean the virtual directory, publication, snapshot folder,
subscription, repldata folder in the SQL Server directory, etc...
yours sincerely,
patrick
|||Patrick,
currently books on line (BOL) is the best resource for
this sort of data. I have some links on
www.replicationanswers.com you might find useful.
Finally, keep an eye out for Hilary's book:
http://www.nwsu.com/0974973602p.html.
As for the snapshot folder and the repldata folder -
usually they are one and the same. The repldata folder is
an installation folder and is usually made available as a
share to subscribers. This is the folder that stored the
initial configuration textfiles, and datafiles if
selected. ODBCBCP is used to transfer the data to this
file. On initialization the contents of this folder are
applied to the subscriber by the distribution/merge agent.
Alternative snapshot locations are possible - removable
media such as removable disks, CD-ROMs, or in locations
other than in the default snapshot folder on the
Distributor, such as File Transfer Protocol (FTP) servers
which may be compressed, however the above is the default
behaviour.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||are we talking SQL CE or SQL Server? SQL CE has a virtual directory which an
isapi filter runs in. The only other virtual directory used in replication
is when you are downloading a publication using ftp and have defined a
virtual directory on your ftp server.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"robert" <robert@.discussions.microsoft.com> wrote in message
news:553B67F1-EF21-480B-99EF-7EFE5B431313@.microsoft.com...
>
> with components i mean the virtual directory, publication, snapshot
folder,
> subscription, repldata folder in the SQL Server directory, etc...
> yours sincerely,
> patrick
Labels:
compononents,
corresponding,
course,
database,
explain,
literature,
microsoft,
mysql,
oracle,
recommend,
replication,
server,
sql,
thereplication
Saturday, February 25, 2012
Replication
Hi everybody,
Could someone explain me how to use replication in sql server with access as
frontend?This is such a large topic, I would suggest you begin by reading and
following the directions in Books onLine ( the SQL Server Help files..)
THere is enough information there to get you started...
"Nicollo Machiaveli" <machiaveli280278@.hotmail.com> wrote in message
news:eR%23IffTcDHA.3872@.TK2MSFTNGP11.phx.gbl...
> Hi everybody,
> Could someone explain me how to use replication in sql server with access
as
> frontend?
>
Could someone explain me how to use replication in sql server with access as
frontend?This is such a large topic, I would suggest you begin by reading and
following the directions in Books onLine ( the SQL Server Help files..)
THere is enough information there to get you started...
"Nicollo Machiaveli" <machiaveli280278@.hotmail.com> wrote in message
news:eR%23IffTcDHA.3872@.TK2MSFTNGP11.phx.gbl...
> Hi everybody,
> Could someone explain me how to use replication in sql server with access
as
> frontend?
>
Subscribe to:
Posts (Atom)