Comment détecter toute modification à une base de données (DDL et DML)

dba.stackexchange https://dba.stackexchange.com/questions/985

  •  16-10-2019
  •  | 
  •  

Question

Il y a beaucoup de bases de données sur le serveur SQL de mon client. Ces bases de données sont en cours de développement, afin que les développeurs peuvent concevoir, refactoring, faire des modifications de données et ainsi de suite. Il y a des bases de données qui changent rarement. Mon client doit garder toutes les sécurité (soutenu) et passer un peu de temps à gérer l'environnement. (Il n'y a pas de position de l'administrateur DB à la société.) Après une longue discussion, le client a décidé d'utiliser une stratégie de sauvegarde quotidienne complète, en raison de la facilité de restauration.

Voici donc le résumé de la situation:

  • Nombre de bases de données peut varier tous les jours.
  • Les bases de données qui ont été modifiées (données sens et / ou la structure ont été modifiés) doit être sauvegardé.
  • Les bases de données qui ne sont pas modifiées doivent pas être sauvegardé.
  • Solution ne doit pas la structure de base de données d'impact (il est pas à l'exigence limitée)
  • Ce "moteur de sauvegarde" doit fonctionner automatiquement.

Le principal problème. Comment détecter une base de données a été modifiée La première partie du problème (DDL change) peut être résolu en utilisant déclencheurs DDL. Mais les changements de données (changements DML) sont un problème. Il est impossible d'appliquer les déclencheurs DML à toutes les tables de toutes les bases de données pour suivre les changements (performances, gestion des objets étendus ...). Le moteur de sauvegarde doit suivre toutes les modifications pour marquer chaque base de données prêts à sauvegarder.

  • changement Data Capture est une solution mais semble trop lourd (nécessite SQL Server Enterprise Edition ainsi).

  • Une autre façon de suivre les changements de fichiers de base de données (taille ou dernière modification), mais il ne fonctionne pas correctement: base de données A peut changer sa taille quand il dépasse tout l'espace libre réservé et sp_spaceused n'est pas une solution.

  • Le traçage est une solution, mais il provoque problèmes de performance et exige que la direction supplémentaire.

Y a-t-il des solutions pour calculer la taille de l'utilisation de la base de données réelle sans impact sur les autres objets de gestion de base de données (comme les statistiques ..)? Certes qu'un changement aux données d'une table qui ne change pas la taille de la table ne déclencherait pas (je pense), mais il vaut mieux que rien. Vraiment, je suis à la recherche d'une solution directe ou indirecte pour SQL Server 2008.

Merci pour tous les commentaires, les solutions et les pensées.

AJOUTÉE:

Voici la solution (grâce à 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%')
    )
Était-ce utile?

La solution

Une idée serait de faire un instantané tous les jours et surveiller la taille du fichier d'instantané sur le disque à l'aide d'un moniteur de fichiers. L'instantané augmente sa taille que lorsque les données sont ajoutées là, donc ce serait une idée valable si vous trouveriez un outil pour surveiller la taille réelle (taille indiquée).

.. Je n'ai pas utilisé cela, donc ne peut pas vous donner un aperçu technique: -.)

Une autre idée serait de vérifier le journal des transactions de chaque db (si vous utilisez le mode de récupération complète sur eux, bien sûr) avec une fonction que j'ai vu sur les forums (db_fnlog .. ou quelque chose) qui lit les opérations du journal, et voyez si vous avez des suppressions / insertions / mises à jour.

Ce sont pas des choses faciles à faire .. mais j'espère que vous les trouverez utiles.

PS: trouvé l'article avec le journal fonction de lecture (il est fndblog, par la façon :-): Read le journal des transactions par Jens K. Suessmeyer .

Autres conseils

  • Pour DDL changements que vous pouvez lire la par défaut Trace.
  • Pour les modifications DML puisque vous trouvez CDC être peu lourd, vous pouvez gérer votre propre trace côté serveur léger qui trace seulement les événements pertinents

Pour vous DDL change DDL Triggers, Mais DML Les modifications que vous pouvez essayer d'utiliser 3 différentes options

1) Suivre 2) CDC (Change de capture de données) 3) Fonction de vérification

Pour le suivi des changements .. vous pouvez voir le lien ci-dessous http://www.mssqltips.com/sqlservertip/1819/using-change-tracking-in-sql-server-2008/

le suivi des modifications sera utilisé wheather la table a changé ou non ... mais il est très difficile de trouver les données a changé .. si vous voulez trouver les données a changé alors vous pouvez aller chnage la capture de données.

Pour Aduit SQLServer ..vous pouvez vérifier le lien ci-dessous   http: //blogs.msdn .com / b / manisblog / archives / 2008/07/21 / sql-server-2008-auditing.aspx

Pour DML les changements que vous pouvez utiliser l'un des followinh audit natif SQL Server propose:

  • Suivre SQL Server
  • capture des modifications de données SQL Server
  • Audit SQL Server

Chacun a ses avantages et ses inconvénients, mais l'audit est le dernier introduit par Microsoft, donc ce serait une bonne idée de construire vos solutions actuelles et futures enveloppées avec elle.

Notez que seule la fonction d'audit fournit des informations sur Qui / Quand / Comment

Vous pouvez détecter tout changement ddl en utilisant le fichier de trace. ci-dessous est script pour obtenir des changements. 

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

Vous pouvez détecter toute modification sur la table et la procédure stockée en utilisant ce script: 

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')
Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top