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
В обозревателе объектовподключитесь к экземпляру компонента Компонент Database Engine и разверните его.
Разверните узел Базы данных, разверните базу данных
AdventureWorks2022
, разверните узел Таблицы , а затем таблицу Purchasing.PurchaseOrderHeader.Правой кнопкой мыши щелкните элемент Триггеры, а затем выберите пункт Создать триггер.
В меню Запрос выберите пункт Указать значения для параметров шаблона.
Можно также нажать клавиши CTRL-SHIFT-M, чтобы открыть диалоговое окно Задание значений для параметров шаблона .
В диалоговом окне Задание значений для параметров шаблона введите для показанных параметров следующие значения.
Параметр Значение Автор Ваше имя Дата создания Сегодняшняя дата Описание Проверяет кредитоспособность поставщика, прежде чем позволить вставить новый заказ на покупку от этого поставщика. Имя_схемы Покупка Имя_триггера NewPODetail2 Имя_таблицы PurchaseOrderDetail Команда_изменения_данных Удаление инструкций UPDATE и DELETE из списка. Нажмите кнопку ОК.
В редакторе запросовзамените комментарий
-- 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;
Чтобы проверить синтаксис, в меню Запрос выберите пункт Синтаксический анализ. Если появится сообщение об ошибке, сравните эту инструкцию с вышеуказанной информацией, внесите исправления и повторите этот шаг.
Чтобы создать триггер DML, в меню Запрос нажмите Выполнить. Триггер DML создается как объект в базе данных.
Чтобы увидеть этот триггер DML в обозревателе объектов, щелкните правой кнопкой мыши элемент Триггеры и выберите пункт Обновить.
Перед началом
Использование Transact-SQL
В обозревателе объектовподключитесь к экземпляру компонента Компонент Database Engine и разверните его.
В меню Файл выберите пункт Создать запрос.
Скопируйте следующий пример в окно запроса и нажмите кнопку Выполнить. В этом примере создается такой же хранимый триггер 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 обеспечивает детальный контроль над областью мониторинга. Используя универсальные фильтры включения и исключения, вы можете выбрать определенные базы данных и определенные действия, которые вы хотите отслеживать в них, гарантируя вам эффективное получение необходимой информации с хирургической точностью.