Discussion :

[ldiaz]

Bonjour a tous,

la questio est de savoir si pour certaines requetes passer a un block size de 16k est plus interessant que le par default 8k. (ORACLE 9i - HP UX)

Pour demarrer j'ai fait ceci:

1 alouer espace: db_16k_cache_size big integer 25165824
2 creer un tbs test_16k_ts de 50M avec blocksize TEST_16K_TS 16384
3 creer un user test avec default tbs le nouveau...
4 creation des memes tables meme structure, meme données meme index etc sur le nouveua schema.
5 EXEC DBMS_STATS.gather_schema_stats('test');
6 Executer la meme query sur les 2 environnements:

Environement a 16k

Code :

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

------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost | ------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 562 | 27538 | 80 | | 1 | SORT ORDER BY | | 562 | 27538 | 80 | |* 2 | FILTER | | | | | |* 3 | HASH JOIN | | 562 | 27538 | 73 | |* 4 | TABLE ACCESS FULL| RHUPTSOLICITUD | 562 | 10116 | 37 | | 5 | TABLE ACCESS FULL| RHUDIRECCION | 47883 | 1449K| 33 | ------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 -

J'ai activé l'event 10046 pour tracer la session, voici les données:

Code :

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

1
2
3
filter(TO_DATE('03/03/2009')<=TO_DATE('04/03/2009')) 3 - access("A"."IDP"="B"."IDP") 4 - filter("A"."FCHUPDATE">='03/03/2009' AND "A"."FCHUPDATE"<='04/ 03/2009')
 
Note: cpu costing is off END OF STMT PARSE #1:c=0,e=1499,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=18446744071645767046 EXEC #1:c=0,e=104,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=18446744071645986652 WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1111838976 p2=1 p3=0 WAIT #1: nam='db file sequential read' ela= 250 p1=11 p2=5 p3=1 WAIT #1: nam='db file scattered read' ela= 495 p1=11 p2=6 p3=3 WAIT #1: nam='db file scattered read' ela= 575 p1=11 p2=9 p3=4 WAIT #1: nam='db file scattered read' ela= 1764 p1=11 p2=13 p3=4 WAIT #1: nam='db file scattered read' ela= 523 p1=11 p2=17 p3=4 WAIT #1: nam='db file scattered read' ela= 891 p1=11 p2=21 p3=4 WAIT #1: nam='db file scattered read' ela= 484 p1=11 p2=25 p3=4 WAIT #1: nam='db file scattered read' ela= 529 p1=11 p2=29 p3=4 WAIT #1: nam='db file scattered read' ela= 10721 p1=11 p2=33 p3=4 WAIT #1: nam='db file scattered read' ela= 498 p1=11 p2=37 p3=4 WAIT #1: nam='db file scattered read' ela= 486 p1=11 p2=41 p3=4 WAIT #1: nam='db file scattered read' ela= 567 p1=11 p2=45 p3=4 WAIT #1: nam='db file scattered read' ela= 9532 p1=11 p2=49 p3=4 WAIT #1: nam='db file scattered read' ela= 538 p1=11 p2=53 p3=4 WAIT #1: nam='db file scattered read' ela= 501 p1=11 p2=57 p3=4 WAIT #1: nam='db file scattered read' ela= 629 p1=11 p2=61 p3=4

environement a 8k

Code :

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

------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost | ------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 562 | 27538 | 102 | | 1 | SORT ORDER BY | | 562 | 27538 | 102 | |* 2 | FILTER | | | | | |* 3 | HASH JOIN | | 562 | 27538 | 95 | |* 4 | TABLE ACCESS FULL| RHUPTSOLICITUD | 562 | 10116 | 49 | | 5 | TABLE ACCESS FULL| RHUDIRECCION | 47883 | 1449K| 43 | ------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 -

filter(TO_DATE('03/03/2009')<=TO_DATE('04/03/2009')) 3 -

Code :

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

1
2
access("A"."IDP"="B"."IDP") 4 - filter("A"."FCHUPDATE">='03/03/2009' AND "A"."FCHUPDATE"<='04/ 03/2009')
Note: cpu costing is off END OF STMT PARSE #1:c=0,e=1433,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=18446744072667060037 EXEC #1:c=0,e=82,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=18446744072667246339 WAIT #1: nam='SQL*Net message to client' ela= 4 p1=1111838976 p2=1 p3=0 WAIT #1: nam='db file sequential read' ela= 3536 p1=9 p2=11755 p3=1 WAIT #1: nam='db file scattered read' ela= 418 p1=9 p2=11756 p3=5 WAIT #1: nam='db file scattered read' ela= 566 p1=9 p2=11761 p3=8 WAIT #1: nam='db file scattered read' ela= 20332 p1=9 p2=11770 p3=7 WAIT #1: nam='db file scattered read' ela= 523 p1=9 p2=11777 p3=8 WAIT #1: nam='db file scattered read' ela= 14027 p1=9 p2=11786 p3=7 WAIT #1: nam='db file scattered read' ela= 523 p1=9 p2=11793 p3=8 WAIT #1: nam='db file scattered read' ela= 472 p1=9 p2=11802 p3=7 WAIT #1: nam='db file scattered read' ela= 494 p1=9 p2=11809 p3=8 WAIT #1: nam='db file scattered read' ela= 12242 p1=9 p2=11818 p3=7 WAIT #1: nam='db file scattered read' ela= 553 p1=9 p2=11825 p3=8 WAIT #1: nam='db file scattered read' ela= 18561 p1=9 p2=11834 p3=7 WAIT #1: nam='db file scattered read' ela= 16248 p1=9 p2=11841 p3=8 WAIT #1: nam='db file scattered read' ela= 440 p1=9 p2=11850 p3=7 WAIT #1: nam='db file scattered read' ela= 504 p1=9 p2=11857 p3=8 WAIT #1: nam='db file scattered read' ela= 491 p1=9 p2=11866 p3=7

