Est-ce que mon nouveau sens Oracle DBA parle

Lorsque nous configurons des LUN FC pour nos boîtiers MSSQL, nous devons rarement leur présenter plus de 8 LUN différents de différents types (Quorum, MSDTC, TempDB, Data, Logs, Backup et quelques autres).

Nous avons un nouveau DBA Oracle, et il m'a donné une liste des LUN qu'il veut pour son premier nouveau serveur - il y en a 38! et c'est pour une boîte DB vraiment basique, avec seulement une seule DB. Ce sont tous des LUN assez petits (100 Go) et ils se fixent clairement ensemble en utilisant ASM de manière LVM.

Est-ce la meilleure façon de le faire, je ne suis vraiment pas un expert Oracle mais cela me semble trop complexe, quelles sont vos pensées et vos expériences à ce sujet?

Je suis un DBA Oracle. Votre nouveau DBA fonctionne comme beaucoup de DBA Oracle et plus d'ingénierie.

1. AUCUN oracle n'a pas besoin de 38 LUN. J'ai réparti des fichiers de données sur un grand nombre de lun's mais ce sont sur des systèmes qui sont TRÈS actifs et TRÈS volumineux. Les LUN ne sont pas nécessairement mappés vers de nouveaux groupes RAID, n'est-ce pas? Donc, avoir des fichiers sur des lunes séparées ne répartit pas nécessairement quoi que ce soit (je ne suis pas un expert en la matière).

2. Tout ce type de segmentation de fichiers permettra de faire beaucoup plus de travail pour le DBA. Cela augmente son importance pour l'équipe. Beaucoup d'administrateurs de bases de données Oracle essaient de se faire paraître plus importants et de trop ingénier les choses TOUT LE TEMPS.

3. La séparation des données vers différents groupes / luns de raid n'est pas spécifique à Oracle. Son basé sur l'utilisation. Afin de répartir correctement les fichiers, votre administrateur de base de données devrait comprendre l'application pour savoir à quoi on accède beaucoup (btw, la séparation des index des données n'améliore PAS les performances car l'accès est série ...). Connaît-il l'application? A-t-il regardé la base de données pour voir à quels objets on accède beaucoup? Que faut-il étaler? Qu'est-ce que l'écriture et la lecture en bloc doit être isolé.

Cela ressemble à une base de données de petite / moyenne taille. Quel est le niveau d'activité? Il ne sait probablement pas.

En règle générale, sur les petites bases de données, vous n'avez pas besoin de faire grand-chose au niveau du système de fichiers pour améliorer les performances. 95% est SQL et les développeurs exécutent-ils trop d'instructions sql en boucles.

modifier (des années plus tard !):

J'ai passé un certain temps à parler aux ingénieurs SAN et j'ai quelque peu amélioré ma connaissance des SAN et des LUN depuis la publication de cet article. Tout d'abord, un LUN est «logique». Il n'est pas nécessaire de mapper pour séparer les groupes RAID, les disques, etc ... Cela est configuré par l'ingénieur SAN et ne sera pas visible pour le DBA. Il y a beaucoup plus à séparer les E / S dans un SAN que la plupart des gens réalisent.

Je travaille sur un très gros système qui a un niveau d'activité très élevé. Nous avons des centaines de LUN, de groupes RAID, etc ... nous diffusons des fichiers partout. Nous travaillons avec les ingénieurs SAN pour configurer les LUN afin de nous assurer qu'elles sont réparties sur différentes parties du SAN. Nous n'avons vraiment AUCUNE visibilité sur la façon dont les LUN sont mappés à partir du niveau du système d'exploitation. Un nouveau système de fichiers ne signifie pas que nous avons des données mappées vers un nouvel emplacement sur le SAN.

En ce qui concerne le papier HP sur le striping ASM. Cela n'a aucun sens lorsque vous travaillez avec un SAN. L'entrelacement, la mise en miroir, le RAID, etc. sont tous effectués sous la surface. Vous ne le verrez pas au niveau de l'application ou de la base de données. La configuration d'Oracle ASM pour le `` striping '' n'a pas de sens dans un SAN, car vous allez simplement segmenter les volumes logiques qui pourraient utiliser une configuration RAID 5 (grande majorité en raison des coûts de contrôle. Les SAN sont des investissements de plusieurs millions de dollars). Vous verrez simplement les systèmes de fichiers. Ceux-ci ne sont pas nécessairement mappés vers différents disques ou différents emplacements dans le SAN.

IBM a apparemment une nouvelle fonctionnalité qui permet au SAN de décider où écrire sur les disques en fonction de l'activité. Mon point ici est que les personnes qui optimisent les SAN sont des spécialistes. Vous devez travailler avec eux. Un administrateur de base de données ou un développeur d'application n'aura pas de visibilité pour voir si quelque chose est en cours de diffusion.

D'après ce que j'ai vu, la plupart des magasins n'ont pas de très bons ingénieurs SAN. Cela a tendance à être un travail pour les jeunes. La plupart des bons sont généralement des consultants. Donc, la plupart du temps, vous utilisez simplement la configuration par défaut du fabricant. Pour réitérer l'ajout de plus d'unités logiques, il est probable que les données ne seront pas diffusées, sauf si un ingénieur SAN les configure pour vous sous la surface. En plus de cela, vous pouvez avoir 1 LUN et le répartir pour vous. Sauf si vous avez un bon ingénieur SAN, tout cela n'a pas de sens. Il est évident pour moi que le DBA en question n'en sait pas assez sur les SAN pour même savoir qu'il ne sait rien.

99,9% des configurations standard de temps sont très bien. Sauf si vous avez un goulot d'étranglement d'E / S spécifique, cela n'est pas nécessaire. Si vous le faites, vous devez alors travailler avec l'ingénieur SA et SAN pour déterminer le problème. Beaucoup de temps, cela n'a RIEN à voir avec la disposition du SAN. Encore une fois, les administrateurs de base de données et les développeurs n'auront pas accès à ce qui se passe en dessous et encore moins aux connaissances nécessaires pour comprendre cela. Les SAN sont très complexes.

Vous pouvez essayer de le frapper au-dessus de la tête avec CECI , décrivant l'approche SAME (Stripe And Mirror Everything), qui est d'une simplicité rafraîchissante.

Je n'ai pas de réponse directe car nous utilisons MSSQL et mySQL. Mais chaque fois que mon DBA demande quelque chose qui semble juste fou ... comme ça. Je lui demande de documenter pourquoi chaque pièce est requise. Cela sert à deux fins: une fois, ils changent soudainement d'avis pour quelque chose de plus sain d'esprit et deux me permettent de voir leur processus de réflexion afin que je puisse appliquer une logique de système à ce qu'ils veulent et présenter une alternative qui n'est pas si folle . Donc dans ce cas, je demanderais un document justifiant la nécessité de chacun des 38 LUN

Il existe des études qui montrent que l'entrelacement dans ASM et au niveau matériel peut être un avantage pour les performances. Livre blanc HP-Oracle Ces gains de performances sont principalement observés dans des situations de concurrence élevée auxquelles il ne semble pas que vous vous attendiez. Mais c'est peut-être à cela que votre DBA est habitué.

Je sais que pour DB2 sous AIX, nos DBA obtiennent 5 volumes par base de données - chacun pour une partie différente de la base de données. Un pour la base de données, un pour le journal principal, un pour le journal d'archivage, un temp et quelque chose d'autre. Ce sont des volumes, ils ne doivent pas nécessairement être des LUN, cela dépend de la façon dont vous aimez gérer votre stockage.