• Object_Name => le nom de l'objet dans la corbeille, commencant toujours par BIN$ suivant d'un identifiant unique de 26 caractère + un numéro de version dans le cas ou on s'amuserait à créer et a supprimer plusieurs fois la même table.
• Original_Name => Vous aurez deviné qu'il s'agit du nom d'origine de l'objet (dans mon cas ex1)
• Type => Correspond au type d'objet supprimé (Table, Index)
• CreateTime => Date de création de l'objet.
• DropTime => Date de suppression de l'objet.
• DropScn => numero de scn, utile si on veut restaurer une version particulière de la table.
• Space => Nombre de blocks utilisé par l'objet en question. (vous allez peut être découvrir quelques GO de libre...)

• C'est se priver d'une possibilité rapide et simple de faire face à une erreur humaine.
• Un utilisateur lambda peut même réparer son erreur sans l'intervention du DBA.
• Etant donné que l'on peut modifier le comportement au niveau session, si vraiment dans le cas d'un traitement particulier (table temporaire), on ne veut pas garder de trace il suffit de faire un ALTER SESSIONDROP TABLE ma_table PURGE; Dans ce cas la table va directement dans la néant sans passer par la case corbeille. ou utiliser la commande
• Ca peut même devenir un outil puissant. Exemple : Une application crée par traitement de nuit un pseudo datawarehouse en plusieurs heures en prenant soin de supprimer les tables existantes avant de commencer. Pour une raison inconnu, le traitement se plante. Et bien les utilisateurs finaux n'ont pas accès à leur datawarehoure préféré. En admettant que la hotline soit dans un pays lointain,cela peut prendre plusieurs jours. Grace à une restauration des tables via la corbeille on peut revenir à l'état J-1 très rapidement. (Remarque : Toute information ressemblant à des faits issues du vrai monde, ne serait que pure coincidence !)
• Il convient néanmoins au DBA de surveiller à ce que cette corbeille ne devienne pas trop encombrante et éventuellement de programmer un traitement périodique pour effectuer une purge des objets les plus anciens ou inutiles.

Bonjour,

Vous n'avez pas oublié ma table Reponse_1_P avec ses quelques dizaines de millions de lignes ?

Tant mieux, car on va en reparler encore un peu.

Juste pour rappel, la table est partionnée par date, puis sous-partionné par questionnaire.

Plusieurs choses peuvent arriver à cette table:

• Quotidiennement de nouvelles données vont être intégrées
• On va utiliser cette table pour créer de nouvelles tables d'aggrégations (calcul de moyenne par exemple) afin de rendre les requêtes moins couteuses
• On va devoir sauvegarder.
• Et de temps en temps purger un peu !

Mais avent tout, sachant que bon nombre de requêtes vont porter sur le pays en plus de la date et du type de questionnaire, il serait peut-être bon d'indexer la colonne ID_PAYS.

Rien d'extraordinaire me direz vous:

C'est effectivement une possibilité mais dans ce cas, l'index sera GLOBAL à la table, alors que des le départ il était question que les interrogations portent sur une date et un type de questionnaire.

Pour simplifier cela signifie que nos requêtes vont porter non pas sur l'ensemble de la table (même si rien nous en empeche), mais plutôt sur les partitions et sous-partitions.

Oracle permet de créer des indexes propres à la partition. Il suffit pour cela d'ajouter la clause "LOCAL"

Les avantages sont multiples:

• Possibilité de reconstruire les indexes par partitions et donc de découper la maintenance de l'index dans le temps
• Lors de l'ajout de nouvelles données dans une nouvelle partition,l'index sera mis à jour uniquement au niveau partition et non pas de facon globale. Or sur des tables de plusieurs centaines de millions de lignes l'impact n'est pas négligeable.
  

D'une façcon générale, Oracle recommande d'utiliser les indexes de type local dans un environnement type Datawarehouse. En effet, une maintenance sur une des partitions la table rendrait l'index invalide. Dans le cas d'un index global, c'est tout l'index qui serait invalide et le cout de la reconstruction de l'index serait couteux. Depuis Oracle 10, il est possible d'effectuer une maintenance d'index après un DDL sans rendre l'index inutilisable. La recommandation d'utiliser des index de type local reste cependant d'actualité. 

Remarque: Des indexex bitmap sur une table partitionnée sont toujours de type local.

Encore une fois, on se rend compte que les options que proposent ORACLE sont nombreuses et que lorsque on implémente une fonction avancée d'ORACLE, il convient de se documenter  un minimum au risque de se retrouver avec des problèmes de peformance ou d'administration complexes à résoudre de part les contraintes de disponibilités et des volumétries en jeu.

LAO.

• Partition by range
• Partition by list
• Partition by hash

Partition by range.

Le partitionnement "by range" convient parfaitement pour historiser les données. Cela permet d'organiser les données selon un intervalle dans le temps (jours, mois, trimestre ,année). 
Il est fréquent que les grosses tables soient intérrogées par periode. Dans ce cas la Oracle utilisera le critère de partitionnement pour n'accèder qu'à une petite partie des données.

Partition by list.

Le partitionnement par liste s'effectue surtout sur des colonnes à faible cardinalité. C'est à dire dont le nombre de valeur distinctes est peu elevé. Attention, contrairement au "partition by range" et"partition by hash", la clé de partitionnement ne peut concerner qu'une seule colonne.

Partition by hash. 

Le partitionnement par hash permet de distribuer les données selon un algorithme qu'Oracle applique en fonction de la colonne partionné. L'idée est qu'Oracle répartie les données de façon égale en les différentes partitions. Pour que le répartion soit homogène il faut bien évidemment choisir une clé de hash qui elle même soit répartie de facon homogéne dans la table.
Par exemple, si j'ai une table de facture et que je partitionne par hash sur l'information client en décidant de créer 64 partitions alors que je n'ai que deux clients distincts avec 90 % de facture pour un client et 10 pour l'autre le choix de partitionnement par hash est à revoir. Il aurait mieux fallu choisir un partitionnement par liste. 
En revanche, si j'ai un millier de clients avec environ le même nombre de factures par client, on aurra une répartition homogène. Pour le partitionnement par hash, Oracle recommande fortement que le nombre de partition soit une puissance de 2 !

Remarque : Avec cet article, ca fait deux fois que j'indique qu'ORACLE recommande que pour une partition par hash, le nombre de partitions soit une puissance de deux.

Alors je peux me poser la question de lapertinence de cette recommandation. Elle a le mérite de venir d'Oracle. Mais bon nombres de concepts sont appliqués dans des applications dites sensibles sans que leur origine ou bienfondé soit vérifié.
Alors il n'est certe pas possible de toujours tout vérifier, mais dans de nombreux cas, cela ne prends que quelques minutes. Alors que dans quelques mois (après de grandes aventures...), il sera beaucoup plus compliqué de faire marche arrière, même si on est convaincu que ce qui est en place est "bancal".

Revenons à nos moutons.
Crééons deux tables partitionnées par hash une avec 4 ( 2^2) partitions et une autre avec 5 partitions.