Meilleur moyen de sauvegarder et de tronquer les journaux de transactions selon un calendrier

9

Je ne suis pas DBA, mais les choses étant ce qu'elles sont, je dois porter le chapeau DBA et configurer des plans de maintenance sur mon instance SQL Server.

Ainsi, depuis un certain temps, mon processus SSIS du jour au lendemain exécute une tâche d' exécution SQL pour effectuer les sauvegardes - essentiellement master.dbo.xp_create_subdirpour s'assurer que les dossiers de destination existent, puis BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

Chaque fois que cette tâche échouait, le reste du processus s'interrompait et j'obtenais une notification, et j'arrivais le lendemain matin pour remarquer que le lecteur des journaux de transactions était plein, et donc je les tronquais manuellement et avançais. .. jusqu'à ce que l'histoire se répète et que les journaux de transactions dépassent à nouveau l'espace disque disponible.

Le script "troncature manuelle" ressemble à ceci:

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

Je suis donc fatigué de cela, et j'ai décidé d'essayer de faire les choses correctement à la place, et de suivre les étapes ici et de créer un plan de maintenance réel :

Plan de maintenance SQL Server

Le fait est que je n'ai jamais fait cela auparavant, j'ai donc quelques questions:

  • La sauvegarde des journaux de transactions comme celui-ci les tronquera-t-elle automatiquement, ou dois-je faire autre chose?
  • Est-il correct d'exécuter simultanément des sauvegardes de données et de journaux de transactions? Sinon, quelle est la bonne façon de procéder?
  • Les fichiers de sauvegarde sont récupérés du jour au lendemain par un autre processus qui récupère tous les fichiers sur le serveur et les stocke ailleurs - serait-ce une bonne idée de faire expirer le jeu de sauvegarde après 2 jours? Dois-je les faire expirer?
  • Les tâches de nettoyage suppriment respectivement les "anciens" fichiers .bak et .trn sous les sous-dossiers de G:\Backups. Cela a-t-il du sens?
  • Serait-il préférable de le faire dans SSIS, afin que je puisse faire échouer mon ETL si / quand les sauvegardes échouent? Ou mon processus ETL devrait-il même s'en soucier?

Désolé si c'est trop de questions pour un poste, si nécessaire, je modifierai et poserai plusieurs questions à la place - je pense qu'elles sont toutes étroitement liées cependant.

Mathieu Guindon
la source
3
Pouvez-vous expliquer ce que vous entendez par "tronquer"? Voulez-vous dire que vous vous attendez à une sauvegarde du journal pour réduire le fichier journal? Dans quel but? Alors ça peut repousser?
Aaron Bertrand
3
Aussi, je vous suggère de lire cette question et ses réponses pour le fond avant d'aller plus loin: dba.stackexchange.com/q/29829/1186
Aaron Bertrand
3
Si vous n'avez besoin que d'une récupération quotidienne, restez en mode simple. (Pourquoi voudriez-vous passer à simple, puis revenir à plein? Que pensez-vous que cela accomplit?) Mais si le jour est tout lu, votre journal ne devrait pas changer de toute façon pendant la journée. Dans tous les cas, non, la sauvegarde du journal ne réduira jamais le fichier journal.
Aaron Bertrand
3
Si vous passez 6 mois en mode de récupération complète sans jamais effectuer de sauvegarde de journal, oui, vos fichiers journaux augmenteront. Cependant, si, comme vous le dites, votre seule activité de lecture pendant la journée, l'utilisation du mode de récupération complète est un gaspillage, simplifiez-la. Ensuite, le fichier journal ne grandira généralement pas du tout (car en mode de récupération simple, l'espace pour toutes les transactions, sauf les transactions actives, peut être réutilisé). Les administrateurs de base de données qui savent ce qu'ils font utilisent généralement le mode de récupération complète (afin qu'ils puissent restaurer à un moment donné), dimensionnent leurs fichiers journaux de manière appropriée et effectuent des sauvegardes de journaux suffisamment fréquemment pour que les fichiers journaux ne se développent pas.
Aaron Bertrand
3
Puisque vous dites que vous n'avez pas besoin d'une récupération ponctuelle, je ne sais pas pourquoi vous considérez même le modèle de récupération complète comme une option.,
Aaron Bertrand

Réponses:

7

Seul SSIS de nuit effectue des écritures, le jour est entièrement lu - je n'ai besoin que d'une récupération quotidienne.

