Discussion :

[jeeps64]

Bonjour

Suite a un traitement important (au niveau volumetrie), je constate un remplissage de la log de la base. Une commande de delete reste alors en cours.

Je tente de faire un dump tran...sans succés. Pire, le dump tran passe en sleeping et ne rend jamais la main.

J'ai constaté aussi un process au status 'PLC sleep' et lancant la commande 'CHECKPOINT SLEEP' sur la base incriminée (Sasns doute un process systeme)

Le probleme s'est deja posé plusieurs fois et le seul moyen de "corriger le probleme" a été de redémarrer le serveur SYBASE. Le probleme est que la base ne remontait pas direcetement, j'ai du updater la table sysdatabases (status=-32768), puis redémarrer le serveur SYBASE, puis reloader un dump.

Merci d'avance de votre aide

jeeps64

Rq : Sybase version 12.5.3 sur Windows

[mpeppler]

Le problème est que si le delete qui rempli le tranlog est encore en cours alors on ne peut pas tronquer le tranlog.

Solutions:

1. Splitter le delete en plusieurs batch, p.ex. avec une boucle.
2. Aggrandir la taille du tranlog...

Michael

[jeeps64]

Le dump tran, meme si il ne fait rien, doit quand meme tourner or la il ne tourne pas du tout.

Pour info, je n'arrive pas a killer le process de delete en cours (il est en status 'sleeping'). Dans l'errorlog, il me dit bien qu'il le kill mais en fait il le fait pas.

[mpeppler]

Je ne sais pas exactement quel est le problème - j'ai eu un problème similaire il y a quelques années, et il était du à un problème interne de la base (mauvais calcul de l'espace log dispo).

A priori il faudrait vérifier la cohérence de la base (dbcc, vérification que la taille du syslog via sp_helpdb soit cohérente, etc).

Michael

[jeeps64]

Bonjour

J'ai fait les dbcc checkstorage et checkdb sur la base...vierge
Puis un dbcc checktable sur la table "à deleter"...lui aussi vierge

En ce qui concerne la log de la base, elle a l'air clean

Je vais tenter de dropper / recreer la base et les devices ce soir.
Je seche complet la

Merci encore des infos


jeeps64

[Jean.Cri1]

Le dump tran est aussi une commande loggée et il se peut alors que si ta log est completement pleine il ne puisse etre effectué.
Il faut alors utiliser l'option with no_log pour effectuer le dump tran dont la réalisation ne sera plus conditionnée par le taux de remplissage de la log.

C'est peut etre ton probleme.

[jeeps64]

J'ai de nouveau reproduit le probleme
Et en effet, le dump tran db with no_log a fonctionné...je n'y avais pas pensé

Merci beaucoup

Bonne journée

[jeeps64]

J'ai de nouveau reproduit le probleme
Et en effet, le dump tran db with no_log a fonctionné...je n'y avais pas pensé

Merci beaucoup

Bonne journée

[jeeps64]

Bonjour

Mon probleme est en cours de resolution
En effet, le dump tran with no_log a fonctionné
En travaillant sur les traitements qui tournaient au moment du probleme, je me suis rendu compte que l'un d'entre eux faisait une transaction non loguée
Une fois cette commande modifiée, les threshold se sont déclenchés correctement et plus de probleme

Merci a tous

jeeps64