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
Version imprimable
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
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,Citation:
Envoyé par Wurlitzer
-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
BonjourCitation:
Envoyé par Sabact
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...
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 :mouarf: ) 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 ;)
L'Administration Guide dit aussi ceci:
Voir aussi l'architecture OATM recommandée pour Oracle Applications/EBS dans le Oracle Application System Administrator's Guide.Citation:
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.
Les tablespaces de 2Go sont là pour 2 raisons:
- avant on était limités à 2 Go par fichier :-D
- quand un datafile pete, et qu'on utilise pas RMAN, c'est plus rapide de restaurer 1 fichier de 2Go qu'un fichier de 50 Go
Sinon vi séparer pour les perfs bof en effet....y'a plus utile comme optim ;) et en data placement, y'avait surtout les redologs à isoler sur des disques rapides.
Faut pas confondre les datafiles et les tablespaces. Tu peux avoir plusieurs datafiles de 2Go pour les bonnes raisons que tu évoques (sauf que le "avant" existe toujours dans certain cas) dans un seul tablespace de plusieurs centaines de Go qui mélangerait tout Index et Data.Citation:
Envoyé par mildiou51
Quand au gain de perf à séparer les DATA des INDEX, je l'ai constaté sur un gros OLTP (1000 utilisateurs) ou j'avais des problèmes d'accès disque. De séparer sur deux axes les DATA et les INDEX permet de paralléliser les IO et donc d'optimiser les temps de réponse. Maintenant, je ne dis pas qu'il y a pas d'autres façons d'arriver au même résultat en jouant avec le RAID et ASM.
dans un SAN bien configurer ça n'aurait pas dû se produire ou alors t'as vraiment pas eu de chance. En effet, dans un SAN un fichier est réparti sur plusieurs disques et c'est donc parallélisé de fait ;)
Je dois m'adapter à l'architecture de mes clients, en l'occurence c'etait des disques en RAID5 (pas genial mais bon...)
Je suis d'accord que sur un SAN (meme si je maitrise pas trop la techno), je n'ai jamais rencontré ce problème.
Reste que psychologiquement, j'aime bien savoir ou sont mes données mais bon la j'avoue que l'on sort du domaine rationnel :mrgreen:
C'est pas pour de suite RAC alors :-D