Bagaimana mendeteksi setiap perubahan pada basis data (DDL dan DML)

13

Ada banyak basis data di server SQL klien saya. Basis data ini sedang dikembangkan, sehingga pengembang dapat merancang, refactor, melakukan modifikasi data, dan sebagainya. Ada beberapa database yang jarang berubah. Klien saya harus menjaga semuanya aman (dicadangkan) dan meluangkan waktu untuk mengelola lingkungan. (Tidak ada posisi administrator DB di perusahaan.) Setelah diskusi panjang, klien telah memutuskan untuk menggunakan strategi pencadangan penuh harian, karena kemudahan pemulihan.

Jadi, inilah ringkasan situasinya:

  • Jumlah basis data dapat bervariasi setiap hari.
  • Basis data yang diubah (artinya data dan / atau struktur telah diubah) harus didukung.
  • Basis data yang tidak diubah TIDAK akan didukung.
  • Solusi tidak akan memengaruhi struktur basis data (bukan persyaratan yang dibatasi)
  • "Mesin cadangan" ini akan bekerja secara otomatis.

Masalah utama: bagaimana mendeteksi bahwa database telah diubah. Bagian pertama dari masalah (perubahan DDL) dapat diatasi dengan menggunakan pemicu DDL . Tetapi perubahan data (perubahan DML) merupakan masalah. Tidak mungkin untuk menerapkan pemicu DML ke semua tabel dari semua database untuk melacak perubahan (kinerja, manajemen objek yang diperluas ...). Mesin pencadangan harus melacak semua perubahan untuk menandai setiap basis data sebagai siap untuk dicadangkan.

  • Ubah Data Capture adalah solusi tetapi tampaknya terlalu berat (membutuhkan SQL Server Enterprise Edition juga).

  • Cara lain adalah melacak perubahan file database (ukuran atau waktu perubahan terakhir), tetapi tidak berfungsi dengan benar: Database dapat mengubah ukurannya ketika melebihi semua ruang kosong yang disediakan dan sp_spaceused bukan solusi.

  • Menelusuri adalah solusi tetapi menyebabkan masalah kinerja dan membutuhkan manajemen tambahan.

Apakah ada solusi untuk menghitung ukuran penggunaan database aktual tanpa dampak pada objek manajemen database lain (seperti statistik ..)? Memang perubahan pada data tabel yang tidak mengubah ukuran tabel tidak akan memicu (saya pikir), tapi itu lebih baik daripada tidak sama sekali. Benar-benar saya mencari solusi langsung atau tidak langsung untuk SQL Server 2008.

Terima kasih atas komentar, solusi, dan pemikiran.

TAMBAH:

Ini solusinya (terima kasih kepada Marian ):

Select
    NextLSN = MAX(fn.[Current LSN])
    ,Databasename = DB_NAME()
 from fn_dblog(NULL,    NULL) fn
     LEFT JOIN sys.allocation_units au
         ON fn.AllocUnitId = au.allocation_unit_id
     LEFT  JOIN sys.partitions p
         ON p.partition_id = au.container_id
     LEFT  JOIN sys.objects so
         ON so.object_id = p.object_id  
    WHERE 
    (
        (Operation IN 
       ('LOP_INSERT_ROWS','LOP_MODIFY_ROW',
            'LOP_DELETE_ROWS','LOP_BEGIN_XACT','LOP_COMMIT_XACT') 
            AND so.is_ms_shipped = 0)
        OR 
        ([Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%')
    )
garik
sumber
Jadi apakah Anda menerapkan ini sebagai bagian dari pekerjaan atau ??? Saya akan senang memiliki metode keluaran harian (katakan pada jam 2 pagi) semua perubahan dari 24 jam sebelumnya ke direktori sehingga saya dapat memiliki sedikit changelog untuk diri saya sendiri.
jcolebrand
@ jcolebrand ya, saya lakukan. Jika saya harus memeriksa semua aktivitas basis data dan kemudian membuat cadangan (penuh atau diferensial). Saya memeriksa LSN (kunci utama catatan log), yang berfungsi mengembalikan fn_dblog. Itu semuanya. Saya tidak berpikir itu akan berhasil dalam kasus Anda. Saya belum menyelidiki semua fitur data yang dapat dikembalikan oleh fn_dblog, tapi saya pikir itu tidak mengembalikan semua informasi yang harus dilakukan. Seperti yang Anda lihat ada banyak tabel sistem lain yang bergabung dengannya. Jika mudah, kami akan memiliki banyak alat yang normal dan murah :)
garik

Jawaban:

7

Satu ide adalah membuat snapshot setiap hari dan memantau ukuran file snapshot pada disk menggunakan monitor file. Cuplikan ini meningkatkan ukurannya hanya ketika data ditambahkan di sana, jadi itu akan menjadi ide yang valid jika Anda akan menemukan alat untuk memantau ukuran sebenarnya (ukuran yang dilaporkan).

Sekarang .. Saya tidak menggunakan ini, jadi tidak bisa memberi Anda wawasan teknis :-).

Gagasan lain adalah untuk memverifikasi log transaksi dari setiap db (jika Anda menggunakan mode pemulihan penuh pada mereka, tentu saja) dengan beberapa fungsi yang saya lihat di forum (db_fnlog .. atau sesuatu) yang membaca operasi dari log , dan lihat apakah Anda memiliki penghapusan / sisipan / pembaruan.

Itu bukan hal yang mudah untuk dilakukan .. tapi saya harap Anda akan menemukan mereka berguna.

PS: menemukan artikel dengan fungsi baca log (ini adalah fndblog, by the way :-): Baca log transaksi oleh Jens K. Suessmeyer .

Marian
sumber
1
Saya tidak berbicara tentang ukuran file db, tetapi tentang file lokal snapshot, yang dibuat dengan: buat database xxxdb sebagai snapshot dari yyydb. Lihat detail tentang foto di sini: msdn.microsoft.com/en-us/library/ms175158.aspx .
Marian
1
  • Untuk perubahan DDL Anda dapat membaca Jejak Default .
  • Untuk modifikasi DML karena Anda merasa CDC sedikit berat, Anda dapat menjalankan penelusuran sisi server ringan yang hanya melacak peristiwa yang relevan
Pengembara
sumber
1

Untuk perubahan DDL Anda Pemicu DDL, Tapi Perubahan DML Anda dapat mencoba menggunakan 3 opsi berbeda

1) Ubah pelacakan 2) CDC (Ubah data Capture) 3) Fitur Audit

Untuk Ubah pelacakan .. Anda dapat melihat tautan di bawah ini http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

pelacakan perubahan ini hanya akan digunakan ketika tabel telah berubah atau tidak ... tetapi sangat sulit untuk menemukan data apa yang telah berubah .. jika Anda ingin menemukan data apa yang telah berubah maka Anda dapat pergi Tangkap data Chnage.

Untuk Aduit di sqlserver ..Anda dapat memeriksa tautan di bawah ini http://blogs.msdn.com/b/manisblog/archive/2008/07/21/sql-server-2008-auditing.aspx

Anil Inampudi
sumber
1
+1, tetapi CDC dikirimkan dengan Enterprise Edition
garik
1

Untuk perubahan DML, Anda dapat menggunakan salah satu dari fitur audit SQL Server asli berikut:

  • Pelacakan Perubahan SQL Server
  • SQL Server Ubah Pengambilan Data
  • Audit SQL Server

Masing-masing memiliki kelebihan dan kekurangan, tetapi Audit adalah yang terbaru yang diperkenalkan oleh Microsoft, jadi itu akan menjadi ide yang baik untuk membangun solusi Anda saat ini dan masa depan dibungkus dengan itu.

Perhatikan bahwa hanya fitur Audit yang memberikan informasi tentang Siapa / Kapan / Bagaimana

Ivan Stankovic
sumber
0

Anda dapat mendeteksi perubahan ddl dengan menggunakan file jejak. di bawah ini adalah skrip untuk mendapatkan perubahan.

SELECT 
    te.name AS eventtype
    ,t.loginname
    ,t.spid
    ,t.starttime
    ,t.objectname
    ,t.databasename
    ,t.hostname
    ,t.ntusername
    ,t.ntdomainname
    ,t.clientprocessid
    ,t.applicationname  
FROM sys.fn_trace_gettable
(
    CONVERT
    (VARCHAR(150)
    ,(
        SELECT TOP 1 
            value
        FROM sys.fn_trace_getinfo(NULL)  
        WHERE property = 2
    )),DEFAULT
) T 
INNER JOIN sys.trace_events as te 
    ON t.eventclass = te.trace_event_id 
WHERE eventclass=164

Anda dapat mendeteksi modifikasi apa pun di atas meja dan prosedur tersimpan menggunakan skrip ini:

SELECT 
    SO.Name
    ,SS.name 
    ,SO.type_desc 
    ,SO.create_date
    ,SO.modify_date 
 FROM sys.objects AS SO
INNER JOIN sys.schemas AS SS 
    ON SS.schema_id = SO.schema_id 
WHERE DATEDIFF(D,modify_date, GETDATE()) < 50
AND TYPE IN ('P','U')
Landasan
sumber