web-dev-qa-db-fra.com

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

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.

sql-serverview
21
xorpower

Cela est consigné dans la trace par défaut donc, 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*/ )
36
Martin Smith

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 des sauvegardes de journaux. 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 alors 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 la ALTER VIEW a été émis dans une transaction autonome (c'est-à-dire non entouré de BEGIN TRANSACTION/COMMIT) puis il démarrera une transaction nommée CreatProc transaction. Recherchez-le et le [Transaction SID] 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. Utilisation SUSER_SNAME pour 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 mot de passe sa aurait pu le faire.

19
Remus Rusanu

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

6
gbn

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!

0
Mark Madej