it-swarm.asia

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.

21
xorpower

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*/ )
36
Martin Smith

Martin sudah menunjuk jalan terbaik, jejak audit administrasi yang biasanya aktif (kecuali jika telah dinonaktifkan secara eksplisit). Jika Anda tidak dapat menemukan info di jejak admin (dinonaktifkan atau 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 saat ini dipulihkan. 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 VIEW dikeluarkan dalam transaksi mandiri (mis. tidak dikelilingi oleh BEGIN TRANSACTION/COMMIT) maka akan memulai transaksi bernama CreatProc transaction. Carilah itu, dan [Transaction SID] adalah 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_SNAME untuk mengambil nama login dari SID login. Jika SID adalah 0x01 itu berarti login adalah sa, yang berarti setiap orang yang mengetahui kata sandi sa bisa melakukannya.

19
Remus Rusanu

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 tinjauan umum daripada perburuan penyihir. Mungkin ada orang lain dengan hak untuk membuat perubahan yang tidak disetujui dan tidak sah juga

6
gbn

Jika Anda belum melakukannya, Anda mungkin ingin memeriksa laporan Skema Perubahan Sejarah tersedia di SQL Server Management Studio. Sepertinya perubahan log SQL Server secara default ( jejak default ) dan Anda harus dapat melihat data 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!

0
Mark Madej