Sql ms триггер: MS SQL Server и T-SQL

Создание триггеров DML — SQL Server






Twitter




LinkedIn




Facebook




Адрес электронной почты










  • Статья



Применимо к:база данныхSQL Server Azure SQL Управляемый экземпляр SQL Azure

В этом разделе описывается создание триггера DML Transact-SQL с помощью SQL Server Management Studio и инструкции Transact-SQL CREATE TRIGGER.

Перед началом

Ограничения

Список ограничений, связанных с созданием триггеров DML, см. в разделе CREATE TRIGGER (Transact-SQL).

Разрешения

Требует разрешения ALTER на таблицу или представление, на которых создается триггер.

Как создать триггер DML

Можно использовать один из следующих способов:

  • Среда SQL Server Management Studio

  • Transact-SQL

Использование среды SQL Server Management Studio

  1. В обозревателе объектовподключитесь к экземпляру компонента Компонент Database Engine и разверните его.

  2. Разверните узел Базы данных, разверните базу данных AdventureWorks2022 , разверните узел Таблицы , а затем таблицу Purchasing.PurchaseOrderHeader.

  3. Правой кнопкой мыши щелкните элемент Триггеры, а затем выберите пункт Создать триггер.

  4. В меню Запрос выберите пункт Указать значения для параметров шаблона. Можно также нажать клавиши CTRL-SHIFT-M, чтобы открыть диалоговое окно Задание значений для параметров шаблона .

  5. В диалоговом окне Задание значений для параметров шаблона введите для показанных параметров следующие значения.

    ПараметрЗначение
    АвторВаше имя
    Дата созданияСегодняшняя дата
    ОписаниеПроверяет кредитоспособность поставщика, прежде чем позволить вставить новый заказ на покупку от этого поставщика.
    Имя_схемыПокупка
    Имя_триггераNewPODetail2
    Имя_таблицыPurchaseOrderDetail
    Команда_изменения_данныхУдаление инструкций UPDATE и DELETE из списка.
  6. Нажмите кнопку ОК.

  7. В редакторе запросовзамените комментарий -- Insert statements for trigger here следующей инструкцией:

    IF @@ROWCOUNT = 1  
    BEGIN  
       UPDATE Purchasing. PurchaseOrderHeader  
       SET SubTotal = SubTotal + LineTotal  
       FROM inserted  
       WHERE PurchaseOrderHeader.PurchaseOrderID = inserted.PurchaseOrderID  
    END  
    ELSE  
    BEGIN  
          UPDATE Purchasing.PurchaseOrderHeader  
       SET SubTotal = SubTotal +   
          (SELECT SUM(LineTotal)  
          FROM inserted  
          WHERE PurchaseOrderHeader.PurchaseOrderID  
           = inserted.PurchaseOrderID)  
       WHERE PurchaseOrderHeader.PurchaseOrderID IN  
          (SELECT PurchaseOrderID FROM inserted)  
    END;  
    
  8. Чтобы проверить синтаксис, в меню Запрос выберите пункт Синтаксический анализ. Если появится сообщение об ошибке, сравните эту инструкцию с вышеуказанной информацией, внесите исправления и повторите этот шаг.

  9. Чтобы создать триггер DML, в меню Запрос нажмите Выполнить. Триггер DML создается как объект в базе данных.

  10. Чтобы увидеть этот триггер DML в обозревателе объектов, щелкните правой кнопкой мыши элемент Триггеры и выберите пункт Обновить.

Перед началом

Использование Transact-SQL

  1. В обозревателе объектовподключитесь к экземпляру компонента Компонент Database Engine и разверните его.

  2. В меню Файл выберите пункт Создать запрос.

  3. Скопируйте следующий пример в окно запроса и нажмите кнопку Выполнить. В этом примере создается такой же хранимый триггер DML, как показано выше.

    -- Trigger valid for multirow and single row inserts  
    -- and optimal for single row inserts.  
    USE AdventureWorks2012;  
    GO  
    CREATE TRIGGER NewPODetail3  
    ON Purchasing.PurchaseOrderDetail  
    FOR INSERT AS  
    IF @@ROWCOUNT = 1  
    BEGIN  
       UPDATE Purchasing.PurchaseOrderHeader  
       SET SubTotal = SubTotal + LineTotal  
       FROM inserted  
       WHERE PurchaseOrderHeader.PurchaseOrderID = inserted.PurchaseOrderID  
    END  
    ELSE  
    BEGIN  
          UPDATE Purchasing.PurchaseOrderHeader  
       SET SubTotal = SubTotal +   
          (SELECT SUM(LineTotal)  
          FROM inserted  
          WHERE PurchaseOrderHeader. PurchaseOrderID  
           = inserted.PurchaseOrderID)  
       WHERE PurchaseOrderHeader.PurchaseOrderID IN  
          (SELECT PurchaseOrderID FROM inserted)  
    END;  
    






Заметки Дмитрия Пилюгина о Microsoft SQL Server

Несколько раз встречал подобные вопросы в форумах. Задача, формулируется примерно так. Получить в триггере текст команды, которая привела к тому, что этот триггер сработал.

Это может быть полезно если мы, например, хотим увидеть/залогировать конкретный запрос, который привел к изменению данных. Сразу скажу, что штатный механизм для обеспечения этого на сегодняшний день, в версиях 2000, 2005, 2008 — не предусмотрен. Но тем не менее, что-то похожее можно реализовать с некоторыми ограничениями.

В этом нам поможет команда DBCC INPUTBUFFER. В отличии от fn_get_sql и, появившейся в 2005, sys.dm_exec_sql_text, которые вернули бы текст самого триггера, DBCC INPUTBUFFER — вернет последнюю инструкцию, отправленную серверу, в которой будет весь текст пакета.

Для того чтобы иметь возможность записать данные, возвращаемые DBCC, воспользуемся маленькой хитростью, при помощи динамического sql, обернем выполнение этой команды в вызов хранимой процедуры и запишем результат процедуры во временную таблицу, пользуясь синтаксисом insert … exec.
В итоге, выглядит это все так:

/*
создаем тестовые таблицы, одну - которую будем логировать,
вторую - в которую будем писать лог
*/
if object_id('dbo.TriggerTable') is not null drop table dbo.TriggerTable
if object_id('dbo.LogTable') is not null drop table dbo.LogTable
create table dbo.TriggerTable( field int )
create table dbo.LogTable( field nvarchar(4000) )

/*создаем триггер на вставку*/
go
create trigger TriggerTable_insert on  dbo.TriggerTable after insert as
begin
	set nocount on;

	declare @temp table(EventType nvarchar (30), Parameters int, EventInfo nvarchar(4000) )
	insert into @temp
	exec sp_executesql N'DBCC inputbuffer (@@spid) WITH NO_INFOMSGS'

	insert into dbo. LogTable
	select EventInfo from @temp

end

/* добавляем значения */
go
insert into dbo.TriggerTable values (1)
go
insert into dbo.TriggerTable values (2)
go

/* проверяем что записалось в лог */
select * from dbo.LogTable
go

/* удаляем тестовые таблицы */
drop table dbo.LogTable
drop table dbo.TriggerTable
go

результат:

field
----------------------------------------
insert into dbo.TriggerTable values (1)
insert into dbo.TriggerTable values (2)
(2 row(s) affected)

О проблемах и ограничениях. Как было сказано, это не штатный механизм, и он имеет некоторые проблемы. Первая и главная, на мой взгяд, проблема, в том, что в буфер попадают все инструкции в текущем пакете, а не только та, что инициировала выполнение триггера. По этому получить в чистом виде именно тот запрос, который вызвал триггер, без остальных инструкций — невозможно. Вторая проблема заключается в том, что буфер имеет ограниченную четырьмя тысячами символов длину. Еще одна проблема, это выполнение вставки из ХП, в этом случае в буфер записывается вызов этой ХП, а не сам запрос на вставку. Ниже это все проиллюстрировано.

