[9i] Exchanging Partitions

Version imprimable

29/05/2006, 22h55
SamG

[9i] Exchanging Partitions

Bonjour,

J'ai lu pas mal de littératures sur le Web où l'on conseille de charger les données dans une table temporaire, et après de faire un "alter table ... exchange partition ..." pour migrer les données dans la table partitionnée de destination.

Devant construire une nouvelle version d'une application et de sa base en y incluant le partitionnement. Je voudrais connaître l'intérêt de charger des données dans une table en faisant après un échange, par rapport au simple fait de charger les données directement dans la partition.
A priori, je ne vois pas de gain de performance, ni même de facilité accrue...
Si quelqu'un pouvait éclairer ma lanterne.

Je précise que j'utilise Oracle 9.2.0.7 avec du SQL*Loader en mode direct.

Merci d'avance.

http://www.stanford.edu/dept/itss/do...i.htm#i1107555

Citation:

For example, in data warehousing environments exchanging partitions facilitates high-speed data loading of new, incremental data into an already existing partitioned table.

http://www.databasejournal.com/featu...le.php/3317621

Citation:

One of the most common ways of leveraging range partitioning techniques is to partition fact tables by date range, where each date range encompasses one load cycle for the table. The data is loaded into a separate table having exactly the same column definitions, constraints and indexes as the fact table. The constraints are enabled (sometimes), the indexes rebuilt (they will have been unusable for the load process to avoid overhead in maintaining and logging the indexes), and a "partition exchange" operation is executed to swap the data and index segments of the table with the data and index segments of a fact table partition. This DDL operation is extremely fast, and just as importantly, is as fast to reverse.
30/05/2006, 11h05
lalystar

Bonjour,

Si tu charges directement dans ta table finale à partir de SQL*Loader par exemple, je ne vois effectivement pas l'intérêt.

Là où c'est plus intéressant, c'est quand tu charges dans une table "temporaire", qu'ensuite tu fais de l'enrichissement de tes données, des contrôles d'intégrités, de la suppression de doublons... Une fois que tes données sont "cleans", tu peux les insérer dans ta table finale en une seule commande et les rendre disponibles à tes utilisateurs.
En général, dans un datawarehouse, on charge les données dans un schéma dédié avant de les insérer dans les tables finales (Cf. http://www.developpez.net/forums/sho...&highlight=ODS)

NB : à mon avis ca ne fonctionne que si tous tes indexes sur ta table partionnées sont locaux.

Laly.
30/05/2006, 13h13
SamG

J'ai enfin une réponse à cette question qui me taraudait l'esprit depuis plusieurs jours.

Merci beaucoup pour ces informations.
30/05/2006, 13h34
Jaouad

Citation:

Envoyé par lalystar

NB : à mon avis ca ne fonctionne que si tous tes indexes sur ta table partionnées sont locaux.

A mon avis il est quand même déconseillé d'avoir un index local sur une table partitionné.
Cela me rappelle l'histoire d'un DBA qui a crée un index global sur une table partitionnée,il supprime une partition et tout d'un coup ne comprends pas les perfs dsastreuses :mouarf: . ( En supprimant la partition l'index devient unusuable )
30/05/2006, 16h41
Nick_Holmes

Pourrait-tu développer ton propos STP ?
Je ne comprend pas l'intérêt de l'index global dans le cas d'une table partitionnée (surtout que tu donnes l'inconvéniant principal d'un tel index juste après). J'utilise tjs un index local dans ce cas sans me poser la question. :P

@+,
NicK.
30/05/2006, 16h51
Jaouad

:aie: ha trompé ayé corigé
31/05/2006, 09h26
Wurlitzer

Il me semble que dans certain cas il est interessant d'avoir un index global malgré les defauts qu'ils ont et que vous venez de mettre en évidence.

Pour une table avec N partitions et un index local sur un champ qui n'est pas la clé de partitionnement, Oracle doit lire les N indexes locaux pour verifier dans chacune des partitions si tu as la valeur recherchée. Tu fais donc N lectures au lieu d'une seule avec un indexe global.
31/05/2006, 11h09
lalystar

Le seul cas je pense, où il doit y avoir un index global est dans le cas d'une contrainte d'unicité qui ne contient pas la clé de partition.

Sinon c'est que la clé de partionnement est peut être mal choisie si bcp de requête ne l'utilise pas et qu'il faut alors créer un index global.

Laly.
31/05/2006, 13h30
Nick_Holmes

+1 avec Lalystar & Wurlitzer.
J'ai peut qu'il faille trancher au cas par cas selon l'utilisation faite de la table partitionnée.

@+,
NicK.