Est-il possible de déterminer qui a laissé tomber une table?

Un tableau de la base de données de production a «mystérieusement» disparu.

Quelqu'un connaît-il un moyen de diagnostiquer ce qui lui est arrivé? Et qui l'a fait?

Edit 1: Ceci est une application interne, avec une sécurité faible. Toutes les applications (sauf la mienne bien sûr ;-) sont vulnérables à l'injection SQL, mais nos utilisateurs sont très peu sophistiqués et le nom de la table n'était pas celui qui pourrait être immédiatement évident, donc je ne pense pas qu'il s'agissait d'une injection SQL (pas que cela importe ... sorte de sortir de la portée de la question).

Edit 2: Aussi, juste un FYI; cette table existe depuis longtemps, elle n'a donc pas été «annulée» lors d'une restauration.

Vous pourrez peut-être obtenir les informations du journal en utilisant la fonction undocumented :: fn_dblog qui interprète les enregistrements du journal. Je suis en train d'enseigner un cours de récupération après sinistre en ce moment, mais si vous pouvez attendre 2-3 heures, je posterai comment le faire pour vous - devrait également pouvoir obtenir le nom d'utilisateur sans avoir à acheter d'outils ( J'avais l'habitude de tourner autour du journal une tonne en 2000 alors que j'écrivais un tas de code d'analyse de journal interne que DBCC CHECKDB utilise en 2000).

[Modifié pour inclure les instructions] Ok - j'ai terminé l'enseignement et j'ai créé un article de blog pour vous montrer comment analyser le journal en 2000, 2005, 2008 pour savoir quand la table a été supprimée et qui l'a fait. Consultez mon article de blog sur Découvrir qui a déposé une table à l'aide du journal des transactions . [/Éditer]

Avez-vous toujours le journal des transactions autour? Dans quel modèle de récupération se trouve la base de données? Si c'est SIMPLE, ne faites rien qui pourrait provoquer un point de contrôle. Si c'est PLEIN ou BULK_LOGGED, ne faites pas de sauvegarde de journal. Dans les deux cas, le journal sera tronqué et vous risquez de perdre la possibilité de regarder en arrière dans le journal, bien que j'aie inclus un indicateur de trace dans le billet de blog qui peut également vous aider.

Merci

PS Une façon d'empêcher les chutes de table en 2000 sans ajouter de sécurité est de créer une vue schemabound simple dessus - DROP TABLE échouera si la vue existe.

C'était peut-être Little Bobby Tables ...

Vous pourrez peut-être récupérer ces informations dans les journaux SQL.

Si le journal de suivi par défaut est en cours d'exécution, toutes les informations sont stockées dans le dossier du journal. Vous devriez pouvoir voir quand l'objet (table) a été supprimé et par quelle connexion qui l'a fait. Mais ce type d'autorisation ne devrait être accordé qu'aux DBA de toute façon

J'essaie de réparer un MSDB corrompu. Désolé, je ne suis pas en mesure d'élaborer.

Exécutez-les et cela devrait donner une idée générale de l'endroit où chercher, en supposant que votre trace par défaut est activée.

SELECT * FROM :: fn_trace_getinfo (par défaut)

SELECT t.EventID, t.ColumnID, e.name as Event_Description, c.name as Column_Description FROM :: fn_trace_geteventinfo (1) t JOIN sys.trace_events e ON t.eventID = e.trace_event_id JOIN sys.trace_columns c ON t.columnid = c.trace_column_id

Le seul moyen de découvrir ces informations est de lire le journal des transactions (en supposant qu'il soit en mode de récupération complète).

Deux façons de procéder:

• Outils tiers tels que ApexSQL Log ou SQL Log Rescue (gratuit mais SQL 2000 uniquement)
• Utilisation de commandes telles que DBCC LOG ou fn_dblog - dont aucune n'est bien documentée malheureusement

Dans SSMS, vous pouvez essayer de cliquer avec le bouton droit sur le dB et de naviguer dans Rapports -> Rapports standard -> Historique des modifications de schéma.

Faites un clic droit sur le rapport et Excel «SaveAs» et trouvez votre nom d'objet.

Vous ne pourrez rien obtenir si le serveur a été redémarré plus de cinq fois après la chute de l'objet.