[ASE] Base instable : des solutions ?

Bonjour à tous.

Je travaille sur une base de données Sybase ASE 12.5.2 sous environnement UNIX.

J'obtiens regulierement des messages d'erreur du type " journal de transaction plein, veuillez le vider ou faire un alter de la base". Le moyen de pallier ce soucis était de faire un "dump transaction with NO_LOG". Mais, l'ensemble des alimentations ne s'exécutait jamais en entier.

J'ai donc essayé différentes solutions : augmenter la taille allouée pour le journal de transaction, création d'un segment contenant uniquement le journal de transaction, mise en place d'un seuil et vidage automatique du journal de transaction (grâce à sp_threshold_action) . Merci fadace pour tous les tutos mis à disposition !

Bref, ceci n'a pas apporté d'amélioration ; pis encore, jeudi, la base ne répondait plus. Depuis, j'ai essayé de killer les transactions bloquantes puis redémarrer le serveur.
Celui-ci s'est éteint mais lors du démarrage qui a suivi, il a lancé une procédure de récupération. Cette procédure s'éternise ( plus de 3 jours complets pour l'instant). Il y a une base en particulier qui est crashée. Sur cette base, il y a deux instances. Au démarrage du moteur Sybase, un message d'erreur m'indique qu'il n'y a plus assez d'espace pour le segment qui stocke le journal de transaction. Du coup, le demarrage de l'instance ne se fait pas. Par conséquence, je ne peux modifier la taille du segment de log. Je suis donc bloqué.


Mes questions sont les suivantes :

• Est-il possible d'augmenter la taille du segment destiné au journal de transaction?

• L'instance de la base qui est bloquée peut être ré alimentée facilement. Est-il possible de supprimer cette instance sans altérer l'autre qui tourne sur le meme moteur?

• Comment faire pour que les journaux de transactions ne soit pas toujours pleins (segment , device , place allouée,... ? ) J'ai appliqué les conseils de fadace mais les problemes reviennent regulierement. Pour info, le segment de log est sur un device à part qui fait une taille de 512 Mo.

Je suis preneur de tout conseil, début d'explication, tutorial ou site spécialisé.

D'avance merci,

le dump tran with no_log est la version "violente" de purger tes logs, on lui préfère

Code:

---

dump tran with truncate_only

---

Mais pour ton problème qui n'en est pas un il faut que tu fasse un autre device de log

Code:

---

1 2 3 4 5

disk init name='log2', physname='/disk/sybase/toto ../log02.log', size ="20M' go

---

et une fois ton device fait tu fais une augmentation des logs de ta base:

Code:

---

1 2 3

alter database toto log on log2='20M' go

---

toto et 20 méga sont là comme exemple.
Voir aussi les options de la base type
"trunc log on checkpoint" avec sp_dboption sous master
A+

ok merci,

le problème est que j'ai deja fait cela. J'ai crée un device à part pour le segment de log. Il fait 512 Mo mais le meme problème revient. A savoir le journal de transaction est plein.

A l'heure actuelle le problème est que ce segment est plein et donc la recuperation ne s effectue pas. Mais pour modifier la taille de ce segment la base doit etre lancée.

oui la base doit être lancé et en mode "singel user", tu positionne cela avec sp_dboption sous master et checkpoint sur ta base...
Si ton log augmente et ne se vide pas ... n'aurais tu pas du replication server ? car peut être as tu un point de truncature secondaire !!!
Quoi qu'il en soit positionne les options trunc log on checkpoint sur ta base cela videra tes transaction 'commité" et laissera les transaction en cours se finir, sinon on revient a la cmd dump tran .. with truncate_only, je le répète le no_log tue toutes tes transactions, donc a faire en cas de dernier recour

Aïe j'ai perdu 15 neurones. Peux-tu m'expliquer ce qu'est le replication server et comment faire pour verifier les points de truncature ?

Replication server est un produit supplémentaire de sybase qui permet la répli entre différent dataserver (sybase ou autre d'ailleur...) je pense que si tu avais cela tu le saurais ;-).
Je posais la question c'est qu'en cas de load d'une base répliqué en natif (Donc load d'1 dump de prod) tu as un "point de truncature secondaire", ce qui te fait augmenter tes logs (table syslogs de ta base). Donc dans ce type de cas tu dois faire un dbcc set trunc (ltm,ignore) (je crois j'ai plus la cmd en tête sorry. Erreur que j'ai commise il y'a pas si longtemps LOL ..
Pour ton cas tu dois, je pense ,positionner l'option trunc log on check point, ou pour plus de sécuriter faire des dump de tes logs régulièrement, ce qui te permet de garder trace de l'activiter de ta base tout en te liberant de la place dans tes logs.
Ton espace de Log doit te suffire c'est donc vers ces voies là que tu dois de diriger je pense.
A+

Premièrement, il y a un soucis de terminologie dans ton post.
Tu as un dataserver, avec plusieurs base.
Lorsque tu redémarres un dataserver, ASE annule les transactions non commitées qui on cependant été écrites, et s'assure que les transactions récemment commitées ont été écrites dans l'espace de data, et pas seulement dans l'espace de log. C'est ce qu'on appelle l'automatic recovery, et c'est ce processus qui prend beaucoup de temps sur une de tes bases.
Pour redémarrer le dataserver plus vite, tu peux désactiver l'automatic recovery pour les bases utilisateur en utilisant le traceflag 3608.
Ton dataserver démarrera plus vite, tu pourras dropper la base qui te gène et le redémarrer sans le traceflag 3608.
Enfin, pour savoir quel processus empêche la log de se vider (qui détient le point de troncature, en terminologie sybase), tu peux regarder dans la table master..syslogshold.
Je pense pour ma part qu'un process essaie de modifier trop de données en une seule fois, et qu'il faut le réécrire pour qu'il modifie les données par blocs de 10000 ou 20000 lignes, par exemple.

Merci de ces conseils, je pense que je vais m en inspirer. J'ai opté pour une solution plus radicale à base de "kill -9" et de "rm * -r". Donc, j'ai une base toute propre et desormais toute réinstallé. Je vais en profiter pour faire qqchose de propre en suivant vos conseils.

J'avais tenté le coup du démarrage sans recovery avec le flag 3608 mais cela aboutissait à un joyeux "segmentation fault". Du coup, j'ai opté pour la solution sauvage.

Merci à tous!

Bourrin!!!
J'aime :D :D :D
Surtout les Seg fault, que j'ai toutes les 2 secondes quand j'arrive à compiler du C lol...

Bon sur ce, on a eu le problème de journal de transaction plein (mon DBA m'avait alloué un espace trop petit, quand j'ai commencé à transférer les 260 procs stocks, vu que j'avais 30 erreurs par proc stock j'ai rempli le log en un jour), le DBA a augmenté la taille du journal (où? bonne question), et voulait mettre en place un système de sauvegarde de ces logs : en effet, quand tu sauvegarde un log (par les procs de sybase qui vont bien), il vide le-dit log.
Par contre, aux dernières nouvelles, il ne savait pas comment mettre en place ces sauvegardes (avec un peu de chance, c'est documenté? Enfin, vu la qualité de la doc sybase ASE... Je te souhaite bonne chance, pour m'y être perdu 2-3 jours...). Mais c'est une technique à étudier, si tu veux que ton instabilité disparraîsse définitivement (du moins, jusqu'à ce que la vitesse d'utilisation de ta base dépasse sa vitesse de backup ^^)

Ben vous scryptez vos dump tran et vous faites passer cela en cron... Pour augmenter les logs il faut faire un new device et un

Code:

---

alter database toto log on <newdevice>=taille

---

Vila pour une augmentation des logs (donc de la table syslogs !!!)
A plush