[ASE 15.0.2] PRIMARY KEY CLUSTERED et performance

Bonjour
Je constate un écart important de temps d'exécution d'une même requête entre 2 bases :
- 80s sur BDNC (base ayant les index PK non clusterisés)
- 45Os sur BDC (base ayant les index PK clusterisés)

Le 2 bases ont un contenu et volumétrie semblables.
La seule différence serait la présence d'indexes PK clusterisés sur "BDC" alors qu'ils sont non-clustérisés sur "BDNC".

Les plans d'exécution sont identiques (seuls le noms d'indexes changent parfois car génération à partir d'un script du PowerAMC, les colonnes indexées sont identiques).

Avez-vous un retour d'expérience "du terrain" d'utilisation d'index clusterisés ?
Avez-vous constaté un changement de performances avec ce type d'indexes ?

Merci
msomso

Bonjour

juste pour info supplémentaire : est-ce que les 2 bases sont sur la même instance ?

merci

Elles sont sur le même serveur, mais ce sont 2 bases indépendant (crée chacune par "create database ...").
Il ne s'agit pas de bases clusterisées/répliquées.

Est-ce que les plans d'exécutions sont les mêmes?
Est-ce que les tables sont en DOL ou en APL?
Est-ce que les caches/pool sont les mêmes?
Est-ce que les IOs physiques sont similaires?

Michael

Bonjour Michael

Citation:

---

Est-ce que les plans d'exécutions sont les mêmes?

---

Oui, cf fichiers joints.

Citation:

---

Est-ce que les tables sont en DOL ou en APL?

---

Nos tables sont en "lock datarows"

Citation:

---

Est-ce que les caches/pool sont les mêmes?

---

Oui, les caches et pool sont définis au niveau serveur.

Citation:

---

Est-ce que les IOs physiques sont similaires?

---

Le résultat retourné est pratiquement identique : 11272 rows sur DBNC et 11180 rows sur DBC.
On voit dans les plans d'exécution que les pool utilisés pour la lecture d'index ne sont pas les mêmes entre les 2 bases.
Ceci sans règle apparente:
- un index est lu avec 2Ko sur BDC et 16Ko sur BDNC
- un autre est lu avec 16Ko sur BDC et 2Ko sur BDNC.

Quel autre info attends-tu précisément ?

Merci
msomso

Les clustered index sur des tables DOL ont une utilité différente comparé aux tables APL. Sur une table APL le clustered index correspond à la table elle-même, et donc un "range" scan dans l'ordre de l'index peuvent aller plus vite (moins d'IO).

Pour les table DOL l'index clustered est un index de placement, cad qu'ASE va placer les nouvelles lignes aussi près que possible des lignes existentes ayant des clés contigues, mais l'index est disjoint de la table.

Dans le cas présent il ne semble pas que les indexes clustered apportent un avantage, mais ils ne devraient pas non plus vraiment ralentir la chose. Je suspecte autre chose, par example le temp d'optimization, le nombre d'IO physiques.
De plus, les IOs 16k ou 2k dependent de ce qui est déjà en cache - si une page qui fait partie des pages qui doivent être lues existe dans le pool 2k alors le pool 16k ne peux pas être utilisé, ce qui peut expliquer pourquoi l'utilisation du 16k ou 2k est un peu aléatoir...

Michael

Je vais refaire un test demain après avoir redemarré le serveur pour avoir au moins la situation claire au niveau des caches.

Qu'en pensez-vous ?
msomso

Bonjour
Serveur redémarré et génération de nouveau plans d'exécutions.

Résultat: toujours grand écart de temps d'exécution de ma requête qui prend 80s sur "BDNC" et 320s sur "BDC".
Contrairement à hier, les plans générés sont différents.
Pour la table DM_INST l'optimiseur privilégie le ¨PK_DM_INST (index PK clusterisé) au foreign key INS_ASS150_ETA_FK.
La suite du plan se trouve modifiée.
Je joins les plans d'aujourd'hui si quelqu'un pouvait regarder ...

Merci
msomso
P.S.
Y aurait-t-il un moyen d'augmenter mon espace pièces jointes ?

Le problème est évidemment de trouver pourquoi ASE choisi le "mauvais" plan.

Pour cela il peut être intéressant d'excuter les deux query avec

Code:

---

1 2 3

set statistics io on set statistics plancost on

---

Le plancost en particulier donne les IOs estimés et effectifs pour chaque étape, ce qui peut donner des informations plus détaillées.

Michael

Après avoir mis à jour les statistiques sur la base plus rapide (BDNC), les 2 plans deviennent identiques (= exécution plus longue).
Je mesure 200s sur BDNC et 320s sur BDC.

Je ne crois pas pouvoir comprendre d'avantage ...

Merci en tout cas
msomso