Discussion :

[aline]

Bonjour,

J'aimerai avoir un retour de vos expériences concernant ces deux technologies.
Pour ne pas qu'il y ai de confusion, je précise:

Raid logique. Le raid est fait par l'OS. On ne voit donc qu'une entité logique et on ne s'occupe de rien.

raid physique: Pour chaque fichier, on spécifie deux (n) emplacements (évidement par sur le même disque).

Je suis toujours passée par des raids logiques, mais je pense que la deuxième solution est indispensable pour aller un peux plus loin.

Qu'en pensez vous?

[BV94]

ORACLE préconise l'utilisation du raid physique bien évidemment.
De plus, tablespaces de données et indexes doivent être stockés sur deux disques physiques différents...

[Alain B.]

raid physique: Pour chaque fichier, on spécifie deux (n) emplacements (évidement par sur le même disque).

A mes yeux, un raid physique est géré de maniere hardware par le contrôleur des disques. Il regroupe au moins deux disques physiques, mais l'OS n'y voit qu'un seul disque.

De plus, tablespaces de données et indexes doivent être stockés sur deux disques physiques différents...

Moui, c'est de l'histoire ancienne ca , avec les performances des disques actuelles...
Je conseille une petite recherche à ce sujet sur l'excellent http://asktom.oracle.com/

[orafrance]

Moui, c'est de l'histoire ancienne ca , avec les performances des disques actuelles...

Non, non, c'est toujours d'actualité mais si dans une baie SAN performante c'est moins nécessaire

En tout cas, il y a bien mieux désormais, c'est la répartition par taille d'objet avec des tailles de blocs pour chacune des tranches (petit, moyen, grand et très grand).

[LeoAnderson]

Moui, c'est de l'histoire ancienne ca , avec les performances des disques actuelles...

+1 mais plus que les perf, c'est l'organisation des devices qui compte.

Sur des systèmes pro, il est rare que le chemin logique ne soit rattaché qu'à un seul disque. Un même chemin logique est donc répartit sur plusieurs disques.
De fait, on peut avoir données et indexes côte à côte (logiquement) sans que forcément ils soient sur le même disque physique...

Par contre, c'est sûr que si vous n'avez qu'un gros PC avec 3 disques SCSI "simples", il faut séparer data et indexes.

[aline]

Bonjour à tous, et merci pour vos réponses.

Non, non, c'est toujours d'actualité mais si dans une baie SAN performante c'est moins nécessaire

En tout cas, il y a bien mieux désormais, c'est la répartition par taille d'objet avec des tailles de blocs pour chacune des tranches (petit, moyen, grand et très grand).

Je ne comprends pas très bien ta réponses Fred. C'est très intéressant, mais est-ce le sujet?
Tu dis que les petites tables, tu les mets dans des petits tablespaces avec des petites tailles de blocs et les grosses dans des gros tablespaces avec des grosses tailles de blocs?

C'est le même genre de technique que l'on faisait quand le nombre d'extents était important (jusqu'en Oracle8) sur les tablespace qui n'étaient pas géré localement avec des petits et des gros extents?


Je ne vois pas le rapport avec le raid et la création de volumes différents ou je n'ai pas bien compris ta remarque.

+1 mais plus que les perf, c'est l'organisation des devices qui compte.

Sur des systèmes pro, il est rare que le chemin logique ne soit rattaché qu'à un seul disque. Un même chemin logique est donc répartit sur plusieurs disques.
De fait, on peut avoir données et indexes côte à côte (logiquement) sans que forcément ils soient sur le même disque physique...

Par contre, c'est sûr que si vous n'avez qu'un gros PC avec 3 disques SCSI "simples", il faut séparer data et indexes.

c'est pile poil le coeur de ma problématique.
J'ai une grosse appli à gérer et je ne sait pas s'il faux que cela soit fait avec un gros PC ou bien si lui coller une baie nous fera gagner énormément(compte tenu du coût).


Si cela doit être fait avec le gros PC, j'aurai deux volumes logiques (deux disques en raid chacun).
Dans ce cas, quelle répartition me conseillez vous (données, indexes,undo,redo,system,archive logs...)?



Et que pourai nous apporter une baie en terme de perfs?


Y a t'il de la documentation sur ce genre de caractéristique très techniques?


Merci à tous encore ,

[orafrance]

Je ne vois pas le rapport avec le raid et la création de volumes différents ou je n'ai pas bien compris ta remarque.

Je profite juste d'un sujet sur le stockage pour rappeler cette pratique

En fait, l'idée n'est pas tant pour le nombre d'extent que pour le nombre d'accés disque nécessaire pour récupérer les datas

Si cela doit être fait avec le gros PC, j'aurai deux volumes logiques (deux disques en raid chacun).
Dans ce cas, quelle répartition me conseillez vous (données, indexes,undo,redo,system,archive logs...)?

