Alta Disponibilidade e Recuperação de Desastres (HADR)

Olá,

A idéia deste post é comentar brevemente sobre o tema “Alta Disponibilidade e Recuperação de Desastres”. Comentar sobre as diferenças entre as duas expressões (que são geralmente inter-relacionadas, porém têm objetivos distintos), sobre algumas das várias opções que temos para desenhar uma estratégia de alta disponibilidade e/ou recuperação de desastres e comentar sobre as principais tecnologias oferecidas pelo produto SQL Server para te apoiar na definição da melhor estratégia.

 Vou falar sobre “arquitetura”, não sobre “implementação”, que provavelmente será tratada com detalhes nos próximos posts. A idéia é dar um overview sobre o conceito e sobre as tecnologias, para você pode avaliar o que cabe no seu ambiente e o que te interessa mais, para que você possa se aprofundar por conta.

 O que significa?

 Apesar de “Alta Disponibilidade e Recuperação de Desastres” – “High Availability and Disaster Recovery” em inglês, ou simplesmente HADR – geralmente ser utilizada como uma única expressão, significando um único conceito, na verdade trata-se de dois objetivos distintos. Para efeitos teóricos e conceituais, seguem as definições que acho mais coerentes para cada uma delas:

 “Alta disponibilidade refere-se à disponibilidade dos recursos de um sistema (sejam eles hardware, software, energia, etc.), no momento em que ocorrer uma falha em pelo menos um dos componentes deste sistema.”

 Ou seja, você tem um sistema, uma estrutura de banco de dados, formada por um datacenter, um servidor, um sistema operacional, uma ou mais bases de dados, uma ou mais tabelas, conexões de rede, storage, etc., etc.. E em algum momento, algum destes componentes falha, vamos imaginar como exemplo a famosa tela azul, uma falha no teu sistema operacional. O quão redundante está o teu sistema, a ponto de você poder apontar o teu sistema para uma máquina redundante (uma cópia) e botar teu sistema novamente na ativa? Lembrando apenas que o tempo que você vai levar para botar esta máquina em pé novamente, varia de cliente pra cliente, de necessidade para necessidade, mas a gente fala sobre isso daqui a pouco.

 Já a “Recuperação de Desastres” refere-se à habilidade de continuar a prover disponibilidade de um sistema no evento de um desastre de qualquer grandeza (seja ele maior, como um furacão atingindo seu datacenter, ou menor, como a exclusão indevida de uma tabela ou uma queda de energia).”

 Ou seja, seu sistema existe e está, ou não, configurado com alta disponibilidade, porém ocorre um evento de um desastre qualquer (qualquer um, de maior ou menor grandeza!), logo a “recuperação de desastres” trata do quão preparado você está para botar novamente em funcionamento o seu sistema.

 Costuma-se dizer que são expressões inter-relacionadas, pois para a recuperação de um desastre (um restore de um backup no caso de uma exclusão inadvertida de dados, por exemplo), não necessariamente o seu sistema deveria estar configurado com alta disponibilidade. Você pode não ter qualquer objetivo definido (um SLA – service-level agreement, um RTO – recovery time objective, ou um RPO – recovery point objective), nenhum tempo pré-acordado para botar novamente em funcionamento a tabela que continha os dados que foram excluídos, logo você não tem preocupação com alta disponibilidade. Porém você tem uma estratégia muito simples para recuperação de desastres (backup/restore), logo você calmamente restaura os seus dados e pronto, você está recuperado de um desastre! Parece um exemplo bobo e fictício mas acreditem, este cenário é mais comum do que imaginamos!

 E o que pode falhar?

 Uma infinidade de coisas pode acontecer, desde uma tomada desligada pelo pessoal da limpeza, passando pela exclusão indevida de dados de uma tabela de produção por um DBA já cansado, um problema em um pente de memória ou até a inundação do seu datacenter, a quebra de um ar-condicionado que pode levar ao super-aquecimento do seu hardware queimando a CPU do seu servidor, etc.

- Hardware: CPU, discos, memória, placa de rede ;
- Software: sistema operacional, SQL Server corrompido, arquivo de dados corrompido;
- Falta de energia – queda temporária de energia, tomada desligada indevidamente;
- Datacenter – um possível incêndio, uma inundação, furacões, terremotos, etc.;
- Humanos – erros humanos podem ocorrer (DBAs, usuários), dados podem ser apagados, configurações podem ser alteradas indevidamente

 E como definir a melhor estratégia?

 Comece com as seguintes perguntas: 

