db 100Gb, fichier log 660Gb

Version imprimable

01/02/2021, 12h44
KeepItSimple

db 100Gb, fichier log 660Gb

bonjour,

SQL server enterprise (2 noeuds - 2 db's dans un High availability group sur un lan) sous windows 2016.
Le dossier E:\SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Data contient ~ 100Gb
Le dossier E:\SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Log fait 682Gb, avec un des fichiers log qui fait à lui seul (pour une des db's) 669 Gb?

Comment ca se fait? Comment puis-je réduire ce "log" qui fait à lui tout seul 6 fois le contenu de la database? Je précise que le backup tourne chaque nuit sans erreur.

Merci.
01/02/2021, 13h18
Invité

Backup full ou Log ?
01/02/2021, 14h53
KeepItSimple

backup full

full.
01/02/2021, 15h53
Invité

si ta bd est en recovery mode Full, il faudrait faire des backup Log (du journal)
01/02/2021, 16h05
KeepItSimple

il y en a.
01/02/2021, 16h21
KeepItSimple

En fait non, je ne suis pas sur
Au niveau du maintenance plan , je vois un full backup vers F:\SQL Server\Backup d'une db spécifique.
Et si je fais un clic droit sur la db je vois "last database log backup 24/7/2020"
=> Il faut faire un maintenance plan avec un backup séparé pour les logs?

Lancez la requête suivante pour voir les sauvegardes réalisées :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SELECT CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, 
       bs.database_name, 
       bs.backup_start_date, 
       bs.backup_finish_date, 
       bs.expiration_date,
       CASE bs.type
           WHEN 'D'
           THEN 'Database'
           WHEN 'L'
           THEN 'Log'
       END AS backup_type, 
       bs.backup_size, 
       bmf.logical_device_name, 
       bmf.physical_device_name, 
       bs.name AS backupset_name, 
       bs.description
FROM   msdb.dbo.backupmediafamily AS bmf
       INNER JOIN msdb.dbo.backupset AS bs ON bmf.media_set_id = bs.media_set_id
ORDER  BY database_name, 
          backup_finish_date;

Après on pourra vous aiguiller !

A +

01/02/2021, 19h34
KeepItSimple

1 pièce(s) jointe(s)
j'ai lancé un backup du transaction log entre-temps.
Le query j'ai changé l'ordre: backup_finish_date desc; et le nom de la db 'Primary' (ce n'est pas moi qui ai choisi ce nom débile mais mon prédécesseur :D ).
C'est la seule qui prend des centaines de Gb. Il y a d'autres petites db "de test" (quelques centaines de Mb, pas de données de production).

Screenshot:
Pièce jointe 589889

J'ai lancé un shrink du logfile (apparemment 99% des 660Gb sont libres). Il répond assez vite mais n'a apparemment rien fait. Pas de message d'erreur ni de succès. Ca tourne en background?

en ligne de comamande
Code:

1 2 3 4 USE [Primary] GO DBCC SHRINKFILE (N'Primary_log' , 0, TRUNCATEONLY) GO
Citation:

Cannot shrink log file 2 (Primary_log) because the logical log file located at the end of the file is in use.

Code:

SELECT name, log_reuse_wait_desc FROM sys.databases

=>LOG_BACKUP.
J'ai vu qu'il y avait moyen de l'aider en passant du "recovery model" FULL à SIMPLE. Mais est-ce que ca a un impact avec le réplica? (je ne veux pas le recommencer).
02/02/2021, 10h24
mikedavem

Refait un backup log et tente un nouveau SHRINKFILE.

Le passage en mode SIMPLE n'est pas possible avec une base de données dans un AG à moins de l'enlever bien entendu.
Il faudra alors refaire l'initialisation de la session.

++
02/02/2021, 12h01
SQLpro

DBCC SHRINKFILE (N'Primary_log' , 1)

Pour bouger les pages vides en fin de journal sinon il ne peut les tronquer.

A +