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.
Donc, depuis un certain temps, mon processus SSIS pendant la nuit exécute une Exécution d'une tâche SQL pour effectuer les sauvegardes - essentiellement en exécutant master.dbo.xp_create_subdir pour vous 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 tronçonnais 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 et de faire les choses correctement à la place, et de suivre les étapes ici et de créer une réelle maintenance plan:
Le fait est que je n'ai jamais fait cela auparavant, j'ai donc quelques questions:
- Est-ce que la sauvegarde des journaux de transactions comme celui-ci les tronquera automatiquement, ou il y a autre chose que je dois faire?
- 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 (ne pas discuter du modèle de récupération connecté en masse),
- Un modèle de récupération complète permet des sauvegardes de journaux qui permettent une récupération ponctuelle.
- 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.
- 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 - Utilisation en pourcentage?
Je vous suggère fortement de plans de maintenance de fossé et d'implémenter [une solution de maintenance intelligente - qui est facile, flexible et suit les meilleures pratiques] - 5 . - solution de sauvegarde d'Ola (et 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 INIT et 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écessaire 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 journal de transactions une sauvegarde complète comprend-il?
En outre, une sauvegarde du journal pendant une sauvegarde complète ne tronquera pas le journal des transactions. Une (deux) sauvegarde (s) de journal après la fin de la sauvegarde complète tronquera 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 d'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.