Bah là 2 disques ne suffisent pas dans l'idéal puisque tu dois avoir au moins 2 groupes de 2 redo chacun sur un disque différent (G1R1 avec G2R2 et G1R2 avec G2R1), le undo sur un autre disque, les TEMP encore sur un autre et le inde et data encore séparer... ça c'est le monde idéal selon Fred_D

Et que pourai nous apporter une baie en terme de perfs?

Les problèmatiques d'accés disques sont complétement gérées par la baie qui se débrouille pour paralléliser les lectures/écritures. En plus, la baie contient un cache qui seconde parfaitement le DB_CACHE

Y a t'il de la documentation sur ce genre de caractéristique très techniques?

Asktom a pas mal de sujet et Metalink fournit également des notes intéressantes... mais j'avoue que c'est pas évident d'avoir un avis tranché sur la question

[LeoAnderson]

Je serais tenté de faire une réponse du mec que c'est pas lui qui paye : "si tu peux avoir la baie, fonce, tu verras, on trouve toujours à s'en servir" !

Après, si tu es moins riche et joueuse : "Prends le gros PC en disant que tu as des doutes sur les perfs, mais que vu la différence de prix, ça se tente". Une fois que tu as le gros PC, tu tunes la base moyennement, et tu dis "la baie était indispensable" et au passage, tu gagnes un super gros PC pour lancer 18 DBA Studio, 25 Toad, 45 Raptor,500 SQL*Plus et 3 jeux en simultané

[aline]

Bonjour,

Essayons quand même d'aller plus loin et de ne pas regarder le cas idéal!

Scénario 1:
Vous avez un gros pc avec quatres diques en raid (donc en fait deux disques). vous faites deux volumes logiques parce que vous ne pouvez pas faire mieux. comment répartissez-vous les fichiers?

Scénario 2:
Vous disposez d'une baie de disques.
Combien de volumes voulez vous créer et comment faites vous la répartition?

J
Asktom a pas mal de sujet et Metalink fournit également des notes intéressantes... mais j'avoue que c'est pas évident d'avoir un avis tranché sur la question

Tu as des liens précis. Je n'ai pas réussi à en trouver un de très concret

[pifor]

Sur AskTom:
http://asktom.oracle.com/pls/ask/f?p...A:359617936136
http://asktom.oracle.com/pls/ask/f?p...:1993364819100
http://asktom.oracle.com/pls/ask/f?p...A:396975084466

[orafrance]

Scénario 1:
Vous avez un gros pc avec quatres diques en raid (donc en fait deux disques). vous faites deux volumes logiques parce que vous ne pouvez pas faire mieux. comment répartissez-vous les fichiers?

Scénario 2:
Vous disposez d'une baie de disques.
Combien de volumes voulez vous créer et comment faites vous la répartition?