1. Qual o nível de disponibilidade que a empresa quer/precisa ter? Qual é o “desejo”!?
2. O que deve estar sempre disponível? Meu datacenter inteiro, meu servidor, meu database, apenas dois databases, minha tabela de clientes, só as vendas do dia? Qual é a granularidade desta redundância?
3. Quanto tempo (em minutos) eu posso ficar fora do ar, com minhas operações e meu pessoal parados? Ou seja, quanto eu posso perder (em dinheiro, em negócios, em clientes)? É claro que todos vão dizer “eu não posso perder nada”, mas qual é um valor aceitável, realista (um hospital tem necessidades diferentes de uma loja de e-commerce), já que além de improvável, é muito caro atingir 100% do tempo disponível (uptime).
4. Quanto a empresa está disposta a gastar com esta solução? Hardware, infra-estrutura (datacenter, ar condicionado), licenciamento de software, equipe, treinamento, etc..

 Com as respostas acima será possível responder às seguintes questões, fundamentais para a definição da sua estratégia: 

1. Quais componentes eu preciso tornar redundantes para atender as necessidades da empresa?
2. Quem estará envolvido (pessoal) no momento de crise (DBA’s, SysAdmin’s, Desenvolvedores, Usuários, etc.)?

 Redundância de pessoas, hardware e software

A sua estratégia deve contemplar redundância de pessoal, hardware e software. Todos os possíveis pontos de falha devem ser endereçados e uma estratégia de failover para qualquer dos componentes redundantes deve ser definida.

 A redundância em um ambiente de alta disponibilidade deve ser feita em todos os níveis, desde as pessoas envolvidas (um DBA, um SysAdmin, um Desenvolvedor, etc.) até componentes de hardware (CPU, memória, discos, placas de rede) e software (sistema operacional, SQL Server). Todos os possíveis pontos de falha devem ser identificados e endereçados, e uma estratégia para botar estes componentes de novo na ativa, devem ser definidos.

 Lembre-se que o seu sistema será tão redundante quanto o elo mais fraco de sua arquitetura: se seu hardware estiver redundante, mas o seu pessoal não estiver (se você tiver apenas um DBA na equipe, e ele estiver impossibilitado de chegar a tempo no momento de um desastre), então o elo mais fraco será seu pessoal, e o ambiente não estará disponível da mesma maneira.

 E quais tecnologias estão disponíveis no SQL Server:

 Uma breve (breve mesmo!) descrição sobre as principais tecnologias:

 A solução de Clustering oferece failover automático (não manual) do seu hardware (escopo de servidor), é transparente para os usuários (eles nem ficam sabendo que o failover ocorreu), porém não oferece redundância do seu storage. Se o seu storage falhar, você estará em apuros. A configuração é um pouco mais complicada que as outras soluções, requer hardware específico e é um pouco mais cara! Você não pode usar o failover para execução de queries para relatórios (read-only), por exemplo (o servidor de failover não pode ser utilizado com exceção a partir do momento do failover).

 A tecnologia de Database Mirroring (synch e asynch) oferece 3 configurações: synchronous, asynchronous e synchronous com failover automático. A synchronous (sincronizada) oferece maior nível de disponibilidade, pois só “comita” a transação no cliente após escrever a transação no log da base espelhada (mirror), o que aumenta a latência no retorno do commit, prejudicando um pouco a performance da aplicação. A synchronous com failover automático é a mesma coisa, porém trabalhando com um servidor chamado “witness”, que garante o failover automático. Já a asynchronous (não sincronizada) não espera a escrita na base espelhada para devolver o commit para o cliente, este processo ocorre em paralelo, melhorando a performance porém prejudicando um pouco a disponibilidade. É possível a utilização das bases de mirroring para relatórios através de database snapshots. Um ponto negativo é que trabalha no escopo de database, ou seja, apenas um database por vez é espelhado, ou seja, as bases master, msdb, model, por exemplo, não são espelhadas em conjunto, o que pode causar uma séria de problemas (que serão discutidos em próximos posts).

 A Replicação (Replication), permite filtrar as informações que serão redundadas, e oferece o menor nível de granularidade para redundância. Trabalha com os conceitos de Publishers, Subscribers e Distributors e permite a redundância de mais de um database por vez. É a melhor opção que combina disponibilidade com escalabilidade, pois permite utilização online das “bases espelhadas”. Oferece as configurações Transactional, Merge, Snapshot e Peer-to-Peer.

 O Log Shipping é basicamente o backup e restore de bases de dados em um servidor remoto e um tempo pré-definido. É bastante utilizado e oferece possibilidade de redundância de uma base de dados para mais de um servidor ao mesmo tempo (ao contrário do database mirroring). Por tratar de um restore, obviamente oferece um failover mais demorado de acordo com o tamanho do seu database, mas dependendo do cenário pode ser um bom complemento para uma solução de database mirroring.

 Além das soluções acima listadas (as principais e provavelmente mais utilizadas), ainda teremos a nova funcionalidade de “Always On” (no SQL Server 2012), soluções de mirroring de storage, soluções de RAID, e é claro, o essencial backup e restore. Enfim, várias tecnologias e funcionalidades disponíveis, que combinadas (em conjunto, não sozinhas!) te oferecem as melhores opções para alta disponibilidade de recuperação de desastres.

 Um abraço,
 Raul Santos Neto

Partitioning – Como saber se o partition elimination está realmente funcionando no SQL Server 2005?

Olá,

Post rápido sobre partitioning.. mais precisamente sobre como avaliar se sua query está ou não, utilizando apenas a partições necessárias, ou seja, se a eliminação de partições (“partition elimination”) está sendo devidamente acionada pelo SQL Server.

Observação: testes realizados no SQL Server 2005.

Montando o cenário para testes:

/* cenário */
IF  EXISTS (SELECT * FROM sys.partition_schemes WHERE name = N’PS1′)
DROP PARTITION SCHEME [PS1]
GO

IF  EXISTS (SELECT * FROM sys.partition_functions WHERE name = N’PF1′)
DROP PARTITION FUNCTION [PF1]
GO

CREATE PARTITION FUNCTION PF1 (int) AS RANGE FOR VALUES (100, 200, 300, 400);
GO

CREATE PARTITION SCHEME PS1 AS PARTITION PF1 ALL TO ([PRIMARY]);
GO

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N’T1′) AND type in (N’U'))
DROP TABLE T1
GO

CREATE TABLE T1 (a INT, b INT) ON PS1 (a);
GO

DECLARE @i INT; SET @i=1;
WHILE (@i <= 50)
BEGIN;
 INSERT INTO T1 VALUES (20 * @i, @i);
 SET @i = @i + 1;
END;
GO

/* verificando a configuração das partições */
SELECT $partition.PF1(a) [Partition Number], a, b from t1

/* verificando o conteúdo da tabela particionada */
SELECT * FROM t1; –// total of 50 rows

/* DMVs úteis para verificações diversas */
select OBJECT_NAME(object_id), * from sys.partitions;
select * from sys.partition_schemes;
select * from sys.partition_functions;
select * from sys.partition_parameters;
select * from sys.partition_range_values;

 Ao verificar a configuração da partição PF1 através da query abaixo, é possível verificar todas as partições (ou intervalos) resultados da criação da tabela T1 nos ranges 100, 200, 300 e 400:

/* verificando a configuração das partições */
SELECT $partition.PF1(a) [Partition Number], a, b from t1

Partition Number a b
1 20 1
1 40 2
1 60 3
1 80 4
1 100 5
2 120 6
2 140 7
2 160 8
2 180 9
2 200 10
3 220 11
…
5 840 42
5 860 43
5 880 44
5 900 45
5 920 46
5 940 47
5 960 48
5 980 49
5 1000 50

Analisando o resultado, podemos ver que foram criadas 5 partições (0 a 100, 100 a 200, 200 a 300, 300 a 400 e 400 a infinito).

Mas vamos começar os testes. Habilite as informações de profile: 

 SET STATISTICS PROFILE ON;

Para começar, vamos executar uma query que traga TODOS os registros, para ver como SQL Server se comporta:

SELECT * FROM t1;

Rows Executes StmtText
50 1 SELECT * FROM t1;
50 1   |–Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
5 1        |–Constant Scan(VALUES:(((1)),((2)),((3)),((4)),((5))))
50 5        |–Table Scan(OBJECT:([TRANS_Trigger].[dbo].[T1])) 

Veja que o SQL Server 2005 utiliza um “Nested Loop” para gerar os resultados. Note também no “Constant Scan” nos valores 1, 2, 3, 4 e 5 (nossas partições!) e um “Table Scan” para cada um dos valores no “Constant Scan”. Ou seja, um “Table Scan” por partição foi executado, para que todas as linhas fossem retornadas (exatas 50 linhas foram lidas). Observação: no SQL Server 2008, nem o Nested Loop nem o Constant Scan são mais utilizados, logo os resultados serão diferentes.

Agora vamos tentar utilizar uma partição específica:

SELECT * FROM t1 WHERE a = 300;

Rows Executes StmtText
1 1 SELECT * FROM [t1] WHERE [a]=@1
1 1   |–Table Scan(OBJECT:([TRANS_Trigger].[dbo].[T1]), WHERE:([TRANS_Trigger].[dbo].[T1].[a]=(300)) PARTITION ID:((3)))

Veja que apenas um “Table Scan” é gerado (não existe “Constant Scan”), e note que o SQL Server vai procurar direto na terceira partição (PARTITION ID:((3))), no range de 200 a 300. Neste momento o partition elimination já está funcionando!

Agora vamos executar outra query, que precise utilizar mais de uma partição (porém não todas elas!):

SELECT * FROM t1 WHERE a > 300 and a < 600;

Rows Executes StmtText
14 1 SELECT * FROM [t1] WHERE [a]>@1 AND [a]<@2
14 1   |–Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1006]) PARTITION ID:([PtnIds1006]))
2 1        |–Constant Scan(VALUES:(((4)),((5))))
14 2        |–Table Scan(OBJECT:([TRANS_Trigger].[dbo].[T1]), WHERE:([TRANS_Trigger].[dbo].[T1].[a]>(300) AND [TRANS_Trigger].[dbo].[T1].[a]<(600)) PARTITION ID:([PtnIds1006])) 

