Bonjour,
Reellement il n'y a pas qu'une seule table, mais un ensemble de table qui ont des cardinalites plus ou moins importantes entre elles.
Elles sont accedees uniquement sur la PK, ces PK sont gerees dans des TS separes en raw device.
Un historique oui mais de plusieurs annee qui doit etre accessible en transaction. Pas de partition par date possible mais partitino possible.
Une solution a base d'archivage mensuelle a ete etudie.
Le changement physique doit etre transparent pour les applications transactionnelles de lecture.
Pour les mises a jour on a un peu de marge.
Soit une table nomme TABLE1 a decouper.
L'application de lecture utilise un synonyme. Avant le synonyme pointe directement sur la table. Apres le synonyme pointe sur une vue.
La vue est cree de la maniere suivante:
select * from TABLE1_ACTIVE union select * from TABLE1_1 union select * from TABLE_2 ... jusqu'a _24
Je vais pas trop donne plus de detail, mais en gros il faut des processes mensuelle qui deplacent les donnees de la table active vers les _1, _2 etc ...
On pouvait le faire car dans nos applis toutes donnees inserees n'est jamais mis a jour et purgees apres quelque annees par d'autres processes de purge.
L'avantage etant de travaille sur une heap table beaucoup plus petite et d'avoir les _1 / _2 crees en IOT uniquement accedees en select et purgees apres un certain temps ...
Ca on n'a pas pu le faire, car juge trop lourd implementer.
Ensuite ce qu'on a simplement essaye de faire a ete de transformer ces "heap table" en IOT, non partitionnees et partitionnees et aussi avec l'option "buffer overflow". On a teste, mais en gros en heap table ca marche mieux pour nous ... En IOT on gagnait en place mais en fait la place n'est pas critique.
Dans notre cas IOT partitionnee ou pas n'est pas meilleur, mais attention c'est dans notre cas uniquement et du aux particularites de notre modele. En regle general les IOT sont plus rapides en select que les heap tables.
En fait on n'a pas de probleme de perf en particulier mais si je lis qu'en changeant uniquement la taille de nos l'initial et nos extent, on va gagner en perf, ca m'interresse.
On ne peut pas mettre ces tables en cache et a peu pres 95% du temps passe dans le serveur est lie au temps passe a faire des acces disques.
Donc avec les extent l'idee serait d'ameliorer le traitement de ces acces disques. On peut changer de technique de stockage (j'ai lu des trucs sur les solid disk ...), mais les admin se mefie de cette technique.
Sinon peut etre qu'on peut pas aller plus vite tout simplement. Encore une fois y'a pas de criticite, les temps de reponse sont stables depuis plusieurs mois.
Donc changer les tailles d'extent oui mais pourquoi? base sur quelle observation? que mesurer?
Merci,
jrman
Partager