Depois de apresentar a forma como cada Storage Server disponibiliza seus discos para os Database Servers no artigo anterior (aqui) vou escrever um pouco sobre como eles são acessados pelo Grid. Não existem surpresas ou mistérios aqui, só alguns detalhes interessantes.
Oracle Exadata, uma das máquinas mais desejadas do universo Oracle, appliance que fortaleceu a equipe de engineered systems da Oracle. Na minha opinião um divisor de águas. Para quem leu o meu artigo passado (aqui) acredito que tenha ficado claro que que não estamos falando só de hardware, mas sim de hardware e software que trabalham de forma integrada.
Se o hardware não é o mistério, o que faz o Oracle Exadata funcionar de verdade? O que é o Exadata Software, como funciona, qual a sua arquitetura, quais são seus processos, como seus discos são acessados, como se comunica com o banco?
Aqui, vou falar especificamente do Exadata Software, tentar responder estas perguntas e mais algumas.
O que é Oracle Exadata? Essa é uma pergunta que você já deve ter ouvido por ai, bom vou tentar responder (ou ajudar a responder). Respondendo da forma mais direta possível: Oracle Exadata (ou Oracle Exadata Database Machine) é um applicance criado pela equipe de Engineering Systems da Oracle e dedicado exclusivamente para que bancos de dados Oracle (versões 11 e 12) sejam executados com a maior performance e disponibilidade possível, independe do tipo (OLTP, DSS ou DW).
Legal não é? Mas o Oracle Exadata é muito mais do que isso, existem diversos detalhes técnicos de hardware e software que são muito importantes e transformaram o Oracle Exadata em um sucesso e desejo de muitos. Neste artigo, e nos próximos, vou falar somente sobre o Oracle Exadata, mostrar detalhes técnicos e algumas decisões gerenciais que estão ligadas a ele. Vou deixar de lado os detalhes comerciais (que você acha em qualquer documento que passou pela equipe de marketing da Oracle) e falar do técnico.
Depois de configurar o Broker, precisamos de um último passo para garantir que os requisitos básicos do MAA estejam contemplados. Nos últimos artigos passamos por alguns passos que provavelmente você não iria realizar em produção (e nem gostaria), fizemos o failover e o switchover (ambos com o broker – que configuramos aqui).
OITAVO ARTIGO
Neste artigo vamos configurar/adicionar ao ambiente a figura do Observer, será habilitado o Fast-Start Failover (FSFO) no Broker para permitir um monitoramento em tempo real do ambiente. Com isso, em uma eventual falha do ambiente primary o standby irá assumir o papel sem ser necessário executar qualquer comando.
No final de Setembro e início de Outubro aconteceu a OpenWorld 2014 e tivemos muitas novidades, infelizmente serei um pouco parcial aqui por estar muito ligado ao Engineered Systems Oracle (Exadata, Backups) e alta disponibilidade – MAA (DataGuard, RAC). Nesta edição tivemos boas notícias em várias áreas, alguns lançamentos e muita informação técnica.
Para quem nunca foi na OpenWorld algumas coisas precisam ser esclarecidas, você não irá conseguir assistir a tudo o que você quer. Você terá que escolher qual palestra irá assistir, garanto a você que existirão duas que você gostaria de assistir no mesmo horário e terá que escolher só uma. Diferentemente da OpenWorld do Brasil, lá as palestras são com a equipe de engenharia da Oracle, você tem acesso a pessoa que criou o conceito por trás da tecnologia, como o CBO, o In-Memory do 12C (que foi a mesma do CBO), do Resource Manager, do Smarscan do Exadata e afins. Para os técnicos é ideal.
Vamos falar de Exadata? Essa é uma pergunta muito interessante pois ela não é tão simples de responder. Na verdade ela leva a muitas outras perguntas.
Claro que falar de Exadata depois de ele estar a mais de 4 anos no mercado parece fácil, a documentação está ai e existem alguns blogs falando sobre ele. Mas o que você realmente conhece de Exadata? Você tem alguma ideia do que é o Exadata?
Começarei uma série de artigos sobre o Exadata, mas sem um número definido (não serão somente um ou dois artigos). Falarei de diversos pontos, desde a organização física e lógica dos componentes, passando por diversos detalhes técnicos (inclusive os segredos não ditos). O interessante é que como a “pauta” não está fechada você pode contribuir, comente aqui suas dúvidas e o que você quer saber.
No primeiro artigo o foco será em um overview do Exadata, o que podemos encontrar nele e como é organizado. Irei além do que já foi comentado nos artigos sobre o Exadata X4 (aqui e aqui).
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.
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?
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.
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.