Je l'ai trouvé utile lors de la suppression d'une table avec un grand nombre de lignes pour supprimer des lignes par lots de 5000 environ (je teste généralement pour voir quelle valeur fonctionne le plus rapidement, parfois c'est 5000 lignes, parfois 10 000, etc.) . Cela permet à chaque opération de suppression de se terminer rapidement, plutôt que d'attendre longtemps qu'une instruction supprime 400 millions d'enregistrements.
Dans SQL Server 2005, quelque chose comme ceci devrait fonctionner (veuillez tester d'abord, bien sûr) :
WHILE EXISTS ( SELECT * FROM giganticTable WHERE exp_date < getDate())
BEGIN
DELETE TOP(5000) FROM giganticTable WHERE exp_date < getDate()
END
Je verrais ce que la suppression par lots fait à la taille du fichier journal. S'il fait toujours exploser les journaux, vous pouvez essayer de changer le modèle de récupération en Simple , en supprimant les enregistrements, puis en revenant à Bulk Logged, mais uniquement si le système peut tolérer la perte de certaines données récentes. Je ferais certainement une sauvegarde complète avant d'essayer cette procédure. Ce thread suggère également que vous pouvez configurer une tâche pour sauvegarder les journaux avec la troncature uniquement spécifiée, ce qui pourrait être une autre option. J'espère que vous avez une instance avec laquelle vous pouvez tester, mais je commencerais par les suppressions par lots pour voir comment cela affecte les performances et la taille du fichier journal.
