Existe-t-il une raison logique d'avoir un espace de table différent pour les index?

Question

Bonjour Certains peuvent-ils me dire pourquoi nous avons créé un espace de table différent pour Index et les données.

Answer 1

Il est largement admis que conserver les index et les tables dans des espaces de table distincts améliore les performances. Ceci est maintenant considéré comme un mythe par de nombreux experts respectables (voir ce fil de discussion Ask Tom - recherchez le mot "mythe" ), mais reste une pratique courante car les vieilles habitudes ont la vie dure!

Modification par un tiers

Extrait de asktom: " Index Tablespace " à partir de 2001 pour Oracle version 8.1.6, la question

• Est-ce toujours une bonne idée de conserver les index dans leur propre tablespace?
• Cela améliore-t-il les performances ou s'agit-il davantage d'un problème de récupération?
• La réponse diffère-t-elle d'une plateforme à l'autre?

Première partie de la réponse

Yes, no, maybe.

The idea, born in the 1980s when systems were tiny and user counts were in the single 
digits, was that you separated indexes from data into separate tablespaces on different 
disks.

In that fashion, you positioned the head of the disk in the index tablespace and the head 
of the disk in the data tablespace and that would be better then seeking 2 times on the 
same disk.

Drives back then were really slow at seeking and typically measured in the 10's to 100's 
of megabytes (if you were lucky)


Today, with logical volumes, raid, NN gigabyte (nn is rapidly becoming NNN gigabytes) 
drives, hundreds/thousands of concurrent users, thousands of tables, 10's of thousands of 
indexes - this sort of "optimization" is sort of impossible.

What you strive for today is to be able to manage things, to spread IO out evenly 
avoiding hot spots.

Since I believe all things should be in locally managed tablespaces with UNIFORM extent 
sizes, I would say that yes, indexes would be in a different tablespace from the data but 
only because they are a different SIZE then the data.  My table with 50 columns and an 
average row size of 4k might belong in a tablespace that has 5meg extents whereas the 
index on a single number column might belong in a tablespace with 512k or 1m extents.

I tend to keep my indexes separate from the data but for the above sizing reason.  The 
tablespaces frequently end up on the same exact mount points.  You strive for even io 
across your disks and you may end up with indexes and data on the same devices. 

Answer 2

Cela fait sens dans les années 80, quand il n'y avait pas beaucoup d'utilisateurs et que la taille des bases de données n'était pas trop grosse. A cette époque, il était utile de stocker des index et des tables dans les différents volumes physiques.

Maintenant, il y a les volumes logiques, le raid, etc., et il n'est pas nécessaire de stocker les index et les tables dans différents espaces de table.

Mais tous les espaces de table doivent être gérés localement avec une taille d'extension uniforme. De ce point de vue, les index doivent être stockés dans un tablespace différent, car la table contenant les 50 colonnes pourrait être stockée dans un tablespace de taille exted de 5 Mo, lorsque le tablespace pour les index aura une taille étendue de 512 Ko.

Answer 3

• Performance. Il devrait être analysé de cas en cas. Je pense que garder tout le monde dans un seul espace de table devient aussi un autre mythe! Il devrait y avoir suffisamment de broches, suffisamment de brouillards et faire la queue dans le système d'exploitation. si quelqu'un pense que créer un seul espace de table suffit et qu'il est identique à beaucoup d'espaces de table sans prendre en compte tous les autres facteurs, cela signifie encore un autre mythe. Cela dépend!
• Haute disponibilité. L'utilisation d'espaces de table distincts peut améliorer la haute disponibilité du système en cas de corrution de fichier, de corruption du système de fichiers, de corruption de bloc. Si le problème ne survient que dans un espace de table d'index, il est possible d'effectuer la récupération en ligne et notre application est toujours disponible pour le client. voir aussi: http : //richardfoote.wordpress.com/2008/05/02/indexes-in-the-own-tablespace-recoverability-advantages-get-back/
• en utilisant des espaces de table distincts pour les index, les données, les blobs, les clobs, éventuellement certaines tables individuelles peuvent être importantes pour la facilité de gestion et les coûts. Nous pouvons utiliser notre système de stockage pour stocker nos blobs, nos clobs, et éventuellement les archiver sur une couche de stockage différente avec une qualité de service différente