Oracle e MAA – Artigo I

Este artigo é o primeiro de uma série sobre Maximum Availability Architecture (MAA), com os passos, dicas e afins para configurar e manter um ambiente deste porte. No final da série teremos um ambiente com Oracle RAC tanto no primary quanto no standby. Ambos sincronizados com Data Guard (DG) rodando em alta disponibilidade.

Não é a intenção aqui mostrar com configurar um ambiente RAC, já partirei de um ambiente com o RAC instalado e um banco rodando. Utilizarei o Oracle 11GR2 versão 11.2.0.3, já que a intenção também é mostrar como atualizar um ambiente em DG. Além disso, tentarei cobrir alguns pontos como “real-time apply” e criação do banco standby usando Media Management Layer (MML).

Tentarei ser o mais didático e claro possível e caso tenha alguma dúvida, pergunte. Todos os comandos que executei estarão no artigo. Infelizmente este primeiro artigo será extenso (muito) e cheio de detalhes técnicos, não tem como montar um ambiente assim de forma rápida e sem os diversos detalhes envolvidos. Infelizmente não existe um guia rápido de 10 passos para MAA com RAC, isso não existe. Você verá aqui um guia detalhado do início ao fim sobre como configurar MAA com RAC em ambos os lados.

Provavelmente alguns passos utilizados aqui para a configuração do ambiente podem ser mais simples na prática. Espero no final cobrir boa parte de um ambiente DG e MAA: switchover, failover, reisntate, broker, observer e afins.

Uma configuração como esta seria a aplicada em um ambiente Exadata que necessita de alta disponibilidade. Você teria que configurar MAA com DG entre dois Exadatas, como é RAC seria um DG sobre RAC.

PRIMEIRO ARTIGO

Neste primeiro artigo iremos configurar um ambiente DG em dois sites, somente o banco será replicado. Neste artigo não iremos ver a configuração do Broker nem failover, switchover e reinstate; isso ficará para próximos artigos.

Continue lendo…

Role Separation e ORA-600 [kfdskAlloc0]

Um post rápido sobre um problema recorrente, mas que pode ajudar alguém. Como DBA você está preocupado em seguir as recomendações e melhores práticas e instala um banco de dados com “role separation”. Usuários separados, um para o Grid e um para o Oracle, mas no final das contas recebe um belo ORA-600.

No ambiente descrito aqui temos um banco de dados Oracle 11.2.0.4 instalado em um Oracle Enterprise Linux 6.5 x64 com usuários específicos para o Grid e outro para o Oracle. De qualquer forma esse erro também já ocorreu em um Exadata e em RAC, e já vi em outras versões.

Você segue o ritual e instala o Grid com sucesso, inicia a instância do ASM e instala o Oracle (com o usuário oracle). Mas ao tentar restaurar um backup ou chamar o “dbca” você recebe um “ORA-00600: internal error code, arguments: [kfdskAlloc0]”. Vou tentar exemplificar e mostrar a solução.

Continue lendo…

Exadata X4 – Parte II

O lançamento do Exadata X4 trouxe muitas mudanças, principalmente nos Storage Servers. Como disse no outro post as mudanças dos Storage Servers precisam ser detalhadas com mais cuidado, ler nas entre linhas e notas de rodapé. Infelizmente este é um artigo extenso e cheio de detalhes técnicos, mas garanto que a leitura vale o tempo investido.

Continue lendo…

Exadata X4 – Parte I

No final do ano passado a Oracle anunciou o Exadata X4, nada mais justo do que uma análise um pouco mais detalhada sobre ele. Sinceramente, acredito que esta tenha sido a maior mudança na família Exadata desde o lançamento da versão V2. As mudanças do X4 são significativas, coisas bem interessantes foram alteradas pela Oracle (alterações boas e más).

Continue lendo…

Matando Sessões KILLED

Algumas vezes sessões ficam “presas” no banco de dados com status KILLED. Elas estão/são mortas e mesmo assim não desaparecem da gv$session, ficam como “zumbis”. Algumas podem até impedir o shutdown do banco de dados. Aqui vamos ver como resolver isso.

Felizmente resolver este problema não é complicado, mas temos que verificar algumas coisas antes de sair matando os processos do Oracle. De forma resumida (e bem resumida) toda a conexão feita pelo usuário ao banco de dados cria um processo no servidor que fica responsável por fazer a comunicação com o kernel do banco de dados. Ao finalizarmos este processo a conexão do usuário é terminada e o Oracle libera a sessão do usuário.

Continue lendo…

Webinar Exadata SIG – Gerenciamento de Recursos

No dia 31/07/2013 apresentei o 2º Webinar do Exadata SIG, este sobre gerenciamento de recursos em um ambiente Oracle. O Webinar cobriu diversos assuntos, incluindo Resource Manager, IORM, Instance Caging e algumas dicas sobre o gerenciamento do Exadata.

A principal idéia que tentei passar no Webinar é que usando o Exadata podemos administrar e gerenciar todos os recursos do ambiente. Podemos gerenciar as conexões através do uso de services do Oracle RAC, número de CPU disponíveis através o instance caging, divisão do CPU através do Resource manager, e gerenciamento do IO através do IORM. O importante é a integração que o Exadta permite.

Claro que não é só o Exadata que pode tirar proveito destas funcionalidades, um Oracle em um ambiente tradicional também pode se beneficiar de algumas delas. A única restrição é em relação ao IORM. Caso você queira ler mais sobre o IORM pode ler alguns posts que fiz sobre ele aqui no site (aqui, aqui e aqui).

O link para download do Webninar é este (Webinar-Gerenciamento-de-Recursos) . Ele está em formato PDF, os arquivos externos que estão na apresentação estão aqui (Anexos-Webinar-Exadata) em formato ZIP.

Caso queira saber mais sobre o Exadata SIG, você pode visitar a página do GUOB e clicar na aba “GUOB Exadata SIG”.

Update VMware ESXi 5.x com vCLI

Como no post anterior, o VMware ESXi 5 também pode ser atualizado através do vCLI. Nesta versão alguns comandos mudaram, mas o conceito permanece o mesmo.

Para o ESXi 5.0 em diante a forma básica de aplicação de updates continua na mesma linha, por não estar utilizando o vCenter não temos a centralização na aplicação dos updates. Além disso, todas as máquinas virtuais hospedadas no servidor ainda precisam ser paradas para aplicar o update.

Continue lendo…

Update VMware ESXi 4.1 com vCLI

Não é só de banco de dados que vive um DBA, as vezes temos que dar manutenção em diversos ambientes. Temos que nos preocupar com updates do sistema operacional, placa de rede, Storage e afins.

Recentemente tive que fazer uma atualização de um servidor com VMware onde era utilizado o ESXi 4.1. Infelizmente por ser ESXi algumas funcionalidades interessantes não estavam habilitadas, uma delas era o vCenter para gerência dos updates de forma centralizada.

Assim, tive que aplicar o update “na mão”. Como não é algo trivial resolvi compartilhar os passos para que possa auxiliar alguém que esteja na mesma situação. Aqui o update é para o ESXi 4.1 realizado de forma remota e atualizando para o último update. Os passos aqui descritos podem ser utilizados para qualquer update disponível no site da VMware, podendo ser um update completo ou um simples patch bundle.

Continue lendo…

VMware, Storage e IOPS

Recentemente estava acompanhando um problema que não era específico de banco de dados, mas muito relacionado com o dia a dia de um DBA. Aqui, o ambiente era VMware mas ele não era o problema, ele estava no Storage. Na realidade o problema não era o Storage em si, mas escolhas erradas que foram feitas na sua utilização.

Resumidamente as equipes reclamavam que as vezes ficava “tudo lento”. Não era um ambiente de “produção”, mas sim um ambiente para que equipes de desenvolvimento tenham bancos de dados para testes (Oracle, SQL Server, DB2) e servidores de aplicação (JBoss, Apache). Tudo isso sobre VMware ESXi 4.1 e 5.0 e um Storage EMC (série VNX).

Depois dos relatos das equipes comecei a investigar e observei que pelos gráficos de desempenho do VMware o consumo de CPU estava abaixo de 50% para o host físico, mas algumas coisas estavam estranhas com o disco e o datastore. No VMware cada host físico e máquina virtual tem uma aba de performance onde temos acessos a diversos gráficos de desempenho (se você estiver usando o vCenter, mude os gráficos para Realtime) e eles estavam fora do padrão. Acredito que outros players de virtualização tenham métodos semelhantes para análise.

Continue lendo…

Oracle e Hugepages

Em diversos artigos no MOS encontramos informações importantes resumidas a uma simples nota de rodapé ou a uma única linha no meio do texto. Geralmente isso nos leva a pesquisar mais, nos aprofundar no assunto. Foi isso que aconteceu quando estava começando a trabalhar com o Exadata em 2010. Eu estava garimpando algumas notas no MOS atrás de informações sobre o uso do Exadata com OLTP e encontrei uma breve referência ao uso de Hugepages.

Estava lendo a nota MOS# 1067520.1 (que é uma das principais notas sobre desempenho para o Exadata) e lá estava a seguinte informação: “Hugepages should be used, as this reduces the page table size and also reduces process startup time. Review  MOS Note 361323.1 and Note 401749.1 for details on hugepages”.

Era uma informação literalmente solta no meio do texto e achei melhor investigar. A nota MOS# 361323.1 tinha o sugestivo nome de “HugePages on Linux: What It Is… and What It Is Not…” e era uma ótima introdução ao que é Hugepages. Já tinha ouvido sobre Hugepages e Oracle, mas isso era para Oracle 9 em ambientes 32 bits com mais de 4GB de memória.

Continue lendo…