Gestion de tablespace

Salut tout le monde,
On parle de gestion de tablsespace LOCAL ou par dictionnaire de donnée ...
Par contre il y a que des avantages du coté de la gestion local par rapport à celle du dictionnaire de données... :roll:
Je me pose la question.., pour quoi ne pas utiliser alors que la gestion LOCAL... :?:
De plus dans la doc je ne trouve rien de spéciale au niveau de la gestion de l'espace dans les tablespace à part la spécification de l'option
EXTENT MANAGEMENT DICTIONNARY
ou
EXTENT MANAGEMENT LOCAL
Au moment de la création du la tablespace...

Alors pourquoi spécifier ces options ?
Et c'est quoi l'avantage de la gestion par le DICO par rapport à la gestion LOCAL.
8O Merci

Dans le cas EXTENT MANAGEMENT LOCAL, toutes les informations concernant le tablespace sont stockées.... dans le tablespace... et non pas dans le dictionnaire de données qui se trouve dans le tablespace SYSTEM

OUi, C'est même ça l'avantage de la gestion LOCAL, car les interrogations et les mises à jours du dictionnaire de données sont coûteuses, alors pourquoi la gestion par le dictionnaire existe toujours...!!
En faite je ne vois pas l'interet de donner des infos sur la façon avec laquelle Oracle gère l'espace dans un tablespace si on arrive pas à exploiter ces infos dans quelque chose par la suite...
Donc je me dis que c'est juste bon à savoir et pas plus :!:

:(

L'ajout de nouvelles fonctionnalités ne rend pas nécessairement obligatoire la suppression des anciennes.

*(Les explications de SheikYerbouti ont toujours la transparence du cristal. (La Rédaction))

OK, mais moi je voulais m'assurer que la gestion par dico ne possède des avantages par rapport à celle en LOCAL.
Effectivement on peut garder des fonctionnalité dans les nouvelles versions pour des raisons de compatibilité avec les anciennes ...

Mais on est bien d'accord qu‘après la spécification de la méthode de gestion LOCAL ou par DICO, le DBA n'aura pas autre choses à faire à ce sujet...
8O

*(Les questions de Blids sont toujours un peu théorique (blids)) :wink:

En choisissant la gestion locale, Oracle utilise des blocs de type Bitmap pour gérer les espaces libres.
Cette fonctionnalité n'est peut-être tout simplement pas implémentée lorsque les infos sont stockées dans le dictionnaire...

Mais le DBA pourra faire le chagement par la suite...
donc y a pas de problème...
Je dirais c'est la seule chose que le DBA pourra faire en plus aprés la création du tablespace .. :!:

Merci

En fin de compte on ne peu pas changer les paramettres de stockage d'un tablespace (maxextents, initial, ....) dans une gestion LOCAL, mais c'est possible dans la gestion par le DICO ...
Et voila un avantage :wink:

Bonjour
Apres avoir lu pas mal de posts concernant la gestion des extents, je suis tombée sur celui-ci et ma question est :
Comment respecter la règle des paquets en « local management », si on ne peut pas au moins définir une taille min d’extent ?

Je voudrais créer des TBS dont les clauses de storage sont adaptées au volume des tables, et Oracle m’a tout créé pareil…Et notamment des INIT de 16K pour toutes les tables (alors que les INIT des TS sont 65K ?? :roll: ).
Or j’ai des tables qui vont recevoir plusieurs milliers d’inserts par jour, alors que d’autres resteront toujours petites (d’où l’idée de TBS séparés…).

J’ai essayé avec l’option UNIFORM, mais même en mettant une taille d’extent a 500K, les tables créées dans ce TBS ont un init de 16K.
En plus le NEXT ne peut plus être modifié sur ces TBS …est-ce à dire qu’il ne faut pas se louper dans les estimations à la création… ?? Ca m'etonne

Merci d’avance pour vos avis éclairés
Isa

Bonjour,


La gestion par LMT ne semble avoir que des avantages : c'est pourquoi à partir d'Oracle 9i R2 le tablespace SYSTEM est lui-même en LMT et on ne peut même plus créer de tablespace en DMT.


Laly.

Je pense que ces deux pages peuvent être utiles ;)

http://asktom.oracle.com/pls/ask/f?p...:2971225873749

http://asktom.oracle.com/pls/ask/f?p...:7149039425561

Conclusion apres lecture : on ne s'occupe de rien et on sera toujours sur qu'Oracle allouera la bonne taille d'extent, qu'il n'y aura pas de fragmentation et que les perf seront bonnes. C'est magique ! ? :wink:

Toujours dans mes tests de pre-migration, j'ai essaye cela (je suis en 9.0.2)

alter table<table> move partition <P> compress

et j'ai obtenu
ORA-28606: block too fragmented to build bitmap index (278,256)
La table est dans un LMT. N'est-ce pas contradictoire avec ce qui est contenu dans les pages citees ?

Isa

Bonjour,


Sur Metalink :

Citation:

---

{ This note contains error information about an "Oracle Server" error number. It may contain additional support notes as described in [NOTE:22080.1] }
Error: ORA-28606 (ORA-28606) Text: block too fragmented to build bitmap index (%s,%s)
---------------------------------------------------------------------------
Cause: The block(s) exceed the maximum number of rows expected when creating a bitmap index. This is probably due to maximum slot allowed set too low. The values in the message are: (slot number found, maximum slot allowed)

Action: alter system flush shared_pool; update tab$ set spare1 = 8192 where obj# = (select obj# from obj$ where NAME=<table_name> AND owner# = <table_owner>; commit;

---

Laly.

Merci pour la correction .

Mais la question demeure : si les LMT ne subissent aucune fragmentation, pourquoi un tel message ??

on a jamais dit que LMT ne provoque pas de fragmentation... elle la limite seulement ;)

Lu dans la page
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:7149039425561 citee par CD

Citation:

---

if you use locally managed tablespaces -- it is physically impossible to have them be fragemented.

---

et

Citation:

---

space is always automagically coalesce in locally managed

---

.

Bon j'en reviens a mes questions initiales:
-peut-on, en LMT, avoir une prévision de gestion d'espace ?
-est-ce que la taille de NEXT donnee a la création du TBS a un impact négatif sur les perfs si elle est mal choisie?
-comment corriger si c'est le cas ?


Isa

pour modifier le NEXT il suffit de déplacer tous les segments dans un autre tablespace et recréer le tablespace d'origine avec le NEXT souhaité, ensuite tu remets tous les segments dedans (MOVE pour le table et REBUILD pour les indexes)

D'accord, merci.
Quand le TBS contient quelques millions de lignes, ca doit prendre un certain temps...

Je vais etudier ça.