Distribution is FULL due to CHECKPOINT

**guilld** · 07/05/2019, 10h26

Bonjour,

Je tourne en rond depuis 48h..

J'ai une base de données sur laquelle j'ai mis en place une réplication.
Cette réplication s'est arrêtée par manque de place dans le log de la base DISTRIBUTION (déjà je comprends pas comment cela peut arriver sachant que l'espace disque est à 60 % libre).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Msg 9002, Level 17, State 1, Line 2
The transaction log for database 'distribution' is full due to 'CHECKPOINT'.

Du coup, j'ai lu sur le NET que la SP3 et le CU peuvnet débloque la siutation...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Microsoft SQL Server 2014 (SP3-CU3) (KB4491539) - 12.0.6259.0 (X64) 
	Apr  1 2019 22:19:54 
	Copyright (c) Microsoft Corporation
	Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

Bah... non!!

alors je tente un peu de tout sur cette fichue base DISTRIBUTION (Shrink, ajout d'un fichier log, backup, augmentation manuelle de la taille du log, passage du Recovery model en FULL, etc..)
Bref tout y passe et toujours le meme message d'erreur :

Nom : Capture.JPG
Affichages : 893
Taille : 43,2 Ko

Nom : Capture.JPG
Affichages : 893
Taille : 43,2 Ko

Etant à sec d'idée, si vous aviez une ...

**Michel.Priori** · 07/05/2019, 11h00

J'imagine que cet article a déjà été lu :
https://docs.microsoft.com/en-us/sql...ql-server-2017

Du coup on a quoi comme info pour log_reuse_wait_desc ?

Tant qu'on y est un petit rapport sur le contenu de sys.master_files serait utile.

**guilld** · 07/05/2019, 11h14

Oui, déjà parcouru.. sans y voir de réponse.. ou bien ai je raté une info car il y a pas mal de lien "For more information, see.."

Résultat pour le log_reuse_wait_desc : CHECKPOINT

**guilld** · 07/05/2019, 11h43

le résult de sys.master_files : (voir pièce jointe)

**Michel.Priori** · 08/05/2019, 09h26

Envoyé par guilld

le résult de sys.master_files

Vu.
Il n'y a que le fichier de donnée, dommage.

Quelles sont les actions faites à ce jour ? (reboot, dbcc opentran, checkpoint, suspendre les job, vérification des synchronisations,...)
Est-ce qu'un backup log with no truncate fonctionne ?

Quel serait le coût de reconstruire la réplication ?

**SQLpro** · 08/05/2019, 10h02

Donnez-nous le résultat de cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
SELECT DB_NAME(mf.database_id) AS DB,name AS F_NAME, type_desc, 
       physical_name, state_desc, 
       CAST(size / 128.0 AS DECIMAL(16, 3)) AS SIZE_MB, 
       CAST(max_size / 128.0 AS DECIMAL(16, 3))AS MAX_SIZE_MB, 
       CASE is_percent_growth 
          WHEN 1 THEN CAST(growth AS VARCHAR(32)) + ' %'
          ELSE CAST(CAST(growth / 128.0 AS DECIMAL(16, 3)) AS VARCHAR(32)) + ' MB' 
       END AS GROWTH_TYPE,
       is_media_read_only, mf.is_read_only, volume_mount_point, 
       CAST(total_bytes / 1073741824.0 AS DECIMAL(16, 3)) AS VOLUME_SIZE_GB,
       CAST(100.0 * available_bytes / total_bytes AS DECIMAL(16, 3)) AS FREE_VOL_PERCENT
FROM   sys.master_files AS mf
       CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.file_id) AS vs;

A +

**guilld** · 09/05/2019, 08h53

Bonjour,

MICHEL:

Quelles sont les actions faites à ce jour ? (reboot, dbcc opentran, checkpoint, suspendre les job, vérification des synchronisations,...)
Est-ce qu'un backup log with no truncate fonctionne ?

Le cout de reconstruction de la réplication serait assez contrégniant.

Reboot : OK
dbcc opentran :No active open transactions.
Job suspendu : OK
Synchro : Stoppé

Les backup ne fonctionne pas : Erreur 9002

SQL PRO:
Voir piece jointe..

Si je devais passer par une reconstruction, comment "démonter" cette réplication sachant chaque action sur la base DISTRIBUTION se solde par une erreur .. ?

Merci pour votre aide.. !

**Michel.Priori** · 09/05/2019, 13h30

Re,
Désolé d'être lourd. C'est pas évident de traiter un problème comme ça par forum interposé.
Merci d'être le plus précis possible.

