Discussion :

[msomso]

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

[mpeppler]

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

[msomso]

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

[mpeppler]

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

[msomso]

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.

[DBRep]

Bonsoir,

*** 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...

*** 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)

*** 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

[msomso]

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

[mpeppler]

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

[msomso]

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

[mpeppler]

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