Veja que no “Constant Scan”, apenas os valores 4 e 5 aparecem, ou seja, só estas duas partições foram acionadas. Apenas 14 linhas foram lidas.

E como saber que não está funcionando? Por exemplo, ao utilizar OR na cláusula WHERE, ao invés de apenas AND:

SELECT * FROM t1 WHERE a > 300 OR a < 350;

Rows Executes StmtText
50 1 SELECT * FROM t1 WHERE a > 300 OR a < 600;
50 1   |–Nested Loops(Inner Join, OUTER REFERENCES:([PtnIds1004]) PARTITION ID:([PtnIds1004]))
5 1        |–Constant Scan(VALUES:(((1)),((2)),((3)),((4)),((5))))
50 5        |–Table Scan(OBJECT:([TRANS_Trigger].[dbo].[T1]), WHERE:([TRANS_Trigger].[dbo].[T1].[a] IS NOT NULL) PARTITION ID:([PtnIds1004]))

Veja que em tese, apenas uma partição deveria ter sido utilizada (a com range entre 300 e 400), porém o SQL Server não entende o OR e acaba lendo TODAS as partições. No SQL Server 2008 isto ainda não havia sido corrigido. Farei uns testes no SQL 2012 para ver se isto não acontece mais e posto aqui os resultados.

Um abraço,
Raul Santos Neto

SQL Server 2012 – Novas certificações

Olá,

Confira no link abaixo do blog BORN TO LEARN, algumas informações sobre as novas provas de certificações que teremos para o SQL 2012! Algumas pequenas alterações serão feitas, entre elas a necessidade da “re-certificação”. Espero sinceramente que o nível técnico e a dinâmica das provas tenham sido alterados, e que o processo de re-certificação seja bem pensado. Infelizmente as certificações da Microsoft perderam força e importância nos últimos anos e já estava mais do que na hora deles mudarem este processo para tentar reverter esta situação. É esperar pra ver!

Sneak Peek: SQL Server 2012 learning products in development
http://borntolearn.mslearn.net/btl/b/weblog/archive/2011/10/14/sneak-peek-sql-server-2012-learning-products-in-development.aspx

Um abraço,

Raul Santos Neto