Scénario 1 :
Si GxRy représente le groupe x et le redo y :
Disque 1 : G1R1+G2R1+1 table sur 2+1 index sur 2 (les indexes qui n'appartiennent pas aux tables stockées ici) + UNDO
Disque 1 : G1R2+G2R2+1 table sur 2+1 index sur 2 + TEMP

Scénario 2:
Autant de volume que de canaux sur la baie. Si il y a 4 canaux alors 4 volumes pour paralléliser la charge

[aline]

Scénario 1 :
Si GxRy représente le groupe x et le redo y :
Disque 1 : G1R1+G2R1+1 table sur 2+1 index sur 2 (les indexes qui n'appartiennent pas aux tables stockées ici) + UNDO
Disque 1 : G1R2+G2R2+1 table sur 2+1 index sur 2 + TEMP

et le tablespace system , et les archives logs?
J'hésite à faire comme toi et de mettre les archives d'un coté ou bien de mettre tout les redos logs sur un volume et les archives sur l'autre

[LeoAnderson]

Conclusion : 2 volumes, c'est pas assez ! ;-)

(car il manque aussi les binaires Oracle, la swap, ....)

[orafrance]

J'hésite à faire comme toi et de mettre les archives d'un coté ou bien de mettre tout les redos logs sur un volume et les archives sur l'autre

Très mauvaise idée si tu mets tous les redos au même endroit tu as toutes les chances de perdre le redo courant et ça peut couter très cher

C'est pas par plaisir qu'on est obliger de faire 2 redos par groupe

Sinon, en effet, les binaires et le swap doivent être prévu également, mais c'est pas là dessus qu'il y aura beaucoup de charge I/O. Les binaires c'est logique et le swap on n'est pas sensé l'utiliser

Quand au tablespace SYSTEM, c'est un tablespace comme un autre pour moi...

[LeoAnderson]

Très mauvaise idée si tu mets tous les redos au même endroit tu as toutes les chances de perdre le redo courant et ça peut couter très cher

+1

C'est pas par plaisir qu'on est obliger de faire 2 redos par groupe

On n'est pas obligé... c'est conseillé mais techniquement, rien ne t'en empêche. La seule contrainte, c'est d'avoir au minimum 2 groupes.

Sinon, en effet, les binaires et le swap doivent être prévu également, mais c'est pas là dessus qu'il y aura beaucoup de charge I/O. Les binaires c'est logique et le swap on n'est pas sensé l'utiliser

Quand au tablespace SYSTEM, c'est un tablespace comme un autre pour moi...

La charge sur SYSTEM dépend du type d'application (beaucoup d'appels à de très nombreux objets PL/SQL ? ) et de la gestion des tablesace (EXTENT MANAGEMENT LOCAL ou non).
Il n'est donc pas exclu que SYSTEM soit très sollicité !

Et les binaires et la swap, leur sollicitations dépend de la machine et de son utilisation... donc, on ne peut pas ignorer ça !
Honnêtement, en dessous de 3 axes physiques en RAID + 1 disque physique rapide non mirroré (système, binaires et SWAP => sauvegardés normalement), ça me semble pas raisonnable si tu veux t'assurer des perfs. correctes tout en minimisant les risques d'incident majeur avec perte de données.

[Jaouad]

Bonjour ,
une question pour mon cher orafrance :

dans l'idéal puisque tu dois avoir au moins 2 groupes de 2 redo chacun sur un disque différent (G1R1 avec G2R2 et G1R2 avec G2R1),

je ne suis pas tout à fait d'accord avec toi, parce que dans un systéme bien pensé on a souvent des raid mirroré et donc si on perd le disque sur lequel est le redo courant, le disque de secours prends le relais et c'est totalement tansparent pour Oracle.

Lorsque que l'on sait que les REDO sont enormément consomateurs d'I/O ne vaut il pas mieux ( c'est ce que je penses) conseiller un membre pa groupe lorsqu'on des disques mirrorés

[aline]

Bonjour ,
une question pour mon cher orafrance :



je ne suis pas tout à fait d'accord avec toi, parce que dans un systéme bien pensé on a souvent des raid mirroré et donc si on perd le disque sur lequel est le redo courant, le disque de secours prends le relais et c'est totalement tansparent pour Oracle.

Lorsque que l'on sait que les REDO sont enormément consomateurs d'I/O ne vaut il pas mieux ( c'est ce que je penses) conseiller un membre pa groupe lorsqu'on des disques mirrorés

bonjour à tous!

c'était ce que je voulais dire quand je disais:
"J'hésite à faire comme toi et de mettre les archives d'un coté ou bien de mettre tout les redos logs sur un volume et les archives sur l'autre".

Si tout est mirroré, on ne voit que deux disques dans mon exemple. donc un membre par groupe ?!

Ensuite, (et c'était ma question) soit:
1) on met tout les redos sur le même volume et les archives sur l'autre,
2) (comme Orafrance le conseille) on fait une séparation sur les redos (groupe impaire volume 1, groupe paire volume 2) et on met les archives sur un volume.

Mais, il me semble que l'écriture sur les redos aussi couteuse soit elle ne l'est pas plus que l'écriture des archives. Donc, dans le cas ou l'on a que deux volumes, pourquoi ne pas prendre la solution 1?

[LeoAnderson]

Attention : le RAID ne protège que des défaillances matérielles (si le disque 1 lâche, les données sont sur le 2).

Mais il ne protège pas du tout des défaillances humaines (rm ./redo_G1_M1.rdo).

Donc, il est nettement plus sûr d'avoir plusieurs axes physiques distincts, (même non-mirrorés je serais tenté de dire) pour les redos qu'un seul axe physique mirroré !

[orafrance]

je ne suis pas tout à fait d'accord avec toi, parce que dans un systéme bien pensé on a souvent des raid mirroré et donc si on perd le disque sur lequel est le redo courant, le disque de secours prends le relais et c'est totalement tansparent pour Oracle.

Lorsque que l'on sait que les REDO sont enormément consomateurs d'I/O ne vaut il pas mieux ( c'est ce que je penses) conseiller un membre pa groupe lorsqu'on des disques mirrorés

Certes... mais si la perte du redo résulte d'une corruption de bloc, la corruption est aussi mirorrée... et là... c'est le drame

Non, vaut mieux conseiller un membre par disque ou canal (sur une baie)... à mon avis

Edit : bonne réponse de LeoAnderson que je n'avais point lu

[orafrance]

Mais, il me semble que l'écriture sur les redos aussi couteuse soit elle ne l'est pas plus que l'écriture des archives. Donc, dans le cas ou l'on a que deux volumes, pourquoi ne pas prendre la solution 1?

Certes... c'est une excellente remarque... j'avais omis qu'on ne peut pas écrire dans les REDO tant que l'archive n'est pas faite... donc on ne parallélise pas les écritures. Tu as parfaitements raison... pour les perfs... pour attention en cas de perte du REDO courant