Version imprimable
Régle numéro une : un consultant qui avance "sa vérité" sans l'illustrer par des events ou des waits ne passe pas le déjeuner... et souvent, un consultant qui donne un avis dans les deux heures qui suivent le début de sa prestation est un consultant qui n'a fait que changer l'entête et pied de page d'un document qu'il ressort à chaque occasion :mrgreen:Citation:
Envoyé par laurentschneider
oui, il faut tester et si ça marche tant mieux.
il faut aussi toujours prendre en compte la version. Ce qui était vrai en 8i (à propos de locally managed) ne l'est plus forcément en 10g.
Dans l'article cité, Oracle propose des chiffres très clair je ne suis pas du tout d'accord. Tu te réfères au document SAFE ?
How to Stop Defragmenting and Start Living: The Definitive Word on Fragmentation
Definitive a sans doute un autre sens en anglais :aie:
Le document, je cite et traduit, est basé sur Oracle 7.3 et contient les nouveautés 8.0 et les utilisateurs Oracle8i doivent ce référer à une version actualisée de SAFE (qui ne sera jamais publiée).
Ce fut un très bon document, un peu vieux ma foi
Merci de me dire si tu te réfères à autre chose
oui, mais bon, ce n'est pas forcément dû à Oracle.Citation:
Envoyé par orafrance
Une règle plus simple serait "Plus de disques utilisés, plus de bande passante I/O".
On peut bien sûr partitionner par ASM, avec plusieurs fichiers par tablespace, avec un Striping RAID, avec du partitioning, avec plusieurs tablespaces, avec des disques pour logwriters et des disques pour archiver. On peut aussi tout mettre sur les même disques et si tout les disques sont employés (statistiques des sysadmins), il est possible que la performance soit acceptable.
Ce sont des chiffres qui m'ont été communiqué par un gourou de chez Oracle mais le SAFE les confirment ;)Citation:
Envoyé par laurentschneider
En effet, le SAFE précise que pour éviter la fragmentation tu dois avec des extents uniforme (2.1.1) et la taille est confirmée par le point 2.1.3.... à ceci prêt que j'ai pas préciser dans le tuto que ces chiffres ne valent qu'à partir de la 8i :oops:
Bien sûr qu'Oracle n'y est pour rien ;) Je dis juste qu'Oracle tente de nous faciliter la tâche et que finalement ça fait oublier à pas mal de DBA que derrière un tablespace y'a des fichiers et donc un minimum de choses à vérifier.Citation:
Envoyé par laurentschneider
Et même si le data placement est lourd à maintenir, si tu arrives en limite de capacité de la baie c'est bien une chose à faire... comme la fragmentation des objets est lourde à corriger mais les réorgs sont aussi nécessaire parfois :? chacun sa croix :aie:
quant à la réflexion sur les extents, il n'y a pas pire qu'une immense table avec des immenses extent. J'avais un client, qui n'utilisais pas le partitioning, qui avait des tables de plusieurs centaines de giga et chaque extent faisait 2 giga. Ce qui veut dire que pour chaque extent créé, il fallait allouer 4 giga, ce qui bien sûr n'est pas très réjouissant pour le temps de réponse ...
Bon, je ne veux pas réinventer la roue, mais je pense que Oracle a largement simplifier tout en augmentant la performance dans plus de 80% des cas en introduisant les LMT et ASSM.
tu veux dire ne valent plus à partir de la 8i, non?Citation:
Envoyé par orafrance
si tu me trouves de tels chiffres pour LMT sur le site d'oracle.com, je serai bien surpris.
même en LMT le nombre d'extents pose problème c'est pourquoi je modère mes propos dans le point 4.1. En effet, le bitmap en entête de fichier n'est pas extensible à l'infini. La recommendation des 1024 extents par segment reste donc d'actualité même en LMT.
Je peux t'assurer que tu peux avoir des résultats intéressants contrairement à ce qu'affirme Tom Kyte qui m'a d'ailleurs motiver à écrire ce passage sur les mythes... que j'ai corrigé après avoir fait l'expérience de gros segments et donc vu de mes yeux que Tom n'avait pas vu si juste que ça :?
D'ailleurs, le LMT n'a jamais eu pour objet de supprimer la fragmentation mais de la réduire (ce qui n'est pas si mal :mrgreen:)
La note 105120.1 de Metalink fait la description suivante :
le principal intérêt c'est de ne plus se prendre la tête avec PCTFREE et PCTUSED, d'éviter les contentions lors des modifications des extents et de ne plus maintenir une FREELIST dans le catalogue de la base.Citation:
*****************************************************************************************
***ADVANTAGES IN USING LOCALLY MANAGED TABLESPACES OVER DICTIONARY MANAGED TABLESPACES***
*****************************************************************************************
- Because locally managed tablespaces do not record free space in data
dictionary, it reduces contention on these tables.
- Local management of extents automatically tracks adjacent free space,
eliminating the need to coalesce free extents.
- Avoids recursive space management operations, which can occur in
dictionary-managed tablespaces if consuming or releasing space in an
extent results in another operation that consumes or releases space in
a rollback segment or data dictionary table.
- Sizes of extents that are managed locally can be determined automatically
by the system. Alternatively, all extents can have the same size in a
locally managed tablespace.
- Changes to the extent bitmaps do not generate rollback information
because they do not update tables in the data dictionary (except for
special cases such as tablespace quota information).
- Reduced fragmentation
Enfin, tout ça pour dire, qu'il ne faut pas être parano de la fragmentation mais qu'il convient quand même de garder un minimum de régles en tête : 1024 extents/segment, uniform size, séparer les objets TRES gros, des objets moins gros et des petits objets, etc... le SAFE n'est pas complétement obsoléte ;)
Edit : j'oubliais, le LMT permet aussi un moindre coût en ressource lors de la mise à jour des extents ;)
Il est bon de se rappeler historiquement comment ça fonctionnait. CependantCitation:
Envoyé par orafrance
1024 extent / segment :
cela dépend de la taille du segment, cette limite n'a aucun sens si le segment fait plusieurs centaines de giga. Bon, il est vrai qu'avec le partitioning on évite d'avoir souvent des segments de 10 téra...
uniform size :
pourquoi? en assm les extents ont des tailles plus ou moins compatible, à savoir 64K, 1Mb, 8Mb et 64Mb. Les tailles n'ont pas été choisies au hasard
Il n'y a aucun extent de plus de 64Mb. J'ai posé personnellement la question des tables avec 10000 extents au responsable du développement Storage chez Oracle (USA) et pour lui des énormes tables avec des dizaines de milliers d'extent de 64Mb ne sont pas problèmatiques, en particulier lorsque l'on fait surtout des insert et que l'on n'accède que aux données récentes. Pour réduire le nombre d'extent, il faut alors diminuer la taille du segment, en le partitionant. De lire des extents de 2 gigas à cause de la règle des 1024, je doute franchement.
Quant à séparer les objets selon leur taille en utilisant Uniform, c'est techniquement intéressant, mais rarement implémenté. Il ne faut pas oublier qu'en dix ans (le document se base sur Oracle 7.3 qui a dix ans), le dba doit gérer beaucoup plus de données et beaucoup plus d'applications. Les bases de 10 gigas sont devenues de mini-bases. Avec un shared-pool de 128Mb, tu ne démarres même plus ton instance. Non, le travail du dba a changé, et je serais étonné d'entendre un dba dire que tous les objets de ses bases sont organisés par taille. Vraiment. Ou alors il est temps de penser à la retraite ;)
The top 10 signs your DBA might need to retire
Quant à ta remarque sur ton expérience avec les gros segments, je suis d'accord sur ce point, c'est l'expérience seule qui détermine la performance dans une situation donnée.
Citation:
Envoyé par tomkyte
Avec des extents de 160M ça te fait aller jusqu'à 160 Go quand même... spa si mal ;)Citation:
Envoyé par laurentschneider
En effet, le problème se pose quand tu fais un truncate et que tu repars avec une table vide et des extents de 64M ce qui n'est pas forcément jusdicieux. ;)Citation:
Envoyé par laurentschneider
Oui, c'est une évidence, en écriture ça n'a absolument aucune importance... mais en général, tu aimes bien lire ce qui est écrit ;) Trève de plaisanterie, j'ai bien précisé avoir vu des gains dans le cas très particulier et non recommandé par Oracle d'une instance mélangeant OLTP et Datawarehousing :?Citation:
Envoyé par laurentschneider
Quand à partitionner... très bien mais si on parle de partitionner pour réduire le nombre d'extents c'est bien que ce nombre a un impact sur les perfs. J'vois pas comment on peut dire : les nombres d'extents n'a aucune importance en même temps que : pour réduire les extents il faut partitionner :koi:
C'est évident, néanmoins je me suis vu être obligé de réorganiser ma base ainsi pour régler des problèmes de perfs. Je te parle là d'une base avec une SGA de plusieurs centaines de Go (oui oui, Go :?) avec des segments de très gros... et je peux t'assurer que les gains était bien là. Je n'aurais pas mis mon article à jour sans l'avoir constaté de mes propres yeux parce que comme toi, j'avais la certitude que c'était obsoléte comme manière de faire. Mais encore une fois, je répéte que c'est un cas exceptionnel et que très souvent le nombre d'extents n'a pas d'impact.Citation:
Envoyé par laurentschneider
Exactement, et je ne dis rien de plus que de ma propre expérience, j'ai bel et bien vu que le nombre d'extent à un impact... MAIS c'est le nombre d'extent dans le datafile qui compte, en effet, c'est la taille du bitmap en entête de fichier qui pose problème. Donc dire 1024 extents/segment c'est un peu abusif, il vaudrait mieux parler de nombre d'extents par entête de fichier ;)Citation:
Envoyé par laurentschneider
Tout ça pour dire, encore une fois, que ça importe peu mais que si on constate des problèmes d'I/O faut pas forcément se focaliser uniquement sur la baie de disque et nos amis sysop ;) d'où l'importance de baser ses régles de tuning sur les waits plutôt que sur des ratios... selon moi :)
PS : Tiens, je repense à un truc, l'insertion en mode DIRECT n'ajoute-t-il pas les données après la HWM ?
Oui, ça se tientCitation:
Envoyé par orafrance
:yaisse:Citation:
Envoyé par orafrance
Oui, bien.Citation:
Envoyé par orafrance
Ce que j'aime moins, c'est les dbas qui réorganisent systèmatiquement toutes les tables "par principe" même lorsque ça n'apporte pas d'amélioration de la performance. Si tu penses qu'une réorg va améliorer tes perfs, teste le sur une base de test, et si tu vois une sensible différence, alors c'est bon. Par contre avoir un "script" qui automatiquement réorganise les tables de plus de 1024 extents, pas question :cfou:
parfaitement d'accord, c'est bien pour ça que je dis qu'un tuning de base c'est pas simplement déclencher une action parce que tel ratio est mauvais ou que tel segment contient du chainage (ce qui est assez drôle d'ailleurs c'est de voir des DBA réorganiser des tables sans se poser de question sur PCTFREE et PCTUSED :mouarf:).
Seul les waits et les events font foi en matière de tuning... ce serait trop simple s'il suffisait de suivre bêtement des régles même si Oracle nous y encourage notamment avec les advisors de la 10g (le segment advisor est une bonne blague d'Oracle, je peux pas voir ça autrement :mrgreen:).
Finalement, je pense qu'on est d'accord :yaisse2:
Alors là, les amis d'Oracle, je suis comblé (et dire que c'est la première fois que je demande de l'aide !)
Vos échanges sont passionants !
Du coup j'ai enlevé le Résolu.
Merci encore à tous :king:
un peu hors-sujet, mais qui m'a bien fait rire, Connor McDonald a écrit une procédure satirique pour les dba qui veulent avoir TOUT VERT dans Quest Spotlight :
http://www.oracledba.co.uk/tips/choose.htm
excellent :king:
Bonjour,
Imaginons une table qui ferait dans les 70Go dans un unique TS geree en raw device et qui aurait initialement ete cree avec un initial de 128Kb et des next de 128Kb egalement ... Donc si vous comptez bien elle a dans les 500 000 extents. Initialement a cause de la regle recente qui dit qu'on se moque du nombre d'extents ...
Cette table est mise a jour quotidiennement avec des insert et quelques delete aussi mais globalement elle grossit de 1 voir 2% par semaine.
Bien sur ce sont toujours les donnees les plus recentes de cette table sont immediatement accedees en mode OLTP 24/24h a peu pres a 50 tps pas plus (enfin le we ca baisse un peu).
On ne veut plus la partitionner car on a deja montre que ca n'apportait rien mais on pourrait imaginer la reconstruire a un moment ou elle n'est pas mis ajour si un nombre d'extent reduit ameliorerait ses acces ...
La question est donc la suivante ... comment savoir si on aurait interet a la reconstruire. On sera en mesure de tester une autre reorg mais y a t il un petit select des familles sur les events ou ailleurs qui pourrait nous donner des arguments un peu costaud pour proposer de faire ce test ... (je veux dire autre que, et si on essayait pour voir ...)
Merci,
jrman
Si vous avez des problèmes de performances sur des requêtes qui accèdent à cette table , il faut les analyser de façon la plus précise possible. Cela peut donner des indications sur ce qui peut éventuellement être optimisé. Il faut aussi tenir compte de toutes les requêtes qui accèdent à la table pour éviter de déshabiller Pierre pour habiller Paul ...
et y'a pas moyen d'archiver les données ?
et un partitionnement par date n'y change rien ?Citation:
Envoyé par jrman
les indexes utillisés pour les tests étaient-ils partitionnés ? comment ?