• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 289
  • Last Modified:

Is Old SQL Server Table Trigger Performance Issue Workaround Still Valid?

I am looking for on-line documentation or moral support!

Years ago, we had a developer that determined we had this problem with our SQL Server 2000 installation:   BUG: UPDATE Trigger May Have Long Parse and Compile Time

So he added the workaround code (line 4 and line 6):
CREATE TRIGGER [dbo].[ti_MtsEHistory] ON [dbo].[MtsEHistory] FOR INSERT AS
BEGIN

DECLARE @InsertedBugWorkAroundtable(EventID int)

	INSERT INTO @InsertedBugWorkAround SELECT EventID FROM inserted 

	-- Set the Created field for any rows being inserted.
	 UPDATE MtsEHistory
	    SET Created = GETDATE(),
		ModifyDateTime = GETDATE()
	   FROM MtsEHistory, inserted
	  WHERE MtsEHistory.EventID = inserted.EventID

END

Open in new window


When I joined the company we were still on SQL Server 2000.  I ran tests by removing the workaround code and could not recreate the performance problem.  

We are now on SQL Server 2008.  Regardless of whether the UPDATE statement in the code above needs refactoring, I need help proving to my supervisor that the workaround is no longer needed.  (He won't take my word for it.)  The MtsEHistory table has millions of row, lots of columns and is one of our most used tables.  It is common sense that any trigger code that doesn't do anything useful should be removed.
0
AEPRTD
Asked:
AEPRTD
1 Solution
 
QuinnDexCommented:
first thing to do is find any other queries Sp's index's etc that reference the InsertedBugWorkAroundtable

removing the code or the whole trigger will only stop that table being updated any tests you did will still be using the table during execution and if its fundamental to the query will not be using new data
0
 
John_VidmarCommented:
The link you provided describes the 4 conditions that must all exist for the problem to occur:
1. The trigger contains an UPDATE statement.
2. The UPDATE statement contains a JOIN clause.
3. Three (3) or more tables are listed in the JOIN clause.
4. Either the INSERTED or DELETED tables are listed in the JOIN clause.

Your trigger does not have 3 or more tables, therefore, no problem.  The workaround (if the problem did exist) was to replace the inserted table with a local table-variable, which was not done (i.e., line 12 should have the table-variable, not inserted).  I would eliminate the table-variable, if anything, its slowing down your trigger.
0
 
AEPRTDAuthor Commented:
I did not realize all four conditions had to exist for the bug to exist.  And as you stated, it wasn't just the act of declaring and populating a table variable that fixed the problem, it was the subsequent use of the table variable in joins that fixed the problem.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now