Discussion :

[Sabact]

Bonjour à tous,
Est ce vous pouvez me donner le but de la création d'un autre tablespace séparé avec le tablespace system, et l'avantage aussi si vous le me permettez.

Merci pour votre réponse

[Wurlitzer]

La création de plusieurs tablespaces a pour but d'organiser un peu ces données. La séparation SYSTEM, DATA, INDEX permet en autre de séparer le dictionnaire, des données et des index sur des disques différents et don d'optimiser les performances

[Sabact]

La création de plusieurs tablespaces a pour but d'organiser un peu ces données. La séparation SYSTEM, DATA, INDEX permet en autre de séparer le dictionnaire, des données et des index sur des disques différents et don d'optimiser les performances

Merci,
-Je suis tout à fait d'accord quand vous dites "Organiser les données", mais sur si on dit pour optimiser la les performances, cela mais fait un ambiguité, est ce vous pouvez donner le principe de fonctionnement (d'interaction)du tablespace pour que cela fais entrainer une performance sur la base.
-Si je melange mes données dans un seul tablespace,quel est la différence de performance (durée de requette- Select-update- insert), par rapport avec une autre base qui est bien ordonnée(Tablespace différent)- selon les nombres des données.

Merci pour votre réponse

[Pomalaix]

-Si je melange mes données dans un seul tablespace,quel est la différence de performance (durée de requette- Select-update- insert), par rapport avec une autre base qui est bien ordonnée(Tablespace différent)- selon les nombres des données.

Bonjour

La séparation des index et des tables dans des tablespaces différents est considérée comme indispensable pour garantir de bonnes performances. Ne pas se plier à cette règle passe pour le pire amateurisme.

En fait, cette évidence fait largement débat, et quelques grands noms comme Tom Kyte prétendent que cette règle n’est rien d’autre qu’un mythe.
http://groups.google.ch/group/comp.d...b58005b8?tvc=1


Néanmoins, tout ce qu'on trouve sur le sujet reste déclaratif et théorique, et les démonstrations et les tests chiffrés, dans l'un ou l'autre camp, font furieusement défaut.

Il est assez amusant de voir s'opposer la vision micro des uns (mouvement des têtes de lecture) et la vision macro des autres (dès lors qu'on est dans un environnement réel, cette "mécanique quantique" n'est plus pertinente), et de constater que sur ce thème, Tom Kyte serait plutôt d'obédience bordélico-statistique, et rejoindrait par derrière le décor son cher ennemi Don Burleson...

[orafrance]

Pour moi c'est tout simplement pour réorganiser plus facilement l'espace disque. En effet, lorsqu'on purge les tables, on ne peut récupérer l'espace qu'en réorganisant les objets pour faire redescendre la HWM. Or, les tables sont plus compliquées à réorganiser surtout quand elles contiennent des LOB ou LONG.

Donc, on peut éventuellement faire l'impasse sur les tables et ne récupérer de l'espace que sur les indexes. Avoir un tablespace ne contenant que des indexes permets de pouvoir le vider complétement (avec des REBUILD) pour le retailler.

On peut aussi ajouter un autre intérêt : en cas de perte d'un tablespace, si celui ci ne contient que les indexes une restauration n'est pas forcément nécessaire. Ca permet donc de limiter le risque de perte de données aussi

Et sinon, je rejoins Tom Kytes sur l'intérêt peu évident sur les perfs. Ceci dit, on ne peut pas faire de régles. En effet, le data placement ("science" consistant à éviter d'éparpiller les datafiles sur les disques... qui entre autre explique l'usage de datafiles de 2Go très souvent vu sans que les DBA eux-même ne s'expliquent cette habitude ) peut faire des miracles alors même que Tom Kytes affirme que désormais les baies de disques permettent de s'affranchir du coté physique des données. Bref... il faut surtout retenir qu'une politique de placement des données est couteuse pour un résultat hasardeux

PS : Pom' je ne t'oublie pas

[pifor]

L'Administration Guide dit aussi ceci:

Separate data of one application from the data of another to prevent multiple applications from being affected if a tablespace must be taken offline.

Take individual tablespaces offline while others remain online, providing better overall availability.

Optimizing tablespace use by reserving a tablespace for a particular type of database use, such as high update activity, read-only activity, or temporary segment storage.

Back up individual tablespaces.

Voir aussi l'architecture OATM recommandée pour Oracle Applications/EBS dans le Oracle Application System Administrator's Guide.