Gestion de l'espace dans les tablespaces (tables partitionnées)

Bonjour

Actuellement en 10g, nous avons élaboré pour notre datawarehouse un système ou les tables partitionnées sont
stockees dans des tablespaces dédiés a une unité de temps
ex: 7 partitions-jours = 1 tablespace = 1 datafile
1 partition-mois = 1 tablespace = 1 datafile

(ex : P201201 est dans le TS XXX201201 defini sur un datafile nomme 201201 )

En effet au tout debut de l'implementation, toutes les partitions de toutes les tables étaient dans un meme TS
et nous avions des problemes de gestion d'espace
(TS qui grossissaient énormement mais pleins de "trous" car lors des inserts, les blocs en-dessous du HWM n'etaient pas re-utilises)

Nous avons mis en place un process d'archivage des partitions : drop partition puis drop du TS et création d'un nouveau TS un autre avec lequel on n'a pas de souci
puisqu'il va etre entièrement rempli avec la nouvelle partition (ou les 7 partitions de la semaine)

Un autre avantage c'est d'avoir tous les blocs d'une partition dans le meme fichier, donc meilleure performance (lors du partition pruning)

Mais, cela génere une énorme quantité de fichiers....

Nous allons migrer en 11g et je voudrais revenir a une organisation avec moins de fichiers, mais sans etre confrontée a nouveau a des pbs d'espace


Je pense que le process simple "drop partition- create partition - remplir cette partition" sera OK,
mais il y a des cas + complexes qui necessitent de faire un truncate puis load
(reprocess de partitions dans le passé ou load jour apres jour de la meme partition )

Si on fait un truncate partition reuse storage, au reload la partition ne risque -t-elle pas d'etre fragmentée dans le TS ,
avec donc une perte de performance fors de la lecture ?

Nous utilisons Datastage - la version précédente utilisait SQL*Loader, la nouvelle fait des bulk inserts.
Datastage parallelise ses inserts : pour le meme job; n process insèrent en parallele, ce qui crée plusieurs paquets de blocs dans la partition
c'est pourquoi je m'inquiete de cette fragmentation

Si on fait un truncate partition drop storage, ou seront localisées les donnees lors du load? Apres le HWM si on a + de données qu'avant ? donc des trous ?
Ou bien l'espace libere est-il proprement reattribué et réutilisé pour le nouveau load ?

Merci d'avance à ceux qui ont quelques idées sur ce sujet

Isa

Bonjour,

Citation:

---

Un autre avantage c'est d'avoir tous les blocs d'une partition dans le meme fichier, donc meilleure performance (lors du partition pruning)

---

Non, le nombre de fichier n'a aucun impact sur la performance.
C'est plutôt le contraire: plus vous en avez plus le checkpoint sera long.

Citation:

---

Si on fait un truncate partition reuse storage, au reload la partition ne risque -t-elle pas d'etre fragmentée dans le TS ,
avec donc une perte de performance fors de la lecture ?

---

Plusieurs choses.
Premièrement, cette fragmentation n'a aucun impact sur la performance.

Et il n'y a pas de la place perdue truncate partition reuse storage vu que vous rechargez le même volume de données

Citation:

---

Si on fait un truncate partition drop storage, ou seront localisées les donnees lors du load? Apres le HWM si on a + de données qu'avant ? donc des trous ?Ou bien l'espace libere est-il proprement reattribué et réutilisé pour le nouveau load ?

---

Il ne faut pas confondre l'espace alloué dans le tablespace (et là ce qui est libéré peut être utilisé par n'importe quelle table du même tablespace - donc probablement pas de soucis) avec l'espace alloué à la table (dans lequel il y a un high water mark).

Je ne vois pas quelle fragmentation vous pouvez avoir du moment que vous faites un truncate.
Votre problème de fragmentation vient probablement d'un temps où vous faisiez des delete avant de charger en direct-path.

C'est au contraire en multipliant les tablespaces que vous perdez de la place un peu partout.

Donc en bref, pour les perfs et pour l'espace disque, il vaut mieux tout regrouper. Pour d'autres raisons, vous pouvez quand même être amenés a avoir plusieurs tablespaces, si vous voulez mettre les vieilles partitions sur des disques plus lents par exemple, ou mettre ces anciennes partitions en read-only, ne pas les backuper de la même manière,...

Cordialement,
Franck.

Merci pour votre réponse.

c'est vrai qu'au debut on avait pas mal de delete qui ont depuis été remplacés au maximum par des truncate.

En ce qui concerne la fragmentation, comme nous sommes dans un datawarehouse, avec des lectures de gros volumes, il vaut mieux que les blocks ne soient pas trop dispersés.
Mais effectivement,ils ne seront pas + dispersés dans un fichier que dans plusieurs ;)

Comme nous avons une seule table par tablespace, je craignais que l'espace libéré lors du truncate ou drop ne soit justement pas réutilisé s'il est en dessous du HWM.
D'après vos explications ce n'est pas le cas:
Donc, si on considère une table avec des partitions de taille homogène, une fois qu'un TS a atteint sa taille maximale (= nombre max de partitions de la table selon la durée de rétention des infos, puisque nos partitions sont time-based),
les opérations suivantes ne devraient ni augmenter sa taille, ni augmenter sa fragmentation
--> drop partition "passée" + create "nouvelle" partition + load
--> truncate partition + load de cette partition (cas de reprocess)

Correct ?

Correct.
Pourquoi une seule table par tablespace ?

Pas mal de raisons...
- Pour repondre au probleme initial des TS qui stockaient beaucoup de tables et devenaient énormes,
- pour améliorer les perfs (on pensait améliorer les lectures en ne mettant pas "tous les oeufs dans le meme panier")
- pour faciliter l'archivage table par table , partition par partition,
- pour pouvoir transporter nos tablespaces d'une instance a l'autre si besoin (ciblage de partitions)
- pour pouvoir donner des parametres de taille de TS different par table (si grosse ou petite)

Tout cela est géré par des packages Oracle qui créent/ droppent les partitions et les TS automatiquement -donc pas de souci d'administration

La question n'est pas de savoir si c'etait une bonne ou une mauvaise solution, à l'epoque elle semblait OK, maintenant elle est à revoir en raison du trop grand nombre de fichiers , j'essaie de rassembler les éléments nécessaires pour améliorer sans créer de nouveaux problèmes :D