Question

Je travaille avec Sybase 15 dans ma demande et il y a des problèmes de performances liés à imbriquée jointures. Je procédure stockée qui sélectionne des colonnes 2 à partir de 2 tables et compare égalités de plus de 10 colonnes entre ces 2 tableaux. Mais quand je lance ce Stor. proc., le résultat prend 40 minutes. J'ai ajouté « set Merge-off se joindre à » déclaration haut de mon proc alors le résultat prend 22 secondes. mais je besoin d'une solution plus sans cela. J'utilisais sybase 12.5 avant et il n'y avait pas une question comme ça et mon proc était de prendre 3 minutes pour le résultat.

I ont comparé les configurations de serveur avec sp_configure entre 15 et 12,5 et configurations de serveur sybase15 (E / S et les paramètres de configuration de la mémoire) sont plus grandes que serveur sybase12.5.

Info: ressources système de sybase15 situé pc sont vraiment bons

.
Était-ce utile?

La solution

Je viens de passer 14 heures au travail de débogage des problèmes de performance critiques qui ont surgi d'une migration Sybase 15 le week-end.

Le Optimiseur de requête a été fait (pour nous) des décisions très bizarres.

Prenons un exemple,

select a, b, c from table1, table2, table3 where ...

contre

create table #temp (col1 int, col2 int, ... etc)

insert #temp
select a, b, c from table1, table2, table3 where ...

Nous avons eu la première course en temps utile, et ne pouvait pas faire pour rendre la bonne décision dans le 2ème cas, malgré a été considérablement remaniée. Nous avons même pris la requête en dehors des tables temporaires, mais quand même eu des résultats inhabituels.

A la fin nous avons eu recours à SET FORCEPLAN ON pour certaines requêtes - c'est au bout de 10 heures d'avoir nos CBM et Sybase sur la ligne. La solution est venue des développeurs d'applications aussi plutôt que des conseils des ingénieurs Sybase.

Donc, pour vous faire gagner du temps, prendre cette route est ma suggestion.

Autres conseils

Comme les autres, je commisération plutôt que d'une vraie réponse! Nous voyons un problème où le planificateur de requêtes ASE 15 sous-estime massivement le coût d'une analyse de table et surestime De même, le coût d'utilisation de l'index ordonné en clusters. Il en résulte une jointure par fusion étant le plan proposé. La désactivation des jointures par fusion ou le réglage de la allrows_oltp optgoal parfois résultats dans un meilleur plan de requête. Les coûts estimés sont encore loin, mais en prenant une option sur la table le planificateur de requêtes peut trouver une bonne solution -. Mais par l'analyse erronée

ASE 15 documents dire qu'il a un beaucoup plus propre ensemble d'algorithmes alors que le planificateur ASE 12 avait un tas de cas particuliers. Peut-être un cas particulier qui dit « si vous avez la colonne d'index cluster dans la jointure, il va être plus rapide qu'un balayage de table » ne serait pas une telle mauvaise idée ...: (

Sybase réécrit efficacement le moteur de recherche pour la version 15 ce qui signifie que les requêtes qui ont fonctionné super-rapide sur 12.x peut courir beaucoup plus lent sur la version plus récente, et vice versa. La seule façon de déboguer est de comparer le plan de requête 12.x au 15 plan de requête et de voir ce qui se fait différemment.

Toutes les personnes concernées par cette question devrait lire ce document:

http: // www. sybase.com/files/White_Papers/ASE15-Optimizer-Best-Practices-v1-051209-wp.pdf

Il a un avertissement franc sur la migration de Sybase Sybase 12 à 15.

Quoteth:

  

... ne pas traiter ASE 15 comme « juste   une autre version. » Autant que nous le ferions   vous dire que vous pouvez simplement   mise à niveau et pointer vos applications sur   les serveurs mis à niveau, la profondeur et   l'ampleur du changement dans l'un des plus   domaines fondamentaux d'une base de données, une requête   exécution, nécessite une approche plus ciblée   régime d'essai. Ce document est destiné   de vous fournir les faits clairs   et les meilleures pratiques pour réduire cette   effort autant que pratiquement   possible.

Il va à parler de la nouvelle ASE 15 Optimiseur de requête, les requêtes vis-à-vis des requêtes OLTP et DSS (décision système de soutien).

Cependant , il y a bonnes nouvelles : en Mars 2009, Sybase 15.0.3 introduit un mode de compatibilité. Voir la doc suivante:

http://www.sybase.com/detail?id=1063556

Avec ce mode, vous ne devez pas analyser les requêtes de décider si elles correspondent à des profils OLTP ou DSS.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top