[ASE 12.0] APRES LA Migration en V12.0 [Résolu]

[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,

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

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)

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

[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 :

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

[msomso]

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 :

Code :

1
2
SELECT 'GO'
GO

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

[mpeppler]

Pour générer un script directement via isql:

Code :

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

[DBRep]

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

[DBRep]

Envoyé par msomso

*** 1 ***
L'instruction GO a été ignorée

C'est l'outil ISQL qui vous a joué un tour

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

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

[mpeppler]

Envoyé par DBRep

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

[msomso]

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

[DBRep]

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)

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

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

[Roller]

Envoyé par msomso

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

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

Code :

reorg rebuild

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 :

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.

[mpeppler]

Doc 12.0, en français: http://sybooks.sybase.com/nav/detail.do?docset=1145

Michael

[msomso]

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