Comment serait vues & amp; procs référençant un autre journal cause cause de croître?

Question

J'ai 2 bases de données sur un serveur; appelons-les db A et B. La base de données A représente environ 11 Go, la base de données B est très petite (155 Mo). La base de données B contient des vues et des procédures qui accèdent et mettent à jour en permanence les données de la base de données A.

Ce qui est intéressant, c’est que le journal de la base de données B se développe rapidement, pour atteindre une taille énorme. Je pense qu’il a atteint environ 12 Go en moins d’une semaine. La base de données A ne grandit pas si vite.

Qu'est-ce qui pourrait faire que mon journal grossisse autant? Y a-t-il quelque chose qui se passe lorsque vous sélectionnez des données dans une autre base de données, ce qui entraînerait une telle croissance de mon journal?

Je sais que lorsque vous faites quelque chose de similaire avec une base de données sur un serveur différent, toutes les données sont transférées vers la base de données appelante avant d'être jointes et sélectionnées ... Je peux voir que cela provoque une croissance du journal, est-ce que la même chose pourrait se produire le même serveur?

Édition STD SQL2000 SP4
Modèle de récupération complète

Merci d'avance, John

BTW-Je me rends compte que changer mon modèle de récupération en Simple peut aider, mais j'aimerais savoir pourquoi cela se produit en premier.

Answer 1

Je ne vois pas pourquoi une simple instruction SELECT ajouterait quelque chose au journal des transactions, mais je n'ai pas beaucoup d'expérience avec les serveurs liés. Je ne peux donc pas dire avec certitude ce qui pourrait se passer en coulisse. .

Cependant, vous dites que "la base de données B contient des vues et des processus qui accèdent et mettent à jour en permanence les données de la base de données A.", alors que les données sous-jacentes existent dans la base de données A, car votre nouvelle application se connecte à la base de données B et utilise ses objets, il semble raisonnable que ces opérations soient enregistrées dans le journal de bord de B.

Mais ce n’est que conjecture de ma part. Pourquoi ne pas simplement inspecter le journal des transactions directement et voir si ce qu'il contient semble raisonnable? RedGate propose un explorateur de journaux gratuit fonctionnant avec SQL 2000 (voir http: // www. .red-gate.com / produits / SQL_Log_Rescue / index.htm ); Je ne l'ai utilisé qu'une seule fois auparavant, mais cela semblait bien fonctionner et cela m'a vraiment sauvé le bacon dans ce cas particulier.

Je dois admettre que je suis curieux de connaître les détails, mais dans votre cas, je serais tenté de supprimer ma curiosité et de traiter du fichier journal. Après tout, il ne s’agit que d’une mesure temporaire. Si la croissance du journal est un artefact des serveurs liés, elle doit se corriger une fois que vous avez terminé la nouvelle application et retiré la base de données A.

De plus, Godeke a souligné le point de vue des sauvegardes. Si votre fichier journal devient trop volumineux, sauvegardez-le plus souvent. La sauvegarde tronque le journal, mais uniquement en interne; c’est-à-dire que le pourcentage du fichier journal utilisé sera réduit, mais la taille réelle du fichier sur le disque ne changera pas tant que vous n’utiliserez pas DBCC SHRINKFILE.