it-swarm-eu.dev

Jak detekovat jakékoli změny v databázi (DDL a DML)

Na serveru SQL mého klienta je mnoho databází. Tyto databáze jsou ve vývoji, takže vývojáři mohou navrhovat, refaktorovat, provádět úpravy dat atd. Existují některé databáze, které se zřídka mění. Můj klient musí všechny uchovávat v bezpečí (zálohovat) a trávit nějaký čas správou životního prostředí. (Ve společnosti není pozice administrátora DB.) Po dlouhé diskusi se klient kvůli snadné obnově rozhodl používat denní strategii plné zálohy.

Zde je shrnutí situace:

  • Počet databází se může každý den lišit.
  • Databáze, které byly změněny (což znamená, že došlo ke změně dat a/nebo struktury), se zálohují.
  • Databáze, které nebyly změněny, NENÍ zálohovány.
  • Řešení nemá dopad na strukturu databáze (není to omezen požadavek)
  • Tento „záložní stroj“ musí fungovat automaticky.

Hlavní problém: jak zjistit, že databáze byla změněna. První část problému (změny DDL) lze vyřešit pomocí DDL triggery . Změny dat (změny DML) jsou však problémem. Je nemožné použít spouštěče DML na všechny tabulky všech databází ke sledování změn (výkon, správa rozšířených objektů ...). Zálohovací stroj musí sledovat všechny změny, aby označil každou databázi jako připravenou k zálohování.

  • Change Data Capture je řešení, ale zdá se být příliš těžké (vyžaduje také SQL Server Enterprise Edition).

  • Dalším způsobem je sledovat změny v souborech databáze (velikost nebo čas poslední změny), ale nefunguje to správně: Databáze může změnit svou velikost, když překročí všechny vyhrazené volné místo a sp_spaceused není řešením.

  • Trasování je řešení, ale způsobuje problémy s výkonem a vyžaduje další správu.

Existují nějaká řešení pro výpočet skutečné velikosti využití databáze bez dopadu na jiné objekty správy databáze (jako jsou statistiky ..)? Připouští se, že změna údajů v tabulce, která nezmění velikost tabulky, by se nespustila (myslím), ale je lepší než nic. Opravdu hledám přímé nebo nepřímé řešení pro SQL Server 2008.

Děkujeme za jakékoli připomínky, řešení a myšlenky.

PŘIDANÉ:

Zde je řešení (díky 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%')
    )
13
garik

Jedním z nápadů by bylo vytvořit snímek každý den a sledovat velikost souboru snímku na disku pomocí monitoru souborů. Snímek zvětšuje jeho velikost pouze tehdy, když tam jsou přidána data, takže by byl platný nápad, kdybyste našli nástroj pro sledování skutečné velikosti (nahlášená velikost).

Teď .. Nepoužil jsem to, takže vám nemůžu poskytnout technické informace :-).

Dalším nápadem by bylo ověření protokolu transakcí každého db (pokud na nich samozřejmě používáte režim úplného zotavení) pomocí nějaké funkce, kterou jsem viděl na fórech (db_fnlog .. nebo tak něco), která čte operace z protokolu a zjistěte, zda máte nějaké smazání/přílohy/aktualizace.

Nejsou to jednoduché věci, ale doufám, že pro vás budou užitečné.

PS: našel článek s funkcí čtení protokolu (je to fndblog, mimochodem :-): Přečtěte si protokol transakcí Jens K. Suessmeyer .

7
Marian
  • Pro změny DDL si můžete přečíst Default Trace .
  • Pro úpravy DML, protože zjistíte, že CDC je trochu těžké, můžete spustit vlastní lehké trasování na straně serveru, které sleduje pouze relevantní události.
1
Nomad

Pro změny DML můžete použít kteroukoli z následujících nativních funkcí auditování SQL Serveru:

  • Sledování změn serveru SQL
  • SQL Server Change Data Capture
  • Auditování SQL serveru

Každý má své výhody a nevýhody, ale auditování je nejnovější, které společnost Microsoft představila, takže by bylo dobré sestavit vaše současná i budoucí řešení, která jsou s ním zabalena.

Všimněte si, že pouze funkce Auditování poskytuje informace o tom, kdo/kdy/jak

1
Ivan Stankovic

Pro DDL změny, které DDL Triggers, ale DML Změny, můžete zkusit použít 3 různé možnosti

1) Změna sledování 2) CDC (Zachycení změn dat) 3) Funkce auditu

Pro sledování změn .. můžete vidět níže uvedený odkaz http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

toto sledování změn bude použito pouze v případě, že se tabulka změnila nebo ne ... ale je velmi obtížné zjistit, která data se změnila .. pokud chcete zjistit, která data se změnila, můžete jít do Chnage Data Capture.

Pro Aduit v sqlserveru .. můžete zkontrolovat níže uvedený odkaz http://blogs.msdn.com/b/manisblog/archive/2008/07/21/sql-server-2008-auditing.aspx

1
Anil Inampudi

Jakékoli změny ddl můžete zjistit pomocí trasovacího souboru. Níže je skript pro získání změn.

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

Pomocí tohoto skriptu můžete zjistit jakékoli změny v tabulce a uložené proceduře:

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')
0
Anvesh