Discussion :

[stephz]

Bonjour,

J'ai rencontré un problème récemment qui ne m'était jamais arrivé et qui m'inquiète.
Suite à une matinée de travail en production une application connectée à la base de données s'est mise à ralentir puis à planter.
Une grosse partie du travail effectué le matin durant 4 heures a complètement disparue de la base de données.
Ces données ont pourtant été stockées car elles étaient visibles par les applications.

Le plus étrange, c'est que nous avons essayer de restaurer nos sauvegardes et les données ne s'y trouvaient pas non plus. La base est en mode de récupération complète avec une sauvegarde des journaux toutes les 20 minutes.

Ce phénomène s'est produit 2 fois ce mois ci et je n'ai pas trouvé d’explications.
Est ce que quelqu'un à une idée ?

Mon système est Windows 2012 Server et SQL Server 2016 Sp1 avec les dernières mise à jours cumulative. 8 Processeurs, 16 cœurs et 72 Go de RAM
L'ensemble est hébergée sur un système VMWare.
Je suis à votre disposition s'il vous faut plus d'informations

Bien cordialement
Stéphane

[stephz]

Je n'ai pas de script ou ps qui permettrai la suppression de ces données.
La base de données est en réplication de fusion

Merci

[Donpi]

Si ça ralenti et que ça fini par planter, je regarderais si ça n'est pas une saturation du LOG

Il se peut qu'une transaction reste ouverte et sature les log.
Si votre applicatif utilise des NOLOCK dans ses requêtes, les données seront visibles même si non "commitées".

On peu avoir plus d'info sur le message d'erreur au moment du plantage ?


Quoi qu'il en soit, j'investirais sur la correction du bug plus qu'a récupéré les données.
A moins qu'un membre du forum sorte un truc de sa manche, elles sont perdues.

[iberserk]

Cela m'est déjà arrivé... suite au plantage l'hébergeur a restauré la VM... avec la dernière sauvegarde qu'il avait qui datait de plusieurs heures:
Demandez lui si vous avez un hébergeur
Demandez à votre équipe chargé de l'infra des VM si vous hébergez vous même

[stephz]

Bonjour,

tout d'abord merci de vos réponses.

Les Vm sont hébergés en interne et aucune restauration n'a été effectué.

En revanche, Cette histoire de LOG m'a fait réfléchir.
Le problème à commencé par des timeout des applications. Un process a été identifié comme l'origine des blocages. Ce process a été tué.
Très peu de temps après, on nous a signalé que le travail de la matinée n'apparaissait plus.


Donc si j'ai bien compris ce process a ouvert une transaction qui est restée ouverte ce qui a saturée le fichier LOG.
Ce que j'ai du mal à appréhendé, c'est que le fait d'avoir tué ce process à invalidé toutes les transactions suivantes.
Ces transactions bien que commitées ou RollBackées ont été perdues certainement car elles ne pouvainet pas être rejouées lors d'une restoration

Si j'ai bien compris, c'est ce qui s'est passé ?

Merci

[SQLpro]

Un process a été identifié comme l'origine des blocages. Ce process a été tué.

Tuer un processus c'est forcer un ROLLBACK sur la connexion cible. D'ou la perte de données. Si vous tuez un processus sans savoir ce qu'il à fait....

Très peu de temps après, on nous a signalé que le travail de la matinée n'apparaissait plus.

Donc si j'ai bien compris ce process a ouvert une transaction qui est restée ouverte ce qui a saturée le fichier LOG.
Ce que j'ai du mal à appréhendé, c'est que le fait d'avoir tué ce process à invalidé toutes les transactions suivantes.
Ces transactions bien que commitées ou RollBackées ont été perdues certainement car elles ne pouvainet pas être rejouées lors d'une restoration

Si j'ai bien compris, c'est ce qui s'est passé ?

Merci

A +

[stephz]

Bonjour,

je comprends bien que tuer un process, engendre la perte des données de celui-ci, mais des données enregistrées par d'autres applications jusqu’à 4 heures auparavant, je ne comprends pas

[Donpi]

Par rapport à ce que je viens de lire , je ne devait pas être top loin de la vérité.

