Trigger Management and Optimization
Trigger Management and Optimization
Trigger Modifications
Because triggers are objects we can deal with them as we deal with any DB object by deleting or creating and so on.
Deleting A trigger on a table or view
Disabling a trigger
Deleting triggers
Deleting table and view triggers
DROP TRIGGER PreventNewDiscounts;Deleting database level triggers
DROP TRIGGER PreventViewsModifications
ON DATABASE;Deleting server triggers
DROP TRIGGER DisallowLinkedServers
ON ALL SERVER;Disabling triggers
There are some cases when you need just to stop trigger for specific period of time AKA **Disabling" a trigger.
A deleted trigger can never be used again, unless you recreate the trigger.
📘 note
When you need to disable a trigger, you need to explicitly specify the object the trigger is attached to, even if it is a normal table.
Re-enabling triggers
Altering triggers
there are two main approaches for changing triggers after they were created
Create and Drop workflow
using
ALTER
In the first approach, you're going to create the trigger and if something happened and you wish to change it, you DROP the trigger and re-create it. which is something frustrating during development, instead you can ALTER the trigger in time
Trigger Management
To get information about the current triggers you've on your server, we'll explore the sys.triggers table which contains information about the system triggers
this table contains about 13 attributes, but we are going to explore the most important ones.
name
trigger name
object_id
unique identifier of the trigger
parent_class
trigger type - 1 for table trigger - 0 for database trigger
parent_class_desc
textual describe of trigger type
parent_id
unique identifier of the parent object that trigger is attached to
create_date
date of creation
modify_date
date of last modifications
is_disabled
current state
is_instead_of_trigger
INSTEAD OF or AFTER trigger
If you want to know the sever level triggers
the table will have the same structure as the databsase triggers level with the same information
What if you need to identify the events that will fire a trigger ?
this information is stored in sys.trigger_events
you don't need to memorize all of the events that will fire the triggers, they are contained in sys.trigger_event_types
the problem here is that the information is divided into many tables, if you want to form a good answer
"list the trigger along with their firing events and object they're attatched to" we need to join the tables together
note: the second join is chosedn to be a LEFT join beause database-level triggers do not appear as attached to an object
In real-world you'll not use those views in isolation, they usually combined together to get a useful information
Practice Time
troubleshooting Triggers
Keep a history of triggers runs
how to search for triggeers causing issues
Tracking Trigger Exectuins (system views)
one important thing to keep on mind when troubleshooting triggers is to have a history of their execution
note: SQL Server provides information on the execution of the triggers that are currently stored in memory, so when the triggers are removed from memory they areremoved from the view as well sys.dm_exec_trigger_stats
so how to get around this problem? by creating our custom solution
This will raise an error, but also we got a **permenant record that we can use to track the history of triggers runs
How can we identify the triggers on a certain table or view? using sys.objects table which contains information about the objects on the database.
Products
123
Then
To identify the events capable of firing a trigger, we'lljoin to the sys.trigger_events also
if we want to further view also the trigger definiton, we'll use OBJECT_DEFINITION() method which return the definintion for an object Id passed as an argument
now you can inspect and modify the trigger definintion if needed
Practice Time
Resources
Last updated