Vous devez choisir votre modèle de récupération en fonction des besoins de votre entreprise:

  • Quelle quantité de données les entreprises peuvent-elles perdre et survivre en même temps?

Sur la base de la réponse ci-dessus, vous devez choisir soigneusement votre modèle de récupération de base de données .

En termes simples (sans discuter du modèle de récupération enregistré en masse) ,

  • Un modèle de récupération complète permet des sauvegardes de journaux qui permettent une récupération ponctuelle.
    • La troncature du journal peut se produire lorsque vous effectuez des sauvegardes du journal des transactions, c'est-à-dire que l'espace du fichier journal sera réutilisé après chaque sauvegarde du journal et ne se gonflera pas!
  • Un modèle de récupération simple vous permet uniquement d'effectuer des sauvegardes complètes. La récupération ponctuelle n'est pas possible.
    • La troncature du journal ne peut se produire que lorsqu'un point de contrôle se produit (manuellement ou automatiquement), c'est-à-dire que puisque vous effectuez des sauvegardes complètes régulières, vous n'avez pas à vous soucier du journal des transactions car CHECKPOINT se chargera de réutiliser la partie inactive du fichier journal.

N'oubliez pas que la troncature du journal n'est PAS une réduction physique de la taille du fichier journal des transactions. Cela signifie que la partie inactive du fichier journal des transactions est marquée comme réutilisable .

Par conséquent, vous devez correctement dimensionner votre fichier journal des transactions (et vos fichiers de données). La croissance du fichier journal déclenchera les événements de croissance automatique (si votre base de données est définie sur la croissance automatique en dernier recours). Vérifiez ma réponse - Croissance automatique - Pourcentage d'utilisation?


Je vous suggère fortement d' abandonner les plans de maintenance et de mettre en œuvre [une solution de maintenance intelligente - simple, flexible et conforme aux meilleures pratiques] - 5 . - La solution de sauvegarde d'Ola (et la solution de maintenance d'index également).


permet de répondre à vos questions:

La sauvegarde des journaux de transactions comme celui-ci les tronquera-t-elle automatiquement, ou dois-je faire autre chose?

Veuillez ne pas ajouter de sauvegardes ni les faire expirer. Ils créent un gros gâchis. Utilisez INITet effectuez des sauvegardes de journal distinctes avec horodatage. Facile à maintenir. Utilisez la solution de sauvegarde d'Ola pour cela. La solution est également flexible pour supprimer les anciennes sauvegardes.

Est-il correct d'exécuter simultanément des sauvegardes de données et de journaux de transactions? Sinon, quelle est la bonne façon de procéder?

Une sauvegarde complète n'a aucun effet sur une sauvegarde T-log. Une sauvegarde complète ne contient que suffisamment de journal des transactions nécessaires pour qu'en cas de restauration, la base de données puisse être transactionnellement cohérente avec le moment où la partie de lecture des données de la sauvegarde complète s'est terminée. Vérifier - Combien de journaux de transactions une sauvegarde complète comprend-elle?

En outre, une sauvegarde du journal pendant une sauvegarde complète ne tronquera pas le journal des transactions. Une ou plusieurs sauvegardes de journal après la fin de la sauvegarde complète tronqueront le journal.

Les fichiers de sauvegarde sont récupérés du jour au lendemain par un autre processus qui récupère tous les fichiers sur le serveur et les stocke ailleurs - serait-ce une bonne idée de faire expirer le jeu de sauvegarde après 2 jours? Dois-je les faire expirer?

Les tâches de nettoyage suppriment respectivement les "anciens" fichiers .bak et .trn sous les sous-dossiers de G: \ Backups. Cela a-t-il du sens? Serait-il préférable de le faire dans SSIS, afin que je puisse faire échouer mon ETL si / quand les sauvegardes échouent? Ou mon processus ETL devrait-il même s'en soucier?

Pour les deux, utilisez la solution de maintenance de sauvegarde d'Ola. Il se chargera de supprimer les anciens fichiers.

Kin Shah
la source
Impressionnant. J'ai donc changé le modèle de récupération en «Simple» pour toutes mes bases de données et j'ai exécuté le script d'Ola. Semble tout ce que je dois faire maintenant est de planifier réellement les emplois créés?
Mathieu Guindon
Oui s'il vous plaît. Aussi, n'oubliez pas de marquer comme réponse / vote positif si la réponse est la solution ou utile - de cette façon, elle ne sera pas signalée comme sans réponse.
Kin Shah