Discussion :

[lepierot]

Bonjour,
Dans mon entreprise nous utilisons VMWARE et une baie Netapp pour les disques.

La question que je me pose avant la creation d'une nouvelle base de données est de savoir si ca vaut toujours le coup de separer les data les index et les redo voire meme le soft Oracle.

j'envisag de tout mettre sur un disque D:\App\...

A votre avis ?

Merci

[Ikebukuro]

Houlala, vaste sujet.

Si tu mets tout sur un seul disque et qu'il tombe... plus de base.
Si tu gères deux disques mais dépendant du même contrôleur, s'il tombe : plus de base.
Si tu mets deux disques différents, gérés par deux contrôleurs différents mais sur le même serveur, s'il tombe : plus de base.
etc etc


Concernant de façon plus précise la séparation des données, index sur des tablespaces différents, voilà ce que j'ai compris; je te fais un copier/coller de ma doc :

SEPARER DANS DEUX TABLESPACES DISTINCTS LES DONNEES DES INDEX
Les recommandations usuelles
Les livres d’administration Oracle conseillent fortement de séparer dans des tablespaces dédiés les données et leurs index, principalement pour des raisons d’administrations.

Les avantages à séparer des données ou à avoir plusieurs tablespaces de données
Les performances
Depuis longtemps il est dit que la séparation données/index sur différents tablespaces, voir disques durs, permet de lutter contre les problèmes de contention lors de l’accès aux disques contenant ce tablespace.

Néanmoins plusieurs DBA «gourous» du Net (Ask Tom, Donald Burleson) remettent en cause cette affirmation disant que cette raison était pertinente dans les années 80 et 90 mais que l’architecture actuelle des serveurs, les fonctionnalités d’Oracle ont rendu caduc celle-ci :
http://stackoverflow.com/questions/1...ce-for-indexes
http://www.dba-oracle.com/t_segregat...ablespaces.htm

L’administration
Le tablespace est l’unité de base de nombreuses tâches d’administration.

Créer un tablespace pour chaque type d’élément (données, index, LOB, Undo, Temp, Système, …) permet de mieux les organiser et garantit une plus grande souplesse dans ces tâches d’administration :
• Backup/restauration uniquement des données ou index en sélectionnant le tablespace dédié : plus rapide et fichiers de plus petite taille
• Accès aux données maintenu même si le tablespace des index est en mode offline pour administration
• Rendre inaccessible une seule application en mettant offline son tablespace et laisser les autres TBS online et leurs applications accessibles : renommer ses fichiers du système d’exploitation, les déplacer…
• Identification plus simple des E/S ralentissant le système si ce sont des E/S liées aux données ou index
• Allocation d’extents de différentes tailles pour les tablespace des données et des index
• Avoir une taille de bloc entre tablespaces différente : par défaut les TBS ont une taille de bloc du paramètre DB_BLOC_SIZE mais on peut l’augmenter pour gérer les TBS des LOB (16/32Ko)
• Mettre un TBS de données en mode Read only :
o pour le protéger de modifications intempestives ou erronées : par exemple un TBS de données Infocentre. Making a tablespace read-only prevents updates on all tables in the tablespace, regardless of a user's update privilege level.
o éliminer le besoin de faire des backup réguliers sur des données qui ne changent pas et donc avoir un backup de la base plus petit

[Waldar]

Je vais nuancer un peu, même si fondamentalement je suis d'accord avec tout ce qu'à écrit Ikebukuro.

La question du backup du tablespace d'index se pose, car entre le coût du transfert réseau et du stockage, il peut être judicieux de reconstruire les index après restauration.

Dans ma précédente boîte, où on avait un beau serveur Oracle, on avait en stockage : 1 To de SSD sur PCIe, 8 To de SSD SATA et 60 To de HDD.
PCIe : TEMP / UNDO
SSD : les index (dans un seul TBS) et quelques tables dans un TBS "fast"
HDD : le reste des données séparées dans plusieurs tablespaces effectivement pour faciliter la gestion des sauvegardes / restauration.

Si on avait eu 80 TO de SSD sur PCIe on aurait sûrement fait autrement, mais il y a aussi une logique économique à tenir.

Je précise par ailleurs qu'il s'agit d'un serveur DWH, avec moins d'index qu'un serveur à vocation OLTP.

[Ikebukuro]

Tiens, je l'avais oublié celle-là : comme dit Waldar, il est mieux de mettre les tablespaces UNDO et TEMP sur un disque dur très très rapide car ce sont eux qui bossent le plus dans une base Oracle de type OLTP.
Ces tablespaces travaillent tout le temps tout le temps tout le temps

[pachot]

Bonjour,
Je n'ai presque jamais vu d'interêt à separer les tables de leurs index. Raisons de performances: aucune. Les deux on les mêmes types d'I/O (random et sequentiel) et jamis en concurrence. Et je n'ai jamais compris l'idée de ne pas avoir à restaurer les index "car on peut les reconstruire". Qui peut prédire le temps de création des index? Et être sûr que les performances seront les mêmes (clustering factor, pctfree)? Et etre sûr d'avoir le l'espace nécessaire dans les tempfiles? Le but des backups physiques et d'avoir un temps de restore prédictible, et un résultat de restore identique physiquement à ce qu'il y avait avant le crash. ce n'est possible qu'avec une copie physique de toute la base - table et index.
Le but des tablespaces est de regrouper ce qui va fonctionellement ensemble (fortement couply, mêmes besoins de disponibilité), et de séparer ce qui peut avoir des contraintes différentes (gros volume, read-only, disponibilité moins critique,...). Donc séparer les applis, oui. Mettre à part les grosses tables, oui. Les partitions 'froides' oui. Mais souvent les index vont avec leurs tables: même besoin de dispo, même comportement en modification, lus tout seuls ou en alternance mais jamais en même temps...
Bien sûr il peut y avoir aussi des raisons de le faire. Pour mieux faire réfléchir au besoin de séparer, on peut se demander où mettre les vues matérialisées (des tables mais avec des donnles redondantes comme les index), ou mettre les IOT (des index, mais qui contiennent les données primaires),...

SSD : les index (dans un seul TBS) et quelques tables dans un TBS "fast"

Dans l'accès par index, ce n'est pas le INDEX RANGE SCAN qui a besoin d'une latence moindre mais le TABLE ACCESS BY ROWID qui va chercher des blocs éparpillés. C'est plutôt ces tables que je mettrais sur SSD. Je ne dis pas ca pour dire que c'est bien ou pas bien mais juste qu'il faut se méfier des idées trops simples et trop génériques.

[Pomalaix]

Je n'ai presque jamais vu d'interêt à separer les tables de leurs index.

Idem ! Je dis toujours que ça ne fait pas de mal, mais que ça n'a aucun intérêt.

En revanche, je ne te suis pas sur l'argument du clustering factor.
Celui-ci dépendant uniquement de la position des différentes lignes dans la table, la reconstruction de l'index n'aura aucune incidence.

[pachot]

En revanche, je ne te suis pas sur l'argument du clustering factor.
Celui-ci dépendant uniquement de la position des différentes lignes dans la table, la reconstruction de l'index n'aura aucune incidence.

Je ne pensais pas à des reconstructions d'index. Juste le fait que la table sur SSD peut être utile sur des access frequents en INDEX RANGE SCAN + INDEX ACCESS BY ROWID dans le cas où le clustering factor n'est pas optimal car c'est là qu'on voit le plus d'accès random pour lesquels la latence est critique.

[Waldar]

Et je n'ai jamais compris l'idée de ne pas avoir à restaurer les index "car on peut les reconstruire"

C'est une logique économique, liée au contexte "datawarehouse" de ce serveur.
Dans mon cas on pouvait en général rattraper les données sources depuis le serveur front office.

En trois ans il n'y a du avoir que quelques restaurations partielles sur des tables supprimées "accidentellement" par leurs créateurs.
Là on est content d'avoir des tablespaces pas trop gros

Je ne dis pas ca pour dire que c'est bien ou pas bien mais juste qu'il faut se méfier des idées trop simples et trop génériques.

J'avoue, je n'ai pas fait le test à l'époque, je suis volontiers ton avis.
Nos cas d'usage classiques c'était principalement du FULL TABLE SCAN. On aurait bien aimé avoir que du SSD a minima, mais ce n'était pas le cas (les coûts, toujours eux).
Les index servaient à garantir les contraintes mais n'étaient quasiment jamais utilisés ; sauf pour quelques traitements où la parallélisation n'est pas native - dans les requêtes récursives notamment.

[IndianaAngus]

Bonjour,
Dans mon entreprise nous utilisons VMWARE et une baie Netapp pour les disques.

La question que je me pose avant la creation d'une nouvelle base de données est de savoir si ca vaut toujours le coup de separer les data les index et les redo voire meme le soft Oracle.

j'envisag de tout mettre sur un disque D:\App\...

A votre avis ?

Merci

Est ce que tes disques seront des disques virtuels? C'est à dire issue d'un datastore ou bien pourras tu avoir plusieurs LUN différentes? Dans le 1er cas, que tu sépare ou pas, ca ne changera rien vu que tous les I/O iront sur un seul disque (le datastore).
Sois dit en passant, avez vous la licence adéquate pour faire tourner de l'Oracle sur VMWare? (Je demande car pas mal de personnes ne sont pas au courant des règles de licensing à ce sujet).

Pour certains de nos clients nous avons plusieurs LUN physiques en ASM ou nous séparons les DATA, les REDO et la FRA pour que les uns ne marchent pas sur les autres mais on ne séparent pas DATA et INDEX.

[pachot]

nous séparons les DATA, les REDO et la FRA pour que les uns ne marchent pas sur les autres mais on ne séparent pas DATA et INDEX.

Oui, c'est indispensable de séparer FRA et DATA . Pas pour des raisons de performances, mais parce que l'un sert à réparer l'autre en cas de problème. REDO peut être séparé pour avoir un mirroring différent et pour le mettre sur des disques avec moins de capacité mais aussi moins de latence.

[Ikebukuro]

Et ne pas oublier aussi, pour des raisons de sécurité, de séparer sur différents disque durs, les membres d'un même groupe de Redo logs.

[Ikebukuro]

Idem ! Je dis toujours que ça ne fait pas de mal, mais que ça n'a aucun intérêt.

Et si tu veux faire une sauvegarde que de tes données? En cas de crash de la base, on reconstruira les index mais imagine qu'on fasse 100 sauvegardes de Tables+Index avant d'avoir un crash? Si on avait fait 100 sauvegardes de Tables, on aurait économisé du temps et de l'espace disque.

[Pomalaix]

Et si tu veux faire une sauvegarde que de tes données?

On effectue des sauvegardes en vue d'une éventuelle restauration, c'est à dire une remise en état de la base avec ses pleines fonctionnalités, notamment de performances. Or sans les index, les perfs, hein....
Ladite restauration doit en général être menée en temps limité (le fameux RTO), ce temps d'interruption étant contractualisé.
Si vous ne sauvegardez pas les index et devez les reconstruire, êtes-vous toujours dans les délais contractuels ?

De plus, si l'espace de stockage dédié aux sauvegarde est une contrainte forte, vous pouvez notamment :
- faire des sauvegardes RMAN incrémentielles (possible même en édition standard)
- utiliser la compression (celle d'Oracle ou à un autre niveau)
- utiliser la déduplication éventuellement offerte par votre système de stockage.

Donc pour moi votre scénario est purement théorique, en tout cas dans le contexte transactionnel.

[Ikebukuro]

C'était effectivement une remarque théorique et pas pragmatique