Discussion :

[Monstros Velu]

Bonjour,

j'ai lancé un delete de 16 000 000 de lignes dans une table, et le log a pris tout la place sur le disque dur du server (de prod). Du coup, la DB était inutilisable.
Du coup, j'ai annulé l'opération de delete... J'ai eu le message de Management Studio "Query was cancelled by user." mais la base est en "Recovery Mode" depuis.

Que faut-il faire ?

[Monstros Velu]

Il suffisait d'attendre... 45 minutes c'est long !

[SQLpro]

Un rollback est souvent beaucoup plus long qu'un COMMIT. Parce qu'il faut lire le JT en arrière alors que d'autres transactions l'avance !

A +

[elsuket]

Bonjour,

Je crois que la colonne percent_complete de la DMV sys.dm_exec_requests prend une valeur non nulle dans le cas d'une récupération.
Si tel est le cas, cela vous aurait permis de connaître l'avancement de la récupération .
En revanche je suis certain qu'elle prend une valeur non-nulle pour un ROLLBACK.

j'ai lancé un delete de 16 000 000 de lignes dans une table, et le log a pris tout la place sur le disque dur

En effet, quel que soit le mode de récupération de votre base de données, le moteur écrit d'abord les données supprimées dans le fichier du journal de transaction avant de vider les pages de la table dans le fichier de données.

Vous pouvez donc faire des lots de DELETE (DELETE TOP 100000 par exemple) dans un WHILE.

Si vous utilisez le mode de récupération FULL OU BULK_LOGGED, entre chaque DELETE, procédez à une sauvegarde du fichier du journal des transactions, de manière à ne pas le faire grossir.
Si vous êtes sous SQL Server 2008, vous pouvez rajouter l'option WITH COMPRESSION à l'instruction BACKUP LOG

Si vous êtes dans le mode SIMPLE, vous n'avez pas besoin de sauvegarder le journal.

Pour connaître le mode de récupération de votre base de données :

Code :

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

1
2
3
SELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'maBD'

@++

[Monstros Velu]

On est en 2005, et en mode FULL. Et il y a une sauvegarde du fichier de log toutes les heures.

Suite à cet incident, on a fait un nettoyage de l'espace disque du server, l'ajout de fichiers de log sur un disque qui servait à autre chose et sur lequel il y avait de la place, et une suppression par lot (une boucle contenant un begin tran et un commit). C'est finalement passé.

[elsuket]

l'ajout de fichiers de log

Si vous parlez du fichier du journal des transactions pour SQL Server, sachez que cela ne vous a procuré que de l'espace en plus, mais ne vous fait rien gagner en termes de performance, car ce fichier est écrit séquentiellement.

Si vous avez donc plusieurs fichiers pour le journal des transactions, ceux-ci seront utilisés tour à tour

@++