Replication Timeout Issue

Greetings!

I am running into this error when running Replication:

The response message was received from 'https://replia.websitename.net/replia/replisapi.dll' and is being processed.

(f) The process could not connect to Distributor 'OURDATABASE-DB'.

(f) The process could not connect to Distributor 'OURDATABASE-DB'.

(f) Unable to complete login process due to delay in opening server connection

*******************************************************

01/11/2007 18:26:09 - Error during FINAL DB Replication. The process could not connect to Distributor 'OURDATABASE-DB'.

I am running Replication on a Windows XP Pro laptop, with 1 GB of RAM, 1.83 GHz CPU. Any ideas, suggestions and/or help would be appreciated!

Thanks!

Cristian E.

Please provide more information. What version of SQL server are you using? Are you using standard edition, enterprise, or express? Transactional or merge replication?

Gary

|||

Hello,

1. Is the Laptop computer your Subscriber or Publisher/Distributor?

2. If you do not do web sync, can you run sync through merge agent (replmerg.exe) from Console window command line using fully connected mode?

This posting is provided AS IS with no warranties, and confers no rights.

|||

I am using SQL Server 2005 Express version, Merge replication. I changed the History Verbose Level to a 2 and I got a different error:

(f) The response message was received from 'https://replia.websitename.net/replia/replisapi.dll' and is being processed.
(f) The process could not connect to Distributor 'ABCD-DB'.
(f) The process could not connect to Distributor 'ABCD-DB'.
(f) Named Pipes Provider: Could not open a connection to SQL Server [2].
(f) An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.
(f) Login timeout expired
(f) The merge process failed to execute a query because the query timed out. If this failure continues, increase the query timeout for the process. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write.
*******************************************************
01/13/2007 09:31:39 - Error during FINAL DB Replication. The process could not connect to Distributor 'ABCD-DB'.

*******************************************************

I have already increased the timeout to 15-20 mins. Any other suggestions?

Thanks!

Cristian E.

|||

I am using SQL Server 2005 Express version, Merge replication. I changed the History Verbose Level to a 2 and I got a different error:

(f) The response message was received from 'https://replia.websitename.net/replia/replisapi.dll' and is being processed.
(f) The process could not connect to Distributor 'ABCD-DB'.
(f) The process could not connect to Distributor 'ABCD-DB'.
(f) Named Pipes Provider: Could not open a connection to SQL Server [2].
(f) An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.
(f) Login timeout expired
(f) The merge process failed to execute a query because the query timed out. If this failure continues, increase the query timeout for the process. When troubleshooting, restart the synchronization with verbose history logging and specify an output file to which to write.
*******************************************************
01/13/2007 09:31:39 - Error during FINAL DB Replication. The process could not connect to Distributor 'ABCD-DB'.

*******************************************************

I have already increased the timeout to 15-20 mins.

The Laptop computer is the Publisher and it is running web synchronization (web services).

|||

Has it ever worked before?

Can you try this on your machine?

osql -S"ABCD-DB" -U"login"

See if you get the same error message for "Named Pipes Provider: Could not open a connection to SQL Server [2]. "

If you get the same message, then the problem is as simple as enable the protocols in your sql server setting.

I also noticed that the name "ABCD-DB" sounds more like a database name than a server name...

Regards,
Gary

sql

replication timeout

I have 3 production machines which are replicated to a dr site, all
machines are using a central distributor machine. I have created a
separate distributor database for each system.
My problem is that one of my systems will not replicate I am doing
snapshot and transactional, it just keeps timing out I have put sql
profiler on the dr box and can see that the data gets to the box but
it just times out. All boxes publisher, distributor, subscriber can
see each other so why is it timing out?
what is the exact error message you are getting?
"stephen" <twolf@.icon.co.za> wrote in message
news:75c81dee.0404170439.22bbd18d@.posting.google.c om...
> I have 3 production machines which are replicated to a dr site, all
> machines are using a central distributor machine. I have created a
> separate distributor database for each system.
> My problem is that one of my systems will not replicate I am doing
> snapshot and transactional, it just keeps timing out I have put sql
> profiler on the dr box and can see that the data gets to the box but
> it just times out. All boxes publisher, distributor, subscriber can
> see each other so why is it timing out?
|||Have you looked into creating a different snapshot profile?
If you go into Publisher/Distributor Properties, Agent Profiles, and
then Snapshot Tab, If you look at the existing "Default profile" the
Query time-out is set to 300; you might want to increase that number
to maybe 1000 or so.
Here is something that I have found interesting though that you might
want to know ahead of time so you DON'T CANCEL the replication
process:
Depending on how high you increase this number to, there is always the
potential of getting a somewhat bizare error message while the
replication is running stating that no response has been received from
the snapshot agent, and the Replication monitor will display the red X
symbols (like if it had failed). However, the process is still alive
and well (you can check it under jobs to see if it is still in fact
running), so once it goes past the table that may be causing it to
time-out, the Replication monitor will refresh and the Xs will be
removed.
Try this on a test environment first as every environment reacts
diferently, and always remember to keep a current backup just in case.
Hope this helps.
Jose
twolf@.icon.co.za (stephen) wrote in message news:<75c81dee.0404170439.22bbd18d@.posting.google. com>...
> I have 3 production machines which are replicated to a dr site, all
> machines are using a central distributor machine. I have created a
> separate distributor database for each system.
> My problem is that one of my systems will not replicate I am doing
> snapshot and transactional, it just keeps timing out I have put sql
> profiler on the dr box and can see that the data gets to the box but
> it just times out. All boxes publisher, distributor, subscriber can
> see each other so why is it timing out?

