AlwaysOn AG e backups nas réplicas secundárias

No SQL Server 2012 AlwaysOn Availability Group (AG) temos a opção de executar backups nas réplicas secundárias. Esta é uma possibilidade interessante para muitos ambientes, considerando que assim podemos aumentar nossa janela de manutenção e tirar a carga dos backups da réplica primária.

Na figura abaixo é possível entender como configurar as réplicas preferenciais para backup:

AG_properties_backup

Percebam que podemos configurar os backups das bases que participam do AG das seguintes formas: executar preferencialmente nas réplicas secundárias (Prefer secondary), somente nas réplicas secundárias (Secondary only), somente na réplica primária (Primary) ou em qualquer réplica (Any Replica).

Observe que na imagem da tela sublinhei a palavra “automated”. Porque? Porque estas configurações só são aplicáveis para backups automatizados; logo isso não se aplica para backups ad-hoc. Sendo assim, se configurarmos um AG como ”Secondary only” mas precisarmos de um backup a partir da réplica primária, basta executar um backup ad-hoc na réplica primária; esta configuração nunca te impedirá de realizar backup de suas bases.

Agora, o que o AG entende como ”automated backup”? Aqui compreende-se um backup feito a partir de um plano de manutenção (com a opção abaixo desmarcada) ou um comando de backup em conjunto com a função sys.fn_hadr_backup_is_preferred_replica.

AG_properties_backup_task

Por fim, lembre-se que nas réplicas secundárias somente poderão ocorrer backups FULL com COPY_ONLY e backups de log; além disso a réplica secundária deve estar com sincronia ativa com a réplica primária (SYNCHRONIZED ou SYNCHRONIZING).

Até +

Referências:
http://technet.microsoft.com/en-us/library/hh245119.aspx
http://technet.microsoft.com/en-us/library/hh710053.aspx
http://technet.microsoft.com/en-us/library/hh213235.aspx

Os 5 “noves” da alta disponibilidade

Em ambientes críticos a disponibilidade de um sistema pode ser essencial para a sobrevivência do negócio. Porém manter um sistema 100% do tempo no ar é um desafio que envolve pessoas, investimento, infraestrutura e processos bem definidos. Mas mesmo com tudo isso, ainda assim será praticamente impossível ter um sistema com 100% de disponibilidade (uptime). Porque?! Porque são inúmeros os eventos que podem afetar a disponibilidade de um ambiente, como manutenções, atualizações de hardware/software, falta de energia, acidentes, desastres naturais, etc.

100% é praticamente impossível, mas um executivo poderá lhe pedir 5 noves :)

“Give me five nines” é uma expressão conhecida no mundo da alta disponibilidade e isso é a representação de 99, 999% de uptime, o que na prática se traduz em 5 minutos de downtime em um ano!

E aí?! Pronto para este desafio?!

Se 5 noves lhe parece um número muito otimista, poderá negociar 3 noves, que na prática lhe dá uma margem de quase 9 horas de indisponibilidade (downtime) em um ano.

Como chegamos neste número? Através da seguinte fórmula:

 ((8760-X)/8760)*100

8760 é a quantidade de horas em um ano com 365 dias e X é a quantidade de horas de downtime.

Assim, se em um ano você tem 24 horas de downtime, no fim você terá uma disponibilidade de 99,72%, neste caso, dois noves :)

Reflexão

Qual infraestrutura, soluções e processos seriam necessário para que seu ambiente atingisse a gloriosa marca de 6 noves? Sim! Já falam em 6 noves! Prepare-se :)

Referências
http://blogs.msdn.com/b/pcb/archive/2011/01/27/going-beyond-five-nines-uptime-on-the-microsoft-platform.aspx
http://blogs.technet.com/b/uspartner_ts2team/archive/2012/01/10/what-does-five-nines-mean.aspx
http://technet.microsoft.com/pt-pt/video/hh770194.aspx

AlwaysOn AG e FCI: Qual a diferença?

O AlwaysOn vem sem aclamado em muitos eventos, fóruns e encontros ocasionais entre DBAs nerds; porém, está acontecendo uma pequena confusão no nome, isto porque o nome AlwaysOn não veio para discernir uma única solução de HA e DR, mas duas soluções: AlwaysOn Failover Cluster Instance (FCI) e AlwaysOn Availability Groups (AG).

Quer saber mais sobre HA e DR? Leia este post!

Qual a diferença entre FCI e AG?

O AlwaysOn FCI nada mais é que o clássico SQL Server instalado sobre um Windows Cluster. Porque FCI? Porque nesta solução o escopo da redundância é a Instância inteira.

Na versão 2012 esta solução veio com algumas melhorias: a tempdb pode ser armazenada localmente, os nós podem estar em subnets diferentes (sem a necessidade de utilizar VLANs), temos uma política de failover mais flexível, suporte à SMB, etc.