ca a l'air d'etre mieux quand meme non?

Sur un autre forim, on a parlé de la contiguité des clefs...j'ai pas tres bien compris ce concept...Ici quel est le numero qui nous dit ca? c'est p2?
D'avance merci

[pifor]

Si vous voulez parler du clustering factor, voir le chapitre suivant du livre de J. Lewis: http://www.apress.com/book/downloadfile/2410

[ldiaz]

Salut

merci de ton link, je vais le lire cette apreme.
Le clustering factor ca a a voir avec la contiguité des clefs?
surement...
Merci encore

[pachot]

Bonjour,

La grosse différence que tu as ici, sur un full scan, c'est que ton primier test ('16k') fait des i/o de 64k alors que ton 2ème test ('8k') fait des i/o de 32k. [erreur voir plus bas]
Ceci est lié au fait que la taille d'i/o est paramétrée n'est pas paramétrée en Ko mais en nombre de blocs oracle. Je suppose que tu as: db_file_multiblock_read_count=4

Ce qui veut dire que tu aurais probablement le même gain de performance en gardant des blocs de 8k mais en mettant db_file_multiblock_read_count=8

Mais ce que tu as posté ne permet pas vraiement de conclure sur une différence de perf. Les temps d'i/o sont très disparates (de 0.25 à 10 millisecondes pour chaque i/o)

En général, un block size de 8k est adapté à la plupart de bases. Et il y a tellement de choses qui dépendent de la taille de bloc, que faire une vraie comparaison serait très complexe. Il faudrait bencher toute l'appli, pas seulement une requête.

Cordialement,
Franck.

[ldiaz]

Salut
merci pour tes precieux commentaires...Je suis d'accord d'ailleurs...Il existe sur le web autant de personne qui sont pour que ceux qui sont contre...ou simplement qui pensent que ca ne change pas grand chose et que ca ajoute de la maintenance.

Pour info le parametre que tu disais...:
SQL> show parameter db_file_multiblock_read_count;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_multiblock_read_count integer 16
SQL>

Tu vois il est a 16...ca veut dire quoi? qu'il ramene 16 block a la fois?

Sinon lorsque tu dis, "bencher l'appli" ca veut dire utiliser un benchmark c'est ca? T'en connais un en particulier qui serait adapté?? et si oui y a t'il la doc avec, avec un genre de step by step...
D'avance merci

[pachot]

Bonjour,

Je réalise que mon commentaire à propos de db_file_multiblock_read_count n'est pas juste car ton test se fait sur la même base, avec une tablespace qui a une taille de bloc différent et dans ce cas la taille d'i/o est adaptée -> donc la même.

db_file_multiblock_read_count integer 16
Tu vois il est a 16...ca veut dire quoi? qu'il ramene 16 block a la fois?

Oui, qu'il peut ramener jusqu'à 16 blocs à la fois, donc 16*8k=128k
Par contre, les traces que tu a posté ne montrent que des i/o de 54k, c'est peut être la taille des extents de ta table.

Par 'bencher l'appli' je veut dire comparer l'application complète (les batch, l'activité transactionnelle) et pas seulement quelques requêtes.

Cordialement,
Franck

[ldiaz]

Salut
ok alors avec le parametre a 16 (et oui j'ai fait le test sur la meme base), le test est valide? a part qu'il faut l'etendre a toute l'application.
Si je comprend bien, ce n'est pas une regle applicable a tout les envoronnements, mais a adapter a son appli...Ca complique a mort le boulot ca.

Tu conseils un bon livre pour le tunning oracle?

D'avance merci

[fatsora]

Bonjour,


La seule reponse est teste,teste,teste !!!! et ca dépend , il n'y a pas une seule reponse biblique a tous le problemes !

Les exemples que tu citent sont basées sur le site de BURLESON , sujet a caution !!

Voici un contre exemple de chez RICHARD FOOTE


http://richardfoote.files.wordpress....tablespace.pdf

Sinon les livres :

deja la doc officielle :
Performance Tuning Guide

et les livres.... dependent aussi de ta version Oracle

Liste non exhaustive :

Jusquà 11G : Troubleshooting Oracle Performance by Christian Antognini (Paperback - Jun 23, 2008) EDITEUR APRESS

9I :Optimizing Oracle Performance by Cary Millsap and Jeffrey Holt (Paperback - Sep 16, 2003)


10G :Oracle Wait Interface: A Practical Guide to Performance Diagnostics & Tuning (Osborne ORACLE Press Series) by Richmond Shee, Kirtikumar Deshpande, and K. Gopalakrishnan (Paperback - Jun 9, 2004)