스키마 변경이 어떻게 발생 했습니까?

어제 뭔가 나쁜 일이 일어났다.

얼마 전 만들어진보기는 ​​결국 보고서를 파기 한 누군가에 의해 수정되었습니다. 운수 나쁘게. 누군가 (의도적으로 또는 무의식적으로) PRODUCTION 데이터베이스에서이 수정을 수행했습니다.

내 질문 : 누가 (사용자 이름) 이이 수정을했는지 알 수있는 방법 (스크립트 / 소프트웨어 / 프리웨어 등)이 있습니까? 그래서 해당 사용자의 프로덕션 데이터베이스에 대한 액세스 권한을 취소 할 수 있습니다.

내 질문이 명확하지 않은 경우 의견을 말하십시오.

활성화되어 있고 "스키마 변경 내역"보고서에 표시되는 동안 롤오버되지 않는 한 기본 추적에 기록됩니다.

Management Studio에서이 데이터베이스에 액세스하려면 데이터베이스를 마우스 오른쪽 단추로 클릭 한 다음 상황에 맞는 메뉴에서 Reports -> Standard Reports -> Schema Changes History

TSQL을 통해 동일한 정보를 검색하려면 다음을 사용할 수 있습니다.

SELECT StartTime
       ,LoginName
       --,f.*
FROM   sys.traces t
       CROSS APPLY fn_trace_gettable(REVERSE(SUBSTRING(REVERSE(t.path),
                                                       CHARINDEX('\', REVERSE(t.path)), 
                                                       260)
                                             ) + N'log.trc', DEFAULT) f
WHERE  t.is_default = 1
       AND ObjectName = 'FOO'
       AND EventClass IN (46, /*Object:Created*/
                          47, /*Object:Dropped*/
                          164 /*Object:Altered*/ )

Martin은 이미 관리 감사 추적에 대한 최선의 길을 지적했습니다 (명시 적으로 비활성화되지 않은 경우 제외). 관리자 추적에서 정보를 찾을 수없는 경우 (비활성화되었거나 재활용 된 경우) 로그 백업에서 정보를 검색 할 수 있습니다. 프로덕션 DB이므로 정기적 인 전체 백업 및 로그 백업과 함께 정기적 인 백업주기가 있다고 가정합니다. DDL이 현재 복원 된 로그에 있도록 사고 발생 시점까지 데이터베이스를 별도의 서버에서 데이터베이스를 복원해야합니다. 그런 다음 fn_dblog()로그 를 사용 하고 검사 하는 간단한 문제입니다 .

한 가지 방법은 트랜잭션 시작 조작으로 이동하는 것입니다.

select [Begin Time], [Transaction Name], [Transaction SID], * 
from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT';

ALTER VIEW가 독립형 트랜잭션으로 발행 된 경우 (즉, BEGIN TRANSACTION/로 묶지 않음 COMMIT) 이름이 지정된 트랜잭션이 시작됩니다 CreatProc transaction. 그것을 찾으십시오. 그리고 [Transaction SID]원하는 로그인 SID입니다.

또 다른 가능성은 원하는 뷰에서 SCH_M을 획득 한 트랜잭션을 찾는 것입니다.

select [Lock Information], * 
from fn_dblog(null, null)
where [Lock Information] like '%' + cast(object_id('...') as varchar(10))+'%'
and [Lock Information] like '%LOCK_SCH_M%'
go

뷰가 DROP에 의해 변경되고 CREATE가 뒤 따르면 오브젝트 ID가 변경되었을 가능성이 있지만 최소한 CREATE를 마지막으로 수행 한 트랜잭션 (복원 된 db에있는 뷰의 현재 오브젝트 ID)을 얻게됩니다. 거래 ID로 돌아가서 거래 시작 정보를 검색합니다.

select [Begin Time], [Transaction Name], [Transaction SID], *
from fn_dblog(null, null)
where [Transaction ID] = '...'
and Operation = 'LOP_BEGIN_XACT';

[Transaction SID]는 다시 여러분입니다. SUSER_SNAME로그인 SID에서 로그인 이름을 검색하는 데 사용 합니다. SID가 0x01 인 경우 로그인이 sa되었음을 의미합니다. 이는 sa비밀번호 를 알고있는 개인이 비밀번호를 수행 할 수 있음을 의미 합니다.

아니요, DDL 트리거 등을 통해 로그인하지 않는 한

해당 데이터베이스 또는 sysadmin / db_owner / ddl_admin 역할의 멤버 자격을 ALTER 권한으로보고자합니다. 이것은 마녀 사냥보다 일반적인 검토로 더 좋습니다. 비 승인 및 무단 변경을 할 권리가있는 다른 사람이있을 수 있습니다.

아직 SQL Server Management Studio에서 사용 가능한 스키마 변경 기록 보고서 를 확인하지 않았 으면 할 수 있습니다 . 기본적으로 SQL Server가 변경 사항을 기록하는 것처럼 보이는 ( 기본 추적 )이 보고서를 통해 해당 데이터를 볼 수 있어야합니다. 유감스럽게도 시간이 지남에 따라 이러한 추적 파일이 자동으로 삭제 / 롤오버되므로 데이터가 이미 사라질 수 있습니다. 행운을 빕니다!