Est-ce qu'on est sur une MV ? si oui est-ce que le disque virtuel peut effectivement grossir ?

Est-ce que la base est accessible ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

use distribution

Est-ce que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
use distribution
checkpoint

Fait un truc ?

J'ai bien vu que les backup ne fonctionnent pas. Pas même ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP LOG distribution TO DISK = 'x:\...\...*.trn' WITH NO_TRUNCATE;
BACKUP LOG distribution TO DISK = 'x:\...\...*.trn' WITH CONTINUE_AFTER_ERROR;

Est-ce qu'il y a des entrées dans le journal des évènements et dans le journal SQL qui pourraient nous servir ?

Que donne ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC CHECKDB ('distribution')

Que donne un scan système du disque C: ?

La création d'un fichier bacpac est possible ? (Clic droit sur la base > tâches > exporter une application de la couche de données...)

Puis en vrac :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
ALTER DATABASE [distribution] SET  RESTRICTED_USER WITH NO_WAIT
ALTER DATABASE [distribution] SET  SINGLE_USER WITH NO_WAIT
ALTER DATABASE [distribution] SET  OFFLINE
 
ALTER DATABASE [distribution] SET  SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
USE [master]
GO
EXEC master.dbo.sp_detach_db @dbname = N'distribution'

**guilld** · 09/05/2019, 14h39

Michel,
Je comprends la difficulté à aider à distance en aveugle. Donc pas de pb

MV : OUI
Les ESXI sont OK. Il y a de l'espace..

Base accessible : oui

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
use distribution
checkpoint

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Msg 5901, Level 16, State 1, Line 30
One or more recovery units belonging to database 'distribution' failed to generate a checkpoint. This is typically caused by lack of system resources such as disk or memory, or in some cases due to database corruption. Examine previous entries in the error log for more detailed information on this failure.
Msg 9002, Level 17, State 1, Line 30
The transaction log for database 'distribution' is full due to 'CHECKPOINT'.

DISTRIBUTION est en mode SIMPLE et non FULL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP LOG distribution TO DISK = 'x:\...\...*.trn' WITH NO_TRUNCATE;
BACKUP LOG distribution TO DISK = 'x:\...\...*.trn' WITH CONTINUE_AFTER_ERROR;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Msg 4208, Level 16, State 1, Line 32
The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE.
Msg 3013, Level 16, State 1, Line 32
BACKUP LOG is terminating abnormally.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC CHECKDB ('distribution')

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Could not write a checkpoint record in database distribution because the log is out of space. Contact the database administrator to truncate the log or allocate more space to the database log files.
Msg 5901, Level 16, State 1, Line 34
One or more recovery units belonging to database 'distribution' failed to generate a checkpoint. This is typically caused by lack of system resources such as disk or memory, or in some cases due to database corruption. Examine previous entries in the error log for more detailed information on this failure.
Msg 1823, Level 16, State 2, Line 34
A database snapshot cannot be created because it failed to start.
Msg 1823, Level 16, State 8, Line 34
A database snapshot cannot be created because it failed to start.
Msg 7928, Level 16, State 1, Line 34
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
DBCC results for 'distribution'.
DBCC CHECKDB will not check SQL Server catalog or Service Broker consistency because a database snapshot could not be created or because WITH TABLOCK was specified.
DBCC results for 'sys.sysrscols'.
There are 1803 rows in 20 pages for object "sys.sysrscols".
DBCC results for 'sys.sysrowsets'.
There are 241 rows in 3 pages for object "sys.sysrowsets".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
ALTER DATABASE [distribution] SET  RESTRICTED_USER WITH NO_WAIT
ALTER DATABASE [distribution] SET  SINGLE_USER WITH NO_WAIT
ALTER DATABASE [distribution] SET  OFFLINE
 
ALTER DATABASE [distribution] SET  SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
USE [master]
GO
EXEC master.dbo.sp_detach_db @dbname = N'distribution'

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Msg 5069, Level 16, State 1, Line 37
ALTER DATABASE statement failed.
Msg 9002, Level 17, State 1, Line 37
The transaction log for database 'distribution' is full due to 'CHECKPOINT'.

Je crois que je suis dans un cul de sac!!
Rien ne fonctionne ..

**SQLpro** · 09/05/2019, 15h23

Essayez de créer un autre fichier pour le journal de transaction.

A +

**Michel.Priori** · 09/05/2019, 15h30

Ok

arrête le service et RECOPIE les fichiers de la base distribution pour voir :
1- s'il existe une corruption disque.
2- si l'ESXI donne bien de l'espace disque

Si t'as pu faire la copie essaie de "joindre" ces fichiers en tant que distrib2 et de passer les DBCC

