February 2, 2009 at 10:56 am
Nested triggers means that an update to a table in a trigger can fire triggers on that table, providing it's not the same table. So, say you have Table1 that has an update trigger that inserts into table2. Table2 has an insert trigger that nserts into table3. If nested triggers is on and you update table1, then the trigger on table1 will insert into table2, will fire that trigger and will insert into tbl3. If it's off, the insert trigger on table2 won't fire.
Recursive trigger controls if a trigger may fire itself due to data changes. If it's off, your trigger will not be called due to the updates that it does.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 2, 2009 at 10:59 am
GilaMonster (2/2/2009)
Nested triggers means that an update to a table in a trigger can fire triggers on that table, providing it's not the same table. So, say you have Table1 that has an update trigger that inserts into table2. Table2 has an insert trigger that nserts into table3. If nested triggers is on and you update table1, then the trigger on table1 will insert into table2, will fire that trigger and will insert into tbl3. If it's off, the insert trigger on table2 won't fire.Recursive trigger controls if a trigger may fire itself due to data changes. If it's off, your trigger will not be called due to the updates that it does.
Thanks, so that means I'm OK from that aspect, ie. this trigger will not fire itself repeatedly, since my db setting is off.
That cleared it up.
From http://msdn.microsoft.com/en-us/library/ms190739(SQL.90).aspx
An AFTER trigger does not call itself recursively unless the RECURSIVE_TRIGGERS database option is set.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
February 2, 2009 at 12:45 pm
Other than the ol' trigger-firing-itself-due-to-update-inside-trigger-ploy, 2 other questions:
1) any OTHER triggers on this table?
2) is the join column a primary key or unique index value? Looks like cartesian product if not.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 2, 2009 at 12:50 pm
TheSQLGuru (2/2/2009)
2) is the join column a primary key or unique index value? Looks like cartesian product if not.
Agreed. That's one reason I want see the actual exec plan, see what the row counts really are at various points of the query.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
February 2, 2009 at 1:10 pm
TheSQLGuru (2/2/2009)
Other than the ol' trigger-firing-itself-due-to-update-inside-trigger-ploy, 2 other questions:1) any OTHER triggers on this table?
2) is the join column a primary key or unique index value? Looks like cartesian product if not.
Yes, that's the only trigger on this table.
The join column is a unique clustered primary key.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
February 3, 2009 at 4:24 am
Here is the "actual" exec plan obtained from a server-side trace (see attached).
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
February 3, 2009 at 8:42 am
Marios Philippopoulos (1/31/2009)
I have a trigger that appears to execute a very large number of logical reads; on one occasion it has hit 73,421,728 logical reads!There are two puzzling aspects about this:
(1) Only about 30,000 rows are being updated in the base table (as can be seen in the exec plan)
(2) The dominant operator (86% of total workload) is an index seek on an index that contains a seemingly unrelated column (a column that does not appear anywhere in the trigger body).
I have captured the number of logical reads and the execution plan by polling the sys.dm_db_exec_requests DMV once a minute.
How can such a huge number of logical reads of the trigger be reconciled to the relatively modest number of rows updated in the underlying table?
Given the ACTUAL plan, I can't see what your issues are with the number of reads:
1) The clustered index update is 1.46M rows, NC index update 2.93M rows.
2) You are doing a table scan of 1.46M row inserted and 39.9M row updtable
3) You are hash matching the above
4) then doing a sort of the hash result
No idea where your statement of only updating 30K rows is coming from, but it is irrelevant. THAT query you gave the plan for is a beast and that is all there is to it. 🙂
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
February 3, 2009 at 8:47 am
TheSQLGuru (2/3/2009)
Marios Philippopoulos (1/31/2009)
I have a trigger that appears to execute a very large number of logical reads; on one occasion it has hit 73,421,728 logical reads!There are two puzzling aspects about this:
(1) Only about 30,000 rows are being updated in the base table (as can be seen in the exec plan)
(2) The dominant operator (86% of total workload) is an index seek on an index that contains a seemingly unrelated column (a column that does not appear anywhere in the trigger body).
I have captured the number of logical reads and the execution plan by polling the sys.dm_db_exec_requests DMV once a minute.
How can such a huge number of logical reads of the trigger be reconciled to the relatively modest number of rows updated in the underlying table?
Given the ACTUAL plan, I can't see what your issues are with the number of reads:
1) The clustered index update is 1.46M rows, NC index update 2.93M rows.
2) You are doing a table scan of 1.46M row inserted and 39.9M row updtable
3) You are hash matching the above
4) then doing a sort of the hash result
No idea where your statement of only updating 30K rows is coming from, but it is irrelevant. THAT query you gave the plan for is a beast and that is all there is to it. 🙂
It is a beast, no doubt.
The 30k-record number came from the estimated-plan info, which - clearly - is hugely inaccurate.
The developers have had enough of my whining, and they are eliminating the trigger alltogether.
They will embed the update code directly in the sprocs where the base table is itself updated.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
February 3, 2009 at 12:15 pm
They will embed the update code directly in the sprocs where the base table is itself updated.
WISE decision!
* Noel
Viewing 9 posts - 31 through 38 (of 38 total)
You must be logged in to reply to this topic. Login to reply