Selon moi ce qui se passe sur appli client lourd:
- Un utilisateur exécute un bout de programme qui ne referme pas sa transaction.
- L’utilisateur avec la transaction ouverte ne se rend compte de rien. Et au fur et mesure de son travail il bloque de plus en plus de tables
- Pour les autres utilisateurs le programme ralenti ( il s’arrête en vrai ). Certains reçoivent des timeout quand ils essayent d’utiliser les ressources bloquées.
-Au bout d'un moment (4h) le programme de l'utilisateur bloqueur plant pour driverse raison et cela fait un rollback de tous son travail. Mais au moins ça libère les ressources pour les autres.

Avec un client légé c'est plus vicieux, surtout si la connexion est partager par exemple avec un singlton en .NET.
C'est le même cas que le précédent sauf que tous les utilisateurs écrivent dans la même connexion.
Et au moment du plantage c'est tout le travail de tous les utilisateurs qui est perdu.

J'ai peu expérimenté les deux cas de figure. Beaucoup de transpiration à chaque fois.

A+

[stephz]

Je dirai que la solution du client lourd me paraît très proche de la vérité
Je vous remercie beaucoup

Stéphane

[iberserk]

Pendant 4 heures? je suis dubitatif
Même si une transaction a durée 4 heures, toutes celles committées pendant ces 4 heures n'ont pas été roolbackées...

[Donpi]

Pendant 4 heures? je suis dubitatif
Même si une transaction a durée 4 heures, toutes celles committées pendant ces 4 heures n'ont pas été roolbackées...

C'est juste.

Vous avez combien d'utilisateurs en simultané ?
Et les fameuses 4h, c'est vraiment 4h ? ou c'est une façon de dire "un long moment indéfini" ?
J'ai personnellement des utilisateurs qui disent 1h pour 5 minutes.

[stephz]

Effectivement, j’exagère un peu.
Après analyse, nous avons perdues les données effectuées par cette application de 08h12 à 10h55.

Par contre c'est mon interrogation, cette appli à ouvert un process, de multiples transactions au été réalisées au sein de ce même process.
Si l'une d'elle n'est pas correctement validée/invalidée, je suis dubitatif sur la perte de toutes les suivantes

[iberserk]

Effectivement, j’exagère un peu.
Après analyse, nous avons perdues les données effectuées par cette application de 08h12 à 10h55.

Par contre c'est mon interrogation, cette appli à ouvert un process, de multiples transactions au été réalisées au sein de ce même process.
Si l'une d'elle n'est pas correctement validée/invalidée, je suis dubitatif sur la perte de toutes les suivantes

via procédure stockées? requète adhoc?, transactionScope?

[stephz]

Uniquement procédures stockées

[Donpi]

2h30 ça reste pas mal

La connexion est-elle partagée entre le process ? Si oui, c'est la raison.
Après si tous les process on exécuté ce bout de code qui ne comit pas, au moment ou l'un entre eux plante le programme, ils plantent tous, et donc rollback pour tout le monde.

[stephz]

Non, la connexion n'est pas partagée

[aieeeuuuuu]

Bonjour,

Donpi a soulevé un point intéressant. Utilisez vous un niveau d'isolation des transactions autorisant les lectures sales ( indicateur NOLOCK dans les requêtes, SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED, ou piloté depuis l'application) ?

[stephz]

Nous n'utilisons pas l'indicateur NoLock
Nous avons utiliser les changement d'isolation : SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

puis nous avons modifier la valeur de SET READ_COMMITTED_SNAPSHOT que nous avons passez à On, nous avons perdu nos données donc nous l'avons remis à OFF

[iberserk]

Vos transactions sont en read uncommitted donc en lecture sale, READ_COMMITTED_SNAPSHOT ne change donc rien...
Vos applications peuvent LIRE les données non committés...

[stephz]

J'ai effectivement conscience de cet état de fait et la volonté de l'entreprise.
Nous évoluons dans un environnement de production.
Beaucoup de données sont lues alors qu'elles sont en cours de modification.
J'ai bien évidement expliquer cet état de fait à ma hiérarchie.