É meu novo senso de fala do Oracle DBA

Quando configuramos LUNs FC para nossas caixas MSSQL, raramente precisamos apresentá-los com mais de 8 LUNs distintos de vários tipos (Quorum, MSDTC, TempDB, Dados, Logs, Backup e alguns outros).

Temos um novo DBA Oracle e ele me deu uma lista de LUNs que deseja para seu primeiro novo servidor - há 38 deles! e isso é para uma caixa de banco de dados realmente básica, com apenas um único banco de dados. Eles são todos LUNs relativamente pequenos (100 GB) e se unem claramente usando o ASM de uma maneira do tipo LVM.

É a melhor maneira de fazer isso, eu realmente não sou especialista em Oracle, mas parece complexo demais para mim, quais são seus pensamentos e experiências sobre esse assunto?

Eu sou um DBA Oracle. Seu novo DBA está agindo como muitos DBAs da Oracle e com mais de engenharia.

1. NENHUM oracle NÃO precisa de 38 LUNs. Eu espalhei arquivos de dados em um grande número de lun's, mas eles estão em sistemas MUITO ativos e MUITO grandes. Os LUNs não são mapeados para novos grupos de RAID, certo? Portanto, ter arquivos em luns separados não é necessário espalhar nada de qualquer maneira (não sou especialista nisso).

2. Todo esse tipo de distribuição de arquivos fará mais trabalho para o DBA. Isso aumenta sua importância para a equipe. Muitos DBAs da Oracle tentam fazer com que pareçam mais importantes e projetam demais as coisas o tempo todo.

3. Separar dados para diferentes grupos / ataques de raides não é específico da Oracle. É baseado no uso. Para distribuir corretamente os arquivos, seu DBA precisaria entender o aplicativo para saber o que está sendo acessado muito (btw, separar índices de dados NÃO melhora o desempenho, pois o acesso é serial ...). Ele conhece o aplicativo? Ele olhou para o banco de dados para ver quais objetos estão sendo acessados ​​muito? O que precisa ser espalhado? O que grava e lê em massa e precisa ser isolado.

Isso soa como um banco de dados de tamanho pequeno / médio. Qual é o nível de atividade? Ele provavelmente não sabe.

Geralmente em bancos de dados menores, você não precisa fazer muito no nível do sistema de arquivos para melhorar o desempenho. 95% é SQL e os desenvolvedores executam muitas instruções sql em loops.

editar ( anos depois !):

Passei algum tempo conversando com os engenheiros da SAN e aprimorei um pouco meu conhecimento sobre SANs e LUNs desde a publicação. Primeiro, um LUN é 'lógico'. Não é necessário mapear para separar grupos RAID, discos, etc ... Isso é configurado pelo engenheiro da SAN e não será visível para o DBA. Há muito mais para separar as E / S em uma SAN que a maioria das pessoas percebe.

Estou trabalhando em sistemas muito grandes que possuem um nível de atividade muito alto. Temos centenas de LUNs, grupos RAID, etc ... espalhamos arquivos por todo o lugar. Trabalhamos com os engenheiros da SAN para configurar LUNs para garantir que eles sejam distribuídos para diferentes partes da SAN. Realmente não temos visibilidade de como os LUNs são mapeados no nível do SO. Um novo sistema de arquivos não significa que temos dados mapeados para um novo local na SAN.

Tanto quanto o papel da HP sobre striping ASM. Isso é totalmente sem sentido ao trabalhar com uma SAN. A distribuição, o espelhamento, o RAID, etc ... são todos feitos sob a superfície. Você não o verá no nível do aplicativo ou do banco de dados. A configuração do Oracle ASM para 'distribuição' não faz sentido em uma SAN, porque você apenas distribuirá volumes lógicos que poderiam estar usando uma configuração RAID 5 (grande maioria devido aos custos de controle. SANs são investimentos de vários milhões de dólares). Você verá apenas sistemas de arquivos. Esses não são necessariamente mapeados para diferentes discos ou locais diferentes na SAN.

A IBM aparentemente possui um novo recurso que permite à SAN decidir onde gravar em discos com base na atividade. Meu argumento aqui é que as pessoas que otimizam SANs são especialistas. Você precisa trabalhar com eles. Um DBA ou um desenvolvedor de aplicativos não terá visibilidade para ver se algo está sendo espalhado.

Pelo que vi, a maioria das lojas não tem muito bons engenheiros de SAN. Tende a ser um trabalho para pessoas de nível júnior. A maioria dos bons costuma ser consultores. Por isso, na maioria das vezes, você está apenas usando a configuração padrão do fabricante. Reiterar a adição de mais LUNs provavelmente não distribuirá nenhum dado, a menos que você tenha um engenheiro de SAN configurando-o para você sob a superfície. Além disso, você pode ter 1 LUN e distribuí-lo para você. A menos que você tenha um bom engenheiro de SAN, tudo isso não faz sentido. É óbvio para mim que o DBA em questão não conhece o suficiente sobre SANs para saber que ele não sabe de nada.

99,9% das configurações padrão do tempo são perfeitas. A menos que você tenha um gargalo de E / S específico, isso é desnecessário. Se você o fizer, precisará trabalhar com o engenheiro da SA e SAN para determinar qual é o problema. Muitas vezes, nada tem a ver com o layout da SAN. Novamente, os DBAs e os desenvolvedores não terão acesso para ver o que está acontecendo, muito menos o conhecimento para descobrir isso. SANs são muito complexas.

Você pode tentar dar um tapa na cabeça dele com ISTO , descrevendo a abordagem MESMO (Stripe e espelhar tudo), que é simples e agradável.

Não tenho uma resposta direta porque usamos o MSSQL e o mySQL. Mas sempre que meu DBA pede algo que soa maluco ... assim. Exijo que ele documente por que cada peça é necessária. Isso serve a dois propósitos, muitas vezes, de repente eles mudam de idéia para algo mais sensato e dois me permitem ver seu processo de pensamento, para que eu possa aplicar alguma lógica de sistema ao que eles desejam e apresentar uma alternativa que não está tão fora de controle. . Portanto, nesse caso, eu pediria um documento justificando a necessidade de cada um dos 38 LUNs

Existem estudos que mostram que a distribuição no ASM e no nível do hardware pode ser uma vantagem para o desempenho. Whitepaper HP-Oracle Esses ganhos de desempenho são vistos principalmente em situações de alta simultaneidade, que não parecem o esperado. Mas pode ser o que seu DBA está acostumado.

Eu sei que, para o DB2 no AIX, nossos DBAs recebem 5 volumes por banco de dados - cada um para uma parte diferente do banco de dados. Um para o banco de dados, um para o log principal, um para o log de archive, um temp e outra coisa. Esses são volumes, eles não precisam ser LUNs, depende de como você gosta de gerenciar seu armazenamento.