Comment une base de données SQL Server 2005 perdrait-elle quelques jours de données?

Question

J'ai vraiment besoin d'aide ici.

Je suis le propriétaire d'une application de base de données SQL Server qui a perdu trois jours de données! Je ne peux pas comprendre comment ou pourquoi.

Voici donc la configuration.

• SQL Server 2005 Base de données d'édition standard 32 bits sur le serveur Windows 2000. (Base de données B)

• base de données est en mode de récupération simple

• La base de données est connecté en tant qu'abonné à une autre base de données (SQL Server 2005 Enterprise Edition 64 bits sur l'entreprise Win2k3) en utilisant la réplication de fusion continue SQL Server. (Base de données A)

La base de données B a été redémarrée la nuit X dans le cadre du redémarrage planifié. Lorsque la base de données est revenue, elle a été utilisée normalement pendant quelques jours et les données ont été créées parfaitement.

Mais hier, jour X + 4, il a perdu beaucoup de données. La base de données B est sur un serveur avec une autre instance de SQL Server et les deux ont commencé à manquer de mémoire (en conflit les uns avec les autres).

Voici la séquence d'événements du journal des événements lorsque je pense que cela s'est produit. Je sais que les données sont manquantes à cause de mes journaux d'audit et qu'un utilisateur a pris une capture d'écran de certaines données avant qu'elles ne soient supprimées.

Alors voici mon dilemme ... comment cela est-il arrivé?

Comment des données de plusieurs jours peuvent-elles manquer dans DatabaseB ?? (il est par la suite absent de la publication db également!)

Le tronqué avec le champ Appdomain a-t-il entraîné l'effacement des données du journal?

Toutes et toutes les théories considérées. Si quelqu'un a besoin de plus de données, je peux l'ajouter.

Aide!

Answer 1

La réplication de fusion est implémentée avec des déclencheurs, elle n'a donc pas besoin d'une récupération complète. Est-il possible que quelqu'un ait désactivé tous les déclencheurs dans la base de données? c'est facile à faire DISABLE TRIGGER [base de données] Cela représenterait au moins la perte de données par l'abonné.

Ces lignes d'attribut dans le journal ne signifient pas grand-chose, c'est le SQL CLR qui vous indique ses assemblages de déchargement pour libérer de la mémoire. & puis de les recharger plus tard. Tronquer le journal supprime les parties inactives qui ont été validées sur le disque, le fait que le modèle de récupération soit simple signifie qu'il ne sert à rien de tronquer le journal, comme le suggère le message.

Rien de tout cela explique pourquoi les données ont disparu sur les deux serveurs. Il doit y avoir quelque chose d'autre qui a causé cela.

Comment avez-vous vérifié que pendant les 4 jours où tout a été 'créé parfaitement bien' que c'était en réalité? avez-vous des sauvegardes de ces jours? pouvez-vous voir des disques avec des timbres de temps de ces jours?

Est-il possible qu'il y ait un fantôme dans la machine qui a effectué une restauration sans vous le dire?

Answer 2

Ce n'est pas la réponse que vous voulez entendre, mais en un mot, SQL Server ne "perd" pas de données. Quelqu'un l'a supprimé. Si vous avez la base de données en mode de récupération complète, vous pouvez utiliser un produit comme Quest LiteSpeed ​​pour lire les journaux et identifier exactement comment il a été supprimé, mais en mode simple ... désolé, monsieur, mais vous n'avez pas de chance.