/*
создаем тестовые таблицы, одну - которую будем логировать,
вторую - в которую будем писать лог
*/
if object_id('dbo.TriggerTable') is not null drop table dbo.TriggerTable
if object_id('dbo.LogTable') is not null drop table dbo.LogTable
if object_id('dbo.TriggerTable_add') is not null drop proc dbo.TriggerTable_add
create table dbo.TriggerTable( field int )
create table dbo.LogTable( field nvarchar(4000) )

/*создаем триггер на вставку*/
go
create trigger TriggerTable_insert on  dbo.TriggerTable after insert as
begin
	set nocount on;

	declare @temp table(EventType nvarchar (30), Parameters int, EventInfo nvarchar(4000) )
	insert into @temp
	exec sp_executesql N'DBCC inputbuffer (@@spid) WITH NO_INFOMSGS'

	insert into dbo. LogTable
	select EventInfo from @temp

end

/* добавляем значения */

/* Тут все в порядке, в лог попадает запрос на вставку*/
go
insert into dbo.TriggerTable values (1)
go
/* Вот тут в лог попадет все что до и после инсерта, т.е. все содержимое пакета*/
go
-- попадает все что есть в пакете
select 1
insert into dbo.TriggerTable values (2)
select 2
go
/* Тут в лог попадет только сам вызов процедуры*/
create proc dbo.TriggerTable_add @value int
as
insert into dbo.TriggerTable values (@value)
go
exec dbo.TriggerTable_add 3
go
/* проверяем что записалось в лог */
select * from dbo.LogTable
go

/* удаляем тестовые таблицы */
drop proc TriggerTable_add
drop table dbo.LogTable
drop table dbo.TriggerTable
go

результат:

field
----------------------------------------
insert into dbo.TriggerTable values (1)
-- попадает все что есть в пакете
select 1
insert into dbo. TriggerTable values (2)
select 2
exec dbo.TriggerTable_add 3

(3 row(s) affected)

Наверняка существуют и еще какие-то проблемы, но мне хватило вышеперечисленного, чтобы отказаться всерьез рассматривать такой метод логирования действий пользователей на рабочих серверах. Тем не менее даже в таком виде, с ограничениями, этот способ имеет право на жизнь, и может использоваться в простых случаях. А для своих нужд, я остановился на использовании штатного механизма трассировки, при помощи функций семейства sp_trace_XXX. О том как и для чего они у меня используются напишу в следующем посте.

Пример триггера SQL Server

Автор: Daniel Farina   |
Обновлено: 17 марта 2022 г.   |
Комментарии (11)   | Связанный: Еще > Триггеры

Проблема

Вы уже научились писать
SQL-запросы и
хранимые процедуры, но теперь
вы хотите узнать о
Триггеры SQL Server. Этот совет послужит отправной точкой
и руководство по созданию триггеров SQL Server.

Решение

Триггеры — одна из самых непонятных тем для новичков в SQL Server.
Может быть, это связано с тем, что они позволяют почти все одинаковые функции
как
хранимых процедур, что заставит неопытного разработчика запутаться в том,
для создания хранимой процедуры или триггера.

Что такое триггер SQL Server?

Триггер SQL Server — это часть процедурного кода, например хранимая процедура, которая
выполняется только тогда, когда происходит данное событие. Существуют различные типы событий
который может запустить триггер. Просто чтобы назвать вам несколько, вставка строк в таблицу,
изменение структуры таблицы и даже вход пользователя в экземпляр SQL Server.

Есть три основных характеристики, которые отличают триггеры от сохраненных
процедур:

  • Триггеры не могут запускаться пользователем вручную.
  • Триггеры не могут получить параметры.
  • Вы не можете зафиксировать или откатить транзакцию внутри триггера.

Невозможность использования параметров в триггерах не является ограничением
для получения информации об огневом событии. Как вы увидите далее, там
альтернативы для получения информации о событии стрельбы.

Классы триггеров SQL Server

В SQL Server существует два класса триггеров:

  • Триггеры DDL (язык определения данных). Этот класс триггеров срабатывает
    события, изменяющие структуру (например, создание, изменение или удаление таблицы),
    или в определенных событиях, связанных с сервером, таких как изменения безопасности или обновление статистики
    события.
  • Триггеры DML (язык модификации данных). Это наиболее часто используемый класс
    триггеры. В этом случае событием срабатывания является оператор модификации данных; это
    может быть оператором вставки, обновления или удаления либо в таблице, либо в представлении.

Кроме того, триггеры DML бывают разных типов:

  • FOR или AFTER [INSERT, UPDATE, DELETE]: Эти типы триггеров выполняются
    после окончания оператора запуска (вставка, обновление или удаление).
  • ВМЕСТО [ВСТАВИТЬ, ОБНОВИТЬ, УДАЛИТЬ]: В отличие от типа FOR (ПОСЛЕ),
    Триггеры INSTEAD OF выполняются вместо оператора срабатывания. Другими словами,
    этот тип триггера заменяет оператор запуска. Это очень удобно в случаях
    где вам нужно иметь ссылочную целостность кросс-базы данных.

В чем важность триггеров SQL Server?

Одной из фундаментальных характеристик реляционных баз данных является непротиворечивость данных.
Это означает, что информация, хранящаяся в базе данных, должна быть непротиворечивой во всех отношениях.
раз для каждого сеанса и каждой транзакции. Механизмы реляционных баз данных
подобно тому, как SQL Server реализует это, применяя ограничения, такие как первичные ключи и
внешние ключи. Но иногда этого недостаточно.

В SQL Server нет возможности обеспечить ссылочную целостность между двумя
таблицы с использованием внешних ключей, если эти таблицы находятся в разных базах данных или в разных
серверы. В таком случае единственный способ реализовать это — использовать триггеры.

Как узнать, какие строки были обновлены, вставлены или удалены с помощью SQL Server
DML-триггер?

В случае триггеров DML во время выполнения есть две виртуальные таблицы
триггера, который содержит данные, затронутые выполнением триггера. Те
таблицы названы вставленными и удаленными и они
имеют ту же структуру таблицы, что и их базовая таблица.

Имейте в виду,
что вставленные и удаленные таблицы не всегда доступны вместе (т.е.
может иметь вставленную таблицу, но не удаленную или наоборот). Вы будете
найти больше информации об этих таблицах в следующем совете

Общие сведения о вставленных и удаленных таблицах SQL Server для триггеров DML.

Синтаксис триггера SQL Server DML

В следующем разделе кода вы увидите основной синтаксис CREATE TRIGGER.

 СОЗДАТЬ ТРИГГЕР имя_триггера
ON {Имя таблицы или имя представления}
[ С <Опции> ]
{ ЗА | ПОСЛЕ | ВМЕСТО }
{[ВСТАВИТЬ], [ОБНОВИТЬ], [УДАЛИТЬ]} 

Кроме того, в следующей таблице описаны все аргументы команды CREATE TRIGGER.
синтаксис.

Аргумент Описание
С <Опции> В этом аргументе можно указать дополнительные параметры создания
триггера. Я расскажу об этом дальше.
ДЛЯ | ПОСЛЕ | ВМЕСТО Указывает, когда должен срабатывать триггер при возникновении определенного события, например
событие вставки, обновления или удаления.
[ВСТАВИТЬ], [ОБНОВИТЬ], [УДАЛИТЬ] Событие DML (или список событий), которое вызовет срабатывание триггера.
С опцией Описание Замечания
ШИФРОВАНИЕ Шифрует код триггера. Не работает с таблицами, оптимизированными для памяти
ВЫПОЛНИТЬ КАК Изменяет контекст безопасности, в котором будет выполняться триггер Требуется для триггеров в таблицах, оптимизированных для памяти.
СОБСТВЕННАЯ_КОМПИЛЯЦИЯ Компилирует код триггера в двоичный файл, чтобы он работал в собственном коде. Требуется для триггеров в таблицах, оптимизированных для памяти.
СХЕМА ПРИВЯЗКИ Гарантирует невозможность удаления таблиц, на которые ссылается триггер.
или изменен.
Требуется для триггеров в таблицах, оптимизированных для памяти.

Сценарии использования триггеров SQL Server

Есть два четких сценария, когда лучше всего использовать триггеры: аудит и
соблюдение бизнес-правил. Используя триггер, вы можете отслеживать изменения на
заданную таблицу, написав запись журнала с информацией о том, кто сделал изменение
и что изменилось в таблице.

Возможно, вы думаете, что можете сделать то же самое в приложении с хранимой процедурой
который обрабатывает изменения данных, такие как вставки и обновления. Вы можете использовать хранимую процедуру,
но в таком случае вы не сможете логировать внесенные изменения напрямую
к базе данных извне приложения.

То же самое происходит, когда вы хотите применить бизнес-правила с помощью хранимой процедуры.
Если кто-то изменяет данные в базовой таблице вне приложения, которое вы
может возникнуть проблема, поскольку согласованность данных не может быть гарантирована. Чтобы избежать этого
проблема, вы должны убедиться, что хранимая процедура является единственным способом доступа к
стол.

Пример триггера SQL Server DML

Предположим, у нас есть база данных для отдела кадров. Этот
База данных содержит таблицу «Сотрудники» для хранения информации о персонале и заработной плате.
С помощью триггера мы можем хранить запись аудита в отдельной таблице, которая
содержит каждую модификацию записи, а также пользователя, внесшего изменение, и
раз это случилось.

Сначала мы должны создать таблицу «Сотрудники».

 СОЗДАТЬ ТАБЛИЦУ Сотрудники
    (
      Целое число EmployeeID NOT NULL IDENTITY(1, 1) ,
      имя_сотрудника VARCHAR(50) ,
      Адрес сотрудника VARCHAR(50) ,
      МесяцЗарплата NUMERIC(10, 2)
      ПЕРВИЧНЫЙ КЛЮЧ КЛАСТЕРИРОВАННЫЙ (EmployeeID)
    )
ВПЕРЕД 

Затем мы должны создать таблицу EmployeesAudit для хранения записей аудита. Этот
таблица имеет ту же структуру, что и таблица «Сотрудники», но включает столбец AuditId.
в качестве первичного ключа, ModifiedDate, чтобы сохранить дату модификации, ModifiedBy, чтобы мы
может знать, кто изменил таблицу «Сотрудники» и, наконец, операцию, где мы укажем
операция DML, сгенерировавшая контрольную запись с одной из трех букв (I для
вставить, U для обновления и D для удаления).

 СОЗДАТЬ ТАБЛИЦУ Сотрудников Аудит
    (
      AuditID INTEGER NOT NULL IDENTITY(1, 1) ,
      Идентификатор сотрудника ЦЕЛОЕ ЧИСЛО ,
      имя_сотрудника VARCHAR(50) ,
      Адрес сотрудника VARCHAR(50) ,
      MonthSalary NUMERIC(10, 2) ,
      Изменено VARCHAR(128),
      ModifiedDate ДАТАВРЕМЯ ,
      Операция СИМВОЛ(1)
      КЛАСТЕРИРОВАННЫЙ ПЕРВИЧНЫЙ КЛЮЧ ( AuditID )
    )
ВПЕРЕД 

Чтобы иметь возможность протестировать триггер образца, нам нужно добавить некоторые данные в
Таблица сотрудников.

 ВСТАВИТЬ В dbo.Employees
        ( Имя сотрудника ,
          Адрес сотрудника ,
          МесяцЗарплата
        )
ВЫБЕРИТЕ «Марк Смит», «Ocean Dr 1234», 10000
СОЮЗ ВСЕХ
ВЫБЕРИТЕ «Джо Райт», «Вечнозеленый 1234», 10000
СОЮЗ ВСЕХ
ВЫБЕРИТЕ «Джон Доу», «Международный доктор 1234», 10000
СОЮЗ ВСЕХ
ВЫБЕРИТЕ «Питер Родригес», «74 Street 1234», 10000
ВПЕРЕД 

Теперь, когда мы установили тестовую среду, пришло время создать наш триггер. Брать
посмотрите на код ниже.

В основном код состоит из получения пользователя, который изменяет сотрудников
таблице, глядя на
sys.dm_exec_sessions Динамическое управление
Просмотр сеанса с текущим SPID. После этого триггер вставляет одну запись
в таблице EmployeesAudit для каждой записи, вставленной, обновленной или удаленной в
Таблица сотрудников, а также текущее время и операция DML, которая запустила
курок.

Для проверки триггера я создал три запроса. Я помещаю код внутри
транзакции просто для поддержания порядка в моей тестовой среде, вы можете опустить это.

Первый из этих запросов — это обновление.

 НАЧАТЬ ТРАНЗАКЦИЮ

ВЫБИРАТЬ  *
ОТ dbo.Employees
ГДЕ Сотрудник ID = 1
 
ОБНОВЛЕНИЕ Сотрудники
УСТАНОВИТЬ имя_сотрудника = 'zzz'
ГДЕ Сотрудник ID = 1
 
ВЫБИРАТЬ  *
ОТ dbo.Employees
ГДЕ Сотрудник ID = 1
 
ВЫБИРАТЬ  *
ОТ dbo.EmployeesAudit

ОТМЕНА ТРАНЗАКЦИИ 

На следующем снимке экрана вы увидите обновленную запись в таблице «Сотрудники».
и новая запись в EmployeesAudit, которая отслеживает операцию DML в течение
таблицу «Сотрудники».

Второй запрос представляет собой вставку двух строк в таблицу «Сотрудники».

 НАЧАТЬ ТРАНЗАКЦИЮ

ВСТАВИТЬ В dbo.Employees
        ( Имя сотрудника ,
          Адрес сотрудника ,
          МесяцЗарплата
        )
        ВЫБЕРИТЕ «зз»,
                'дсда',
                10000
        СОЮЗ ВСЕХ
        ВЫБЕРИТЕ «Маркус Рубиус»,
                'дсда',
                6000

ВЫБИРАТЬ  *
ОТ dbo.Employees

ВЫБИРАТЬ  *
ОТ dbo.EmployeesAudit

ОТМЕНА ТРАНЗАКЦИИ 

На следующем снимке экрана вы увидите две вставленные строки в разделе «Сотрудники».
и соответствующую запись аудита в таблице EmployeesAudit.

Наконец, третий запрос — это оператор удаления таблицы «Сотрудники».

 НАЧАТЬ ТРАНЗАКЦИЮ

ВЫБИРАТЬ  *
ОТ dbo.Employees
ГДЕ Сотрудник ID = 1

УДАЛИТЬ ИЗ dbo.Employees
ГДЕ Сотрудник ID = 1
 
ВЫБИРАТЬ  *
ОТ dbo.EmployeesAudit

ВЫБИРАТЬ  *
ОТ dbo. Employees
ГДЕ Сотрудник ID = 1

ОТМЕНА ТРАНЗАКЦИИ 

На следующем снимке экрана вы увидите, что строка удалена из таблицы «Сотрудники».
и соответствующую запись аудита в таблице EmployeesAudit.

Следующие шаги
  • Если вам было трудно понять, как я зафиксировал, какую операцию DML
    было выполнено в таблице «Сотрудники», взгляните на этот совет:

    Общие сведения о вставленных и удаленных таблицах SQL Server для триггеров DML.

  • В качестве примера триггера INSTEAD OF вы можете проверить этот совет:

    Использование триггеров INSTEAD OF в SQL Server для операций DML.

  • Дополнительную информацию о DMV sys.dm_exec_sessions можно найти здесь:

    Понимание и использование sys.dm_exec_sessions в SQL Server.

  • Для получения более подробной информации о команде EXECUTE AS см.
    следующий совет:

    Предоставление разрешения с помощью команды EXECUTE AS в SQL Server.

  • Следите за новостями

    Категория «Советы по триггерам SQL Server» для получения дополнительных советов и рекомендаций.

  • Обсуждаемые концепции будут работать с SQL Server 2005 через SQL Server.
    2019 и последующие версии.
Об авторе

Даниэль Фарина родился в Буэнос-Айресе, Аргентина. Самоучка, с детства проявлял страсть к учебе.

Посмотреть все мои советы

Последнее обновление статьи: 17 марта 2022 г.

Преодоление ограничений на триггеры MS SQL Server в запросах SELECT

Поскольку SQL Server служит серверной частью для многих критически важных бизнес-приложений, очень важно своевременно обнаруживать любые неправомерные изменения или события доступа, которые могут указывать на нарушение безопасности. Одним из наиболее распространенных способов реализации простого аудита на серверах SQL является использование триггеров.

Плохая новость заключается в том, что нет возможности запустить триггер на SELECT в SQL Server, поэтому вы не можете использовать триггеры, чтобы увидеть, кто обращается к таблицам и читает их. В частности, SQL Server позволяет создавать триггеры для следующих трех типов:

  • Триггеры DDL для операторов ALTER, DROP и CREATE таблицы или базы данных
  • Триггеры DML для инструкций INSERT, UPDATE или DELETE в таблице или представлении
  • Триггер входа в систему срабатывает при событиях входа в систему

Хорошей новостью является то, что хотя вы не можете создать триггер SELECT в SQL Server, существуют другие способы отслеживания событий доступа в Microsoft SQL Server. Один из вариантов — использовать собственные журналы аудита SQL Server. Однако, к сожалению, они содержат так много шума, что трудно выделить события, которые вы хотите увидеть. Кроме того, собственный аудит SQL Server может значительно повлиять на производительность вашего сервера. Поэтому вам будет намного лучше использовать легкое специализированное решение для аудита, такое как Netwrix Auditor. Netwrix Auditor обеспечивает полную видимость того, кто что делает в ваших экземплярах SQL Server, в том числе, кто получает доступ к каким данным, при гораздо меньшем снижении производительности ваших баз данных SQL.

Автоматизация аудита операторов SELECT

Одно из основных преимуществ Netwrix Auditor заключается в том, что он преодолевает ограничения триггеров SQL, сообщая об успешных запросах SELECT , что позволяет вам точно видеть, кто считывал данные из каких таблиц SQL. Вместо использования триггеров и хранимых процедур вы можете просто просматривать доступ к базе данных с помощью четких отчетов и удобного поиска, а также можете настроить настраиваемые оповещения, основанные на тех же отчетах и ​​поисковых запросах. Имея под рукой эту исчерпывающую информацию, вы можете предотвратить утечку конфиденциальных данных, ускорить расследования безопасности и доказать аудиторам, что только авторизованные пользователи просматривают регулируемые данные. Кроме того, поскольку Netwrix Auditor использует сбор данных без триггеров, он не так сильно влияет на производительность базы данных, как встроенные инструменты.

Дополнительные преимущества

Помимо операторов SELECT, Netwrix Auditor также сообщает и предупреждает о других запросах SQL, таких как INSERT, UPDATE и DELETE. В результате вы можете привлекать к ответственности своих привилегированных пользователей, намного быстрее предоставлять отчеты менеджерам и доказывать аудиторам соответствия, что у вас есть необходимые средства контроля для защиты ваших конфиденциальных структурированных данных.

Кроме того, Netwrix Auditor обеспечивает детальный контроль над областью мониторинга. Используя универсальные фильтры включения и исключения, вы можете выбрать определенные базы данных и определенные действия, которые вы хотите отслеживать в них, гарантируя вам эффективное получение необходимой информации с хирургической точностью.