Faites-vous confiance à DB_CACHE_ADVICE ?

Bonjour

En plein travail d'optimisation d'une base 10gR2 sous Linux, je viens de jeter un coup d'oeil aux recommandations d'Oracle via V$DB_CACHE_ADVICE, et les résultats me laissent perplexe.
En effet, alors que les valeurs paraissent à peu près cohérentes pour une taille de bloc de 8 ou 16K, les valeurs des colonnes ESTD_PHYSICAL_READS et ESTD_PCT_OF_DB_TIME_FOR_READS n'ont plus rien à voir dès qu'on passe à 32K.
Faut-il conclure d'une lecture brute de ces chiffres qu'on passe en gros 8 fois plus de temps en lecture avec des blocs de 32K qu'avec des blocs de 8 ou 16K, selon la colonne ESTD_PCT_OF_DB_TIME_FOR_READS (la dernière à droite) et que c'est la taille de bloc de 16K qui est la plus efficace ?

Ou bien, si on regarde plutôt la colonne EST_PHY_READ_FACTOR, que la taille des caches ou des blocs est en gros sans effet, puisque dans tous les cas, on est aux alentours de 1 ?

Effet boeuf ou effet nul, je ne sais à quelle colonne me vouer...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

Block Size Size Factor Est Size Est Phy Reads Est Phy Read Fact ESTD_PCT_OF_DB_TIME_FOR_READS ---------- ----------- ------------ ------------- ----------------- ----------------------------- 8192 ,0714 16 849 094 1,0883 1,3 8192 ,1429 32 819 222 1,05 1,2 8192 ,2143 48 810 368 1,0386 1,2 8192 ,2857 64 805 860 1,0329 1,2 8192 ,3571 80 802 745 1,0289 1,1 8192 ,4286 96 801 364 1,0271 1,1 8192 ,5 112 799 375 1,0246 1,1 8192 ,5714 128 798 112 1,0229 1,1 8192 ,6429 144 793 996 1,0177 1,1 8192 ,7143 160 784 076 1,0049 1,1 8192 ,7857 176 783 003 1,0036 1,1 8192 ,8571 192 782 093 1,0024 1,1 8192 ,9286 208 781 111 1,0011 1,1 8192 1 224 780 215 1 1 8192 1,0714 240 778 769 ,9981 1 8192 1,1429 256 777 480 ,9965 1 8192 1,2143 272 776 060 ,9947 1 8192 1,2857 288 774 895 ,9932 1 8192 1,3571 304 773 946 ,992 1 8192 1,4286 320 771 983 ,9894 1 16384 ,0769 16 417 373 1,005 ,6 16384 ,1538 32 417 373 1,005 ,6 16384 ,2308 48 415 364 1,0002 ,6 16384 ,3077 64 415 318 1,0001 ,6 16384 ,3846 80 415 318 1,0001 ,6 16384 ,4615 96 415 302 1 ,6 16384 ,5385 112 415 302 1 ,6 16384 ,6154 128 415 302 1 ,6 16384 ,6923 144 415 302 1 ,6 16384 ,7692 160 415 302 1 ,6 16384 ,8462 176 415 302 1 ,6 16384 ,9231 192 415 302 1 ,6 16384 1 208 415 287 1 ,6 16384 1,0769 224 415 272 1 ,6 16384 1,1538 240 415 272 1 ,6 16384 1,2308 256 415 272 1 ,6 16384 1,3077 272 415 272 1 ,6 16384 1,3846 288 415 272 1 ,6 16384 1,4615 304 415 272 1 ,6 16384 1,5385 320 415 179 ,9997 ,6 32768 ,08 32 2 320 731 1,0096 7,9 32768 ,16 64 2 319 384 1,0091 7,9 32768 ,24 96 2 305 790 1,0032 7,8 32768 ,32 128 2 303 160 1,002 7,7 32768 ,4 160 2 302 780 1,0018 7,7 32768 ,48 192 2 302 685 1,0018 7,7 32768 ,56 224 2 302 590 1,0018 7,7 32768 ,64 256 2 302 289 1,0016 7,7 32768 ,72 288 2 301 766 1,0014 7,7 32768 ,8 320 2 301 006 1,0011 7,7 32768 ,88 352 2 300 023 1,0006 7,7 32768 ,96 384 2 299 041 1,0002 7,7 32768 1 400 2 298 550 1 7,7 32768 1,04 416 2 298 154 ,9998 7,7 32768 1,12 448 2 296 871 ,9993 7,7 32768 1,2 480 2 295 571 ,9987 7,7 32768 1,28 512 2 294 510 ,9982 7,7 32768 1,36 544 2 293 401 ,9978 7,6 32768 1,44 576 2 292 656 ,9974 7,6 32768 1,52 608 2 292 133 ,9972 7,6 32768 1,6 640 2 291 579 ,997 7,6

---

ça fait longtemps qu'elle est démarrée la base ? la taille de bloc des tablespaces est de combien ? Sinon, apparemment 16k c'est le top mais c'est en effet curieux de voir que dans ce cas la taille du cache ne change rien... y'a peut-être un souci avec les stats systémes :koi:

Citation:

---

Envoyé par orafrance

ça fait longtemps qu'elle est démarrée la base ? la taille de bloc des tablespaces est de combien ? Sinon, apparemment 16k c'est le top mais c'est en effet curieux de voir que dans ce cas la taille du cache ne change rien... y'a peut-être un souci avec les stats systémes :koi:

---

Salut camarade !

Cette base est démarrée depuis environ une semaine.
La taille de bloc système est de 8K, et nous avons par ailleurs des tablespaces avec un bloc de 16K ou de 32K, avec des caches respectifs de 224 et 400 M.
(on retrouve cette dernière info dans la colonne SIZE_FACTOR, lorsque celle ci vaut 1 et correspond donc à la valeur courante).

Pom'

la nuit portant conseil, je remarque que tu as apparemment bcp plus d'accés sur le 32k que sur le 16k... alors je vois 2 possibilités :
1°) tu accédes beaucoup moins aux data 16k
2°) tu accédes qu'en FTS et dans ce cas le segment ne monte pas en cache

et une 3° me vient : les objets du tablespace sont soit tous en KEEP et occupent moins de 16M soit tous en RECYCLE (pense à vérifier la taille du RECYCLE POOL) auquel cas le cache ne sert pas à grand chose puisque le segment en sortira très vite.

Ou enfin, l'ADVISOR délire à plein tube :aie:

Voila qui permet de voir ce qui est dans le POOL :

Code:

---

1 2 3 4 5 6 7 8 9

COLUMN OBJECT_NAME FORMAT A40 COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999   SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS FROM DBA_OBJECTS o, V$BH bh WHERE o.DATA_OBJECT_ID = bh.OBJD AND o.OWNER != 'SYS' GROUP BY o.OBJECT_NAME ORDER BY COUNT(*);

---

Pour info : http://download-uk.oracle.com/docs/c...ory.htm#i21817

Citation:

---

Envoyé par orafrance

Ou enfin, l'ADVISOR délire à plein tube

---

C'est ce que je me demande... Soit je fais une erreur d'interprétation des chiffres, soit il débloque complètement.

oui enfin j'ai donné d'autres hypothéses :aie:

Citation:

---

Envoyé par orafrance

oui enfin j'ai donné d'autres hypothéses :aie:

---

Voui, mais quand on a éliminé les 3 premières, ben il ne reste que la dernière !

en effet :aie: