Author Archives: Simon

Oracle e MAA – Artigo III – Reinstate

2 Replies

Após fazer o failover no artigo anterior você precisa recuperar o seu ambiente, presiamos fazer o reinstate do antigo primary. De forma resumida o resintate é recuperar o banco para que assuma a nova função.

No mundo real as falhas que podem deixar seu ambiente primary fora e forçar o failover para o standby são diversas. Muitas vezes perde-se o ambiente por completo e precisamos recriar o primary, quando acontece isso a solução é recriar o ambiente e adicionar o banco ao DG. Aqui, o antigo primary teve a sua falha corrigida e ele foi religado. Se no caso você perdeu completamente o antigo primary não há o que fazer, você precisará recriar ele através de um backup do novo primary.

TERCEIRO ARTIGO

Neste artigo irei demonstrar como fazer o reinstate manual do antigo primary. Além disso, também demonstrarei como adicionar este banco como standby ao ambiente para que possamos a ter um ambiente MAA. Como este artigo é uma sequência dos anteriores eu recomendo a leitura dos anteriores para ficar familiarizado, não é obrigatório mas pode ajudar.

Continue lendo…

Oracle e MAA – Artigo II – Failover

7 Replies

No artigo anterior demonstrei como configurar um DG para que você possa ter MAA no seu ambiente. Foram apresentados os passos para criar um DG entre um banco primary ORACLE RAC e standby também em ORACLE RAC. Até o momento o ambiente não está 100%, ainda não configuramos o DG para utilizar o broker e nem fast-start failover, tudo será manual.

A função básica do DG é proteger quanto a possíveis falhas inesperadas em nosso banco primary. Existem vários tipos de falhas que podem deixar indisponível um banco de dados: hardware, software, estagiário, DBA Senior; inúmeras.

Quando trabalhamos com o Oracle em RAC as falhas que podem deixar o seu ambiente indisponível por completo reduzem, no caso de uma falha de um único nó o outro assume a carga e o banco continua disponível ao usuário. Mas ele não protege para falhas mais complexas. Se o seu storage falhar? Ou se a sua rede apresentar problema e o seu RAC cair?

É nesses cenários que o DG pode ajudar, ele irá proteger seu banco Oracle contra possíveis falhas do seu ambiente primary. Com MAA você teria tudo replicado no outro ambiente e em um ambiente RAC você estará protegido contra falhas de ambos os nós.

SEGUNDO ARTIGO

Neste artigo vamos dar sequência ao anterior e simular um failover no ambiente. Neste artigo você verá os passos e o que fazer para realizar o failover do primary para o seu standby, tudo isso de forma manual.

Continue lendo…

Oracle e MAA – Artigo I

3 Replies

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]

1 Reply

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

8 Replies

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

7 Replies

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

6 Replies

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

3 Replies

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

Leave a reply

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

1 Reply

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…