By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,365 Members | 1,387 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,365 IT Pros & Developers. It's quick & easy.

Remote Database updates take long time to complete

P: n/a
Hi
I have have two linked SQL Servers and I am trying to get remote writes
working correctly (fast).

I have configured the DB link on both machines to:
Point at each others DB.
I have security set up to map each others server logins
and Server Options: Collation Compatible, Data Access, RPC, RPC Out, Use
Remote Collation all checked
My problem is that when a SP performs

Begin Transaction

Update Local Table

Update Remote Table

Commit Tran

It takes several seconds to complete. (about 7 seconds not acceptable to
us)
This is due to the remote update - how can I improve the response time?

example of a stored procedures that takes time

where ACSMSM is a remote (linked) SQL Server.

procedure [psm].ams_Update_VFE
@strResult varchar(8) = 'Failure' output,
@strErrorDesc varchar(512) = 'SP Not Executed' output,
@strVFEID varchar(16),
@strDescription varchar(64),
@strVFEVirtualRoot varchar(255),
@strVFEPhysicalRoot varchar(255),
@strAuditPath varchar(255),
@strDefaultBranding varchar(16),
@strIPAddress varchar(23)
as
declare @strStep varchar(32)
declare @trancount int

Set XACT_ABORT ON
set @trancount = @@trancount
set @strStep = 'Start of Stored Proc'

if (@trancount = 0)
BEGIN TRANSACTION mytran
else
save tran mytran

/* start insert sp code here */

set @strStep = 'Write VFE to MSM'

update
ACSMSM.msmprim.msm.VFECONFIG
set
DESCRIPTION = @strDescription,
VFEVIRTUALROOT = @strVFEVirtualRoot,
VFEPHYSICALROOT = @strVFEPhysicalRoot,
AUDITPATH = @strAuditPath,
DEFAULTBRANDING = @strDefaultBranding,
IPADDRESS = @strIPAddress
where
VFEID = @strVFEID;

set @strStep = 'Write VFE to PSM'

update
ACSPSM.psmprim.psm.VFECONFIG
set
DESCRIPTION = @strDescription,
VFEVIRTUALROOT = @strVFEVirtualRoot,
VFEPHYSICALROOT = @strVFEPhysicalRoot,
AUDITPATH = @strAuditPath,
DEFAULTBRANDING = @strDefaultBranding,
IPADDRESS = @strIPAddress
where
VFEID = @strVFEID

/* end insert sp code here */

if (@@error <> 0)
begin
rollback tran mytran
set @strResult = 'Failure'
set @strErrorDesc = 'Fail @ Step :' + @strStep + ' Error : ' + @@Error
return -1969
end
else
begin
set @strResult = 'Success'
set @strErrorDesc = ''
end
-- commit tran if we started it

if (@trancount = 0)
commit tran

return 0



Jul 20 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Steve Thorpe (st***********@nospam.hotmail.com) writes:
It takes several seconds to complete. (about 7 seconds not acceptable to
us)
This is due to the remote update - how can I improve the response time?


Have you tried moving the updates of the remote table to a stored
procedures that runs on the remote server, and then call that stored
procedure remotely? I would expect that to reduce the ping-pong over
the network.
--
Erland Sommarskog, SQL Server MVP, so****@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
Jul 20 '05 #2

P: n/a
I have found the cause of the problem:

'For linked server DELETEs or UPDATEs, SQL Server retrieves data from the
table, performs any filtering that is necessary, and then performs the
deletes or updates through the OLEDB rowset. This processing can result in a
round-trip to the remote server for each row that is to be deleted or
updated. '

The solution is:

EXEC remserver.master.dbo.sp_executesql
@stmt = N'DELETE sometable WHERE col1 = 10 OR col1 = 20'

EXEC localserver.master.dbo.sp_executesql
@stmt = N'DELETE sometable WHERE col1 = 10 OR col1 = 20'

"Erland Sommarskog" <so****@algonet.se> wrote in message
news:Xn*********************@127.0.0.1...
Steve Thorpe (st***********@nospam.hotmail.com) writes:
It takes several seconds to complete. (about 7 seconds not acceptable to us)
This is due to the remote update - how can I improve the response time?


Have you tried moving the updates of the remote table to a stored
procedures that runs on the remote server, and then call that stored
procedure remotely? I would expect that to reduce the ping-pong over
the network.
--
Erland Sommarskog, SQL Server MVP, so****@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Jul 20 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.