Disques RAID & Oracle

Disques RAID & Oracle - SQL/NoSQL - Programmation

Marsh Posté le 01-04-2005 à 10:19:44    

Bonjour a tous,
 
Je me pose une question a laquelle je n'arrive pas a trouver de VRAIE reponse...
En effet, je suis en intervention chez un client qui a un systeme décisionnel a base de Cognos ReportNet avec une base de données Oracle.
Le serveur etait à la base en RAID 5, mais d'apres les préconisations Oracle, le RAID 5 n'est pas conseillé. Je me suis alors dit que le RAID 0 augmenterait nettement les performances (duplication des axes)!
PAs du tout, les temps d'intégration de données (=ETL) sont strictement identiques (~24h) ce qui a le don d'enerver le client, car il perd une journée de la semaine sur son intégration.
 
Quelles sont reellement les meilleures configuration pour que Oracle puisse tourner a plein regime?
(supposant que la base de données est relativement optimisée)!
 
Merci de vos reponses!

Reply

Marsh Posté le 01-04-2005 à 10:19:44   

Reply

Marsh Posté le 01-04-2005 à 12:20:16    

Déjà, le RAID 50 sera mieu que le RAID 5, ça c'est sur, car il bénéficie des points forts des deux RAID (5 et 0).
 
Ensuite, Oracle dépréconise le RAID 5... Et ils préconisent quoi à la place ?
 
Sinon, vu qu'Oracle travaille par tablespace qui peuvent être répartis sur des disques, je pense que tu pourrais énormément gagner en passant à du multiple RAID 0, et en répartissant tes tablespace sur les différentes unités logiques RAID 0. Ainsi, il sera capable de travailler sur plusieurs chaînes à la fois. Seul problème, c'est que si c'est de l'insertion séquencielle, tu gagneras pas grand chose.
 
Bon, ensuite, si changer le type de disque de la base n'apporte rien à la vitesse de transfert, il est fort à parrier que ça plafonne ailleurs.
 
D'où viennent les données ? Un fichier de 2 Go téléchargé avec un modem 56k ? Regarde de ce côté déjà. Style, si le fichier source se trouve sur le même disque que le disque destination, tu vas avoir des perfs catastrophiques. Idem si tu passes par un réseau engorgé.
 
Tu insères les données avec quelle méthode ? Un pont ODBC passant par Access ? Ouais, là t'es mal. Un dblink entre deux Oracles ? Un fichier de requêtes ?
Dans tous les cas, essaie de passer par le SQL Loader... Pour donner des chiffres, tu réduit une insertion de 500 000 lignes de 10 ko de 3 heures à 2 minutes.

Reply

Marsh Posté le 01-04-2005 à 12:22:04    

Sinon, les disques, ils sont sur un SAN ? Si oui, c'est quoi le débit entre le serveur et le SAN ?
Parceque si les disques peuvent délivrer du 320 Mo/s, c'est cool, mais si t'as une connection à 12 Mo/s, ça sert à rien...

Reply

Marsh Posté le 01-04-2005 à 15:01:25    

Merci bcp de ces reponses...
Mais je ne savais pas si l'on pouvais "forcer" le placement et donc le repartissement des données (en l'occurence ici les tablespace) sur les disques de maniere manuelle!
je pensais que c'etait completement logicielle et automatique...
 
Connais-tu la manipulation?
 
Tu as raison, apparemment le fichier contenant les données d'integration sont sur la mm disque (logique), alors je vais deja le changer de partition et si ce la ne change pas grand chose, carrement le mettre sur un autre dur...
Qu'en penses-tu ?
 
 
Merci pour tout!

Reply

Marsh Posté le 01-04-2005 à 16:28:50    

Je pense en effet que changer le fichier de disque est un point très important. Par contre, même si c'est du RAID 0, assure-toi que les deux fichiers ne soient pas sur la même chaîne RAID, car changer de partition seulement ne devrait rien arranger du tout (voir empirer les choses).
 
Sinon, pour positionner les tablespace, je ne sais pas comment on fait. Normalement, dans Oracle, y'a un outil qui te permet de manager les tablespace de façon graphique. Ensuite, il faudra déplacer les tables concernées dessus.
 
Si tu ne veux que accélérer ton import (donc accès séquentiels à la base), je te conseille ceci :
 
Chaîne 1 : Un ou plusieurs tablespace contenant les tables à importer. Surtout, si ton import fait des boucles (après avoir inséré une ligne dans T1, il insère x lignes dans T2, puis recommence avec T1), alors je te suggère de mettre T1 et T2 sur deux tablespace distincts, ça évitera la fragmentation des données (données de T1 perdues au milieu de celles de T2).
Chaîne 2 : Un ou plusieurs tablespace contenant les index des tables importées. Ainsi, ça permettra au serveur de mettre à jour les index pendant l'import, sans ralentir l'import des données elles-mêmes.
 
Ensuite, autre point TRES important (plus que tout le reste à mon sens) : quel est le moyen utilisé pour l'import ? Si ce n'est pas SQL Loader, je te conseille TRES VIVEMENT de voir si tu peux adapter la procédure d'import pour passer par lui. C'est ce qu'il y a de plus rapide, et c'est pas de l'optimisation à deux sous, la différence est plus que flagrande.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed