Article ID: 309182 - Last Review: December 13, 2005 - Revision: 4.1 Slow DELETE or UPDATE against non-SQL linked serverThis article was previously published under Q309182 SYMPTOMS
UPDATE or DELETE statements that act against a remote table that resides on a non-SQL Server data source, may run much slower than an equivalent SELECT statement.
CAUSE
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 SET SHOWPLAN ON output may look something similar to this plan:
|--Remote Delete(SOURCE:(remserver), OBJECT:("".""."titles"))
|--Table Spool
|--Filter(WHERE:([remserver]...[titles].[royalty]=10))
|--Remote Scan(SOURCE:(remserver), OBJECT:("".""."titles"))
|--Remote Query(SOURCE:(remserver), QUERY:(DELETE "".""."titles" FROM "".""."titles" Tbl1001 WHERE Tbl1001."royalty"=(10)))
MORE INFORMATION
Before you decide that this behavior is the cause of a performance issue, confirm that the performance problem is specific to a data modification statement by converting the UPDATE or DELETE query into a comparable SELECT against the remote table. For example, if the query is:
You cannot use the OPENQUERY function for DELETEs or UPDATEs; OPENQUERY is designed to send a read-only command that returns a result set. As mentioned earlier, the ability to remote certain multi-row UPDATE or DELETE statements as a single SQL query to a linked server only exists in SQL Server 2000. If the local (originating) instance is a SQL Server 7.0 server and if the destination instance is also a SQL Server 7.0 or SQL Server 2000 server, you can execute a multi-row UPDATE or DELETE statement entirely on the remote server with one of the following alternatives:
| Article Translations
|

Back to the top
