Il mio nuovo linguaggio parlante Oracle DBA ha senso

Quando installiamo LUN FC per i nostri box MSSQL raramente dobbiamo presentarli con più di circa 8 LUN distinti di vari tipi (Quorum, MSDTC, TempDB, Dati, Log, Backup e pochi altri).

Abbiamo un nuovo DBA Oracle e mi ha fornito un elenco di LUN che desidera per il suo primo nuovo server: ce ne sono 38! e questo è per un box DB davvero semplice, con un solo DB. Sono tutti LUN abbastanza piccoli (100 GB) e si collegano chiaramente usando ASM in un modo di tipo LVM.

È il modo migliore per farlo, non sono davvero un esperto Oracle ma mi sembra troppo complesso, quali sono i tuoi pensieri e le tue esperienze in merito?

Sono un Oracle DBA. Il tuo nuovo DBA si comporta come un sacco di DBA Oracle e oltre l'ingegneria.

1. NESSUN oracolo NON ha bisogno di 38 LUN. Ho distribuito file di dati su un gran numero di lun ma questi sono su sistemi MOLTO attivi e MOLTO grandi. I LUN non sono necessari per il mapping a nuovi gruppi RAID, giusto? Quindi avere file su lance separate non è necessario spargere nulla comunque (non sono un esperto in questo).

2. Tutto questo tipo di striping dei file farà altro che rendere molto più lavoro per il DBA. Ciò aumenta la sua importanza per la squadra. Molti DBA Oracle cercano di farsi sembrare più importanti e di progettare cose IN continuazione.

3. Separare i dati verso gruppi / LUN di raid differnet non è specifico dell'oracolo. Si basa sull'utilizzo. Per distribuire correttamente i file, il DBA dovrebbe comprendere l'applicazione per sapere a cosa si accede molto (a proposito, separare gli indici dai dati NON migliora le prestazioni poiché l'accesso è seriale ...). Conosce l'applicazione? Ha esaminato il database per vedere a quali oggetti si accede molto? Cosa deve essere sparso? Cosa scrive e legge alla rinfusa e deve essere isolato.

Sembra un database di piccole / medie dimensioni. Qual è il livello di attività? Probabilmente non lo sa.

Generalmente su database più piccoli non è necessario fare molto a livello di file system per migliorare le prestazioni. Il 95% è SQL e gli sviluppatori eseguono troppe istruzioni sql in loop.

modifica ( anni dopo !):

Ho trascorso un po 'di tempo a parlare con gli ingegneri SAN e ho migliorato la mia conoscenza di SAN e LUN da quando ho pubblicato questo. Prima di tutto un LUN è "logico". Non è necessario mappare per separare gruppi RAID, dischi, ecc ... Questo è impostato dall'ingegnere SAN e non sarà visibile al DBA. C'è molto di più nel separare IO in una SAN che la maggior parte delle persone capisce.

Sto lavorando su un sistema molto grande con un livello di attività molto elevato. Abbiamo centinaia di LUN, gruppi RAID, ecc ... diffondiamo file ovunque. Collaboriamo con gli ingegneri della SAN per configurare i LUN per assicurarci che siano distribuiti in diverse parti della SAN. Non abbiamo davvero alcuna visibilità su come i LUN sono mappati dal livello del sistema operativo. Un nuovo file system non significa che abbiamo mappato i dati in una nuova posizione sulla SAN.

Per quanto riguarda la carta HP sullo striping di ASM. Questo è totalmente insignificante quando si lavora con una SAN. Lo striping, il mirroring, il RAID, ecc ... sono tutti eseguiti sotto la superficie. Non lo vedrai a livello di applicazione o di database. La configurazione di Oracle ASM per lo "striping" non ha senso in una SAN, poiché sarà sufficiente eseguire lo striping su volumi logici che potrebbero utilizzare una configurazione RAID 5 (la maggior parte a causa dei costi di controllo. Le SAN sono investimenti multi-milioni di dollari). Vedrai solo i file system. Questi non sono necessariamente associati a diversi dischi o posizioni diverse nella SAN.

Apparentemente IBM ha una nuova funzionalità che consente alla SAN di decidere dove scrivere sui dischi in base all'attività. Il mio punto qui è che le persone che ottimizzano le SAN sono specialisti. Devi lavorare con loro. Un DBA o uno sviluppatore di applicazioni non avranno visibilità per vedere se qualcosa si sta diffondendo.

Da quello che ho visto la maggior parte dei negozi non ha ingegneri SAN molto bravi. Tende ad essere un lavoro per persone di livello junior. La maggior parte dei buoni tende ad essere consulente. Quindi molte volte stai solo usando l'impostazione predefinita del produttore. Ribadire l'aggiunta di più LUN probabilmente non diffonderà alcun dato, a meno che tu non abbia un ingegnere SAN configurato per te sotto la superficie. Inoltre, puoi avere 1 LUN e distribuirlo per te. A meno che tu non abbia un buon ingegnere SAN, tutta questa roba non ha senso. È ovvio per me che il DBA in questione non conosce abbastanza delle SAN per sapere che non sa nulla.

Il 99,9% delle configurazioni standard temporali va bene. A meno che tu non abbia un collo di bottiglia di I / O specifico, ciò non è necessario. In tal caso, è necessario collaborare con l'ingegnere SA e SAN per determinare qual è il problema. Molte volte non ha nulla a che fare con il layout della SAN. Ancora una volta, i DBA e gli sviluppatori non avranno accesso a vedere cosa sta succedendo sotto per non parlare delle conoscenze per capirlo. Le SAN sono molto complesse.

Puoi provare a colpirlo sopra la testa con QUESTO , descrivendo l'approccio SAME (Stripe And Mirror Everything), che è piacevolmente semplice.

Non ho una risposta diretta perché utilizziamo MSSQL e mySQL. Ma ogni volta che il mio DBA chiede qualcosa che sembra folle ... così. Gli chiedo di documentare perché ogni pezzo è richiesto. Questo serve a due scopi, una volta molte volte all'improvviso cambiano idea in qualcosa di più sano e due mi permette di vedere il loro processo di pensiero in modo da poter applicare una logica di sistema a ciò che vogliono e presentare un'alternativa che non è così fuori di testa . Quindi, in questo caso, chiederei un documento che giustifichi la necessità di ciascuna delle 38 LUN

Ci sono studi che dimostrano che lo striping in ASM e a livello hardware può essere un vantaggio per le prestazioni. White paper HP-Oracle Questi miglioramenti delle prestazioni si riscontrano soprattutto in situazioni di elevata concorrenza che non sembra che ci si aspetti. Ma potrebbe essere quello a cui è abituato il tuo DBA.

So che per DB2 su AIX, i nostri DBA ottengono 5 volumi per database, ognuno per una parte diversa del DB. Uno per il DB, uno per il registro principale, uno per il registro di archivio, un temp e qualcos'altro. Questi sono volumi, non devono essere LUN, dipende da come ti piace gestire la tua memoria.