IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Adaptive Server Enterprise Sybase Discussion :

[ASE] Base instable : des solutions ?


Sujet :

Adaptive Server Enterprise Sybase

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2007
    Messages : 12
    Points : 9
    Points
    9
    Par défaut [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,

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    293
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 293
    Points : 182
    Points
    182
    Par défaut
    le dump tran with no_log est la version "violente" de purger tes logs, on lui préfère
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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+

  3. #3
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2007
    Messages : 12
    Points : 9
    Points
    9
    Par défaut
    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.

  4. #4
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    293
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 293
    Points : 182
    Points
    182
    Par défaut
    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

  5. #5
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2007
    Messages : 12
    Points : 9
    Points
    9
    Par défaut
    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 ?

  6. #6
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    293
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 293
    Points : 182
    Points
    182
    Par défaut
    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+

  7. #7
    Membre habitué
    Inscrit en
    Août 2007
    Messages
    134
    Détails du profil
    Informations forums :
    Inscription : Août 2007
    Messages : 134
    Points : 168
    Points
    168
    Par défaut
    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.
    DBA sybase confirmé
    Cherche un poste sur Paris

  8. #8
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2007
    Messages : 12
    Points : 9
    Points
    9
    Par défaut
    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!

  9. #9
    Nouveau membre du Club
    Profil pro
    Développeur informatique
    Inscrit en
    Mai 2006
    Messages
    36
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mai 2006
    Messages : 36
    Points : 33
    Points
    33
    Par défaut
    Bourrin!!!
    J'aime
    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 ^^)

  10. #10
    Membre habitué
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    293
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 293
    Points : 182
    Points
    182
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    alter database toto log on  <newdevice>=taille
    Vila pour une augmentation des logs (donc de la table syslogs !!!)
    A plush

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 0
    Dernier message: 25/11/2009, 11h02
  2. [MFC]Application basée sur des boites de dialogue
    Par -=Spoon=- dans le forum MFC
    Réponses: 2
    Dernier message: 24/08/2005, 12h55
  3. analyse "périodes" basées sur des dates.
    Par Yorglaa dans le forum Oracle
    Réponses: 7
    Dernier message: 22/12/2004, 12h39
  4. accès fortran à une base / utilisation des "bytea"
    Par bdkiller dans le forum PostgreSQL
    Réponses: 2
    Dernier message: 05/11/2004, 09h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo