Category Archives: Oracle

Oracle e MAA – Artigo VII – Switchover Broker

Seguindo uma ordem cronológica dos artigos sobre Oracle RAC e MAA vamos fazer um switchover usando o Broker. Em um ambiente de produção você não seguiria esta ordem de eventos, mas para fins didáticos é interessante observar os passos.

No último artigo “forçamos” um failover do ambiente, o banco “maa” que rodava como primary sofreu um failover e o banco “maastb” é agora o primary.  Além disso, no mesmo artigo o banco “maa” sofre um reinstate e passou a atuar como physical standby. Diferentemente do primeiro artigo que falei sobre failover, o último foi através do Broker. Todos os comandos partiram dele, do failover ao reinsate. Como disse no último artigo, o ambiente ainda não está 100%, precisamos configurar o Fast-Start Failover para ter um ambiente completo com MAA.

Infelizmente algumas atividades impediram publicar este artigo de maneira mais rápida, isso deixou este arigo um pouco afastado dos demais. Recomendaria a releitura dos artigos anteriores para relembrar alguns pontos.

SÉTIMO ARTIGO

Neste artigo vamos ver como realizar o switchover do ambiente através do Broker. O banco “maastb” que atua como primary sofrerá uma troca de papeis com o seu banco “maa” (que opera como physical standby).

Vamos ver aqui que através do Broker os passos e comandos ficam mais simples (quando comparado com o switchover manual que foi realizado neste artigo), basicamente iremos acompanhar alguns logs. Claro que tudo isso só acontecerá pois já tomamos diversos cuidados no caminho até aqui, destaco como uma das principais a conexão do Broker a cada instância (StaticConnectIdentifier) por permitir enviar os comandos diretamente uma a uma.

Continue lendo…

Oracle e MAA – Artigo VI – Failover Broker

Neste artigo vamos ver como fazer um failover e reinstate em um ambiente que temos o Broker configurado. Se você está acompanhando a série de artigos até verá que já passamos por failover manual, resintate, switchover (todos manuais e sem Broker) e no último nós configuramos o Broker.

De qualquer forma, ainda não chegamos a um ambiente ideal de Oracle MAA (Maximum Availability Architecture) com DataGuard e Oracle RAC. Até o momento não foi configurado o Fast-Start Failover e em caso de falha, mesmo com o Broker, ainda precisamos de intervenção manual em caso de falha no ambiente.

SEXTO ARTIGO

Neste artigo vamos ver como proceder em caso de falha do ambiente quando estamos com o Broker, vamos ver como realizar o failover e reinstate através do Broker. Como disse acima, ainda não estamos com o ambiente de MAA finalizado, mas isso não impede que ocorra uma falha e você tenha que interferir.

Acredito que já tenha ficado claro através da séria sobre MAA que muitos passos não são aplicados em um ambiente real na mesma sequência que a apresentada na série, você não vai fazer um failover só para testar o Broker – você já configura tudo sem precisar “restaurar” o ambiente. Através dos artigos cobrimos os diversos pontos que envolvem um ambiente MAA, você tem que estar preparado para agir mesmo quer o seu ambiente não esteja completamente configurado. Você vai dizer para o seu gerente que não pode realizar um failover porque não tem o Broker configurado?

Continue lendo…

Oracle e MAA – Artigo V – Broker

Se você está acompanhando a série de artigos sobre MAA com Oracle RAC deve ter notado que gerenciar manualmente um ambiente com esta complexidade não é uma tarefa simples. São inúmeros detalhes e configurações que podem fazer você perder o ambiente através de um único comando, fica mais complicado quando você tem que lidar manualmente com failover, switchover e reinstate.

Felizmente com Data Guard podemos utilizar o Broker para nos auxiliar em algumas tarefas, automatizando diversas tarefas. Neste artigo vou mostrar como configurar e integrar o Broker ao nosso ambiente DG com Oracle RAC.

QUINTO ARTIGO

Como disse, neste artigo vamos ver como configurar o Broker em nosso ambiente, além disso vamos ver o que precisamos fazer para que fique corretamente configurado com um Oracle RAC. A intenção deste artigo é deixar o Broker completamente operacional e integrado e onde (no futuro) possamos realizar failover, reinstate e switchover de forma “automática”. Deixarei somente a configuração do Broker para este artigo.

Como já disse em artigos anteriores, a intenção é mostrar todos os passos envolvidos no processo. Procuro demonstrar e explicar todos os logs envolvidos para que você possa ter uma noção do que está acontecendo e vislumbrar algumas coisas que acontecem por “baixo dos panos”. Infelizmente isso faz com que os artigos fiquem extensos e neste artigo os logs ficarão maiores e agora teremos mais locais para acompanhar.

Continue lendo…

Oracle e MAA – Artigo IV – Switchover

Seguindo a ordem dos artigos o próximo passo é realizar o switchover entre primary e standby. Se você seguiu os artigos até aqui, já realizou um failover manual e um reinstate do seu ambiente. O switchover pode ser realizado sem que ocorra um failover, ele é uma operação legítima de um Data Guard. Os passos deste artigo podem ser realizados em um ambiente que não sofreu nenhuma falha até o momento.

QUARTO ARTIGO

Neste quarto artigo vamos realizar o switchover manual do ambiente, mostrarei os passos envolvidos e mais alguns detalhes. Citei acima que esse é uma sequência dos anteriores, mas os passos são os mesmos para um ambiente que necessita de um switchover sem que antes tenha ocorrido um failover.

Continue lendo…

Oracle e MAA – Artigo III – Reinstate

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

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

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…