Taille du default data cache ASE 15.0.2

**Laurielee** · 23/09/2009, 17h32

Bonjour,

J'ai un souci avec la configuration de l'ASE que je viens d'upgrader en 15.0.2
Comme les perf sont moins bonnes qu'en 12, je cherche à tuner la config.

J'ai configuré la max memory à 3 000 000 de pages de 2K
le procédure cache à 7000 pages de 2K
le nombre de locks à 30 000
(s'il manque des renseignements, dites moi lesquels).

Quand j'essaie de configurer le default data cache à 1600MB (valeur qui est configurée chez mon client en ASE 12) ça plante tout et je n'ai plus la main. Je doit reseter le server et aller corriger le .cfg à la main pour que ça reparte (la valeur 1300 passe).

Les servers ASE et back démarrent (showserver les voit démarrés), mais isql me renvoie une erreur comme si ils n'étaient pas démarrés (ct_connect ...) et dit que ma base de données n'est pas accessible.

Je suis sur
HP 9000/800/rp3440 2 X 73GB disks
Diskbay 6 x 73GB disks
OS mode 64 bits HP-UX B.11.11
Main memory 2046MB

D'où cela peut il venir, quelqu'un le sait il ?

Merci d'avance pour vos réponses
Laurielee

**thx5959** · 24/09/2009, 10h47

Bonjour

- As-tu pensé de faire un
update index statitics après tont upgrade ? car l'optimiseur a besoin des stats surs toutes les colonnes.

- Qu'as tu choisis comme mode pour l'optimiseur ?
• allrows_oltp (meilleur pour les requêtes de type OLTP)
• allrows_mix (mode par défaut en ASE15 alliant les deux types de requêtes)
• allrows_dss (meilleur pour les requêtes décisionnelles)
En fonction du choix que l’on effectue, l’optimiseur utilise une technique d’optimisation différente pour résoudre les requêtes et a à sa disposition certains types d’algorithme.

- Est tu bien en ESD#2 (ebf 16736) .
Cet ebf corrige un certain nombre de bugs ou disfonctionnements tels que des problèmes de performance, de statistiques mal calculées ou dans certains cas bien particuliers les résultats de requête sont différents de ceux attendus, ainsi que des stacks traces impromptus.
Une des corrections importantes est celle concernant la commande Update Index Statistics qui de temps en temps calcule mal le dernier pas des données de la table et affecte un poids O alors qu’il y a des données correspondantes à cette tranche de valeurs. D’où derrière le choix d’un plan qui peut s’avérer inadéquat.

Cdlt

**Laurielee** · 24/09/2009, 11h38

Merci Thx5959.

1 En fait je n'ai pas fait d'update statistics après l'upgrade parce que le guide dit :
After you have upgraded, you do not need to run update statistics on any tables. The upgrade process does not cause any changes in existing statistics.

Par contre tu penses que le update index statitics doit être exécuté sur chaque table ? Y a t il une commande générale ?

2 Je n'ai pas choisi de mode pour l'optimiseur parce que je ne connaissais pas ce nouveau feature.
Je pense que allrows_oltp serait le mieux pour ma base.

3 Par ailleurs je suis en EBF 14329
1> select @@version
2> go
Adaptive Server Enterprise/15.0.2/EBF 14329/P/HP9000-879/HP-UX 11.11/ase1502/24
86/64-bit/FBO/Thu May 24 21:14:31 2007

Cordialement

**Roller** · 28/09/2009, 12h46

Oui, en passant à la version 15, l'optimiseur peut se tromper, surtout dans l'ordre de jointure, s'il ne dispose pas de stats sur toutes les colonnes de l'index.
Il faut soit:

- analyser le plan de la ou les requêtes à problème, en lançant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
dbcc traceon(3604)
set option show_missing_stats on
set showplan on
set statistics io,time on
go

avant de lancer la requête et analyser le plan.
Puis corriger la requête en ajoutant les stats qui manquent à l'optimiseur mais qui influent grandement sur le nombre de lignes concernées, ou forcer le plan d'exécution avec un 'set forceplan on'.

- modifier vos scripts d'update statistics pour lancer un update index statistics, mais les temps d'update statistics seront plus longs, vous pourrez alors êtres contraints d'utiliser le sampling pour les réduires.

**mpeppler** · 28/09/2009, 13h34

Quelle est la version exacte d'ase (select @@version) ?

Merci,

Michael

**Laurielee** · 28/09/2009, 17h03

Je suis en 15.0.2:

1> select @@version
2> go
Adaptive Server Enterprise/15.0.2/EBF 14329/P/HP9000-879/HP-UX 11.11/ase1502/24
86/64-bit/FBO/Thu May 24 21:14:31 2007

Cordialement

**mpeppler** · 28/09/2009, 17h33

Hmm - c'est une version assez "ancienne". Il pourrait y avoir un bug dans le calcul de la mémoire disponible qui cause le problème de base mentionné dans le poste original.

En général la 15.0.2. ESD 6 ou la 15.0.3 ESD 2 sont considérés "stables"...

Si c'est possible je suggère d'upgrader à la 15.0.2 ESD 6 et de voir si le problème persiste.

Michael

**Laurielee** · 29/09/2009, 16h56

Pour le moment ce n'est pas possible d'upgrader. Mais je pense que mon client sera en 15.0.3.

Le pb c'est que sur le download center de Sybase, on ne sait pas à quel niveau d'ESD ou d'EBF on est. A moins que la date (11 déc 2008) ne soit une indication ...

En attendant je vais faire les update index statistics sur chaque table et voir ce que ça donne au niveau perf....

Et j'ai une formation Performance and tuning en vue pour octobre

Merci Michael

**Laurielee** · 12/10/2009, 11h57

Bon, c'est un peu mieux avec les index statistics mis à jour, mais c'est pas encore terrible par rapport à la 12.5.4 ...

**jeeps64** · 12/10/2009, 12h27

Nous avons nous aussi basculer de 12.5.3 à 15 accompagné de probleme de perfs aussi

Au départ, nous avons du mettre l'option 'compatibility mode' à 1 pour forcer l'optimiseur à travailler en 12.5
Nous sommes entrain de tenter de supprimer cette option sur la plupart des serveurs car il y a une serie de bug associés à cette conf

Voici les différents points sur lesquels nous avons pu gagner en performance une fois l'option compatibility mode désactivée :

Augmentation significative du statement cache et du procedure cache
Augmentation de l'ULC sur tempdb (session tempdb log cache size)
Sur certaines requêtes, on a désactivé un algorithme de distinct (
Code : Sélectionner tout - Visualiser dans une fenêtre à part
```
set opportunistic_distinct_view off
```
). Cela est du à un bug sur les requêtes du type
Code : Sélectionner tout - Visualiser dans une fenêtre à part
```
select distinct col1,col2 into #table from matable where ...
```

L'outil de JP MARTIN (ASEMONLOGGER) nous aide grandement dans notre migration d'ailleurs

J'espère que ca pourra vous aider

Jeeps64

**mpeppler** · 12/10/2009, 13h50

Autre chose essentielle - s'assurer qu'on fait bien "update INDEX statistics" sur toutes les tables. Les stats sur les colonnes non-leading sont importantes pour que l'optimiseur 15 puisse bien faire son boulot.

Michael

**Laurielee** · 14/10/2009, 10h52

Michael,

Oui, j'ai listé toutes les tables et exécuté un update index statistics sur chacune d'elles.

Jeeps64,

Pour le moment j'ai du upgrader en 15.0.2, donc pas de compatibility mode ....

# Augmentation significative du statement cache et du procedure cache
Le statement cache est à 0, quelle est l'ordre de grandeur souhaitable ?

Le procedure cache size est à 7000 pages de 2k (5000 en 12.5)

# Augmentation de l'ULC sur tempdb (session tempdb log cache size)
Il est à 2k, comme recommandé.

#Sur certaines requêtes, on a désactivé un algorithme de distinct
On n'a pas de requête select distinct into

Merci

**mpeppler** · 14/10/2009, 15h18

Le statement cache est utile si l'application envoie des requêtes SQL simple, plutôt que des procs stockées.

Si tu mets un place le statement cache, alors il faut aussi positionner le "enable literal autoparam' (via sp_configure), pour vraiment pouvoir tirer parti de cette fonctionalité.

La taille à positionner dépend évidemment du serveur, de la mémoire disponible, etc. - difficile de donner un avis sans connaitre les détails...

Michael

**Laurielee** · 14/10/2009, 16h48

Merci Michael.

Bon, maintenant je commence à upgrader chez mon client (leur machine de test).
J'ai installé l'ASE 15.0.3 EBF16552, ça s'est bien passé.

J'ai passé le preupgrade, corrigé tous les warnings, mais j'ai aussi ce message :

... Checking database 'aeem'.
PORT_PORT_A_728389664 text has some errors.
PORT_PORT_P_744389721 text has some errors.
LINK_LINK_A_945438442 text has some errors.
CRCN_CRCN_P_1000390633 text has some errors.
GEOA_GEOA_S_1128391089 text has some errors.
CGRP_CGRP_S_1144391146 text has some errors.
CUST_CUST_S_1160391203 text has some errors.
***ERROR: Some error(s) found while checking compiled objects in
database 'aeem'. Please drop and recreate these objects.

Or je n'ai aucune idée de ce que sont ces objets, jamais vus avant ....
sp_helpobjectdef ne donne rien.

Heeeelp please

**mpeppler** · 14/10/2009, 17h22

Ces objets sont des defaults ou contraintes qui n'ont pas été nommées.

On le voit au nom, qui finit avec un nombre - où le nombre correspond à l'id de l'objet (table).

P.ex. "PORT_PORT_A_728389664" est probablement un default ou une contrainte sur la table d'on l'id (dans sysobjects) est 728389664.

Maintenant - pour trouver le texte de l'objet correspondant.... il faudrait déjà avoir la DDL source des tables en question, et voir quelle est la difference avec la définition que tu trouve sur le serveur fraichement upgrader.

Michael

**Laurielee** · 15/10/2009, 11h41

J'ai bien ces objets dans la table sysojects.

PORT_PORT_A_728389664 728389664 1 D 0 6
0 0 0 Jul 8 2003 9:01AM
Jul 8 2003 9:01AM 0 0 0
0 0 0 0 0
NULL NULL

Quand je recherche leur texte j'obtiens :

1> sp_helptext PORT_PORT_A_728389664
2> go
# Lines of Text
---------------
1

(1 row affected)
text --------------------------------------------------------------------------
DEFAULT 2 nul

(1 row affected)
(return status = 0)

Ce texte n'est différent de celui d'autres objets similaires que par le mot nul:

1> sp_helptext ATRP_ATRP_G_779865845
2> go
# Lines of Text
---------------
1

(1 row affected)
text --------------------------------------------------------------------------
DEFAULT 1

(1 row affected)
(return status = 0)

Pensez vous que je puisse modifier le texte de ces 6 objets dans syscomments en supprimant le nul ?

1> select * from syscomments where id = 728389664
2> go
id number colid texttype language
text
colid2 status
----------- ------ ------ -------- --------

728389664 0 1 0 0
DEFAULT 2 nul
0 0

(1 row affected)

Merci

**mpeppler** · 15/10/2009, 12h04

C'est possible - mais je ne garantis rien...

En fait il me semble qu'on avait eu ce genre de problème il y a qq temps - mais comme je ne m'occupe pas directement des upgrades ici je ne me rappelle plus des détails exacts.

Si les tables ne sont pas trop grandes je recommenderais de les recréer proprement pour éviter toute surprise.

Alternativement - si il y a un contrat support j'ouvrirais un call...

Michael

**Laurielee** · 15/10/2009, 15h41

Je ne peux pas recréer toutes les tables (PORT, LINK, CRCN, GEOA et CUST), elles sont trop grandes.
De plus dans sysobjects, par exemple pour

PORT_PORT_A_728389664 728389664

728389664 est l'id de PORT_PORT_A_728389664, pas l'id de la table (la table PORT a l'id 712389607).

J'ai essayé de changer le texte de PORT_PORT_A_728389664 dans syscomments

1> select * from syscomments where id = 728389664
2> go
id number colid texttype language
text
colid2 status
----------- ------ ------ -------- --------

728389664 0 1 0 0
DEFAULT 2 NULL
0 0

(1 row affected)

pour mettre NULL à la place de nul, mais ça n'a rien changé au diagnostic ....

Pour upgrader sur notre machine de la version 12.5.0 à la 15.0.2 ce texte ne pose pas de problème, pourtant. Ce serait la 15.0.3 qui serait moins tolérante ?

**lparodi** · 15/10/2009, 21h34

Envoyé par mpeppler

C'est possible - mais je ne garantis rien...

En fait il me semble qu'on avait eu ce genre de problème il y a qq temps - mais comme je ne m'occupe pas directement des upgrades ici je ne me rappelle plus des détails exacts.

Michael

Hello,

C'est en effet une situation frustrante : les objets sont utilisés mais le code stocké dans syscomments est incorrect.
J'ai rencontré deux cas similaires :
- create nonclustered index : les 2 espaces font que parfois le dernier "e" du create disparaît.
- des default présentent une syntaxe incorrecte.

La seule solution est de recompiler les objets à partir du code qui aura été stocké au chaud dans un outil de versioning ... Je déconseillerai fortement la mise à jour directe de syscomments.

Deux bonnes nouvelles néanmoins :
- ce souci de syntaxe à été identifié et résolu il y a déjà quelques temps en 12.5.4 ESD #8 et 15.0.2 ESD#1
- il est possible d'identifier ces objets problématiques en utilisant la commande dbcc upgrade_object . Note utile : il faut absolument la lancer sur une v15, sinon les objets incorrects ne seront pas "vus".

Voilà, en espérant que cela puisse aider ....

**Laurielee** · 16/10/2009, 12h07

Merci lparodi.

Pourtant je pars de 12.5.4 et je migre en 15.0.3 !

La seule solution est de recompiler les objets à partir du code qui aura été stocké au chaud dans un outil de versioning ...

Comment puis je faire ça ? De quel code s'agit il ? (Je n'ai pas encore migré, puisque le preupgrade n'est pas clean).

Vous pensez que je dois migrer quand même, puis exécuter dbcc upgrade_object sur les defaults en 15 (le script preupgrade se conclut par Upgrade eligibility test succeeded, malgré ces 6 text errors) ?

D'autre part j'ai essayé de créer un default pour tester (avant d'essayer de dropper et recréer les fautifs).
J'ai exécuté

1> create default Dtest as "2 null"
2> go

Mais le default créé a comme texte :

1> select * from syscomments where id = 1507536454
2> go
id number colid texttype language
text
colid2 status
----------- ------ ------ -------- --------

1507536454 0 1 0 0
create default Dtest as "2 null"

0 0

(1 row affected)

Ce qui n'est pas du tout ce que je veux ...

Any suggestion ?

Taille du default data cache ASE 15.0.2

Adaptive Server Enterprise Sybase

Discussions similaires

Partager

Partager