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 12.0] APRES LA Migration en V12.0


Sujet :

Adaptive Server Enterprise Sybase

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut [ASE 12.0] APRES LA Migration en V12.0
    Bonjour
    Voici le scénarion de ma migration
    1. Description des serveurs ASE sur les OS suivants:
      Poste OLD_1 : Sun Solaris Sun_svr4 OS 5.4 avec Sybase V11.0.3.3
      Poste OLD_2 : Sun Solaris Sun_svr4 OS 5.4 avec Sybase V11.0.3.3
      Poste New_1: Sun Solaris Sun_svr4 OS 5.6 avec Sybase V12.0.0.3
    2. Export (dump) des bases des serveurs OLD_1 et OLD_2 en V11
    3. Installation de 2 nouveaux ASE sur le poste NEW_1 (via srvbuild)
    4. Import (load) des bases exportées en V11 sur les 2 ASE en V12 .

    Sur un serveur j'ai ainsi créé et chargé les 5 bases du projet sans problème.
    Sur l'autre, l'une de bases m'embête un peu :

    *** Question 1 ***
    En effet, après les étapes:
    - create base for load (V12),
    - dump (V11) et
    - load (V12)
    effectués sans erreur, l'instruction ONLINE DATABASE <nom_base> "ne passe pas". Malheureusement je n'ai aucun message significatif, seulement ceci:

    SQL Server could not bring database <...> online.
    Je précise que le load se termine sans erreur:
    ...LOAD is complete (database <...>). Use the ONLINE DATABASE command to bring this database online; ...
    Je ne trouve aucune indication, ni dans le fichier d'alertes ni dans les log de dump et load. Toutes les autres bases ont été correctement migrées. Celle en erreur, je l'ai supprimée, recréée et rechargée à partir d'un autre dump, mais j'obtiens tjrs le même message enigmatique cité ci-dessus.

    Auriez-vous des suggestions à ce sujet ?


    *** Question 2 ***
    Les premiers tests applicatifs du serveur installé sans erreur, montrent qu'il est plus lent que celui en V11, alors que la machine est plus puissante.
    Faut-il récréer les statistics, indexes suite à ce que je viens de faire ?
    Si oui, pouviez-vous me suggérer par quoi commencer, svp ?

    *** Question 3 ***
    Lors de mes installations des serveurs, j'y ai importé aussi la base sybsystemprocs du serveur en V11 en croyant qu'il pouvait y avoir des procédures applicatives. En principe le load s'est bien passé et elle est passée "ONLINE" avec upgrade en V12. Je me demande maintenant si je ne risque pas de manquer de nouvelles procédures spécifiques à la v12 ...
    Pouvez-vous me donner votre avis, svp ?
    Est-il possible event. de recréer cette base sans reinstaller le serveur ?

    Merci d'avance
    msomso

  2. #2
    Membre chevronné

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Points : 1 828
    Points
    1 828
    Par défaut
    Pour la sybsystemprocs - il faut rejouer le script "installmaster" pour remettre les proc sp_xxx à la sauce 12.0. Ce script est dans $SYBASE/ASE-12_0/scripts. Il est essentiel de le faire rapidement car ces procs sont très différentes entre ces deux versions.

    Pour la perf - l'optimiseur est assez différent entre la 11.0.x et la 12. Il faut à priori faire un "update statistics", voir "update index statistics" pour toutes les tables pour essayer de remettre les choses à plat.

    Pour la base qui n'arrive pas à passer on-line... je ne vois pas ce qui peut être le problème en l'absence de messages d'erreurs (je suppose que tu as checké l'error ?) - Peut-être que fadace a une idée?

    Finalement - 12.0.0.3 est assez antique (bon, pas tout à fait autant que 11.0.3.3!). Si il faut absolument rester en 12.0 je suggère de passer à la dernière EBF (sauf erreur c'est 12.0.0.7).

    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

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut
    Bonjour
    Excuses-moi mais qu'entends tu par "checké l'error" - je n'ai aucun numéro d'erreur affiché ? Juste le message cité dans mon mail.

    Merci pour toutes tes réponses: je me lance dans l'update de statistics, etc.
    Comment faudrait-il faire avec la base sybsystemprocs, s'il y avait eu des procédures partagées (dans sybsystemprocs database) ?


    Merci bien
    msomso

  4. #4
    Membre chevronné

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Points : 1 828
    Points
    1 828
    Par défaut
    Pour l'online database: voir dans la log ASE (par défaut dans $SYBASE/ASE-12_0/install/<nom_serveur>.log) pour voir si il y a éventuellement des messages qui pourraient expliquer le problème.

    Pour la sybsystemprocs - en rejouant installmaster on va remettre les procs systèmes (sp_who, sp_helpdb, etc) qui sont compatibles avec la version du dataserver que tu utilise. D'ailleur, lorsqu'on passe un EBF (p.ex. de 12.0.0.3 à 12.0.0.4) on rejoue toujours ce fichier pour que les corrections au niveau proc stockées systèmes sont mises à jour.
    Si il y avait des proc "maisons" dans la sybsystemprocs de la base source (en 11.0.x) celle-ci pourraient être transférées avec un outil permettant l'extraction de la source des procs (p.ex. dbschema.pl, ou DBArtisan, etc).
    Ceci étant, si tu as fait le dump/load de sybsystemprocs entre la vieille et la nouvelle version alors il est probable que tu as ces procs à dispo (puisque installmaster ne va pas dropper les procs qu'il ne connait pas).

    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

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut
    Bonjour
    Je n'étais peut être pas très claire: aucun message lié au problème de "ONLINE" n'est tracé dans le fichier log du serveur. A mon avis cela doit venir de la base source: il faudrait la vérifier, mais je n'ai pas trop l'habitude de le faire... S'agissant du serveur de test, je vais voir si on accepte d'importer la base de production à la place de celle qui ne veut pas "se mettre online" . Je l'ai importée sur le nouveau serveur de prod sans problème.

    J'ai lancé installmaster avant de partir ce soir. Je verrai demain ce que cela donne.

    Merci aussi pour les autres précisions.

    msomso
    P.S.
    Pourvu que le recalcule de statistiques amèliore les performances.

  6. #6
    Membre du Club
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    37
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2007
    Messages : 37
    Points : 48
    Points
    48
    Par défaut
    Bonsoir,

    Citation Envoyé par msomso

    *** Question 1 ***
    Auriez-vous des suggestions à ce sujet ?
    • Il est possible qu'il n'y ai pas assez d'espace libre dans la DB V11 pour effectuer la migration.
    • Il est possible que certains nom d'objet (table, colonne, procédure, ...) deviennent des mots clés réservés en V12 (vs V11)
    • ...

    Il me semble qu'il existe des procédures de pre-upgrade qui permettent la vérification de tout ça, avant une migration...


    Citation Envoyé par msomso

    *** Question 2 ***
    Faut-il récréer les statistics, indexes suite à ce que je viens de faire ?
    Si oui, pouviez-vous me suggérer par quoi commencer, svp ?
    Je pense qu'effectivement, mettre à jour les statistics ("update statistics") peut aider et également recréer les index (ainsi que les trigger et procédures stockées d'ailleurs)


    Citation Envoyé par msomso

    *** Question 3 ***
    j'y ai importé aussi la base sybsystemprocs du serveur en V11
    Ce n'est pas une bonne idée.
    Comme dit précedement, il faut reéxecuter le script "installmaster"


    DBRep

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut
    Bonjour
    * 1 *
    Pour info:
    Le script installmaster s'est bien déroulé sur mes 2 serveurs.

    * 2 *
    Pour "ONLINE database ..." en erreur:
    Je vais essayer d'allouer + d'espace à ma base un peu "têtue", cependant le message d'erreur est quasi-instantané (comme si rien n'avait été démarré).
    Est-il possible d'activer une trace supplémentaire (session et/ou serveur ) pour avoir un message suite à cette commande ?

    * 3 *
    J'aurais vraiment besoin de vos lumières pour comprendre la gestion des stats.
    Plus je lis la doc et moins j'y comprends. Entre les options :
    - "update all statistics <table_name>"
    - "update statistics <table_name>"
    - "update index statistics <table_name>"
    je suis un peu perdue.


    Je pense faire ceci:
    Pour toute table <ma_table> de ma base:
    1. update statistics <ma_table>, puis
    2. update index statistics <ma_table>

    Mais, je me demande si cela ne revient au même que de faire seulement "update index statistics" .

    Merci d'avance
    msomso

  8. #8
    Membre chevronné

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Points : 1 828
    Points
    1 828
    Par défaut
    Je n'ai pas vraiment de bonnes idées pour le ONLINE database...

    Par contre pour update [index] statistics:

    update statistics calcule les statistiques (distribution, histogrammes, etc) uniquement pour la première colonne de chaque indexe. Cette opération est relativement rapide, puisqu'il n'est pas nécessaire de trier les données (la colonne est déjà dans le bon ordre) pour générer les histogrammes.

    update index statistics calcule en plus les stats (distributions, histogrammes) des autres colonnes présentes dans chaque index. Cela prend plus de temps puisqu'il faut analyser chaqu'une des colonnes de chaque indexe, avec tri pour les colonnes "secondaires".

    En 12.0 il n'y a pas d'échantillonage pour ces calculs de stats, donc l'update index statistics peux prendre un certain temps, et aura besoin de place dans tempdb (toujours à cause du tri).

    update index statistics donne évidemment de meilleurs stats pour l'optimiseur. Le choix de la version de la commande à utiliser dépend évidemment de la situation - on peux commencer par update statistics et voir comment ça va.

    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

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut
    Bonjour

    *** ONLINE database ***
    Je vais commencer par la bonne nouvelle:
    j'ai pu mettre ma base online après avoir agrandi l'espace !

    *** STATISTICS ***
    Pour les statistiques: j'ai lancé un script avec :
    - update statistics <nom de table>
    - update index statistics <nom de table>.
    ***
    Ce traitement a été extremement rapide (mes bases sont de petite taille), ceci étant dit, les dates de stat dans les tables systeme sont bien modifiées. Sinon, il n'y a aucun retour/message de la commande dans mon fichier log et quand je lance un update dans isql, je n'ai rien au retour non plus. Est-ce normal?
    ***
    Je suis désolée d'insister, mais est-ce que la commande "update all statistics <nom de table> " est equivalente aux deux updates cités ci-dessus ?

    *** QUESTION PRINCIPALE ***
    Pour moment, nous ne voyons pas d'amélioration suite à la mise à jour des statistiques. L'application au lancement est + lente qu'avec ancien serveur.
    1. Pensez-vous qu'il est justifié de recalculer les index suite à ma migration ?
    2. Ou bien, faudrait-il penser aux nouveaux paramètres spécifiques "V12" à modifier dans le fichier de configuration ?
    3. Quel est le fichier de paramétrage "par defaut" avec toutes les valeurs "DEFAULT" ?


    D'avance merci
    msomso

  10. #10
    Membre chevronné

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Points : 1 828
    Points
    1 828
    Par défaut
    1. update all statistics:

    Ceci calcule les stats sur TOUTES les colonnes - ce n'est en général pas conseillé.

    (note : update index statistics est un sur-ensemble de update statistics, donc il suffit de faire la première commande).

    2. Lenteur:

    Cela fait très longtemps que j'ai fait un upgrade du genre - mais il est possible qu'il faille faire un "delete statistics" puis un update index statistics pour améliorer la situation.

    Si les accès se font par proc stockées il faudrait aussi faire un
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    sp_recompile <nom_table>
    après l'update statistics pour que les procs soient recompilées lors de leurs prochain usage.

    Alternativement, un drop/create des indexes devrait aussi améliorer la situation.

    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

  11. #11
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut
    Bonsoir
    *** 1 ***
    C'est un peu anecdotique ma petite histoire:
    J'ai généré dynamiquement (via un select sur sysobjects et sysindexes) un script contenant une suite d'appels de type "update index statistics <table> <index>" suivi à la fin d'une instruction GO obtenue par :
    De cette façon, l'instruction GO se trouve précédée d'un espace. Je ne sais pas pourquoi, mais cette espace l'inhibe.
    L'instruction GO a été ignorée et mon script ne s'exécutait donc pas du tout!
    Une fois l'espace au début de ligne éliminé, le traitement en effet "prend son temps" .
    Je testerai demain l'effet de tout ça.
    Avant de partir, j'ai pu voir quand même qu' ASE ne trouvait pas certains indexes, alors que je ne traite que ceux se trouvant dans sysindexes. Comment est-ce possible d'avoir, dans une table système, les indexes inexistants dans la base ?

    note : update index statistics est un sur-ensemble de update statistics, donc il suffit de faire la première commande
    J'ai crû comprendre que le principe du recalcul des statistiques était :
    - "update statistics" -------> pour la première colonne d'un index composé
    - "update index statistics" -> pour toutes les colonnes d'un index composé

    D'accord donc pour le
    sur-ensemble
    , mais dans ce cas il suffirait, me semble-t-il, de passer la 2e et non la 1ere commande. Sinon, je ne comprends vraiment rien du tout. La doc ASE est, pour le moins, floue et imprécise.

    *** 2 ***
    sp_recompile <nom_table>
    Oui j'ai pas mal de procédures. Mais ne serait-il pas plus performant de les recompiler dans la foulée, avant qu'elle ne soient appelées (ralentissements)?
    Si oui, comment le faire ? Je n'ai pas de sources de création de procédures

    *** 3 ***
    un drop/create des indexes devrait aussi améliorer la situation
    Oui, mais ... comment extraire le sql de création d'indexes (je ne peux pas installer des outils supplémentaires sur le site client), ASE propose-t-il une solution ?

    *** 4 ***
    De même, comment valider les autres composants SQL: triggers, rules etc ?
    Connaissez-vous des incompatibilités T-SQL entre V11 et V12 ?

    msomso

  12. #12
    Membre chevronné

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Points : 1 828
    Points
    1 828
    Par défaut
    Pour générer un script directement via isql:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    select "update index statistics " + name + char(10)+"go" from sysobjects where type ='U'
    Update stats/update index stats: Effectivement c'est un peu flou - en fait on fait l'un ou l'autre, en fonction des besoins. Pour avoir de meilleurs stats on utilisera la deuxième forme, mais cela prend plus de temps, d'où le choix.

    Recompilation des procs/triggers: Sous Oracle on fait "alter <object> recompile". Sous Sybase on marque la table, et tout objet qui utilise cette table sera recompilé lors de sa prochaine exécution.

    Pour la recréation des indexes: je ne sais pas si la version 12 inclu déjà l'outil ddlgen. Si ce n'est pas le cas alors il n'y a pas d'outil natif (que je connaise) qui permette de le faire. La librairie de procs stockées de Ed Barlow (http://www.edbarlow.com/gem/procs_only/readme.htm) comporte une proc sp__revindex qui devrait en principe faire ce que tu veux (note que je ne l'ai pas utilisée personellement, mais d'autre DBA que je connais et respecte l'on utilisé, p.ex. Jason Froebe, aussi un ex. de Sybase [comme fadace]: http://froebe.net/blog/2007/08/28/mo...-print-the-go/)

    Pour ce qui est de la syntaxe - le T-SQL de la 12 est un sur-ensemble de 11.0.x (p.ex. le CASE, les jointures ANSI, etc), donc il ne doit pas y avoir de problème de ce genre.

    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

  13. #13
    Membre du Club
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    37
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2007
    Messages : 37
    Points : 48
    Points
    48
    Par défaut
    Citation Envoyé par msomso

    Par contre, je ne comprends pas pourquoi vous suggérez de reconstruir les index, procédures et triggers.
    Bonjour,

    Pour les index, je reconnais que cela fait un peu "ceinture-et-bretelles" avec les updates statistics...

    Pour les procédures et les trigger, un "drop ..." + "create ..." permet d'eviter tout problème issue de la migration du code "pseudo-compilé" de ces procédures.
    Ce n'est pas qu'il y en a eu beaucoup, mais, dans votre cas, vous passez d'une V11.0 à une V12.0 ce qui fait un saut de 3 versions majeures. Personnellement, je ne prendrai pas ce risque pour un système en production pour ce que ça coute...
    Je préfère un "drop ..." + "create ..." a "sp_recompile", parce que le "drop ..." + "recreate ..." s'exécute sur le momment, pendant la phase de migration, alors que le "sp_recompile" recompilera la procédure à sa prochaine exécution, ce qui peut poser des surprises de performance aux redémarrage de production...


    DBRep

  14. #14
    Membre du Club
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    37
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2007
    Messages : 37
    Points : 48
    Points
    48
    Par défaut
    Citation Envoyé par msomso

    *** 1 ***
    L'instruction GO a été ignorée
    C'est l'outil ISQL qui vous a joué un tour


    Citation Envoyé par msomso

    *** 2 ***Si oui, comment le faire ? Je n'ai pas de sources de création de procédures
    Il vous faut utiliser des outils d'extraction de DDL, je crois bien qu'il existe même des scripts SQL pour faire cela ...


    Citation Envoyé par msomso

    Avant de partir, j'ai pu voir quand même qu' ASE ne trouvait pas certains indexes, alors que je ne traite que ceux se trouvant dans sysindexes. Comment est-ce possible d'avoir, dans une table système, les indexes inexistants dans la base ?
    C'est "normal", "sysindexes" contiens aussi une entrée pour la table en elle-même ("indid = 0")


    DBRep

  15. #15
    Membre chevronné

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Points : 1 828
    Points
    1 828
    Par défaut
    Citation Envoyé par DBRep Voir le message



    C'est "normal", "sysindexes" contiens aussi une entrée pour la table en elle-même ("indid = 0")


    DBRep
    Il y a aussi indid = 255, qui contient les colonnes de type TEXT ou IMAGE.

    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

  16. #16
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut
    Bonsoir
    Tout d'abord, merci de votre généreuse participation.
    Voilà où j'en suis:

    1. Le recalcul de statistiques n'as pas éliminé les ralentissements.
    2. J'ai extrait les ddl des indexes, procs, des contraintes FK et triggeurs de mes 2 bases principales. Le ddlgen n'est disponible qu'à partir 12.5. Bien que la version 12.5 existe sur ma machine, j'ai des erreurs en essayant de lancer le ddlgen: librairies introuvables. Possible que l'installation de 12.5 n'est pas complète.J'ai utilisé donc le Sybase Central. Ce n'est pas totalement paramétrable, donc je dois maquiller un peu les scripts avant de les lancer (le drop d'index n'y est pas etc. )
      J'ai reconstruit de cette manière tous les indexes sans problème sur une base (y compris le drop/create des FK).

      Sur l'autre base, je n'arrive pas à dropper les index liés a la PK constraint. Il faut que je vois dans la doc comment dropper les contraintes PK . Soit mon" alter table drop constrainte ..." n'a pas fonctionné, soit isql continue à me jouer un tour.
    3. Je vais recréer mes procs et triggeurs, relancer le recalculs de statistiques et ensuite, on verra


    Je vous tiendrais au courant du résultat final.

    Savez-vous s'il existe une doc Sybase spécifique à la migration ?
    Je me demande si nos problèmes ne viennent pas de mauvais paramétrage/configuration serveur. J'ai laissé tous les paramètres par défaut, sauf la mémoire que j'ai agrandie quand même.

    Merci
    msomso
    P.S.
    Connaissez-vous le problème de la commande startserver -f RUN_xxx.
    Mon fichier de démarrage est créé par le GUI et pourtant cette commande génére erreur:
    can't execute binary file.
    Par contre j'arrive à lancer la commande de ce même fichier par copie/coller et le serveur demarre

  17. #17
    Membre du Club
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    37
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2007
    Messages : 37
    Points : 48
    Points
    48
    Par défaut
    Citation Envoyé par msomso

    Savez-vous s'il existe une doc Sybase spécifique à la migration ?
    Il y a : Sybase Sybooks (mais, il n'y a plus la version 12.0, visiblement)


    Citation Envoyé par msomso

    Je me demande si nos problèmes ne viennent pas de mauvais paramétrage/configuration serveur. J'ai laissé tous les paramètres par défaut, sauf la mémoire que j'ai agrandie quand même.
    Pour les problèmes de performance, oui (voir Sybooks).

    If faudrait commencer par voir ce qui avait été "tunné" en V11 pour le reporter sur la V12.
    Ensuite, si les problèmes de performance persistent après les "update statistics" et la recréation des procédures, il faudra rentrer plus dans le détail :
    - mesurer les différences de performance (est-ce : d'1 seconde ça passe à 3, ou est-ce d'10 secondes ça passe à 5 minutes)
    - est-ce que les "update statistics" ont apportés quelque chose ?
    - volume des données
    - structure des tables (peu ou beaucoup de colonnes)
    - style de requettes posant des problèmes de performance (donc, déjà les identifier) (requette sur une seule table ou avec jointure, beaucoup de jointure ?)

    Après, il y a des outils pour analyser ce qu'il ce passe, "set showplan" pour voir s'il n'y a pas de "table-scan" intempestif, par exemple.
    Tu peux aussi utiliser "sp_sysmon", notamment pour tout ce qui est accès au data cache, disque I/O, etc...


    Citation Envoyé par msomso

    Connaissez-vous le problème de la commande startserver -f RUN_xxx.
    Mon fichier de démarrage est créé par le GUI et pourtant cette commande génére erreur:
    Par contre j'arrive à lancer la commande de ce même fichier par copie/coller et le serveur demarre
    - faire un "file startserver" : est-ce bien un exécutable ELF Solaris ?? (il faut être dans le répertoire où se trouve "startserver", dans "$SYBASE/$SYBASE_ASE/install" je crois bien)
    - faire un "file dataserver" : même question (dans "$SYBASE/$SYBASE_ASE/bin")
    - vérifier qu'il y a bien des droits d'exécution pour ces 2 binaires et également pour le script Shell "RUN_xxx"


    DBRep

  18. #18
    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
    Citation Envoyé par msomso Voir le message
    *** 2 ***


    Oui j'ai pas mal de procédures. Mais ne serait-il pas plus performant de les recompiler dans la foulée, avant qu'elle ne soient appelées (ralentissements)?
    Si oui, comment le faire ? Je n'ai pas de sources de création de procédures

    *** 3 ***


    Oui, mais ... comment extraire le sql de création d'indexes (je ne peux pas installer des outils supplémentaires sur le site client), ASE propose-t-il une solution ?

    msomso
    Pour reconstruire tes indexes, une possibilité (pas très économique, mais simple) est de faire un:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    alter table <tablename> lock datarows
    go
    alter table <tablename> lock allpages
    go
    sur tes tables en APL (all-pages locking), et un sur tes tables DOL (datarows/datapages locking).
    Attention avec cette méthode (allpages->datarows->allpages) tu risques de perdre des propriétés spécifiques aux index clustered sur les tables APL (ignore/allow dup_rows). Vérifie avant que cela ne causera pas de problèmes.

    Enfin, après un load database, il y a une re-résolution de toutes les procédures.
    La "recompilation" (entre guillemets, plus de détails :ici) ne devrait donc pas être nécessaire.
    On peut cependant forcer la re-résolution avec la commande non supportée
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    dbcc markprocs ([dbid])
    , mais je n'ai utilisé cette commande qu'en 12.5 et je ne sais pas si c'est dispo en 12.
    DBA sybase confirmé
    Cherche un poste sur Paris

  19. #19
    Membre chevronné

    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    1 307
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : Suisse

    Informations forums :
    Inscription : Janvier 2006
    Messages : 1 307
    Points : 1 828
    Points
    1 828
    Par défaut
    Doc 12.0, en français: http://sybooks.sybase.com/nav/detail.do?docset=1145

    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

  20. #20
    Membre régulier
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    254
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 254
    Points : 80
    Points
    80
    Par défaut
    Bonjour

    DBRep - je n'ai pas compris ton conseil :
    - faire un "file startserver" : est-ce bien un exécutable ELF Solaris ?? (il faut être dans le répertoire où se trouve "startserver", dans "$SYBASE/$SYBASE_ASE/install" je crois bien)
    - faire un "file dataserver" : même question (dans "$SYBASE/$SYBASE_ASE/bin")
    Dois-je lancer "littéralement" ces 2 commandes (quels paramètres) ?

    Je pense que je partirai du fichier de la configuration V11 pour voir "ce qui a été tuné". Mais je n'ai aucune garantie que la V12 sera optimisée de cette façon.

    Roller - merci pour l'info. En plus, le site est intéressant. Par précaution, je chercherai dans les tables système de procédures, quelle est la date de compilation. Dans mon cas, elle devaient être compilées lors du load et ensuite lors de mes suppression et recréation d'indexes.

    Pourquoi, le lock datarow et lock allpages font reconstruire les indexes ?

    Michael - merci pour cette invitation à plonger dans la doc. Je crois que je n'y échapperai pas ...

    merci
    msosmo

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Gestion de l'auto-incrément après une migration
    Par 4rocky4 dans le forum Administration
    Réponses: 3
    Dernier message: 06/05/2009, 09h34
  2. erreur apres une migration de 5.5 vers 6
    Par Ashen-Shugar dans le forum NetBeans
    Réponses: 2
    Dernier message: 04/01/2008, 09h58
  3. Erreur après la migration de delphi 2005 vers 2006
    Par sawbo1 dans le forum Delphi
    Réponses: 2
    Dernier message: 21/07/2006, 20h18
  4. Changer le code apres une migration HF ->mysql
    Par phebus29 dans le forum WinDev
    Réponses: 1
    Dernier message: 23/06/2006, 20h20
  5. Urgent - après la migration - les tables "Invalid Objet
    Par nnn2050 dans le forum MS SQL Server
    Réponses: 11
    Dernier message: 27/12/2005, 11h50

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