Maintenance du journal des transactions lors du passage à la récupération simple

Contexte:

J'ai récemment hérité de plus de 50 serveurs SQL Server avec plus de 450 bases de données. Les sauvegardes nocturnes sont d'environ 8 To et, il va sans dire, nous utilisons plus d'espace disque que nous le souhaiterions. Toutes les bases de données sont définies sur récupération complète et les journaux de transactions n'ont jamais été sauvegardés. J'ai parcouru tous les serveurs SQL et identifié ceux de faible priorité qui n'ont besoin que d'une sauvegarde nocturne et où une journée de perte de données est acceptable.

Question:

Je passe de nombreuses bases de données de faible priorité au SIMPLEmode de récupération FULL. Les journaux de transactions existants seront-ils tronqués (lorsque des points de contrôle seront créés)? Certains des journaux de transactions existants sont de 50 à 100 Go; quelle est la meilleure approche pour déterminer à quoi je dois les réduire pour aller de l'avant? Je ne veux évidemment pas les garder aussi gros. Ou vont-ils rétrécir d'eux-mêmes au fil du temps (je ne pense pas qu'ils le feront)?

Avant de passer d' FULLau SIMPLEmodèle de récupération, demandez-vous comment les données que vous pouvez vous permettre de perdre. Pour les bases de données où en cas de sinistre vous êtes prêt à restaurer la dernière sauvegarde de base de données, cela SIMPLEdevrait être OK. Si ce n'est pas le cas, restez avec FULL.

Pour réduire le LDFfichier à une taille aussi petite que possible, suivez les étapes données par Kimberly Tripp ici: 8 étapes pour améliorer le débit du journal des transactions

1. Attendez le moment où il y a une faible activité sur la base de données

2. Exécuter dans SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Modifiez la taille du fichier journal des transactions:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)

Je passe beaucoup de bases de données en mode de récupération SIMPLE à partir du mode de récupération FULL (les T-Logs et la récupération ponctuelle ne sont pas nécessaires). Les journaux de transactions existants seront-ils tronqués (lorsque des points de contrôle seront créés)?

Dans un modèle de récupération simple, le moteur de base de données émet des points de contrôle automatiques et sa fréquence est déterminée par l' intervalle de récupération (paramètre de configuration de serveur avancé) ou si le journal est plein à 70%.

À moins que vous ayez des transactions de longue durée qui retarderont la troncature du journal, un point de contrôle automatique tronquera la partie inutilisée du T-log.

Certains des journaux de transactions existants sont de 50 à 100 Go, quelle est la meilleure approche pour déterminer à quoi je dois les réduire pour aller de l'avant. Je ne veux évidemment pas les garder aussi gros.

Si le modèle de récupération de la base de données est défini sur PLEIN pour les bases de données contenant 50 à 100 Go de journaux T, vous devez commencer à effectuer des sauvegardes de journaux T fréquentes. N'oubliez pas que dans le modèle de récupération complète, une fois qu'une chaîne de sauvegarde des journaux a été établie, même les points de contrôle automatiques ne provoquent pas la troncature du journal.

En dernier recours, vous pouvez tronquer le fichier journal, puis effectuer immédiatement une sauvegarde complète, puis commencer à effectuer des sauvegardes T-log afin de pouvoir effectuer une récupération ponctuelle en cas de sinistre.

Ou vont-ils rétrécir d'eux-mêmes au fil du temps (je ne pense pas qu'ils le feront)?

Comme @TomTom l'a souligné, c'est une opération manuelle.

Lisez:

• Gérer la taille du fichier journal des transactions
• COMMENT RÉDUIRE LE JOURNAL DE SERVEUR SQL - Excellente écriture.
• Comment fonctionnent les points de contrôle et ce qui est enregistré - Par: Paul Randal

Nous ne pouvons pas répondre à bon nombre des questions. Quelle est la longueur d'une ficelle?

Certains des journaux de transactions existants sont de 50 à 100 Go, quelle est la meilleure approche pour déterminer à quoi je dois les réduire pour aller de l'avant.

Tant qu'ils doivent l'être. Je suggère de ne PAS rétrécir. Trunacate logs, revenez dans une semaine et voyez combien d'espace est utilisé, PUIS décidez. Mais VOUS devez répondre à celle-ci.

Les sauvegardes nocturnes mesurent environ 8 To et il va sans dire que nous utilisons plus d'espace disque que nous le souhaiterions.

Alors pourquoi les transformer en simples? Je veux dire, sérieusement.

Toutes les bases de données sont définies sur récupération complète et les journaux de transactions n'ont jamais été sauvegardés.

Un peu de logique vous dira que si vous les tronquez igf, vous utiliserez probablement BEAUCOUP moins d'espace pour les sauvegarder de toute façon. Le résultat peut être que vous pouvez bien les conserver en mode de récupération complète. Essayez d'abord. S'ils se rallient à un faible volume, etc., les sauvegardes de journaux seront beaucoup plus petites à l'avenir.

J'ai parcouru tous les serveurs SQL et identifié ceux à priorité faible qui n'ont besoin que d'une sauvegarde nocturne et des pertes de données pendant plusieurs jours même en cas de catastrophe ne sera pas un problème (bases de données de télécopie et autres choses du genre).

Oui. C'est jusqu'à ce que vous vous retrouviez devant le tribunal et que vous vous fassiez culpabiliser pour ne pas avoir de documents juridiques critiques. Savez-vous que les journaux de télécopie peuvent bien faire partie de ce que vous devez conserver pendant des années en tant qu'informations pertinentes pour l'entreprise? C'est comme ça dans ma juridiction (10 ans). Si vous êtes une société par actions U, il peut y avoir une surprise similaire (SOX). Si vous ne le faites pas, il est TRÈS mauvais en cour si vous voulez prouver que vous n'avez pas reçu de fax. Ou en a envoyé un. Personne ne se soucie de savoir si cela s'est produit tous les mois et vous avez des journaux plus récents - vous ne respectez pas les exigences de la loi. Assurez-vous que cela est signé par quelqu'un de TRÈS élevé, car votre entreprise non critique peut être votre raison de licencier.

Ou vont-ils rétrécir d'eux-mêmes au fil du temps (je ne pense pas qu'ils le feront)?

Et ils ne devraient pas faire ça. Le redimensionnement des journaux est une opération manuelle, sauf pour les bases de données à faible volume.