RAID (Redundant Arrays of Inexpensive Disks) vem com diferentes configurações (RAID-0, RAID-1...). Qual é a configuração RAID recomendada que devo configurar e usar ao instalar um banco de dados Oracle. O banco de dados será usado principalmente como um data warehouse.
relate perguntas
-
Backups de banco de dados no Oracle - Exportar o banco de dados ou usar outras ferramentas?
-
ORDER BY usando prioridades personalizadas para colunas de texto
-
Interface sqlplus confortável? [fechado]
-
Como encontrar as instruções SQL mais recentes no banco de dados?
-
Como posso consultar nomes usando expressões regulares?
Depende. Ao analisar um data warehouse, se você não tiver um design específico em mente, o gerenciamento automático de armazenamento pode ser um excelente caminho.
Considere a discussão no AskTom , OTN Forums , OTN Forums 2 e OTN Forums 3 .
Não existe uma maneira certa de lidar com as coisas, e as respostas mudam com base em uma série de fatores de hardware e rede. Para descobrir por si mesmo, pré-carregue um data warehouse de amostra (apenas um show ou dois, o suficiente para brincar) em uma máquina baseada em ASM, em uma SAN com o Raid sendo virtualizado pelo linux e em uma máquina de raid baseada em hardware.
Ao cronometrar os resultados das consultas em todos os três ambientes, você poderá descobrir qual metodologia funciona melhor para você em termos de desempenho. Implantei bancos de dados usando ataques virtuais baseados em ASN e Linux, e um ataque virtual se comportou um pouco melhor (alguns anos atrás). No entanto, suspeito que foi em parte como as unidades foram configuradas.
Não existe uma única resposta certa. Se você puder nos fornecer mais detalhes sobre os requisitos de tamanho e desempenho, talvez seja possível explorar vários casos de teste.
--Editar--
Cada " grupo de discos " pode ser composto por um ou mais discos, diretórios ou arquivos no subsistema apropriado. A Oracle recomenda "Para melhor desempenho e confiabilidade, escolha um dispositivo RAID ou um volume lógico em mais de um dispositivo físico e implemente a metodologia de distribuição e espelhamento (SAME)". ao colocar arquivos em um sistema de arquivos. Isso é como se a oracle estivesse recomendando RAID 1 + 0.
Grupos de discos gerenciados por ASM, no entanto, "Um grupo de discos de redundância normal requer um mínimo de dois grupos de falhas (ou dois dispositivos de disco) se você estiver usando espelhamento bidirecional. O espaço em disco efetivo em um grupo de discos de redundância normal é metade da soma de o espaço em disco em todos os seus dispositivos" aparentemente fornecem espelhamento automaticamente.
Esses próprios dispositivos podem ser compostos por dispositivos RAID e assim por diante. Em testes práticos quando eu estava configurando data warehouses RAID, um simples RAID 5 virtual no sistema de arquivos forneceu um desempenho aceitável, e o ASM adicional não trouxe benefícios de desempenho. Nesse tipo de tarefa de otimização, primeiro identifique seus recursos e, em seguida, teste todas as configurações possíveis, pois às vezes os resultados podem ser extremamente contra-intuitivos.
Se você tiver duas unidades físicas:
RAID0: Rápido, mas sem redundância. Qualquer erro de unidade matará toda a matriz. Algumas pessoas colocam armazenamento temporário em RAID0 (ou seja, tempdb no MSSQL), mas eu ainda consideraria isso perigoso, pois você não perderá nenhum dado significativo se o array cair, você terá uma interrupção do servidor até que a situação seja reparada.
RAID1: Vá para isso se você tiver duas unidades. Não há benefício no desempenho de gravação, embora você possa ver um aumento no desempenho de leitura com um bom controlador. O principal recurso do RAID1 é sobreviver a uma das unidades morrendo.
Se você tiver três unidades físicas:
Suas opções são RAID5, o RAID10 de 3 unidades não padrão (ou RAID1E como os controladores IBM se referem a ele) se suportado. É claro que você pode usar o RAID1 e manter a unidade extra como reserva para quando uma das outras falhar, mas você deve manter as peças sobressalentes em um ambiente de missão crítica de qualquer maneira, portanto, isso é óbvio.
O RAID5 oferece mais espaço que o RAID10 (duas unidades em vez de uma e meia), mas tem um potencial problema de desempenho de gravação, pois para cada bloco gravado, o controlador precisa ler o bloco de paridade, atualizá-lo e escrevê-lo novamente. Esse problema de desempenho de gravação pode ser duplicado para gravações de banco de dados, pois há pelo menos duas gravações para cada atualização: uma no log de transações e outra nas áreas de dados reais. Como o espaço é barato hoje em dia, eu recomendaria o RAID10 de 3 unidades se suportado para um melhor desempenho de gravação. O software RAID do Linux oferece isso, assim como muitos controladores IBM (eles chamam de RAID1E). Você pode encontrá-lo com outros nomes também, pois não é considerado um arranjo padrão, portanto, não possui um nome padrão.
Tanto o R5 quanto o R10-over-three fornecem a mesma redundância (qualquer unidade pode falhar de cada vez e a matriz sobreviverá) e métricas de desempenho de leitura semelhantes (semelhante a uma matriz RAID0 de duas unidades).
Se você tiver quatro unidades físicas:
Se estiver criando apenas uma matriz, existem duas opções (ignorando as variações "com hot spare"): RAID6 e RAID10 "tradicional" (um RAID0 de RAID1s).
Ambos dão o mesmo espaço (duas unidades das suas quatro). RAID6 oferece melhor redundância, pois quaisquer duas unidades podem falhar ao mesmo tempo, enquanto RAID10 só pode sobreviver a quatro das seis situações possíveis de duas unidades perdidas. Ambos oferecem desempenho de leitura semelhante, mas o RAID6 tem um problema de desempenho de gravação semelhante ao do RAID5 (o mesmo em um bom controlador, embora possa ser mais lento que o RAID5 em um controlador ruim ou com RAID de software, dependendo do sistema operacional e dos recursos de controle de E/S. RAID10 é geralmente preferido para bancos de dados por motivos de desempenho - se você precisar de redundância extra, poderá usar seis unidades e ter um RAID0 ou 2 RAID1s de 3 unidades.
Depois de ter quatro ou mais unidades, as coisas ficam mais interessantes, pois você pode ter um par separado de matrizes RAID1. Isso pode oferecer benefícios significativos de desempenho com discos giratórios, mantendo seus armazenamentos de dados em um array e os logs de transações em outro - isso pode reduzir consideravelmente os movimentos da cabeça em alguns casos e os tempos de busca devido ao acesso "aleatório" são um verdadeiro assassino de desempenho. Para um data warehouse, supondo que isso signifique que ele verá muito poucas gravações relativamente falando, dividir os logs de transações de arquivos de dados pode ter um benefício mais limitado, mas você ainda pode considerar vários arrays e, em vez disso, particionar seus dados sobre eles para um desempenho de leitura potencialmente melhor .
Se você tiver mais de quatro unidades:
Suas opções ficam abertas aqui e isso realmente depende de quais são seus dados e quais são suas cargas/padrões de atualização/leitura esperados. Por exemplo, uma vez que nossos serviços são executados em unidades de 12 ~ 70 Gb:
Tempdb é mantido na matriz do sistema. Poderíamos movê-lo para as outras duas matrizes e apenas executar a matriz do sistema como 2 unidades em RAID1, pois a velocidade extra não é muito necessária para os pedaços do sistema (já que isso só é realmente significativo durante a inicialização ou durante a troca e garantimos que há RAM suficiente para nunca precisar trocar), mas com a forma como pagamos ao provedor de hospedagem por esse conjunto de máquinas, não nos custaria menos descartar as duas unidades. Os backups também vão para o array do sistema, antes de serem copiados para os locais de backup off-server, off-site e off-line.
É claro que isso é um exagero para alguns bancos de dados (não faria sentido executar um pequeno servidor de blog dessa maneira!), mas nosso aplicativo principal funciona muito bem com esse arranjo.
Se você tiver seis unidades, considere três matrizes RAID1 ou duas matrizes RAID10 de três unidades.
Geralmente
Infelizmente, não existe uma "melhor prática" simples e real, pois depende muito do tamanho do seu sistema e dos padrões de uso. As únicas regras gerais que consigo pensar ou são:
Hardware ou Software RAID?
Antigamente, o desempenho do RAID de software era inferior ao do RAID de hardware para RAID 5 devido aos cálculos de paridade e para todos os arranjos devido às interfaces lentas entre as unidades e a CPU. Com CPUs modernas, o problema de cálculo de paridade não é realmente um problema, mas se você tiver unidades muito rápidas, o RAID de hardware ainda pode vencer se a velocidade total das unidades puder chegar a qualquer lugarpróximo (dentro de uma ordem de magnitude, em um palpite) de quão rápido a máquina pode se comunicar com o controlador de disco. Se você tiver uma matriz RAID1 de quatro unidades (ou seja, quatro cópias dos mesmos dados para muita redundância) com RAID de software, cada operação de gravação resultará no envio de quatro lotes de dados para o controlador de E/S, possivelmente sequencialmente - com um hardware controlador o SO envia apenas uma solicitação de gravação e o controlador envia isso para as quatro unidades, provavelmente em paralelo.
Um bom RAID de hardware também pode oferecer outras vantagens: alguns controladores de alta especificação têm cache de gravação com backup de bateria para que as gravações pendentes não sejam perdidas em um corte de energia, mesmo que seu no-break falhe, por exemplo.
O RAID de software é obviamente mais barato e mais portátil, então você não está vinculado a um controlador específico se precisar mover os arrays devido a uma falha do controlador/máquina.
O RAID de hardware barato geralmente combina os negativos do RAID de software e hardware com poucos (ou nenhum) dos benefícios de ambos, portanto, é melhor evitar.
Costumo usar RAID de software em nossos servidores de desenvolvimento, teste e UAT e um bom RAID de hardware para servidores que executam serviços ao vivo voltados para o cliente/público.
Em alguns casos, JBOD é a resposta correta (ou seja, não RAID).
O problema é que, se você tiver grupos RAID muito grandes, não terá a flexibilidade de especificar como o armazenamento físico é disposto no banco de dados, como garantir que os índices e registros de uma tabela sejam armazenados em eixos separados, e certificando-se de que você está equilibrando as gravações em todos os seus discos.
Você pode usar striping (RAID0) para equilibrar as gravações, mas se for tudo um grande grupo, você não poderá separar os índices versus os registros.
O espelhamento (RAID1) é tolerante a falhas e é mais rápido para leituras (já que você pode ler de qualquer eixo que não esteja ocupado), mas pode ser mais lento para gravações, pois você precisa esperar que ambas as cópias sejam gravadas.
Eu nunca iria RAID5 ou RAID6 em um banco de dados. Se os dados forem importantes, compre mais discos e vá com RAID1; RAID5/6 é lento (especialmente em software), e com os tamanhos de disco rígido de hoje pode levar dias para reconstruir após a substituição de discos com falha por um grande grupo de discos ... apenas recalcular a paridade ... mas as probabilidades são, a falha está nos dados, não na paridade, mas você não tem idéia de onde estava a falha. (infelizmente, não acho que exista algo como LOCKSS para bancos de dados)
...
O layout mais interessante que eu vi no banco de dados envolveu ter duas partições por eixo - a parte mais interna do disco foi usada para o banco de dados de produção, as seções superiores do disco foram usadas para backups. (e eles garantiram que uma partição não tivesse backup no mesmo eixo; acho que havia vários bancos de dados, então cada um fez backup nos discos de um diferente). Isso lhes dava a vantagem de espalhar as coisas por mais fusos durante o dia de trabalho e, à noite, eles executavam backups.
Suponho que haveria uma recuperação mais lenta se algo desse errado e você precisasse restaurar, pois haveria algumas leituras do disco externo acontecendo enquanto os bancos de dados estivessem em uso durante o dia, mas sempre há compensações em tudo.
...
Então, de qualquer forma, o ponto que estou tentando fazer - não há uma resposta que se encaixe em todas as situações. Se houvesse, os DBAs ficariam sem empregos e as empresas comprariam dispositivos de banco de dados pré-construídos.
Os bancos de dados com os quais eu lido são o que meu chefe chama de 'WORN': Write Once, Read Never; ele está brincando, mas "data warehouse" pode significar qualquer nível de atividade ... eu vi alguns que foram carregados de fitas todas as noites/semanais (e eram apenas cópias da instância OLTP, e nos ajudaram a verificar se as fitas eram boas) e trabalhos de análise massivos foram executados neles e outros em que há um fluxo constante de entrada e leituras ocasionais, mas nenhuma competição real por recursos.
O " Oracle Database Performance Tuning Guide " tem um capítulo dedicado à configuração de E/S . Resumidamente:
Minha recomendação para servidores é sempre RAID 5 . O tempo e o esforço gastos para recuperar seu primeiro disco rígido com falha sempre serão memoráveis. Se você configurar matrizes RAID, recomendo fortemente que padronize em um único tamanho de unidade e armazene 2 discos rígidos sobressalentes na sala do servidor. Uma unidade vai mal? Coloque uma das substituições (e deixe a matriz reconstruir). Eu vi matrizes RAID falharem porque uma segunda unidade ficou ruim enquanto esperavam a chegada da primeira (a entrega no dia seguinte ainda estava muito atrasada).
Quantos dados você planeja usar e com que frequência você lerá ou gravará no sistema? Há muito planejamento envolvido nisso, o suficiente para que algumas pessoas dediquem toda uma carreira acadêmica ao assunto.
Normalmente, eu diria para você ir para a Wikipedia e ler o artigo antes de continuar, pois existem alguns tipos de RAID e cada um é melhor usado em um lugar diferente.
O básico fica assim:
RAID0
Bom para jogadores de vídeo. Ruim para qualquer outra pessoa. Não seria ruim usar isso para um servidor de cache que não precisa manter os dados por nenhum período de tempo. Quando um disco falha, o sistema fica inativo. Fim de jogo.
RAID1
Ótimo para confiabilidade. Sem muita expansibilidade. Muito bom em velocidade.
RAID5
A mistura preferida entre RAID0 e RAID1 (mais ou menos).
Agora, depois disso, realmente se torna quase algo que deve ser perguntado no ServerFault devido ao fato de que é mais a configuração do servidor do que o design do banco de dados. Sempre discuta o desempenho do servidor com o administrador do servidor. É para isso que eles estão lá. Se este não fosse um beta privado, eu votaria para fechar para migrar você para lá.