Menentukan bagaimana perubahan skema terjadi?

Sesuatu yang buruk terjadi kemarin.

Tampilan yang dibuat beberapa waktu lalu telah dimodifikasi oleh seseorang yang akhirnya memecahkan laporan. Sayangnya. seseorang (sadar atau tidak sadar) melakukan modifikasi ini dalam basis data PRODUCTION.

Pertanyaan Saya: Apakah ada cara (skrip / perangkat lunak / freeware dll) yang dengannya kami dapat mengetahui siapa (nama pengguna) yang melakukan modifikasi ini, sehingga saya dapat mencabut akses ke basis data produksi untuk pengguna tersebut.

Jika pertanyaan saya tidak jelas, silakan komentar.

Ini akan dicatat ke jejak default, asalkan diaktifkan dan belum terguling sementara itu akan muncul dalam laporan "Skema Perubahan Sejarah".

Untuk mengakses ini di Studio Manajemen klik kanan database kemudian dari menu konteks pilih Reports -> Standard Reports -> Schema Changes History

Untuk mengambil informasi yang sama melalui TSQL dapat Anda gunakan

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 sudah menunjuk jalan terbaik, jejak audit administrasi yang biasanya aktif (kecuali jika telah dinonaktifkan secara eksplisit). Jika Anda tidak dapat menemukan info dalam jejak admin (dinonaktifkan atau telah didaur ulang), Anda dapat mengambil info dari cadangan log. Karena ini adalah DB produksi, saya menganggap Anda memiliki siklus cadangan reguler, dengan cadangan penuh berkala dan cadangan log. Anda harus mengembalikan, pada server yang terpisah, ke database sekitar waktu kejadian sehingga DDL berada di log yang dipulihkan saat ini. Kemudian adalah masalah sederhana menggunakan fn_dblog()dan memeriksa log.

Salah satu caranya adalah dengan memulai operasi transaksi:

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

Jika ALTER VIEWdikeluarkan dalam transaksi mandiri (mis. Tidak dikelilingi oleh BEGIN TRANSACTION/ COMMIT) maka akan memulai transaksi bernama CreatProc transaction. Carilah itu, dan [Transaction SID]SID login yang Anda inginkan.

Kemungkinan lain adalah mencari transaksi yang memperoleh SCH_M pada tampilan yang Anda inginkan:

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

Perhatikan bahwa jika tampilan diubah oleh DROP diikuti oleh CREATE id objek kemungkinan berubah, tetapi setidaknya Anda akan mendapatkan transaksi yang terakhir melakukan CREATE (id objek saat ini dari tampilan di db yang dipulihkan). Dengan id transaksi Anda kembali dan mengambil info transaksi awal:

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

[SID Transaksi] sekali lagi adalah cowok Anda. Gunakan SUSER_SNAMEuntuk mengambil nama login dari SID login. Jika SID adalah 0x01 itu berarti login itu sa, yang berarti setiap orang yang tahu sakata sandi bisa melakukannya.

Tidak, kecuali Anda login melalui pemicu DDL atau semacamnya

Anda ingin melihat siapa yang sebagai hak ALTER dalam database itu, atau keanggotaan peran sysadmin / db_owner / ddl_admin. Ini akan lebih baik sebagai ulasan umum daripada perburuan penyihir. Mungkin ada orang lain dengan hak untuk membuat perubahan yang tidak disetujui dan tidak sah juga

Jika Anda belum melakukannya, Anda mungkin ingin memeriksa laporan Schema Changes History yang tersedia di SQL Server Management Studio. Sepertinya SQL Server mencatat perubahan secara default ( penelusuran standar ) dan Anda harus dapat melihat data itu melalui laporan ini. Satu-satunya hal yang disayangkan adalah bahwa file jejak ini secara otomatis dihapus / berguling seiring waktu, sehingga data mungkin sudah hilang. Semoga berhasil!