Replication that causes blocking of process

Hi ,
My Replication also got this timeout error while running the last command :
{CALL sp_MSdel_SL030100 (N'BJX0047', N'26.01.06AF')} {CALL sp_MSins_SL030100
(N'BJX0047', N'26.01.06AF', N'535488', 2006-01-19 etc ..)
i found out that SPid83 --> which is doing the sp_MSins_SL030100;1 is
blocking
SPid73 --> which is doing the CALL sp_MSdel_SL030100
How can i resolve it as i am afraid that if i kill any process the sync is
out and i would be forced to re-create the snapshot and also shldn't the
SP_MSdel be done first ?
apreciate ur advise
Message posted via http://www.droptable.com
This looks like an update which is being performed as a delete insert pair.
Study what the procs are doing and see if it can't benefit from new indexes
of updating the indexes.
You might also want to look at this trace flag.
http://support.microsoft.com/kb/238254/en-us
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
"maxzsim via droptable.com" <u14644@.uwe> wrote in message
news:5a944df8034f0@.uwe...
> Hi ,
> My Replication also got this timeout error while running the last command
> :
> {CALL sp_MSdel_SL030100 (N'BJX0047', N'26.01.06AF')} {CALL
> sp_MSins_SL030100
> (N'BJX0047', N'26.01.06AF', N'535488', 2006-01-19 etc ..)
> i found out that SPid83 --> which is doing the sp_MSins_SL030100;1 is
> blocking
> SPid73 --> which is doing the CALL sp_MSdel_SL030100
> How can i resolve it as i am afraid that if i kill any process the sync is
> out and i would be forced to re-create the snapshot and also shldn't the
> SP_MSdel be done first ?
>
> apreciate ur advise
> --
> Message posted via http://www.droptable.com
|||Hi,
First of all tks for the links provided.
as menitoned in the link it's doing a so-called "deferred" update when the
unique constraint (i.e the PK) has been changed
However , from the stored procedure below
{CALL sp_MSdel_SL030100 (N'BJX0047', N'26.01.06AF')} {CALL sp_MSins_SL030100
(N'BJX0047', N'26.01.06AF', N'535488', 2006-01-19
BJX0047 & 26.01.06AF are the 2 PKs' values and both the DELETE/INSERT are
showing the same values, so i am confused
appreciate ur further advice
btw : after leaving this replication for the whole nite , it somehow resolved
by itself
tks & rdgs
Hilary Cotter wrote:[vbcol=seagreen]
>This looks like an update which is being performed as a delete insert pair.
>Study what the procs are doing and see if it can't benefit from new indexes
>of updating the indexes.
>You might also want to look at this trace flag.
>http://support.microsoft.com/kb/238254/en-us
>[quoted text clipped - 13 lines]
Message posted via http://www.droptable.com

replication problem

what's rcsp_resolver does becuase the replication failed ((timeout expired))
please help meSounds like a custom conflict resolution procedure to me - not sure where you would access these - probably in the publication properties somewhere.
GW

Replication Over FTP, Initial Snapshot Timeout

Hello,
I am trying to replicate over FTP (merge replication) and I'm having
trouble with subscribing.
After 60-70 minutes I get a timeout error and the initial snapshot fails
to work.
The exact error is:
"Category:OS
Source:
Number: 12002
Message: The operation timed out"
Then it says that it failed to propagate the file it was working on.
The entire snapshot directory is less than 500 meg. I tried the
compressed snapshot first (which makes it about 130 meg) and that gets
the same timeout error.
Is there a way to increase that timeout somewhere? I don't quite
understand why it's timing out anyway, it should have plenty of time to
transfer that size of a file. Both machines are on high speed connections.
Thanks,
Jeff
right click on your pull subscription agent. Select agent properties, then
select run steps, and give focus to run agent. click on the commands button
and press the end key. Then press space, and type -QueryTimeout 600.
Then restart your pull subscription agent.
You may want to right click on replicaiton monitor and select refresh rate
and settings and set your inactivity threshold to something high.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:oIA3d.1761$DY.272@.chiapp18.algx.net...
> Hello,
> I am trying to replicate over FTP (merge replication) and I'm having
> trouble with subscribing.
> After 60-70 minutes I get a timeout error and the initial snapshot fails
> to work.
> The exact error is:
> "Category:OS
> Source:
> Number: 12002
> Message: The operation timed out"
> Then it says that it failed to propagate the file it was working on.
> The entire snapshot directory is less than 500 meg. I tried the
> compressed snapshot first (which makes it about 130 meg) and that gets
> the same timeout error.
> Is there a way to increase that timeout somewhere? I don't quite
> understand why it's timing out anyway, it should have plenty of time to
> transfer that size of a file. Both machines are on high speed
connections.
> Thanks,
> Jeff
|||Hilary Cotter wrote:
> right click on your pull subscription agent. Select agent properties, then
> select run steps, and give focus to run agent. click on the commands button
> and press the end key. Then press space, and type -QueryTimeout 600.
Ok, I had previously tried this with no success but ...

> Then restart your pull subscription agent.
> You may want to right click on replicaiton monitor and select refresh rate
> and settings and set your inactivity threshold to something high.
This appeared to do the trick. I noticed that after 10 minutes (the
default timeout) is when my transfer would stop taking place.
I successfully transferred a few large bcp files (133 meg and 220 meg),
but ran into another problem when it applied one of those files before
continuing to download. So by the time it finished applying one of those
files, it tried to download the next file and the connection was no
longer active.
So I decided to go back to the compressed snapshot and try again since
it looked like my timeout issue disappeared with the inactivity
threshold setting.
Now I'm not getting a timeout, but for some reason the compressed
snapshot (cab) fails to complete it's download (it's about 120 meg).
First time I got to ~58 meg. Second time it got to ~9 meg. Third time
it got to ~105 meg.
I don't see any problem with the network between the two machines
(though they are separated by the Atlantic Ocean), and only moments
before it had no problem downloading the two large bcp files.
Is there some other setting I can look for? Is there something else it
does while downloading a compressed snapshot?
Thanks,
Jeff
|||Jeff Hedlund wrote:
> Now I'm not getting a timeout, but for some reason the compressed
> snapshot (cab) fails to complete it's download (it's about 120 meg).
> First time I got to ~58 meg. Second time it got to ~9 meg. Third time
> it got to ~105 meg.
> I don't see any problem with the network between the two machines
> (though they are separated by the Atlantic Ocean), and only moments
> before it had no problem downloading the two large bcp files.
Looking at the FTP server logs, I see errors about 120 second inactivity
timeouts. So maybe I am having some network congestion/problems.
Jeff
|||I would try to zip up the snapshot files and then have the subscriber pull
them through ftp. Once they arrive at the subscriber, expand them, create a
pull subscription and then when you get to the specify snapshot location
select specify directory and browse to the location of the snapshot files.
The path will have to be of the form repldata\unc\pubname_subname\date
(IIRC).
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:hGG3d.1861$DY.760@.chiapp18.algx.net...
> Jeff Hedlund wrote:
> Looking at the FTP server logs, I see errors about 120 second inactivity
> timeouts. So maybe I am having some network congestion/problems.
> Jeff
|||I can use this procedure to manually apply the snapshot But using PUSH
subscriptions? what will be the procedure?
Thanks.
"Hilary Cotter" wrote:

> I would try to zip up the snapshot files and then have the subscriber pull
> them through ftp. Once they arrive at the subscriber, expand them, create a
> pull subscription and then when you get to the specify snapshot location
> select specify directory and browse to the location of the snapshot files.
> The path will have to be of the form repldata\unc\pubname_subname\date
> (IIRC).
>
> "Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
> news:hGG3d.1861$DY.760@.chiapp18.algx.net...
>
>
|||the original poster was using FTP. If you are doing a push you can still
compress your snapshot. If your snapshot is very large you should think
about doing no sync subscriptions, and manually get the data over to the
subscriber.
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
"Adrian320" <Adrian320@.discussions.microsoft.com> wrote in message
news:641144BB-058C-4202-B790-ABCE3BC2D18B@.microsoft.com...[vbcol=seagreen]
> I can use this procedure to manually apply the snapshot But using PUSH
> subscriptions? what will be the procedure?
> Thanks.
> "Hilary Cotter" wrote:
pull[vbcol=seagreen]
create a[vbcol=seagreen]
files.[vbcol=seagreen]
time[vbcol=seagreen]
(though[vbcol=seagreen]
had[vbcol=seagreen]
inactivity[vbcol=seagreen]
|||Ok, so when you do it with FTP you can specify the location, ok.
One more question I have the .bcp files on the subscriber computer. But I
don't know how to run a script to restore that table ('article') to the
subscriber database to then enable the nosync subscription.
Is there a link that you could point me to learn about this? Or can I use
the Restore Database command?
Thanks.
"Hilary Cotter" wrote:

> the original poster was using FTP. If you are doing a push you can still
> compress your snapshot. If your snapshot is very large you should think
> about doing no sync subscriptions, and manually get the data over to the
> subscriber.
> --
> 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
> "Adrian320" <Adrian320@.discussions.microsoft.com> wrote in message
> news:641144BB-058C-4202-B790-ABCE3BC2D18B@.microsoft.com...
> pull
> create a
> files.
> time
> (though
> had
> inactivity
>
>