Agora, o AlwaysOn AG é a grande novidade de fato! No AG temos alta disponibilidade no nível de bases de dados (não mais no nível da instância), assim, podemos ter grupos de disponibilidade com 1 ou mais bases de dados. Estas bases de dados podem ser sincronizadas entre 5 instâncias (réplicas) e os arquivos destas bases não ficam armazenados num único storage, eliminando assim o risco de um único ponto de falha. A sincronização entre as réplicas pode ser síncrona ou assíncrona e temos uma réplica primária onde podemos ler e escrever; as demais réplicas podem ser configuradas para leitura e execução de backups. No caso de falha na réplica primária podemos configurar o failover automático para uma outra réplica. Com o recurso do Listener podemos criar um nome virtual que irá abstrair toda essa infraestrutura para as aplicações. Enfim, vejam quantas possibilidades esta solução oferece :)

Posso combinar FCI com AG?

Para alguns cenários a possibilidade de combinar FCI + AG pode ser muito interessante e isto é possível, porém, quando combinamos AlwaysOn FCI com AlwaysOn AG só temos failover automático no escopo do FCI; o failover entre AGs é manual.

 fci_ag

Conclusão

SQL Server AlwaysOn remete a soluções de HA e DR. Apesar de terem o mesmo prefixo é importante diferenciar AlwaysOn FCI e AlwaysOn AG pois são soluções diferentes. A grande novidade é o AlwaysOn Availability Group que traz inúmeras possibilidades para implementar soluções de HA e DR em SQL Servers que suportam ambientes críticos.

Alta Disponibilidade X Recuperação de Desastre

High Avalibility (HA) e Disaster Recovery (DR) são conceitos diferentes mas que muitas vezes são confundidos e tratados como sinônimos. Se traduzirmos estes nomes para o português teremos respectivamente “alta disponibilidade” e “recuperação de desastre”. Neste post você verá que existe uma grande diferença entre eles.

High Avalibility (HA)

Quando falamos em HA, falamos em disponibilidade do ambiente, assim, espera-se que uma solução de HA mantenha o sistema no ar, disponível, pelo maior tempo possível, oferecendo preferencialmente um modo de recuperação automático para eventos de falha, sem que usuários e aplicações notem o problema de forma evidente. Um exemplo de uma tecnologia de alta disponibilidade é o Windows Server Failover Cluster (WSFC) que permite que 2 ou mais servidores trabalhem em conjunto para evitar longas paradas no ambiente; dessa forma quando um dos servidores falha, o outro assume o trabalho automaticamente (note que durante o processo de recuperação os usuários e aplicações perdem suas conexões neste ambiente, mas em alguns segundos tudo é reestabelecido e disponível novamente).

No SQL Server temos tecnologias de HA, como exemplo podemos citar o Database Mirroring, AlwaysOn FCI e AlwaysOn AG.

Disaster Recovery (DR)

Quando falamos em DR estamos falando do pós-desastre e desastres não acontecem todos os dias, logo, é altamente recomendável ter um plano de disaster recovery devidamente documentado, enumerando todos os passos necessários para reestabelecer o(s) sistema(s). Acredite, isso poderá reduzir muito o trauma de um desastre no seu ambiente.

A pergunta inicial para começar a pensar em um plano de DR é a seguinte: “quando meu sistema cair, qual será o meu plano de recuperação?” Nestes casos você deve ser pessimista e pensar: o que fazer quando o cluster inteiro cair? O que fazer quando o datacenter for incendiado (junto com todas as fitas de backup)? O que fazer quando o storage falhar? O que fazer quando os recursos de tolerância a falha e HA se esgotarem?

Um plano de DR deve considerar as exigências do negócio relacionados ao tempo de indisponibilidade; deve se atentar aos usuários que serão impactados direta ou indiretamente; precisa envolver comunicação e é altamente recomendável que seja um plano validado e divulgado para toda organização.

No SQL Server temos soluções aplicáveis em cenários de DR, como o Log Shipping, Replicação, Database Mirroring e AlwaysOn AG.

Cenário

Abaixo temos um esboço de uma solução com HA + DR no SQL Server. No ponto “A” temos uma instância do SQL Server sendo executada sobre um cluster Windows, onde temos alta disponibilidade com failover automático entre os 2 servidores participantes. No ponto “B” temos uma instância stand-alone (não-clusterizada) que é sincronizada através da solução  log shipping. Se o ambiente que hospeda a estrutura “A” for incendiado, basta executarmos o plano de DR, comunicando os usuários da indisponilidade, envolver time de infraestrutura e DBAs para habilitarem o ponto “B” de forma que ele possa receber as conexões das aplicações; notificando o time de deploy para alterar strings de conexão e etc.

 HA_DR

Conclusão

HA e DR são conceitos diferentes. O primeiro tem o intuito de evitar desastres e manter o sistema com maior uptime possível. O segundo tem o intuito de planejar e documentar os passos necessários para reestabelecer o ambiente após um desastre.

Planos e soluções de HA e DR precisam ser testados, ensaiados e simulados periodicamente!

Garanta que sua solução funcionará quando precisar dela :)

Referências:

http://technet.microsoft.com/en-us/library/ms187103.aspx

http://technet.microsoft.com/en-us/library/ms190202.aspx

http://technet.microsoft.com/en-us/library/ms178094(v=SQL.105).aspx

