|
|
You're in the
sql server replication
group:general network error
sql server replication:
subscriptions are getting errors: The process could not query row metadata at the subscriber. (source merge replication provider (agent): error number -217200996 General network error: check your network documentation I turned on logging and everything is fine until: [1/31/2007 4:26:58 AM]subscribeDB: {call sp_MSgetversion } The process could not query row metadata at the 'Subscriber'. The process could not enumerate changes at the 'Publisher'. The merge process encountered an unexpected network error. The connection to Subscriber 'subscribeDB' is no longer available. Percent Complete: 0 The process could not query row metadata at the 'Subscriber'. Percent Complete: 0 Category:NULL Source: Merge Replication Provider Number: -2147200996 Message: The process could not query row metadata at the 'Subscriber'. Percent Complete: 0 Category:COMMAND Source: Failed Command Number: 0 Message: {call sp_MSgetmetadatabatch(?,?,?)} Percent Complete: 0 Category:SQLSERVER Source: subscribeDB Number: 11 Message: General network error. Check your network documentation. Percent Complete: 0 Category:NULL Source: Merge Replication Provider Number: -2147200999 Message: The process was successfully stopped. I know the general network error is a catch-all. I have done Hilary's keepalive and it never seems to fail. I have done a checkdb and checkdb w/ rebuild_repair and that has made no difference. One subscriber has had no problems, two started failing on Friday. Any help would be greatly appreciated. Thanks. Darin
Yes everything is current on all servers regarding the OS and SQL
programs. Darin
FWIW, GNEs are almost always indicative of a hardware (switch, NIC, cable)
or driver error. Not 100%, but pretty close in my experience. Are your SQL Servers and MDACs current? Can you see anything in a Netmon trace run from both machines? -- Kevin Hill 3NF Consulting http://www.3nf-inc.com/NewsGroups.htm Real-world stuff I run across with SQL Server: http://kevin3nf.blogspot.com [quoted text, click to view] "Darin" <darin_nospam@nospamever> wrote in message news:u0TlpZTRHHA.1228@TK2MSFTNGP06.phx.gbl... >I have a publisher that has worked for months. Now, two of the three > subscriptions are getting errors: > > The process could not query row metadata at the subscriber. > (source merge replication provider (agent): error number -217200996 > > General network error: check your network documentation > > I turned on logging and everything is fine until: > > [1/31/2007 4:26:58 AM]subscribeDB: {call sp_MSgetversion } > The process could not query row metadata at the 'Subscriber'. > The process could not enumerate changes at the 'Publisher'. > The merge process encountered an unexpected network error. The > connection to Subscriber 'subscribeDB' is no longer available. > Percent Complete: 0 > The process could not query row metadata at the 'Subscriber'. > Percent Complete: 0 > Category:NULL > Source: Merge Replication Provider > Number: -2147200996 > Message: The process could not query row metadata at the 'Subscriber'. > Percent Complete: 0 > Category:COMMAND > Source: Failed Command > Number: 0 > Message: {call sp_MSgetmetadatabatch(?,?,?)} > Percent Complete: 0 > Category:SQLSERVER > Source: subscribeDB > Number: 11 > Message: General network error. Check your network documentation. > Percent Complete: 0 > Category:NULL > Source: Merge Replication Provider > Number: -2147200999 > Message: The process was successfully stopped. > > > I know the general network error is a catch-all. I have done Hilary's > keepalive and it never seems to fail. I have done a checkdb and checkdb > w/ rebuild_repair and that has made no difference. One subscriber has > had no problems, two started failing on Friday. > > Any help would be greatly appreciated. > > Thanks. > > Darin > > *** Sent via Developersdex http://www.developersdex.com ***
Hi,
Dont take this the wrong way but I had this error and found that my broadband had a fault on the line. I blamed the server for weeks and spent hours trying this and that but it was the link between my servers blipping out that was causing the problem. Just a thought!. [quoted text, click to view] "Darin" wrote:
> Yes everything is current on all servers regarding the OS and SQL > programs. > > Darin > > *** Sent via Developersdex http://www.developersdex.com ***
If my keepalive script (which doesn't really keep anything alive unless you
have a router which will shut down automatically when it senses no traffic) reveals no network problems, it probably is a timeout issue. Change querytimeout to something larger. You can also run a ping -t and watch for dropped packets which just indicates the line going down. replication is normally resilient to lossy lines. -- 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 [quoted text, click to view] "Darin" <darin_nospam@nospamever> wrote in message news:u0TlpZTRHHA.1228@TK2MSFTNGP06.phx.gbl... >I have a publisher that has worked for months. Now, two of the three > subscriptions are getting errors: > > The process could not query row metadata at the subscriber. > (source merge replication provider (agent): error number -217200996 > > General network error: check your network documentation > > I turned on logging and everything is fine until: > > [1/31/2007 4:26:58 AM]subscribeDB: {call sp_MSgetversion } > The process could not query row metadata at the 'Subscriber'. > The process could not enumerate changes at the 'Publisher'. > The merge process encountered an unexpected network error. The > connection to Subscriber 'subscribeDB' is no longer available. > Percent Complete: 0 > The process could not query row metadata at the 'Subscriber'. > Percent Complete: 0 > Category:NULL > Source: Merge Replication Provider > Number: -2147200996 > Message: The process could not query row metadata at the 'Subscriber'. > Percent Complete: 0 > Category:COMMAND > Source: Failed Command > Number: 0 > Message: {call sp_MSgetmetadatabatch(?,?,?)} > Percent Complete: 0 > Category:SQLSERVER > Source: subscribeDB > Number: 11 > Message: General network error. Check your network documentation. > Percent Complete: 0 > Category:NULL > Source: Merge Replication Provider > Number: -2147200999 > Message: The process was successfully stopped. > > > I know the general network error is a catch-all. I have done Hilary's > keepalive and it never seems to fail. I have done a checkdb and checkdb > w/ rebuild_repair and that has made no difference. One subscriber has > had no problems, two started failing on Friday. > > Any help would be greatly appreciated. > > Thanks. > > Darin > > *** Sent via Developersdex http://www.developersdex.com ***
I am still getting the general network failure, and I agree that it is
the network. Unfortunitly, the ISP says the lines are fine, so we are all pointing fingers at eachother. I can open QA and connect to the remote server from the publisher fine, and acctually issue SELECT statements. So, what I am thinking is if I can get the replication to go in very small bursts it might have better success. So, I am playing w/ the profile. I have am using one I created that has: bcpbatchsize=100000 changesperhistory 20 destthreads 4 the next 3 download all 20 fastrowcount 1 historyverboselevel 1 keepalive 300 logintimeout 15 maxdownload & maxupload 20 metadataretention 1 numdeadlockretries 25 pollinginternal 60 querytimout 600 srcthreads 3 startqueuetimout 0 3 uploads 20 validate 0 validateinterval 60 These settings haven't made any difference. I am still getting the errors: the process could not deliver inserts at the subscriber general network error the merge process encountered an unexpected network error. The connection to the subscriber is no longer available. 2 of the 3 subscribers have errors, the third subscriber works perfectly. Can anyone think of any settings in the profile that might help "slow-down" the replication so it will try more and wait longer and send small bursts only? Thanks - this is getting very important as it has been messed up for a week. THanks. Darin
Run tracert in conjunction with ping -t, or use pingplotter to display an
image of your connectivity problems with them. You might also want to try to run continuous pings against devices within the hosted environment. It could be a switch or network card. -- 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 [quoted text, click to view] "Darin" <darin_nospam@nospamever> wrote in message news:u$J6Oo6RHHA.4276@TK2MSFTNGP02.phx.gbl... >I am still getting the general network failure, and I agree that it is > the network. Unfortunitly, the ISP says the lines are fine, so we are > all pointing fingers at eachother. > > I can open QA and connect to the remote server from the publisher fine, > and acctually issue SELECT statements. So, what I am thinking is if I > can get the replication to go in very small bursts it might have better > success. So, I am playing w/ the profile. I have am using one I created > that has: > > bcpbatchsize=100000 > changesperhistory 20 > destthreads 4 > the next 3 download all 20 > fastrowcount 1 > historyverboselevel 1 > keepalive 300 > logintimeout 15 > maxdownload & maxupload 20 > metadataretention 1 > numdeadlockretries 25 > pollinginternal 60 > querytimout 600 > srcthreads 3 > startqueuetimout 0 > 3 uploads 20 > validate 0 > validateinterval 60 > > These settings haven't made any difference. I am still getting the > errors: > > the process could not deliver inserts at the subscriber > general network error > the merge process encountered an unexpected network error. The > connection to the subscriber is no longer available. > > 2 of the 3 subscribers have errors, the third subscriber works > perfectly. Can anyone think of any settings in the profile that might > help "slow-down" the replication so it will try more and wait longer and > send small bursts only? > > Thanks - this is getting very important as it has been messed up for a > week. > > THanks. > > Darin > > *** Sent via Developersdex http://www.developersdex.com ***
Just to let everyone know what the issue was. It was a netowrk issue
caused by a worm that got on their system. Darin
Don't see what you're looking for? Try a search.
|
April 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |