Veritabanındaki herhangi bir değişiklik nasıl algılanır (DDL ve DML)


13

Müşterimin SQL sunucusunda çok sayıda veritabanı var. Bu veritabanları geliştirilme aşamasındadır, bu nedenle geliştiriciler tasarlayabilir, yeniden düzenleyebilir, veri değişiklikleri yapabilir vb. Nadiren değişen bazı veritabanları vardır. Müşterim hepsini güvende tutmak (yedeklemek) ve çevreyi yönetmek için biraz zaman harcamak zorunda. (Şirkette DB yöneticisi konumu yoktur.) Uzun süren tartışmalardan sonra, müşteri geri yükleme kolaylığı nedeniyle günlük tam yedekleme stratejisi kullanmaya karar verdi.

İşte durumun özeti:

  • Veritabanı sayısı her gün değişebilir.
  • Değiştirilen veritabanları (yani veriler ve / veya yapı değiştirilmiştir) yedeklenecektir.
  • Değiştirilmeyen veritabanları yedeklenmeyecektir.
  • Çözüm veritabanı yapısını etkilemeyecektir (kısıtlı bir gereklilik değildir)
  • Bu "yedek motor" otomatik olarak çalışacaktır.

Ana sorun: bir veritabanının değiştirildiğini algılama. Sorunun ilk kısmı (DDL değişiklikleri) DDL tetikleyicileri kullanılarak çözülebilir . Ancak veri değişiklikleri (DML değişiklikleri) bir sorundur. Değişiklikleri (performans, genişletilmiş nesnelerin yönetimi ...) izlemek için tüm veritabanlarının tüm tablolarına DML tetikleyicileri uygulamak imkansızdır. Yedekleme altyapısı, her veritabanını yedeklemeye hazır olarak işaretlemek için tüm değişiklikleri izlemelidir.

  • Veri Yakalama Değiştir bir çözümdür ama çok ağır görünüyor (SQL Server Enterprise Edition da gerektirir).

  • Başka bir yol, veritabanı dosyası değişikliklerini (boyut veya son değişiklik zamanı) izlemektir, ancak düzgün çalışmaz: Bir veritabanı, ayrılmış tüm boş alanı aştığında ve sp_spaceused bir çözüm olmadığında boyutunu değiştirebilir .

  • İzleme bir çözümdür, ancak performans sorunlarına neden olur ve ek yönetim gerektirir.

Diğer veritabanı yönetimi nesnelerini (istatistikler gibi) etkilemeden gerçek veritabanı kullanım boyutunu hesaplamak için herhangi bir çözüm var mı? Bir tablonun verilerinde tablonun boyutunu değiştirmeyen bir değişikliğin tetiklenmeyeceğini (sanırım), ama hiç yoktan iyidir. Gerçekten SQL Server 2008 için doğrudan veya dolaylı bir çözüm arıyorum.

Yorumlarınız, çözümleriniz ve düşünceleriniz için teşekkür ederiz.

KATMA:

İşte çözüm ( Marian sayesinde ):

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%')
    )

Bunu bir işin parçası olarak mı uyguladınız yoksa ??? Ben kendim için bir changelog biraz olabilir böylece önceki çıkış 24 saatten bir dizine tüm değişiklikleri (örneğin 2 am) günlük çıkış yöntemi var isteriz.
jcolebrand

@jcolebrand evet, yaptım. Benim durumumda herhangi bir veritabanı etkinliğini kontrol etmek ve sonra (tam veya diferansiyel) yedekleme yapmak zorunda. Ben fn_dblog işlevi döner LSN (günlük kaydının birincil anahtarı) kontrol ediyorum. Hepsi bu. Sizin durumunuzda işe yarayacağını sanmıyorum. Ben fn_dblog tarafından döndürülebilir verilerin tüm özelliklerini araştırmadım, ama bununla ilgili tüm bilgileri döndürmez düşünüyorum. Gördüğünüz gibi, ona birçok sistem tablosu katıldı. Kolay olsaydı, normal, ucuz araçlar bir sürü olurdu :)
garik

Yanıtlar:


7

Bir fikir, her gün bir anlık görüntü oluşturmak ve bir dosya monitörü kullanarak diskteki anlık görüntü dosya boyutunu izlemek olacaktır. Anlık görüntü yalnızca veri eklendiğinde boyutunu artırıyor, bu nedenle gerçek boyutu (rapor edilen boyut) izlemek için bir araç bulmanız geçerli bir fikir olacaktır.

Şimdi .. Bunu ben kullanmadım, bu yüzden size teknik bilgiler veremem :-).

Başka bir fikir, günlüklerden işlemleri okuyan forumlarda (db_fnlog .. veya başka bir şey) gördüğüm bazı işlevlerle her db'nin işlem günlüğünü (tabii ki tam kurtarma modunu kullanıyorsanız) doğrulamak olacaktır. ve silmeniz / eklemeniz / güncellemeniz olup olmadığına bakın.

Bunlar yapmak kolay bir şey değil ama umarım onları faydalı bulacaksınız.

PS: günlük okuma fonksiyonu ile makale bulundu (bu fndblog, bu arada :-): Jens K. Suessmeyer tarafından işlem günlüğünü okuyun .


1
Ben db dosya boyutları hakkında, ama ile oluşturulan anlık görüntü yerel dosya hakkında konuşmak değildi: yyydb anlık görüntü olarak veritabanı xxxdb oluşturmak. Anlık görüntülerle ilgili ayrıntıları burada bulabilirsiniz: msdn.microsoft.com/en-us/library/ms175158.aspx .
Marian

1
  • DDL değişiklikleri için Varsayılan İz'i okuyabilirsiniz .
  • CDC'nin biraz ağır olduğunu düşündüğünüz için DML değişiklikleri için, yalnızca ilgili olayları izleyen kendi hafif sunucu tarafı izlemenizi çalıştırabilirsiniz

1

DDL değişiklikleri için DDL Tetikleyicileri, Ancak DML Değişiklikleri için 3 farklı seçenek kullanmayı deneyebilirsiniz

1) Değişikliği izleme 2) CDC (Veri Yakalama değiştir) 3) Denetim Özelliği

Değişim izleme için .. aşağıdaki bağlantıyı görebilirsiniz http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

Bu değişiklik izleme yalnızca tablonun değiştiği veya değişmediği durumlarda kullanılacaktır ... ancak hangi verilerin değiştiğini bulmak çok zordur .. Hangi verilerin değiştiğini bulmak istiyorsanız Chnage data Capture'a gidebilirsiniz.

Sqlserver'daki Aduit için .. aşağıdaki bağlantıyı kontrol edebilirsiniz http://blogs.msdn.com/b/manisblog/archive/2008/07/21/sql-server-2008-auditing.aspx


1
+1, ancak CDC Enterprise Edition ile birlikte gönderildi
garik

1

DML değişiklikleri için aşağıdaki yerel SQL Server denetim özelliklerinden herhangi birini kullanabilirsiniz:

  • SQL Server Değişiklik Takibi
  • SQL Server Veri Yakalama Değişikliği
  • SQL Server Denetimi

Her birinin avantajları ve dezavantajları vardır, ancak Denetim Microsoft tarafından sunulan en son sürümdür, bu nedenle mevcut ve gelecekteki çözümlerinizi onunla sarmak iyi bir fikir olacaktır.

Yalnızca Denetim özelliğinin Kim / Ne Zaman / Nasıl Yapıldığı hakkında bilgi verdiğini unutmayın


0

İzleme dosyasını kullanarak ddl değişikliklerini algılayabilirsiniz. aşağıda değişiklikleri almak için komut dosyasıdır.

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

Bu komut dosyasını kullanarak tablodaki ve saklı yordamdaki herhangi bir değişikliği algılayabilirsiniz:

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')
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.