SSD avec Oracle

19

Nous avons cherché à utiliser des disques SSD avec Oracle pour accélérer nos cycles de migration de test. Il faut actuellement 12 à 18 heures pour terminer une migration, en fonction du volume de données (nous faisons évidemment aussi beaucoup de réglages des performances). Nous avons un certain nombre de boîtiers Linux bon marché que nous utilisons pour diverses analyses et analyses.

Le coût des SSD directement de Dell est prohibitif. Je me demandais si quelqu'un avait de l'expérience dans l'utilisation des SSD grand public (tels que les Crucial / Micron).

Je me rends compte que le support TRIM serait un problème sous Linux (en utilisant Centos). Quelqu'un les a-t-il utilisés sur Windows 7 pour contrer cela?

oracle performance

— Stuart Brock
source

1

Nous avons fini par ajouter des disques SSD pour les index et les espaces disque logiques et en les répartissant entre eux. Nous n'avons pas obtenu le grand saut de vitesse que nous espérions. Plus comme 10 à 15% plus rapide pour nos migrations, mais en l'absence d'autres options, c'était un bon gain de temps (notre expert en tuning Oracle avait déjà été lâché sur la base de données). Merci pour tous vos commentaires. Nous sommes allés avec des SSD Crucial qui offraient de très bonnes performances pour un bon prix et qui n'avaient toujours eu aucun problème. Nous avons également accepté qu'ils s'usent et gardons un œil sur eux (et de nombreuses sauvegardes)! Merci pour tous vos commentaires. Stuart.

— Stuart Brock

6

Voici le plus gros problème que je vois avec les SSD et les bases de données:

Échec du SSD
- Cela arrive plus souvent que je ne le souhaiterais; souvent dans un délai d'un à deux ans avec une utilisation normale, et plus rapide en cas de lecture / écriture intensive. Que se passe-t-il lorsque vous envoyez vos fichiers de rétablissement, journaux et données à un SSD? Beaucoup de lectures et beaucoup d'écritures. Mauvaise combinaison, OMI.
SSD "tout faire"
- Les SSD sont agréables en termes de vitesse de lecture, oui. Ils sont parfaits pour démarrer à partir d'un système d'exploitation ou pour démarrer des programmes. Mais il ne faut pas permettre aux SSD de devenir un correctif pour une optimisation complète. Je suis sûr que vous ne l'êtes pas, car vous essayez probablement tout ce que vous pouvez pour accélérer la migration, mais parfois les SSD peuvent sembler un Saint Graal pour éviter certains des problèmes les plus difficiles en matière d'optimisation. (À bien des égards, la même chose peut être dite au sujet de jeter plus de matériel ou de mémoire à un problème. Parfois, il est préférable d'optimiser le problème plutôt que de jeter plus de matériel.)
Inadéquation R / W
- Les lectures sont extrêmement rapides.
- Les écritures ne sont pas aussi rapides que les lectures (mais généralement meilleures que les disques durs)
  http://en.wikipedia.org/wiki/Solid-state_drive
- En tant que tels, les SSD n'ont vraiment de sens que pour les supports de démarrage (comme le système d'exploitation, les exécutables db, etc.)
Nivellement d'usure et sécurité
- Si la sécurité est un sujet de préoccupation, le niveau d'usure de votre SSD va rendre presque impossible d'essuyer le disque et être certain qu'il a été remis à zéro. Deux, trois et plus de passes ne le feront même pas, et il y aura toujours une chance qu'une partie de vos données soit toujours disponible.

— Kerri Shotts
source

Avez-vous toujours la même opinion en 2019?

— TrojanName

7

Je ne vois pas encore de réponses à votre question, et même si je n'ai aucune expérience de l'utilisation de disques SSD grand public avec une base de données, j'ai pensé que la question suivante sur ServerFault pourrait être utile:

/server/69037/configuring-sql-for-optimal-performance-ssd-or-hdd

edit: J'ai trouvé l'article suivant récemment et j'ai pensé l'ajouter à ma réponse. Il parle de l'utilisation de SSD avec SQL Server, mais j'ai pensé que certains des facteurs discutés pourraient également être utiles pour les DBA Oracle.

http://technet.microsoft.com/en-us/magazine/hh334997.aspx (réduction des E / S, augmentation des performances)

— Jeff
source

5

Les disques SSD peuvent accélérer la lecture des données.

L'écriture ne sera pas plus rapide. Ne pensez même pas à placer les répétitions sur SSD car elles ne sont écrites que sur. Pour accélérer l'écriture dans le rétablissement: ajoutez plus de lecteurs et agrégez-les. Les répétitions sont écrites séquentiellement, l'ajout de plusieurs broches améliore le débit d'écriture jusqu'à ce que vous atteigniez la limite du contrôleur.

Que fait cette migration de test? Utilise-t-il du code procédural ou utilise-t-il des ensembles?

Si vous utilisez du code procédural, assurez-vous d'implémenter des opérations en bloc. Les ensembles sont presque toujours plus rapides.

— ik_zelf
source

1

Avez-vous une source pour un benchmark montrant une vitesse d'écriture inférieure sur les SSD, en particulier avec la même quantité de striping? Ma compréhension était que les SSD sont également plus rapides en écriture, mais la différence n'est pas aussi dramatique que pour les lectures.

— Leigh Riffel

@Leigh - C'est vrai, mais le vrai point est que l'avantage est considérablement plus grand pour le io aléatoire que pour le séquentiel . Je pense qu'il est juste de dire que les SSD ne sont encore que pour les besoins élevés d'iops aléatoires.

— Jack Douglas

1

Nous avons fait quelques tests avec les cartes f5100 sur un système M5000 où nous avons essayé d'utiliser les disques flash comme cache secondaire pour zfs, dédié aux fichiers et sga étendu. La lecture était rapide, l'écriture lente, par rapport à ce que nous avons fait avec le SAN. (une boîte EMC). Comme indiqué, les journaux sont écrits séquentiellement. Les disques sont conçus pour ce type d'io, lorsqu'ils sont rayés.

— ik_zelf

2

J'ai échangé mon ancien disque dur contre un SSD Crucial M4 512 Mo pour effectuer un test sur une grande base de données Oracle.

J'exécute oracle 10.2 sous Windows 7 dans VMWare.

Les changements de performances sont vraiment impressionnants. L'importation et l'exportation de bases de données et de requêtes SQL sont beaucoup plus rapides.

Cependant, j'ai une étrange erreur qui apparaît de temps en temps:

ERREUR 2012-06-18 18: 18: 14,177: Erreur lors de l'exécution de la requête
java.sql.SQLException: ORA-01578: Bloc de données ORACLE corrompu (fichier # 6, bloc # 1646317)
ORA-01110: fichier de données 6: 'C: \ ORACLE \ PRODUCT \ 10.2.0 \ ORADATA \ DUNE \ WEBDATA02.DBF '

Je n'ai jamais eu ce problème avec la même VM sur la même machine avec le disque dur.

Après avoir exécuté DBV sur le fichier, rien n'est marqué comme corrompu.

Je n'ai rien trouvé sur ce problème.

— svett
source

Je ne reconnais pas cette erreur mais j'ai oublié de mentionner que les importations ont été massivement accélérées par les SSD. Ce ne sont que les cycles de migration qui n'ont augmenté que de 10 à 15% en vitesse. Merci pour ça.

— Stuart Brock