|
|
You're in the
sql server programming
group:Transactional Repl
sql server programming:
This should be ok, but ideally you should size this according to the largest size of your text data. Replicating text data does take some time, so what you are seeing might be normal. Also check and see if replicating the execution of stored procedures will work for you. This might work better than replicating pure text. Regarding the deadlocks, run profiler or run sp_who2 on the subscribers to see what process is causing the locking. -- 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] "Yaniv" <yanive@rediffmail.com> wrote in message news:ujN4q3WCGHA.228@TK2MSFTNGP12.phx.gbl... > Hi, > > I recently updated an ntext column on a Publisher server and then found > that the data is replicated very slow, that is in the following days a few > more rows were added /replicated to the Pull Subscriber every day. > > sp_configure shows the following output for the max text repl size: > max text repl size (B) 0 2147483647 2147483647 2147483647 > --------- > > In addition I have directed some reports to the Pull Subscriber (for load > balancing purpose) and faced some deadloacks which I have not investigated > yet. But I would like to point that I never face those deadlocks with the > same Reports on my main server before I directed them to the replicated > data . > > Is there any known issue with queries against Subscribers? > > > > Thanks, > Yaniv >
Hi,
I recently updated an ntext column on a Publisher server and then found that the data is replicated very slow, that is in the following days a few more rows were added /replicated to the Pull Subscriber every day. sp_configure shows the following output for the max text repl size: max text repl size (B) 0 2147483647 2147483647 2147483647 --------- In addition I have directed some reports to the Pull Subscriber (for load balancing purpose) and faced some deadloacks which I have not investigated yet. But I would like to point that I never face those deadlocks with the same Reports on my main server before I directed them to the replicated data .. Is there any known issue with queries against Subscribers? Thanks, Yaniv
Unfortunately this is a limitation with Transactional Replication. If at all
possibly use another mechanism to keep the tables in sync. For instance remove the text column from your table article and use ADO or DTS to push it over. This will only work if you do not need real time synchronization. -- 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] "Yaniv" <yanive@rediffmail.com> wrote in message news:%23ueKN5eCGHA.740@TK2MSFTNGP12.phx.gbl... > > I know I have configured repl for the max possible size. But if the text > column contains a string with let's say a LEN of 200 chars then 200 chars > needed to be replicated and not 2GB. > > I do know the long delay relates to the data type because other updates > not involved with text /ntext do not take long to be replicated. > > > Yaniv > > > ============= > "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message > news:uJ0y2VZCGHA.3292@TK2MSFTNGP09.phx.gbl... >> It looks like you have configured replication to replicate a max of 2 >> Gigs! >> >> This should be ok, but ideally you should size this according to the >> largest size of your text data. >> >> Replicating text data does take some time, so what you are seeing might >> be normal. Also check and see if replicating the execution of stored >> procedures will work for you. This might work better than replicating >> pure text. >> >> Regarding the deadlocks, run profiler or run sp_who2 on the subscribers >> to see what process is causing the locking. >> >> -- >> 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 >> >> "Yaniv" <yanive@rediffmail.com> wrote in message >> news:ujN4q3WCGHA.228@TK2MSFTNGP12.phx.gbl... >>> Hi, >>> >>> I recently updated an ntext column on a Publisher server and then found >>> that the data is replicated very slow, that is in the following days a >>> few more rows were added /replicated to the Pull Subscriber every day. >>> >>> sp_configure shows the following output for the max text repl size: >>> max text repl size (B) 0 2147483647 2147483647 2147483647 >>> --------- >>> >>> In addition I have directed some reports to the Pull Subscriber (for >>> load balancing purpose) and faced some deadloacks which I have not >>> investigated yet. But I would like to point that I never face those >>> deadlocks with the same Reports on my main server before I directed them >>> to the replicated data . >>> >>> Is there any known issue with queries against Subscribers? >>> >>> >>> >>> Thanks, >>> Yaniv >>> >> >> > >
I know I have configured repl for the max possible size. But if the text column contains a string with let's say a LEN of 200 chars then 200 chars needed to be replicated and not 2GB. I do know the long delay relates to the data type because other updates not involved with text /ntext do not take long to be replicated. Yaniv ============= [quoted text, click to view] "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message news:uJ0y2VZCGHA.3292@TK2MSFTNGP09.phx.gbl... > It looks like you have configured replication to replicate a max of 2 > Gigs! > > This should be ok, but ideally you should size this according to the > largest size of your text data. > > Replicating text data does take some time, so what you are seeing might be > normal. Also check and see if replicating the execution of stored > procedures will work for you. This might work better than replicating pure > text. > > Regarding the deadlocks, run profiler or run sp_who2 on the subscribers to > see what process is causing the locking. > > -- > 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 > > "Yaniv" <yanive@rediffmail.com> wrote in message > news:ujN4q3WCGHA.228@TK2MSFTNGP12.phx.gbl... >> Hi, >> >> I recently updated an ntext column on a Publisher server and then found >> that the data is replicated very slow, that is in the following days a >> few more rows were added /replicated to the Pull Subscriber every day. >> >> sp_configure shows the following output for the max text repl size: >> max text repl size (B) 0 2147483647 2147483647 2147483647 >> --------- >> >> In addition I have directed some reports to the Pull Subscriber (for load >> balancing purpose) and faced some deadloacks which I have not >> investigated yet. But I would like to point that I never face those >> deadlocks with the same Reports on my main server before I directed them >> to the replicated data . >> >> Is there any known issue with queries against Subscribers? >> >> >> >> Thanks, >> Yaniv >> > >
You can replicate the execution of a stored procedure. Suppose the text DML
which occurs on your publisher occurs as the result of a store procedure, sort of like this p_MyProc @textdata ='In the beginning I was very small, the doctor slapped my mother and not me. My father was anxious to change me; but little did I know what he meant." It is possible to replicate the proc so it fires on both sides (the publisher and subscriber) with the same parameters and values. This can offer better performance than replicating the actual underlying DML. -- 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] "yanive" <yanive@rediffmail.com> wrote in message news:OEQAWWkCGHA.216@TK2MSFTNGP15.phx.gbl... > Hilary, I did not understand what you mean by that: > Also check and see if replicating the execution of stored procedures > will work for you. This might work better than replicating pure text. > > > Yaniv > ====== > > > "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message > news:uJ0y2VZCGHA.3292@TK2MSFTNGP09.phx.gbl... >> It looks like you have configured replication to replicate a max of 2 >> Gigs! >> >> This should be ok, but ideally you should size this according to the >> largest size of your text data. >> >> Replicating text data does take some time, so what you are seeing might >> be normal. Also check and see if replicating the execution of stored >> procedures will work for you. This might work better than replicating >> pure text. >> >> Regarding the deadlocks, run profiler or run sp_who2 on the subscribers >> to see what process is causing the locking. >> >> -- >> 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 >> >> "Yaniv" <yanive@rediffmail.com> wrote in message >> news:ujN4q3WCGHA.228@TK2MSFTNGP12.phx.gbl... >>> Hi, >>> >>> I recently updated an ntext column on a Publisher server and then found >>> that the data is replicated very slow, that is in the following days a >>> few more rows were added /replicated to the Pull Subscriber every day. >>> >>> sp_configure shows the following output for the max text repl size: >>> max text repl size (B) 0 2147483647 2147483647 2147483647 >>> --------- >>> >>> In addition I have directed some reports to the Pull Subscriber (for >>> load balancing purpose) and faced some deadloacks which I have not >>> investigated yet. But I would like to point that I never face those >>> deadlocks with the same Reports on my main server before I directed them >>> to the replicated data . >>> >>> Is there any known issue with queries against Subscribers? >>> >>> >>> >>> Thanks, >>> Yaniv >>> >> >> > >
Thanks for your reply.
Yaniv =============== [quoted text, click to view] "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message news:OHm9p4hCGHA.744@TK2MSFTNGP10.phx.gbl... > Unfortunately this is a limitation with Transactional Replication. If at > all possibly use another mechanism to keep the tables in sync. For > instance remove the text column from your table article and use ADO or DTS > to push it over. This will only work if you do not need real time > synchronization. > > -- > 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 > > "Yaniv" <yanive@rediffmail.com> wrote in message > news:%23ueKN5eCGHA.740@TK2MSFTNGP12.phx.gbl... >> >> I know I have configured repl for the max possible size. But if the text >> column contains a string with let's say a LEN of 200 chars then 200 chars >> needed to be replicated and not 2GB. >> >> I do know the long delay relates to the data type because other updates >> not involved with text /ntext do not take long to be replicated. >> >> >> Yaniv >> >> >> ============= >> "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message >> news:uJ0y2VZCGHA.3292@TK2MSFTNGP09.phx.gbl... >>> It looks like you have configured replication to replicate a max of 2 >>> Gigs! >>> >>> This should be ok, but ideally you should size this according to the >>> largest size of your text data. >>> >>> Replicating text data does take some time, so what you are seeing might >>> be normal. Also check and see if replicating the execution of stored >>> procedures will work for you. This might work better than replicating >>> pure text. >>> >>> Regarding the deadlocks, run profiler or run sp_who2 on the subscribers >>> to see what process is causing the locking. >>> >>> -- >>> 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 >>> >>> "Yaniv" <yanive@rediffmail.com> wrote in message >>> news:ujN4q3WCGHA.228@TK2MSFTNGP12.phx.gbl... >>>> Hi, >>>> >>>> I recently updated an ntext column on a Publisher server and then found >>>> that the data is replicated very slow, that is in the following days a >>>> few more rows were added /replicated to the Pull Subscriber every day. >>>> >>>> sp_configure shows the following output for the max text repl size: >>>> max text repl size (B) 0 2147483647 2147483647 2147483647 >>>> --------- >>>> >>>> In addition I have directed some reports to the Pull Subscriber (for >>>> load balancing purpose) and faced some deadloacks which I have not >>>> investigated yet. But I would like to point that I never face those >>>> deadlocks with the same Reports on my main server before I directed >>>> them to the replicated data . >>>> >>>> Is there any known issue with queries against Subscribers? >>>> >>>> >>>> >>>> Thanks, >>>> Yaniv >>>> >>> >>> >> >> > >
Hilary, I did not understand what you mean by that:
Also check and see if replicating the execution of stored procedures will work for you. This might work better than replicating pure text. Yaniv ====== [quoted text, click to view] "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message news:uJ0y2VZCGHA.3292@TK2MSFTNGP09.phx.gbl... > It looks like you have configured replication to replicate a max of 2 > Gigs! > > This should be ok, but ideally you should size this according to the > largest size of your text data. > > Replicating text data does take some time, so what you are seeing might be > normal. Also check and see if replicating the execution of stored > procedures will work for you. This might work better than replicating pure > text. > > Regarding the deadlocks, run profiler or run sp_who2 on the subscribers to > see what process is causing the locking. > > -- > 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 > > "Yaniv" <yanive@rediffmail.com> wrote in message > news:ujN4q3WCGHA.228@TK2MSFTNGP12.phx.gbl... >> Hi, >> >> I recently updated an ntext column on a Publisher server and then found >> that the data is replicated very slow, that is in the following days a >> few more rows were added /replicated to the Pull Subscriber every day. >> >> sp_configure shows the following output for the max text repl size: >> max text repl size (B) 0 2147483647 2147483647 2147483647 >> --------- >> >> In addition I have directed some reports to the Pull Subscriber (for load >> balancing purpose) and faced some deadloacks which I have not >> investigated yet. But I would like to point that I never face those >> deadlocks with the same Reports on my main server before I directed them >> to the replicated data . >> >> Is there any known issue with queries against Subscribers? >> >> >> >> Thanks, >> Yaniv >> > >
Got you, thanks.
=========== [quoted text, click to view] "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message news:%232bm28kCGHA.3856@TK2MSFTNGP12.phx.gbl... > You can replicate the execution of a stored procedure. Suppose the text > DML which occurs on your publisher occurs as the result of a store > procedure, sort of like this > > p_MyProc @textdata ='In the beginning I was very small, the doctor slapped > my mother and not me. My father was anxious to change me; but little did I > know what he meant." > > It is possible to replicate the proc so it fires on both sides (the > publisher and subscriber) with the same parameters and values. > > This can offer better performance than replicating the actual underlying > DML. > > -- > 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 > > "yanive" <yanive@rediffmail.com> wrote in message > news:OEQAWWkCGHA.216@TK2MSFTNGP15.phx.gbl... >> Hilary, I did not understand what you mean by that: >> Also check and see if replicating the execution of stored procedures >> will work for you. This might work better than replicating pure text. >> >> >> Yaniv >> ====== >> >> >> "Hilary Cotter" <hilary.cotter@gmail.com> wrote in message >> news:uJ0y2VZCGHA.3292@TK2MSFTNGP09.phx.gbl... >>> It looks like you have configured replication to replicate a max of 2 >>> Gigs! >>> >>> This should be ok, but ideally you should size this according to the >>> largest size of your text data. >>> >>> Replicating text data does take some time, so what you are seeing might >>> be normal. Also check and see if replicating the execution of stored >>> procedures will work for you. This might work better than replicating >>> pure text. >>> >>> Regarding the deadlocks, run profiler or run sp_who2 on the subscribers >>> to see what process is causing the locking. >>> >>> -- >>> 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 >>> >>> "Yaniv" <yanive@rediffmail.com> wrote in message >>> news:ujN4q3WCGHA.228@TK2MSFTNGP12.phx.gbl... >>>> Hi, >>>> >>>> I recently updated an ntext column on a Publisher server and then found >>>> that the data is replicated very slow, that is in the following days a >>>> few more rows were added /replicated to the Pull Subscriber every day. >>>> >>>> sp_configure shows the following output for the max text repl size: >>>> max text repl size (B) 0 2147483647 2147483647 2147483647 >>>> --------- >>>> >>>> In addition I have directed some reports to the Pull Subscriber (for >>>> load balancing purpose) and faced some deadloacks which I have not >>>> investigated yet. But I would like to point that I never face those >>>> deadlocks with the same Reports on my main server before I directed >>>> them to the replicated data . >>>> >>>> Is there any known issue with queries against Subscribers? >>>> >>>> >>>> >>>> Thanks, >>>> Yaniv >>>> >>> >>> >> >> > >
Don't see what you're looking for? Try a search.
|
January 2003
March 2003
April 2003
May 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
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |