Сбор данных изменений в SQL Server 2008, кто внес эти изменения?

Question

Неделю назад я задал вопрос о SOF об аудите изменений данных SQL. Подходили обычные вещи об использовании триггеров, также упоминалось о CDC в SQL Server 2008.

Я пробовал это сегодня, и пока все хорошо, единственное, что я не вижу в этом, - это отслеживать, кто на самом деле внес изменения. Кто выполнил заявление?

Мне интересно узнать, использовал ли кто-нибудь CDC для аудита и как вы отслеживали, кто внес изменение?

Answer 1

Я изменил таблицу CDC напрямую, используя: ALTER TABLE cdc.dbo_MyTable_CT ADD UserName nvarchar (50) NULL DEFAULT (SUSER_SNAME ())

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

Моя единственная проблема заключается в том, что мои пользователи входят в систему через группу Windows, которая позволяет им изменять права, но поле UserName всегда является моим именем пользователя, а не их именем. Я не нашел пути решения этой проблемы.

Answer 2

Сбор данных изменений не отслеживает пользователя, машину, которая внесла изменение, или время изменения.

Лучшее решение для отслеживания пользователей, которые внесли изменения с помощью CDC, - это создание нового поля для хранения сведений о пользователях, которое будет обновляться при каждом изменении (эта идея здесь ).

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

Надеюсь, это поможет.

Answer 3

Если вы не сталкивались со статьей Джо Баррето о CDC, это может помочь.

http://blogs.technet.com/josebda/archive/2009/03/24/sql-server-2008-change-tracking-ct-and-change-data-capture-cdc.aspx

Answer 4

MrEdmundo, CDC не готов к прайм-тайму, по моему мнению. В настоящее время, похоже, довольно сложно бороться с развертыванием проекта базы данных из Visual Studio с включенным CDC (ему не нравятся изменения DDL). Кроме того, кажется, что CDC имеет встроенный процесс очистки данных с истекшим сроком службы, так что это может быть плохим временем для вас, если вы действительно хотите поддерживать свою историю аудита в течение длительного времени.

Кроме того, исправьте меня, если я неправильно понял, но, похоже, SQL Audit предназначен для аудита множества событий, происходящих в SQL Server, таких как неудачные входы в систему, изменения DDL и т. Д.

Отслеживание изменений предназначено только для DDL, а не для DML, так что вам не повезло.

Если вы действительно намерены захватить «старую» запись, которая была либо обновлена, либо удалена из таблицы, то, похоже, лучшим ответом остается создание Audit.TableName и триггера update + delete для dbo.TableName. Также убедитесь, что TableName включает столбцы CreatedBy DEFAULT SUSER, CreatedDate DEFAULT getdate (), ModifiedBy, ModifiedDate.

Answer 5

CDC действительно не предназначен для аудита. Если вы ищете возможности аудита, вы должны использовать SQL Server Audit .

Answer 6

Вот триггер, который может быть создан с помощью некоторого автоматизированного процесса или вручную, когда CDC включен для этой конкретной таблицы, этот триггер решит проблему, с которой who & , откуда были сделано:

CREATE TRIGGER TR_TABLENAME_CDC 
ON TABLENAME
FOR INSERT, UPDATE, DELETE 
AS
DECLARE           
       @SessionID int,
       @AppName nvarchar(255),
       @HostName nvarchar(255),
       @UserName nvarchar(32)
BEGIN
    SELECT @SessionID=@@SPID
    SELECT @AppName=program_name, @HostName=host_name from sys.dm_exec_sessions where session_id = @SessionID

    IF(@AppName = 'BLAH BLAH' OR @AppName = 'XYZ' OR @AppName = 'ABC')
    BEGIN
        SELECT @UserName=login_name from sys.dm_exec_sessions where session_id = @SessionID
        INSERT INTO UserDetail (SessionID, AppName, HostName, UserName) VALUES (@SessionID, @AppName, @HostName, @UserName)
    END 
END

Answer 7

Хотя это и не идеально, по общему мнению, CDC не будет фиксировать, кто внес изменение, но мы внедрили столбцы CreatedBy / Date и updatedBy / Date, которые можно использовать, чтобы увидеть, кто инициировал изменение. Конечно, чтобы это работало, оператор SP или SQL, обновляющий строку, должен явно установить поля UpdatedBy / Date соответствующим образом, используя suser_name () и getDate () соответственно. Я согласен, что было бы неплохо получить из коробки и заставить CDC делать то, для чего он не предназначен, но я тоже пытаюсь использовать CDC для аудита асинхронных изменений данных вместо использования традиционных триггеров.