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

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 :

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.

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.