taille de CREATE TABLE

BONJOUR,

JE suis à la recherche d'information sur le CREATE TABLE.
Je comprend pas bien l'anglais et la documentation d'Oracle.

Mon problème est simple. J'ai une énorme table environ 15GB. Cette table grandit vite (500MB par semaine).

Je vais partitioner cette table en OFFLINe (donc sans dbms_redefinition) en faisnt un CREATE TABLE ... puis en copiant les données d'une table à cette nouvelle table puis en renommant les deux tables pour que la seconde prenne la place de la première table.

Donc, j'ai déjà une table avec plus de 15GB de données.

Je voudrais créer la seconde table en spécifiant un STORAGE (INITIAL 10G NEXT 1G). Au niveau du tablespace, ces valeurs sont de 64MB pour l'initial et null pour le next et le max extends est de 2G. Le tablespace est en AUTO pour segment_space_management.

Comme je trouvais ces valeurs très petite par rapport à la taille de la table, je voulais mettre un initial de 10G. Mais la documentation est assez légère par rapport à cet attribut.

Est-ce que quelq'un pourrait me conseiller?

merci et bon week-end à vous

Comment répondre ? Vous ne précisez même pas votre version !

Citation:

---

Envoyé par Waldar

Comment répondre ? Vous ne précisez même pas votre version !

---

J'utilise Oracle 10.2.0.4.
Désolé, j'avais oublié.
:mrgreen::mrgreen:

Bonjour,

si ton tablespace est en auto, oublie les précisions d'initial et next car c'est oracle qui choisit la taille selon ses algorithmes.(tu voulais bien dire en autoallocate?).
sinon, 10Go, 1Go ça me semble absolument démesuré. songe qu'à chaque partition créée, tu aurais un extent d'un Go par partition, même vide!
tu partitionnes comment? as-tu une idée de la taille que fera chaque partition?
si certaines partitions sont destinées à ne plus bouger, c'est à dire qu'elles deviennent en quelque sorte des archives historiques, tout l'intérêt du partitionnement au niveau administratif est que ces partitions pourront être placées en lecture seule et n'auront plus besoin d'être sauvegardées aussi souvent que la base en entier. dans ce cas, il faudrait penser dès maintenant à créer un tablespace où tu mets la partition de ta table que tu pourras un jour passer en lecture seule et compresser éventuellement.
au niveau des performances, des segments de 1G ou 10Go risquent d'être très pénalisants, même si tu tapes bien dans les partitions que tu souhaites directement avec le partition pruning.

Je partitionne de manière composite. La clé de partitionnement principale est basée sur une date. La clé de sous-partionnement est un hash (8 sous partitions par partition).

La taille des sous-paritions seront d'environ 500MB chacune; et est constant.

Donc, pour toi l'idéal serait de gérer la taille au niveau du tablespace. Mais bien que démesurée, immagine que je ne crée un tablespace que pour cette table et ses partitions, tu choisirais quel allocation type? (SYSTEM, UNIFORM SIZE...) avec quel initial, et surtout pourquoi :)

Je suis vraiment perdu dans ce charabia moi :(

laissons tomber l'histoire des tablespaces dédiés. tu pourras toujours tuner ça plus tard en déplaçant des partitions ailleurs. ce que je voulais juste souligner, c'est que si ton tablespace ets en autotallocate, je pense qu'oracle ne tiendra pas compte de tes préconisations en matière de taille et si tu le mets dans un tablespace en LMU, la taille de ton initial et de ton next seront la taille de l'extent avec lequel le tablespace a été construit. C'est bien pour ça qu'on appelle cela le segment space management auto.
Tu me demandes ce que je ferais à ta place? je contruirais un tablespace en LMU de 128Mo parce que la taille de ta table va être assez grosse au final (mais pas suffisamment pour risquer de gâcher de l'espace avec des extents de 1024Mo, vu que tes partitions vont faire dans les 500Mo), je contruirais ensuite la table et j'exécuterais les requêtes les plus courantes sur celles-ci pour avoir une idée du coût. tu peux faire la même chose avec un tablespace monté à 256Mo ou 512Mo, et tester. tu te rendras vite compte de ce qui est le mieux pour ta table. Par la même occasion tu verras aussi si tes critères de partitionnement son efficaces ou pas.
Au besoin tu fais ça dans une base de test.
Je suis désolée mais il n'y a pas de réponse toute faite selon moi. Il faut mettre ses conceptions à l'épreuve du réel ;)
et puis ne pas oublier de faire les index en local...

je n'ai pas répondu à ta question sur LMU ou autoallocate : autoallocate c'est bien quand on ne connait pas la taille finale de son objet. Toi tu en as une bonne idée, alors autant tailler le TBS comme il faut. 128Mo c'est ce qu'on fait chez nous pour stocker les objets supérieurs à 512Mo.