Tu ne nous as pas donné d'info sur les journaux d'erreurs ni sur la création du bacpac.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

BACKUP DATABASE distribution TO DISK = 'x:\...\...*.bak' WITH CONTINUE_AFTER_ERROR;

**Michel.Priori** · 09/05/2019, 15h35

Tant qu'on y est, si on peut avoir des détails sur le journal :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from sys.dm_db_log_info (6)

**guilld** · 09/05/2019, 15h39

Voilà. .

**Michel.Priori** · 09/05/2019, 19h26

Envoyé par guilld

Voilà

Vu pour sys.dm_db_log_info
Le nombre et la taille des virtual log file n'est pas délirant.

Qu'est que les autres points ont donné ?

**SQLpro** · 10/05/2019, 09h41

le répertoire hébergeant les fichiers serait-il en compressé ? En read only ?
A +

**guilld** · 10/05/2019, 14h36

Envoyé par Michel.Priori

Vu pour sys.dm_db_log_info
Le nombre et la taille des virtual log file n'est pas délirant.

Qu'est que les autres points ont donné ?

Je viens de refaire le tour..
Passer en mode single user ne permet pas plus de liberté pour tenter d'autre action (parce qu'on est en mono utilisateur).
Pas de BAK possible.
Pas possible de rajouter un autre fichier Log.
Pas possible de détacher la base parce qu'il y a l'abonnement en cours.
pas possible de faire un BAK des TRN parce que cette base est en mode SIMPLE.
pas possible de passer en mode FULL
...

**Michel.Priori** · 10/05/2019, 15h29

Une des causes peut être un problème physique sur l'un des 2 fichiers.

Dans cette hypothèse les actions suivantes vont peut être nous rassurer (ou pas)

arrête le service et RECOPIE les fichiers de la base distribution pour voir :
1- s'il existe une corruption disque.
2- si l'ESXI donne bien de l'espace disque

Il nous faut plus d'info :

Tu ne nous as pas donné d'info sur les journaux d'erreurs (Windows et SQL) ni sur la création du bacpac.

De plus :
ça fait maintenant combien de jours que ta réplication est plantée ?
Comment se comporte le journal de la base "éditeur" de la réplication ?
Combien de temps avant que tout se bloque ?

**guilld** · 10/05/2019, 15h51

Le journal de Windows est ok, il y a des erreurs dans le log application (SQL) au sujet de la base DISTRIBUTION, donc normal.
Le journal de SQL, ben il pleure toutes les larmes de son corps..

mais ca c'est pas nouveau

8 jours que la replication est plantée. Mais les données sont toujours collectées en local.
SQL en local semble être normal.

De plus pour être honnete, ces data ne sont pas hyper critique, juste de la collecte d'info informative.. pas bloquant si elles sont perdues mais facheux tout de même.. j'ai j'ai pas de pression.. je me laisse encore quelques jours pour résoudre ce probleme.
Aprés cela, j'échoue le navire (stop l'instance actuelle) et je remonte une autre instance..
Mais si j'arrive à remettre à flot cette base ce serait vraiment cool!
En tout cas, merci pour le coup de main.. Vous idée d'expert sont toujours les bien venues..

Lundi j'installe "ApexSQLLog", pour explorer le LOG et avec un peu de chance pouvoir le manipuler en ayant stoppé les services SQL..

**Michel.Priori** · 10/05/2019, 17h36

Envoyé par guilld

Lundi j'installe "ApexSQLLog", pour explorer le LOG et avec un peu de chance pouvoir le manipuler en ayant stoppé les services SQL..

J'aime beaucoup ApexSQLLog mais en l'occurrence je ne miserais pas sur lui pour ça.
La "chance" que le problème soit logique, c'est à dire dépendant d'une donnée, est très mince.

Vu le caractère exceptionnel de ce genre de panne, la cause physique (ou reliée) semble la plus probable.
Même un bug aurait eut une espérance plus grande.
Mais on n'est jamais à l’abri de rien...

Si on sait dater l'heure d'apparition du problème c'est déjà énorme.
Déjà on peut éliminer tout évènement arrivé après, ce sont des conséquences pas des causes (à moins que ce soit multi factoriel, mais là ...)
Le dépouillement des journaux reste pour moi une piste prometteuse, fastidieuse mais prometteuse.

J'imagine que l'arrêt du service n'a pas pu être fait à cause de l’hébergement des autres bases.
ça aussi c'est une piste prometteuse.

Juste pour en avoir le cœur net en attendant l'arrêt du service : testez de recopier quelques Go dans le dossier des données pour voir si l'ESXI donne bien ce qu'il affiche.