Taille du journal virtuel SQL Server

Je suis un peu un DBA accidentel, étant un développeur qui a hérité de quelques serveurs de base de données (2005 et 2008) de quelqu'un qui connaissait peu l'administration de la base de données et qui semblait encore moins intéressé à en savoir plus sur le sujet.

J'apprends au fur et à mesure et j'essaie actuellement de comprendre les fichiers journaux des transactions.

Toutes nos bases de données ont été configurées avec le modèle de récupération simple et le rétrécissement automatique. J'ai compris que l'utilisation du rétrécissement automatique est généralement une idée horrible, mais je crois comprendre que cela a été fait afin d'empêcher les journaux de transactions de devenir incontrôlables. (Le rétrécissement automatique réduit-il réellement le ou les fichiers journaux ou uniquement la base de données?)

J'ai trouvé cela sur SQL Server 2012, et je me demandais si c'était vrai pour 2005 et / ou 2008, et exactement ce que cela signifie: "Lorsqu'une base de données utilise le modèle de récupération simple, le moteur de base de données tronque le journal des transactions après un point de contrôle. [. ..] Le moteur de base de données déclenche un point de contrôle automatique sous le modèle de récupération simple lorsque le journal virtuel est plein à 70%. " Où la taille du journal virtuel est-elle spécifiée?

Je souhaite désactiver la réduction automatique sur toutes les bases de données, mais avant de le faire, je dois savoir que les fichiers journaux ne deviendront pas incontrôlables rapidement.

Toute aide serait grandement appréciée.

Un fichier journal de transactions unique a à la fois une taille physique (que vous voyez sur le disque), et il est également décomposé dans le fichier physique en sections logiques appelées fichiers journaux virtuels (VLF).

La croissance automatique et la réduction automatique fonctionnent sur le fichier journal des transactions physiques .

La troncature du journal des transactions (également appelée «effacement des journaux») fonctionne sur les sections logiques du journal des transactions (VLF) et n'affecte pas la taille du fichier physique. Cette partie est fréquemment sujette à confusion.

Un fichier journal doit toujours se développer pour accueillir une transaction importante; la désactivation de la réduction automatique laissera le fichier journal avec sa taille maximale requise, au lieu de diminuer physiquement sa taille.

Si vous n'avez pas de transactions importantes, il sera sûr de désactiver la réduction automatique; les fichiers journaux ne se développeront pas sans limite, comme ce serait le cas si la base de données se trouvait dans FULLou BULK_LOGGEDet que vous ne preniez pas de sauvegardes du journal des transactions.

Ce comportement est le même pour SQL Server 2005+.

Alors, voici ce que j'ai trouvé après avoir lu les autres réponses ici et fait mes propres recherches:

Q: "Le rétrécissement automatique réduit-il réellement le ou les fichiers journaux ou uniquement la base de données?" R: D'après ce que je comprends: oui, c'est le cas. La réduction automatique est définie au niveau de la base de données et affecte tous les fichiers (visible si vous cliquez avec le bouton droit sur la base de données -> propriétés -> fichiers, ou si vous exécutez la requête 1). Cependant, la croissance automatique fonctionne au niveau du fichier.

Q: "Où est spécifiée la taille du journal virtuel?" R: Voir la réponse de Jon Seigel et le lien que Remus a posté. Pour voir la taille du journal physique et logique, utilisez la requête 2

Un problème est que si le mode de récupération complet de la base de données a été activé, agrandi à une grande taille, puis que le mode de récupération a été modifié en simple, un point de contrôle ne sera pas déclenché car le VLF a la reconnaissance automatique. Il est possible d'essayer de résoudre ce problème (voir la réponse de Remus pour les problèmes potentiels avec la tête / la queue des fichiers journaux) en exécutant la requête 3, ce qui réduira le fichier journal à la taille qu'il était lors de sa création d'origine.

Requêtes:

1)

SELECT name, physical_name AS current_file_location, DB_NAME(database_id) AS dbname
FROM sys.master_files
WHERE DB_NAME(database_id) = 'mydb'

2)

DECLARE @tmpt TABLE(
    dbname VARCHAR(255),
    logsize DECIMAL,
    logspaceused DECIMAL,
    stat INT
)

INSERT INTO @tmpt
    EXEC ('DBCC SQLPERF(LOGSPACE)')

SELECT * FROM @tmpt WHERE dbname LIKE 'mydb' ORDER BY logspaceused DESC

3)

checkpoint
DBCC SHRINKFILE('logfile_name')

Comme vous l'avez mentionné dans votre question, dans SQL 2005 et 2008 après le point de contrôle, le fichier journal des transactions sera également tronqué.

Ma suggestion serait de définir le modèle de récupération sur complet et de créer un travail pour effectuer une sauvegarde à partir du fichier journal des transactions. Ce travail peut être planifié sur votre base de données et tronquera le journal des transactions après avoir effectué la sauvegarde. Il tronquera automatiquement le fichier journal pour vous. Veuillez consulter les liens ci-dessous:

SQL Server 2005: http://technet.microsoft.com/en-us/library/ms189085(v=sql.90).aspx

SQL Server 2008: http://technet.microsoft.com/en-us/library/ms189085(v=sql.100).aspx