SQL Server 2000 para SQL Server 2012: um voo com escala

Se você tem bancos num SQL Server 2000 não será possível migra-los diretamente para o SQL Server 2012. O artifício para esta situação é migrar seu banco para uma versão intermediária (2005, 2008 ou 2008 R2) e só então migra-lo para o SQL Server 2012.

Outro ponto importante: o nível de compatibilidade 80 foi descontinuado no SQL Server 2012. Considerando isto, o que ocorre quando você tem um banco com compatibilidade 80 num SQL Server 2005, 2008 ou 2008 R2 e deseja migra-lo para o SQL Server 2012?

Este banco será migrado normalmente, já que de fato ele está numa instância 2005 ou superior; porém o nível de compatibilidade “sobe” automaticamente para um nível que seja suportado no SQL Server 2012; neste caso, este banco passaria  a ter compatibilidade = 90.

Evidências:

Tenho aqui um banco no SQL Server 2005 com compatibilidade 80. Faço o backup deste banco para restaura-lo no SQL Server 2012.

Antes de restaurar o backup no SQL Server 2012:

restore_header_only

Depois do restore, o banco passa para compatibilidade 90 automaticamente:

restore_header_only_2

Considere estes pontos em sua migração :)

Referências: http://technet.microsoft.com/pt-br/library/bb510680.aspx

Consultar objetos ou trechos de código no SQL Server

Perguntas comuns pra quem interage com bancos de dados SQL Server:

  • Quais procedures consultam dados na tabela X?
  • Quais funções utilizam o hint NOLOCK?
  • Quais tabelas e views contém a palavra _OLD no nome?

Para responder rapidamente estas perguntas podemos utilizar 2 DMVs do SQL Server: sys.objects e sys.sql_modules.

  • A sys.objects retorna informações de todos os objetos de um banco de dados;
  • A sys.sql_modules retorna informações de todos os objetos programáveis, como views, stored procedures, triggers, etc.

Da sys.objects podemos recuperar o nome e o tipo dos objetos; e na sys.sql_modules, podemos pesquisar o código do objeto programável no campo definition:

declare @pesquisar varchar(800) ='%max%'

select
  a.object_id,
  b.name as [Schema],
  a.name as [Objeto],
  a.type_desc as [Tipo do objeto]
from sys.objects a
inner join sys.schemas b
  on a.schema_id = b.schema_id
left join sys.sql_modules c
  on a.object_id = c.object_id
where
  c.definition like @pesquisar or
  a.name like @pesquisar

A consulta acima retorna todos os objetos que tenham a string ‘max’ no nome do objeto ou no código.

Retorno da consulta no banco AdventureWorks2012:

resultado_buscaNomeCodigoExistem outras formas de obter o mesmo resultado. Tem uma sugestão?

Compartilhe :)

Referência: http://technet.microsoft.com/pt-br/library/ms175081.aspx

As páginas de dados do SQL Server

Você já parou pra pensar em como o SQL Server organiza seus dados internamente?

Isso pode ser um pouco estranho, mas apesar de um banco de dados ser composto por inúmeros objetos como tabelas, índices, triggers, procedures e etc; fisicamente, tudo isso é gravado nos arquivos de dados do SQL Server em grupos de 8KB e a este agrupamento de dados, denominamos: PÁGINA.

sqlserver-page

Logo, se você tem uma tabela com 6MB, fisicamente esta tabela estará gravada em arquivo num conjunto de aproximadamente 780 páginas de 8KB cada. Se você executar um SELECT * para consultar os dados desta tabela, o SQL Server colocara estas 780 páginas em memória para retornar sua consulta (para entender como, veja este post).

Com isso podemos dizer que uma tabela nada mais é que uma abstração das páginas de dados, ou seja, a tabela dá ao usuário uma visão mais simples, mais coerente com a sua realidade, sem expor para ele a complexidade física que há por trás.

É similar à nossa realidade: quando você vê um copo, não fica pensando que estruturalmente ele é um conjunto de átomos, certo? O que importa para você, como usuário, é que o copo lhe permita beber algo :)

O SQL Server oferece meios para observarmos de perto a estrutura das páginas e vou dar algumas dicas sobre como fazer isto num próximo post. Existem outros inúmeros detalhes sobre como o SQL Server armazena dados internamente… mas por hora, registre aí: apesar de lidarmos com tabelas, procedures e etc, por tras, tudo é página. Você verá que o próprio SQL Server exibe essa informação em algumas de suas mensagens; por exemplo ao fim de um backup:

Processed 280 pages for database 'BancoTeste', file 'BancoTeste' on file 1.
Processed 3 pages for database 'BancoTeste', file 'BancoTeste_log' on file 1.
BACKUP DATABASE successfully processed 283 pages in 0.088 seconds (25.079 MB/sec).

E aí…. analisando a mensagem acima… quantos MBs tem este arquivo de backup?

 Até +

Referência: http://technet.microsoft.com/en-us/library/ms190969%28v=sql.105%29.aspx

Prosas sobre SQL Server, experiências de campo e mercado