Déterminer comment un changement de schéma s'est produit?


21

Quelque chose de grave s'est produit hier.

Une vue créée il y a quelque temps a été modifiée par quelqu'un qui a finalement rompu les rapports. Malheureusement. quelqu'un (sciemment ou inconsciemment) a fait cette modification dans la base de données PRODUCTION.

Ma question: existe-t-il un moyen (script / logiciel / freeware, etc.) par lequel nous pouvons savoir qui (nom d'utilisateur) a effectué cette modification, afin que je puisse révoquer l'accès à la base de données de production pour cet utilisateur.

Si ma question n'est pas claire, veuillez commenter.

Réponses:


36

Celui-ci est consigné dans la trace par défaut, tant qu'il est activé et n'a pas survolé entre-temps, il devrait apparaître dans le rapport "Historique des modifications de schéma".

Pour y accéder dans Management Studio, cliquez avec le bouton droit sur la base de données puis, dans le menu contextuel, choisissez Reports -> Standard Reports -> Schema Changes History

Pour récupérer les mêmes informations via TSQL, vous pouvez utiliser

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*/ )

Merci Martin, j'ai exécuté la requête en remplaçant 'FOO' par ma vue mais cela n'a rien retourné. Une idée pourquoi cela se produit? Je n'ai pas exécuté sur le serveur, cependant
xorpower

1
@Xorpower - Je l'ai édité pour gérer l' Object:Createdévénement ainsi que la vue a été supprimée et créée plutôt que modifiée. Vous ne savez pas ce que vous entendez par ne pas exécuter sur le serveur? Vous devez bien sûr être connecté à la bonne instance, mais peu importe d'où vient la connexion tant que vous disposez des autorisations.
Martin Smith

Merci Martin, mais le résultat reste le même
xorpower

1
@Xorpower - Que
Martin Smith

3
@Xorpower - On dirait bien que la trace a survolé et que vous avez perdu les détails de plus de 11 heures environ. La trace par défaut ne conserve que 5 fichiers, puis supprime les plus anciens. Vous voudrez peut-être vérifier sur le système de fichiers sur le serveur le dossier juste pour vérifier que c'est certainement le cas. Vous pouvez obtenir le chemin du dossier à partir deSELECT path FROM sys.traces where is_default=1
Martin Smith

19

Martin a déjà indiqué la meilleure avenue, la trace d'audit administratif qui est généralement activée (sauf si elle a été explicitement désactivée). Si vous ne trouvez pas les informations dans la trace d'administration (a été désactivée ou recyclée), vous pouvez récupérer les informations à partir des sauvegardes du journal. Puisqu'il s'agit d'une base de données de production, je suppose que vous avez un cycle de sauvegarde régulier, avec des sauvegardes complètes périodiques et des sauvegardes de journaux. Vous devrez restaurer, sur un serveur distinct, la base de données à peu près au moment de l'incident afin que la DDL se trouve dans le journal restauré actuel. Il suffit ensuite d'utiliser fn_dblog()et d'inspecter le journal.

Une façon consiste à passer par les opérations de début de transaction:

select [Begin Time], [Transaction Name], [Transaction SID], * 
from fn_dblog(null, null)
where Operation = 'LOP_BEGIN_XACT';

Si le a ALTER VIEWété émis dans une transaction autonome (c'est-à-dire non entouré de BEGIN TRANSACTION/ COMMIT), il démarrera une transaction nommée CreatProc transaction. Recherchez-le et [Transaction SID]c'est le SID de connexion que vous souhaitez.

Une autre possibilité consiste à rechercher la transaction qui a acquis un SCH_M sur la vue que vous souhaitez:

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

Notez que si la vue a été modifiée par DROP suivi de CREATE, l'ID d'objet a probablement été modifié, mais au moins vous obtiendrez la transaction qui a fait la dernière CREATE (l'ID d'objet actuel de la vue dans la base de données restaurée). Avec l'ID de transaction, vous revenez en arrière et récupérez les informations de début de transaction:

select [Begin Time], [Transaction Name], [Transaction SID], *
from fn_dblog(null, null)
where [Transaction ID] = '...'
and Operation = 'LOP_BEGIN_XACT';

Le [Transaction SID] est, encore une fois, votre gars. Utilisez SUSER_SNAMEpour récupérer le nom de connexion à partir du SID de connexion. Si le SID est 0x01, cela signifie que la connexion était sa, ce qui signifie que toute personne connaissant le samot de passe aurait pu le faire.


2
Bon conseil sur la lecture des fichiers journaux. Cela est pratique si quelqu'un a désactivé les traces par défaut.
StanleyJohns

Que faire si le SID de transaction est nul?
evictednoise

@evictednoise veuillez publier les enregistrements de journaux pertinents (dans une question distincte). Il peut y avoir plusieurs raisons et les enregistrements du journal aideraient à déterminer la cause réelle.
Remus Rusanu

6

Non, sauf si vous l'avez connecté via un déclencheur DDL ou autre

Vous voulez voir qui en tant que droits ALTER dans cette base de données ou appartenance au rôle sysadmin / db_owner / ddl_admin. Ce serait mieux comme un examen général plutôt qu'une chasse aux sorcières. Il y a probablement d'autres personnes autorisées à apporter des modifications non approuvées et non autorisées


0

Si vous ne l'avez pas déjà fait, vous pouvez consulter le rapport Historique des modifications de schéma disponible dans SQL Server Management Studio. Il semble que SQL Server enregistre les modifications par défaut ( trace par défaut ) et vous devriez pouvoir afficher ces données via ce rapport. La seule chose regrettable est que ces fichiers de trace sont automatiquement supprimés / reconduits au fil du temps, de sorte que les données peuvent déjà avoir disparu. Bonne chance!


Oups, tant pis. Je vois que Martin Smith a déjà fait référence à ce rapport dans sa réponse. Je vais laisser ceci ici au cas où l'un des liens serait utile.
Mark Madej
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.