|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre habitué
![]() Inscription : mars 2006 Messages : 293 ![]() |
Bonjour a tous ma base de prod est bloqué car les logs sont full j'ai tenté
Code :
dump tran toto WITH truncate_only ....no_log ...
|
|
|
00
|
|
|
#2 | ||
|
Membre habitué
![]() Inscription : mars 2006 Messages : 293 ![]() |
ayant trouvé sur le forum un case parlant d'une chose analogue je poste le résulta de cela
Code :
|
||
|
|
00
|
|
|
#3 |
|
Membre du Club
![]() Inscription : mars 2007 Messages : 248 ![]() |
Bonjour
tu dois avoir une transaction longue en cours: tant que commit n'est pas fait la troncature du journal n'a pas d'effet. Essaies de trouver la session (sp_who) et tue le process (kill <spid>). A toi de voir par rapport à l'importance de cette transaction si tu peux le faire, sinon tu peux agrandir le device du segment log. Bon courage msomso |
|
|
00
|
|
|
#4 |
![]() ![]() |
Pour ajouter à ce que dit msomso:
Dès qu'il y a un problème avec la transaction log qui se rempli (ou que le dump tran ne la vide plus) il faut voir dans master..syslogshold si il y a une transaction ouverte. Cette transaction bloquante peut venir de la réplication (replication truncation point) si (par example) les transactions répliquées ne peuvent pas être appliquées à leur destination. D'autres cas typiques viennent de clients lancés en mode "chained" (AutoCommit = 0) qui n'ont pas appliqué de commit. Michael
__________________
Michael Peppler Membre de TeamSybase - www.teamsybase.com "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson |
|
|
00
|
|
|
#5 | ||
|
Membre habitué
![]() Inscription : mars 2006 Messages : 293 ![]() |
Ok j'ai cela
Code :
|
||
|
|
00
|
|
|
#6 |
![]() ![]() |
Tu as une transaction démarrée à 11h13 aujourd'hui par le spid 58 qui est probablement résponsable de ton problème.
Via un select dans master..sysprocesses, et éventuellement monProcessSQLStatement (si celle-ci est en place) tu peux voir ce que cette transaction fait. Si ta DB #4 est toujours bloquée, tu devras killer cette session (ou demander à son propriétaire de sortir de son application). Si c'est de la prod alors évidemment appliquer toutes les précautions d'usage! Michael
__________________
Michael Peppler Membre de TeamSybase - www.teamsybase.com "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson |
|
|
00
|
|
|
#7 |
![]() ![]() |
__________________
Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums ! |
|
|
00
|
|
|
#8 |
|
Membre habitué
![]() Inscription : mars 2006 Messages : 293 ![]() |
Merci à tous de votre aide ... Le problème est enfin résolu et était due a deux facteurs. Le premier est que nous avions commencé la création d'une warm standby avant hier et que le poste windows d'ou nous avions lancé le rs_init a "planté" et nous avons due stopper la procédure mais rs_init avait positionné malgré tout un point de troncature dans les logs, ce qui fait que ceux-ci ont augmenté. Et le deuxième problème est due a l'agrandissement de l'espace des logs sur un "raw device", mal paramétré par l'équipe système, ce qui a fait baucoup d'erreures i/o.
La hotline sybase nous a aidé vraiment bien mais malgré tout la base a été dans un status "332", et la seul solution a donc été de faire un load d'un Dump antérieur, et entre temps supprimer le device posant problème. Vila merci encore.
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com