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.

  1. Deleting A trigger on a table or view

  2. 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

  1. Create and Drop workflow

  2. 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
role

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.

TableName
TableID

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