Partition Offset e Cluster Size – Como verificar?

Boa tarde!

Várias vezes referi a importância de termos o offset das partições e o tamanho do cluster bem definidos.

Para uma performance óptima, do lado do SQL Server, temos que assegurar que o offset da partição é de 1024 Kb (ou 1048576 Bytes). Já no caso do cluster, o valor a se ter em conta é 64Kb.

O ideal é verificar estes valores antes da instalação do SQL Server, pois o “remédio”é reformatar os disco.

Como verificar estes valores?

Verificar o offset de todas as partições:

Execute na command line o seguinte:
wmic partition get BlockSize, StartingOffset, Name, Index

O output será algo como o seguinte:
BlockSize  Index  Name                   StartingOffset
512        0      Disk #4, Partition #0  1048576
512        0      Disk #5, Partition #0  135266304
512        1      Disk #5, Partition #1  17408
512        0      Disk #3, Partition #0  1048576
512        0      Disk #1, Partition #0  1048576
512        1      Disk #1, Partition #1  105906176
512        2      Disk #1, Partition #2  52428800000
512        0      Disk #2, Partition #0  1048576
512        0      Disk #0, Partition #0  1048576

A coluna StartingOffset devolve os valores que queremos. Para relacionar os discos com uma letra, verifique o valor na coluna “Name”, e compare o número do disco com o valor descrito na tool “Disk Management” do Windows.

Verificar o tamanho da allocation unit:

Execute na command line o seguinte:
fsutil fsinfo ntfsinfo <drive letter>
Exemplo:

fsutil fsinfo ntfsinfo f:

O output será equivalente ao seguinte:
NTFS Volume Serial Number :       0x66ac6ab3ac6a7d85
Version :                         3.1
Number Sectors :                  0x0000000055701fff
Total Clusters :                  0x000000000aae03ff
Free Clusters  :                  0x000000000963a5c8
Total Reserved :                  0×0000000000000000
Bytes Per Sector  :               512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0×0000000000140000
Mft Start Lcn  :                  0x00000000000c0000
Mft2 Start Lcn :                  0×0000000000000002
Mft Zone Start :                  0x00000000000c0140
Mft Zone End   :                  0x00000000000cc940
RM Identifier:        BE2060B1-AFBC-11DF-9B68-1CC1DE750143

A informação a reter aqui é “Bytes Per Cluster”.  Neste caso o disco está formatado com blocos de 4Kb. O está longe dos 64Kb recomendados.


A verificação destes pontos é muito importante e, acredite, isso influencia na performance do SQL Server, principalmente se o offset estiver mal definido.

Até a próxima!

Dica rápida: SET STATISTICS IO Vs. SET STATISTICS TIME

Boa tarde!!

O fim do mês tem sido sinónimo de muito trabalho ultimamente, então vou deixar uma dica rápida que vai ajudar no trooubleshooting de queries.

Existem duas opções que podem ser activadas antes da execução de um query, e que devolvem informações úteis para quem está focado na melhoria de performance.

As opções são as seguintes:

  • SET STATISTICS IO ON
    • Devolve informação referente a actividade do disco.
    • Exemplo de outputTable ‘ProductCostHistory’. Scan count 1, logical reads 5, physical
      reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
  • SET STATISTICS TIME ON
    • Devolve informação relativa ao tempo necessário para efectuar o parse, a compilação e executar cada statement.
    • Exemplo de output SQL Server parse and compile time:
      CPU time = 0 ms, elapsed time = 1 ms.
      SQL Server parse and compile time:
      CPU time = 0 ms, elapsed time = 1 ms.

Até a próxima!

Script – Page Restore

Restaurar bases de dados após um desastre não é uma coisa que sonhamos em fazer muitas vezes… Mas quando o problema acontece, temos que agir rápido!

Por este motivo, disponibilizo para download um script que gera o comando de restore do Full Backup, baseado nas páginas que estão presentes na tabela “suspect_pages”.

Como utilizar?
Altere o valor da variável “vBackupPath” e o nome da base de dados na clausula where, no exemplo abaixo é “AdventureWorks2012“.

Com este script, um comando de restore será gerado. Basta copiar, colar e executar.
Atenção: Após a execução deste script será necessário o restore de todos os backups de t-log, até a BD ficar consistente.
Atenção 2: Não execute restore de páginas sem experiência prévia. A probabilidade de problemas pode ser grande. Faça alguns testes com uma DB não produtiva primeiro.
Faça download do scrip aqui. E tenha muito cuidado :)

Verificação de Integridade – Uma rotina necessária.

Hoje irei abordar o tema da verificação de integridade no SQL Server, ou simplesmente sobre o famoso CheckDB. 
O comando CheckDB é um Database Console Command, ou simplesmente DBCC, categorizado como um DBCC de verificação. Este comando é a única maneira de se ler todas as páginas de uma base de dados, sendo a sua execução muito custosa a nível de CPU, Memória e I/O. Vale ressaltar que no SQL Server Enterprise Edition, este comando é executado em múltiplas threads, o que faz a sua execução ser mais rápida.
Como o CheckDB é executado
Pouca gente tem essa curiosidade, mas o CheckDb não corre directamente na base de dados. É criado um snapshot da base de dados, que fica escondido, e as verificações correm sobre este snapshot.
Normalmente as pessoas só percebem isso quando o CheckDB falha, e ao verem a mensagem, percebem que um tal snapshot não pôde ser criado.
A propósito, no caso de haver um erro como este, temos duas opções:
  1. Criar um processo em que é criado um snapshot manualmente com posterior execução do CheckDB sobre este snapshot.
  2. Executar o CheckDB com a opção TABLOCK. Porém, isso poderá trazer problemas já que a BD será alvo de locks por parte do CHECKDB.
Onde quando executar?
Recomenda-se que o CheckDB seja executa no mínimo uma vez por semana. Este procedimento é necessário em todas as DBs, incluindo as system databases e DBs em read-only.

Alguns factos interessantes:

  • Os planos de manutenção do SQL Server ignoram a TempDB…Porém, se a TempDB for corrompida, a instância irá parar! Atenção a esta situação.
  • Ao se executar o CheckDB na master, estaremos a verificar a base de dados (escondida) Resource.

Qual o objectivo do CheckDB?
O CheckDb tem duas funções, a principal é a detecção de inconsistência, e a segunda a correcção das mesmas. Atenção que esta comando verifica a consistência da estrutura da base de dados, não dos dados.
Detecção de inconsistências
O comando CheckDB segue alguns passos na sua execução, passando pelas seguintes fases:
  • Verificação das estruturas alocadas, como GAM, SGAM, PFS, IAM.
  • Verificação de consistência de tabelas e todos os seus índices, assegurando que as páginas de uma tabelas podem ser lidas e tem uma estrutura válida.
  • Verificação dos catálogos de sistema.
Correcção de inconsistências
Após a sua execução, teremos informação sobre a presença de possíveis páginas corrompidas, o que o   próprio CheckDB pode “corrigir”. 
O CheckDB tem uma opção que permite a correcção da estrutura da base de dados, porém os dados existentes nest página serão perdidos. Esta opção é a “REPAIR_ALLOW_DATA_LOSS“, e basicamente a pagina corrompida é deixada de lado, enquanto uma nova página introduzida no seu lugar. Assim, a estrutura ficará consistente, mas os dados contos nesta página serão perdidos. Após a execução deste comando, uma verificação baseada em backups antigos deverá ser feita, de forma a se identificar os dados perdidos e recupera-los.
Outra opção para correcção de inconsistência é a “REPAIR_REBUILD“, que é utilizada para correcção de nonclustered indexes. Neste caso não há perca de dados.
Apesar de haverem opções para correcção, o CheckDB tem as seguintes limitações:
  • Páginas PFS, tabelas de sistema e erros detectados na utilização da opção data purity não podem ser reparados com o CheckDB.
  • Para execução de um comando de repair, a base de dados deverá estar em modo SINGLE_USER.
Opções de execução
Falando sobre opções, temos as seguintes opções na execução do CheckDB:
  • NO_INFOMSGS: Evita o output the mensagens informativas.
  • ALL_ERRORMSDGS: Permite o output de todas as mensagens de erro.
    • Comportamento padrão desde o SQL Server 2008 SP1.
  • NOINDEX: Não verifica os nonclusterd indexes.
  • DATA_PURITY: Valida os dados conforme o tipo de dados da coluna em que está contido.
    • Comportamento padrão desde o SQL Server 2005.
  • ESTIMATEONLY: Estima o valor a ser utilizado pela TempDB.
    • Segundo o Paul Randal, esta opção não esta funcionando correctamente nas versões actuais.
  • TABLOCK: Utiliza locks ao invés de criar um snapshot.
    • Útil quando há problemas na criação do snapshot.
  • EXTENDED_LOGICAL_CHECKS: validação extra em colunas XML e índices Spatial.
  • PHYSICAL_ONLY: Salta a maioria das verificações lógicas.
    • Utiliza muito menos recursos, mas uma execução “full” deverá ser feita constantemente, por razões obvias.

Outras Considerações
Sendo o CheckDB um processo que utiliza muitos recursos, em alguns casos pode demorar muito tempo para ser executado, é frequente não termos tempo para executa-lo dentro da janela de manutenção. Para dar a volta a este problema, recomenda-se que cada passo (interno) dado pelo CheckDB seja executado de forma isolada. Isso pode ser feito ao se executar os seguintes comandos: 
  • CHECKALLOC
  • CHECKTABLE
  • CHECKCATALOG
  • CHECKFILEGROUP
Executando cada dia um destes comandos, conseguimos garantir uma verificação completa, mas de forma faseada.

Outra boa abordagem é a utilização da opção “WITH CHECKSUM” nos backups, isso nos permitirá a validação dos checksums das páginas de uma DB, além da possibilidade de se efectuar um restore com a opção “VERIFY ONLY”. Este método é útil, mas não substitui o CheckDB.

Bem, eu tento sempre escrever o mínimo possível, mas sai o que sai… Espero que este post tenha sigo útil!! Qualquer coisa, estou disponível!!

Até a próxima!!

Considerações sobre instalações de SQL Server em cluster

Após a série de 4 artigos sobre como instalar uma instância em cluster, venho passar algumas considerações básicas sobre o ambiente em que o SQL Server será instalado:

Rede
Considere sempre utilizar, pelo menos, duas redes distintas. Uma para ligar a aplicação com o SQL Server e outra para a gestão da instância. Uma terceira rede poderia ser adicionada para transferencia de ficheiros de backup.
Ah, isso sem contar a rede de storage…

A regra básica é: Dividir ao máximo!

Discos
A mesma regra serve para os discos, tente distribuir os discos por “funções”, tendo o maior número possível de discos isolados. Considere ter um disco dedicado para dados (mdf e ndf), ficheiros de t-log (ldf) e para a TempDB e, talvez, um disco exclusivo para se criar ficheiros para alojar exclusivamente non-clustered indexes – Isso diminuirá a pressão dos ficheiros de dados assim como a sua fragmentação.

Sobre a TempDB, todo o cuidado é pouco…
Em alguns casos, é interessante ter um disco para os ficheiro de T-Log da TempDB separado dos ficheiros de dados. Aliás, falando em ficheiros de dados da TempDB, tenha em atenção o número de ficheiros a se adicionar…Não deixe a configuração default, mas também não exagere na quantidade de ficheiros.
Em casos de cluster, especificamente paraversões de SQL Server 2012+, considere a utilização de um disco local rápido, como um Fusion-IO ou algo com um bom rácico preço/performance.

Atenção as dependências
Tenha muito cuidado ao gerir as dependência de um cluster. Uma dependência mal feita pode custar caro. Um exemplo: Ao se associar os discos ao SQL Server na instalação, estamos automaticamente criando uma dependência no SQL Server Engine. Ou seja, o SQL Server Engine depende dos discos para ficar online, se um disco ficar offline por qualquer motivo, o SQL Server Engine ira ficar offline também. Na mesma onda, o SQL Server Agent depende do SQL Server Engine e, também, ficará offline.

Onde eu quero chegar aqui? A dependência dos discos é importante? Sim, mas por exemplo, um disco de backup não precisa ser uma dependência do SQL Server. Assim como a rede de backups ou a rede de gestão não precisam ser uma dependência do Hostname Virtual do SQL Server.

Configurações gerais
Não se esqueça de definir a memória mínima e máxima e de definir planos de backup, manutenção de índices e estatísticas de uma forma apropriada.

Tenha em conta que um plano de disaster recovery poderá ser necessário, e dependendo da tecnologia utilizada, o servidor de DR pode trazer mais vantagens… Ou seja, não será apenas um servidor de standby, consumindo recursos a espera de um eventual desastre.

Falando em DR, aproveito para lembrar que no SQL Saturday, em Abril, teremos um workshop muito bom de um amigo meu, chamado Edwin Sarmiento, que virá para Portugal especialmente para este evento. O preço do Workshop é de apenas € 100 e ainda é oferecido o curso completo com videos, disponível em https://www.udemy.com/sqlserverhadrdeepdive/. O preço deste Deep Dive, é de $315.

Ou seja, por € 100 você terá a formação directamente com o Edwin e ainda leva o curso para rever os pontos chave.

Ficam aqui os detalhes do workshop. Eu estarei lá!!!

High Availability & Disaster Recovery Deep Dive

High Availability and Disaster Recovery (HA/DR) is an area that every SQL Server DBA needs to be comfortable with. In this full-day workshop, learn what needs to be considered when embarking on a HA/DR project, the different features and technologies available in SQL Server, and implement them accordingly to meet service level agreements of mission-critical databases.

You will learn:
§  What requirements need to be met when implementing an HA/DR project
§  How to identify different SQL Server features and technologies – backup, recovery, database mirroring, log shipping, clustering, AlwaysOn – that can be used in addressing HA/DR requirements
§  How to implement the appropriate technology to meet HA/DR service level agreements

A group discount (20%) for every 5 registrations is available, so if you want to bring along your whole team – contact us to know the details! 

Link para inscrição: https://www.eventbrite.pt/e/bilhetes-high-availability-disaster-recovery-deep-dive-by-edwin-sarmiento-9168803137 

Até a próxima!!!

Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 4

Chegamos a última parte desta série de artigos. Para fechar com chave de ouro, vamos falar sobre Distributed Transaction Coordinator, ou simplesmente DTC. Vou tentar passar uma explicação simples e, em seguida, demonstrar como se preparar o DTC para uma instância em Cluster.

O que é o MS DTC?
O MS DTC é um serviço do SO, que vem instalado automaticamente e corre sob a conta de serviço “Network Service”. A sua função é assegurar que as transacções distribuídas são consistentes, mesmo que haja uma falha.

Estas transacções distrinbuidas, podem ser inicializaras quando uma transacção está lidando com múltiplos computadores via rede OU quando a transacção esta lidando com múltiplos processos no mesmo computador.

Todos os participantes desta transacção distribuída trabalham em sincroniza com os outros participantes (computadores) envolvidos a transacção, sempre a espera de efectuar um commit ou abortar o trabalho. Por esta razão, temos que garantir que todos os intervenientes podem se comunicar pela rede.

Preciso configurar o MS DTC no meu ambiente?
A resposta a esta questão, é a padrão para o SQL Server: Depende.
Você precisa entender se o sistema em questão irá ou não lidar com transacções distribuídas.
Se você tem mais do que uma instância no mesmo computador, você não irá precisar do DTC. De outra forma, se você tiver um cluster de dois nós com instâncias correndo em nós diferentes e comunicando entre si, o MS DTC será utilizado.

Outra possibilidade, é você ter o SSIS instalado, além da componente de engine. Neste caso, o MS DTC poderá ser necessário também.

Para mais informação, verifique este link:  http://msdn.microsoft.com/en-us/library/ms189910#MSDTC

Como confirgurar o MS DTC em cluster?
Desde o Windows Server 2008, a instalação de mais do que uma instância do MS DTC é permitida em um servidor/cluster. Então para uma instância de SQL Server em cluster, é uma boa pratica ter uma Role exclusiva para o MS DTC e uma dedicada para cada Role contendo o SQL Server.

Como documentado pela Microsoft, o SQL Sevrer segue o seguinte caminho para escolher o MS DTC a ser utilizado:

  • Utiliza o MS DTC instalado no grupo local, senão
    • Utiliza a instância mapeada do MS DTC, senão
      • Utiliza a instância MS DTC padrão do cluster, senão
        • Utiliza o MS DTC local da máquina aonde o serviço esta a correr.

Para configurar o MS DTC em cluster, precisamos de um disco (que não precisa ser exclusivo) e um hostname.

Para configurar um role exclusiva para o MS DTC, siga os passos:

  1. Clique com o botão direito sobre Roles e escolha a opção “Configure Role”.

    Screen Shot 2014-01-02 at 14.18.43

  2. Uma nova janela irá abrir. Clique em “next”.

    Screen Shot 2014-01-02 at 14.18.52

  3. Escolha a opção “Distributed Transaction Coordinator (DTC)”. Clique em  “Next”.

    Screen Shot 2014-01-02 at 14.19.11

  4. Preencha o hostname no campo “Name” e o IP na coluna “Networks. Clique em “Next”.

    Screen Shot 2014-01-02 at 14.20.33

  5. Escolha o disco a ser utilizado. Clique em “Next”.

    Screen Shot 2014-01-02 at 15.14.42

  6. Reveja as configurações e clique em “Next”.

    Screen Shot 2014-01-02 at 15.14.57

  7. A instalação irá correr, e no fim será apresentado um relatório. Clique em “Finish”.

    Screen Shot 2014-01-02 at 15.15.11

  8. Agora você poderá ver uma nova Role criada, com os recursos seleccionados e o serviço do MS DTC.

Para adicionar um instância do MS DTC na Role do SQL Server, siga os passos:

  1. Clique com o botão direito na Rola do SQL Server, clique em: “Add Resource”->”More Resources” -> “Distributed Transaction Coordinator” (como na imagem).

    Screen Shot 2014-01-02 at 15.30.50

  2. O recurso será criado na Role, agora será necessário configura-lo. Clique com o botão direito sobre “New Distributed Transaction Coordinator” e clique em “Properties”.

    Screen Shot 2014-01-02 at 15.31.20

  3. Conforme referido anteriormente, o DTC precisa de um hostname e um disco. Nas dependências, seleccione estes dois recursos e clique em OK.

    Screen Shot 2014-01-02 at 15.32.44

  4. Agora vamos iniciar o recurso.

    Screen Shot 2014-01-02 at 15.32.55

Como preparar a rede para transacções distribuídas?
Nota: Em ambientes de cluster, você deverá efectuar estes passos apenas uma vez.

  1. Em “Server Manager” clique em “Tools”->”Component Services” ou simplesmente execute o comando “dcomcnfg”.

    Screen Shot 2014-01-02 at 15.33.55

  2. Expanda a árvore, clique com o botão direito na instância de MS DTC desejada e escolha a opção “Properties”.

    Screen Shot 2014-01-03 at 11.46.28

  3. Na tab “Security” seleccione “Network DTC Acess” assim como “Allow Inbound” e “Allow Outbound”, como mostrado na imagem. Clique em OK.

    Screen Shot 2014-01-03 at 11.49.02

  • Descrevendo, por alto cada uma das opções…
    • Network DTC Access“: Activa/Desactiva o acesso a rede.
    • Allow inbound“:  Permite a execução de uma transacção distribuída, iniciada em outra máquina, na máquina na qual esta opção esta activa.
    • Allow outbound“:  Permite que uma transacção distribuída iniciada localmente seja executada em uma outra máquina.
    • Enable XA transactions” e “Enable SNA LU 6.2 Transactions“: Activa/Desactiva estas especificações particulares de transações distribuídas.

Resolvendo problemas com o MS DTC
Existe uma tool chamada DTC Ping que pode nos ajudar a verificar se o DTC está funcionando correctamente em todos os computadores que deverão estar envolvidos em uma transacção.

Siga este link para efectuar o Download: http://www.microsoft.com/en-us/download/details.aspx?id=2868

Recomendo a leitura do seguinte artigo, para aprender como utilizar esta tool, assim como resolver possíveis error: Troubleshooting MSDTC issues with the DTCPing tool.

Outra optima tool é a DTC Tester. Aonde podemos simular transacções distribuídas utilizando o SQL Server:

Screen Shot 2014-01-03 at 14.15.25
Para fazer download siga este link: http://support.microsoft.com/kb/293799 .

Fim
Chegamos ao fim desta série. Existem muitas coisas para se falar sobre best practices e configurações particulares do SQL Server. Certamente iremos abordar estes assuntos nos próximos posts!

Obrigado pela leitura!!

    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 3

    Em continuação da série, iremos hoje entender como se adicionar um nó a uma instalação já feita, sendo esta uma instância em um nó ou mais.

    Para seguir com is passos seguintes, é obrigatório ter pelo menos um nó instalado. Caso queira começar a instalação do zero, leia a parte 2 desta série.

    Continuando… Conecte no nó em que a instalação será feita, no nosso caso W2012SRV04, e siga os seguintes passos:

    1. Com os mesmo binários utilizados na instalação anterior, clique em Setup.exe.

      Screen Shot 2013-12-09 at 12.38.54

    2. O “SQL Server Installation Center” Abrirá.

      Screen Shot 2013-12-09 at 12.39.28

    3. Ainda no “SQL Server Installation Center”, clique em “Installation” e selecione “Add node to a SQL Server failover cluster”.

      Screen Shot 2013-12-09 at 22.38.41

    4. Aguarde a verificação, e clique em “OK”.

      Screen Shot 2013-12-18 at 14.46.07

    5. O setup irá buscar por actualizações. Mantenha a opção “Include SQL Server product updates” marcada e clique em “Next”.

      Screen Shot 2013-12-09 at 22.39.51

    6. Outra verificação irá correr para identificar possíveis problemas. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.42.01

    7. Indique a chave e clique em “Next”.

      Screen Shot 2013-12-09 at 22.42.17

    8. Aceite os termos e clique em “Next”.

      Screen Shot 2013-12-09 at 22.42.28

    9. Agora confirme as definições de IP, assim como você fez no primeiro nó. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.45.02

    10. Indique as passwords para as contas de serviço do Engine e do Agent. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.45.36

    11. Como no nó anterior, você tem a opção de enviar relatórios de erro para a Microsoft. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.46.14

    12. Agora o setup irá verificar se o processo de instalação irá ser bloqueado durante a instalação. Clique em “Next” no fim desta verificação.

      Screen Shot 2013-12-09 at 22.46.26

    13. Reveja as opções escolhidas e clique em “Install”.

      Screen Shot 2013-12-09 at 22.46.47

    14. Agora tenha paciencia… A instalação está a ser feita :) Clique em “Next” quando estiver completa.

      Screen Shot 2013-12-09 at 22.47.00

    15. Sucesso! O nó agora faz parte da instância!! Verifique se todas as features foram instaladas correctamente. Clique em “Close”.

      Screen Shot 2013-12-09 at 22.56.08

    No fim desta instalação, você terá mais um nó disponível para correr a sua instância. Isso significa que podemos fazer failover do nó  W2012SRV03 para o nó W2012SRV04. Agora temos uma solução de high availability montada, que nós ajudará a recuperar em caso de falha de hardware.

    Por algum outro motivo, como em uma manutenção, você pode querer efectuar um failover manualmente. Para fazer isso abra o  Failover Cluster Manager (o mesmo utilizado no artigo anterior), clique com o botão direito sobre a Role do SQL Server (no nosso caso “SQL Server (DB)”) ae escolha a opção “Move”. Duas opção estarão disponíveis – “Best Possible Node” e “Select Node…”

    Ambas são válidas, mas a segunda te da a oportunidade de escolha o nó para o qual iremos mover a Role. O que é útil no caso de termos mais do que dois nós disponíveis.

    Screen Shot 2013-12-18 at 16.38.27
    É isso por hoje! Estarei de volta em breve com a última parte desta série, falando sobre MS DTC em instância em cluster.

    Até a próxima!!

    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 2

    Em continuação do nosso guia de instalação de uma instância de SQL Server 2012 em cluster, vamos agora começar a por as mãos na massa… Começando pelo primeiro nó!

    O objectivo deste segundo artigo é mostrar como instalar o primeiro nó de uma instância de SQL Server 2012 e como gerir a mesma de uma forma básica, utilizando a ferramenta Failover Cluster Manager.

    Para refrescar a nossa memória, esse á a nossa infra-estrutura:

    Screen Shot 2013-12-12 at 12.03.53

    Para mais detalhes sobre os pré-requisitos e uma explicação geral, de uma olhada na primeira parte desta série de artigos.

    A instalação:  Começando pelo primeiro nó

    Vamos lá! Se você ainda se recordar, nós temos dois passos a cumprir. Para já, iremos instalar uma nova instância em um dos nós, o que ira gerar uma nova “Role” no nosso WFC. Iremos trabalhar no nó W2012SRV03.

    Seguem os passos:

    1. Com a media do SQL Server disponível, clique em “Setup”, como na image abaixo:Screen Shot 2013-12-09 at 12.38.54
    2. O “SQL Server Installation Center” irá abrir. Clique em “Installation” no menu a esquerda e, de seguida, em “New SQL Server Failover Cluster Installation”:
      Screen Shot 2013-12-09 at 12.39.28
    3. O instalador irá varrer o sistema em busca de algum possível constrangimento que impossibilite a instalação. No fim, clique em Ok.
      Screen Shot 2013-12-09 at 16.22.39
    4. Neste passo novas actualizações serão buscadas. Recomendo que estas sejam incluídas na instalação. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.23.21
    5. Agora os ficheiros de supporte ao setup serão extraídos e instalados. Clique em “Install”.
      Screen Shot 2013-12-09 at 16.25.48
    6. Finalmente temos o setup pronto. Agora mais um check será executado para validar problemas com a instalação do SQL Server. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.26.54
      Boa prática:
      Recomenda-se que exista um recurso MS DTC em cluster, assim como um recurso MS DTC dedicado a cada grupo do SQL Server.
      Segue um bom artigo sobre este tema: http://blogs.msdn.com/b/cindygross/archive/2009/02/22/how-to-configure-dtc-for-sql-server-in-a-windows-2008-cluster.aspx

    7. Neste passo, mencione a chave do SQL Server e clique em “Next”.
      Screen Shot 2013-12-09 at 16.29.32
    8. Selecione a check box ao lado de “I accept the license terms” e clique em “Next”.
      Screen Shot 2013-12-09 at 16.30.08
    9. Para instalar uma instância de SQL Server, escolha a opção “SQL Server Feature Installation”. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.31.27
    10. Aqui nós temos algumas opções para instalar features, divididas em dois grupos:  “Instance Features” e “Shared Features”.
      Em “Instance Features” escolha “Database Engine Services”.
      Em “Shared Features” escolha “Management Studio (complete)”. mais um ponto importante aqui é o disco/directoria que as “Shared tools” serão instalados. Uma boa prática é ter um disco local dedicado a estes binários do SQL Server. Neste caso, estarei utilizando o disco de sistema,  pois este é o meu laboratório, mas isso não é uma boa prática para ambientes produtivos! Clique em “Next”.Screen Shot 2013-12-09 at 16.38.20
    11. Neste passo, mais um check tentará identificar possíveis problemas na instalação das features seleccionadas. Aguarde o fim e clique em “Next”.
      Screen Shot 2013-12-09 at 16.39.02
    12. Este é um passo importante. Aqui será definido o Network Name da instância (um dos requisitos ditos no artigo anterior), assim como se iremos utilizar uma instância nomeada ou não e a directoria raiz da instância.
      Pontos a se considerar aqui:
      – Como vemos em “Detected SQL Server instances and Features on this computer” eu já tenho uma outra instância instalada. Então tenho que instalar uma instância nomeada e alterar o Instance ID para evitar conflitos.
      – Baseado na informação acima, para conectar na instância teremos que indicar o seguinte: SQL04DB.
      –  Outro ponto importante aqui é o “Instance root directory”: Como já disse anteriormente recomendo o uso de um disco dedicado aos binários do SQL Server. Evite utilizar o disco de sistema para este fim.
      Preencha todos os pontos e clique em “Next”.
      Screen Shot 2013-12-09 at 16.46.40
    13. Neste passo temos apenas uma verificação de que os nossos requisitos de espaço em disco estão ok. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.47.02
    14. Agora devemos escolhe o nome do Cluster Resource Group a ser criado. O instalador sugere um nome, porém podemos altera-lo.
      Também podemos ver os nomes reservados e já utilizados. Escolha o seu nome preferido e clique em “Next”.Screen Shot 2013-12-09 at 16.47.37
    15. Agora os discos! Mais um dos requisitos… neste ponto nós teremos a informação de todos os discos que fazem parte do cluster, assim como os que estão disponíveis ou não. Para esta demo, criei apenas uma LUN, por conta disso tenho apenas um disco no meu cluster (meu Quorum é uma fileshare :). Seleccione o(s) disco(s) necessários e clique em “Next”.Screen Shot 2013-12-09 at 16.50.23
    16. Você se lembra de que mais um dos requisitos era um IP? Pois é.. chegou a hora de utiliza-lo!! Seleccione a rede desejada (que o IP faz parte), desmarque a opção DHCP e preencha o IP na coluna “Address”.
      E … “Next”!
      Screen Shot 2013-12-09 at 16.56.12
    17. Segue aqui o nosso último requisito: Contas de Serviço. Preencha a informação sobre as contas do SQL Server Engine e Agent (login e password).
      Nota: Para uma instância em cluster, o “Startup Type” deverá ser “Manual”. O Cluster Service irá ser o ponto de gestão dos serviços.
      Clique em “Next”.
      Screen Shot 2013-12-09 at 17.03.20
    18. No mesmo passo, Temos outra tab onde podemos definir a collation do nosso engine. Por padrão temos “Latin1_General_CI_AS”.
      Para mais info sobre collations clique aqui. Esta é uma escolha importante que, se for mal definida, irá gerar uma grande dor de cabeça para ser alterada após a instalação.Screen Shot 2013-12-09 at 17.05.59
    19. Agora precisamos definir o modo de autenticação da nossa instância.
      As opções são “Windows Authentication”, que tirará benefício dos logins da AD e do Windows  , outra opção é “Mixed Mode”, que além dos benefícios da anterior adiciona logins geridos pelo SQL Server (menos seguros). Se você escolher “Mixed Mode” um login chamado “sa”, membro da fixed server role “Sysadmin” será activado. Por esta razão você terá que definir uma password para este login. na caixa abaixo, devemos definir todos os logins (AD e Windows) que terão acesso como Sysadmin a instância.Screen Shot 2013-12-09 at 17.10.25
    20. Agora é hora de definir a estratégia dos nosso discos.
      Este é um passo que merece um artigo por si só…. Estou utilizando apenas um disco neste guia, mas a recomendação é utilizar um disco para casa ponto.
      A regra geral é: Quanto mais espalhado melhor.
      Podemos user o seguinte layout:
      Screen Shot 2013-12-16 at 17.02.52

      Deste layout, o unico que não podemos definir de raiz é o disco para guardar os non-clustered indexes (mais um tema para artigo aqui).
      Pontos chaves deste assunto:

      • isolar a TempDB em um disco rápido. Lembre-se: Apartir do SQL Servr 2012 podemso alocar nossa TempDB em um disco local para instalações em cluster!
      • Coloque os ficheiros de dados e de logs em discos separados.
      • Peça para a equipa de storage discos com o nível de RAID apropriado.
      • Atenção ao offset das partições e tamanho dos blocos, mesmo em instalações superiores a Windows 2008.

      Após considerar todos estes pontos, preencha os campos e clique em “Next”.
      Screen Shot 2013-12-09 at 17.10.25

    21. Aqui você irá definir se enviará os erros para a Microsoft ou não, para melhorias no produto. Clique em “Next”.Screen Shot 2013-12-09 at 17.11.40
    22. Neste passo, será verificado se a instalação poderá ser bloqueada. Após os check, clique em “Next”.Screen Shot 2013-12-09 at 17.12.21
    23. Reveja as opções escolhidas, se estiver de acordo clique em  “Install”.
      Screen Shot 2013-12-09 at 17.12.32
    24. Aguarde pela instalação.
      Screen Shot 2013-12-09 at 17.13.21
    25. Nesta janela teremos a confirmação se as features foram instaladas correctamente ou não.
      Screen Shot 2013-12-09 at 17.20.21

    Nesta segunda parte, nós passamos por todos os passos para instalar o primeiro nó de uma instância em Cluster. Obviamente no seu ambiente existirão pequenas diferenças, mas passamos por todos os passos necessários para a instalação do primeiro nó.

    O próximo passo agora será a adição dos outros nós a esta instância já criada no WFC.

    Para gerir uma instancia em cluster, devemos utilizar a ferramenta Failover Cluster Manaeger.

    Utilizando o Failover Cluster Manager
    Como já temos um nó da nossa instância em cluster instalado, precisamos agora de gerir seus recursos e o Failover Cluster Manager é a ferramenta que suporta estas acções.

    Siga os seguintes passos para abrir o FCM:

    • Clique em “Windows Key”+R.
    • Escreva “cluadmin.msc” e clique em “Ok”.
    • O Windows Failover Cluster será aberto.

    Screen Shot 2013-12-17 at 12.39.52

    Na imagem acima, podemos ver duas “Roles”, representando duas instâncias em cluster. A Role com nome de “SQL Server (DB)” é a que nós acabamos de instalar.

    Seleccione esta Role para ver seus recursos (resources), como IPs, Discos, Serviçoes, etc..

    Neste ponto, temos a instância em cluster instalada em um nó apenas, então não temos a opção de fazer um failover para outro nó!

    Para parar o serviço do SQL Server, o que irá parar o serviço do Agente que é seu dependente, clique com o botão esquerdo sobre o serviço do SQL Server Engine e siga o demonstrado na imagem:

    Screen Shot 2013-12-17 at 12.49.06

    Para iniciar a instância, faça o mesmo, mas escolha a seguinte opção:
    Screen Shot 2013-12-17 at 12.51.49
    Nota: Quando o SQL Server é iniciado, o serviço de Agente deve ser iniciado manualmente. Para reduzir os passos necessários, o mais fácil é iniciar o serviço do SQL Server pelo Agent. Mas porque isso? Como o SQL Server Agent depende do Engine para funcionar, se enviarmos o comando para o Agent ser iniciado, o WFC irá levantar a sua dependência, no caso o SQL Server Engine. Assim em um passo levantamos dois serviços.

    Outra questão muito importante são as dependências do SQL Server.

    Para verificar as dependencias:

    • Clique com o botão esquerdo no serviço do SQL Server Engine.
    • Clique em Properties.
    • Seleccione a tab “Dependencies”.
    Screen Shot 2013-12-17 at 13.11.50
    Desta forma podemos ver todos os recursos dos quais o SQL Server engine é dependente. Olhando para imagem, verificamos que se ambos “Cluster Disk 1″ ou “SQL Server network name (SQL04)” falharem, a nossa instância irá efectuar um failover ou parar!!

    Todos os recursos de cluster podem ter dependências baseadas em outros recursos. Por exemplo, “SQL Server network name (SQL04)” é dependente do IP. Se o IP falhar, o “SQL Server network name (SQL04)” irá ficar offline. Por sua Vez o SQL Server é dependente do “SQL Server network name (SQL04)”… Assim no final desta cadeia de dependências, o SQL Server irá parar porque o recurso de IP falhou.

    O que tirar daqui?
    Verifique as dependências e condições, pois uma configuração apropriada poderá aumentar a taxa de disponibilidade da instância.


    Um exemplo prático:
    Discos de backup são importantes, mas não vitais para o serviço do SQL Server. Porém, se o SQL Server depender do disco de backup e este falhar, o SQL Server irá parar. Isso não faz sentido.
    Tirando a dependência do disco de backup, os backups podem falhar, mas o serviço continuará online. Desta forma podemos corrigir o problema do disco sem efeitos colaterais para o cliente final.

    Então, de atenção a estas opções!

    Próximos passos?
    Ao completar este segundo passo, nós já temos uma instância em cluster a funcionar em um nó… Precisamos completar isso!

    Irei postar mais duas partes:

    • Adicionar outro nó a uma instalação de uma WFCI
    • Configuração de um MS DTC dedicado a Role do SQL Server.

    Se você perdeu o primeiro artigo da série, fica o link:
    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 1

    Até a próxima!

    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 1

    Introdução
    Neste artigo irei mostrar como é feita a instalação de uma instância de SQL Server 2012 em cluster. No nosso caso iremos utilizar um cluster com dois nós.

    No geral, a instalação e divide em duas partes distintas:

    1. Instalação de uma nova instância em cluster.
    2. Adição dos outros nós a instância já instalada (no ponto 1).

    Para um cluster com mais do que dois nós, o segundo ponto será executado em todos os nós, excepto o que foi utilizado para a execução do ponto 1.

    O que é uma inst|ancia em cluster?
    Basicamente, uma instância em cluster é uma instalação do SQL Server engine e agent baseada no serviço de Windows Failover Cluster (WFC). O motivo principal de um serviço de WFC é proteger nosso sistema de falhas de hardware.

    Em um cenário de um cluster com dois nós, estamos a falar de dois servidores, como configurações de hardware similares, ligados por um serviço de WFC. Tendo uma instância de SQL Server instalada sobre esta solução, podemos chamar esta instância de Clustered Instance, ou Instância em Cluster.
    Esta instância em cluster, poderá estar activa em apenas um nó, ficando os outros nós IDLE, a espera de um possível failover.

    Outro ponto importante é o facto de que o WFC aceita storage partilhado, tipicamente SAN, para guardar os ficheiros das bases de dados. Porém, os binários gerados pela instalação do SQL Server deverão ficar em um disco local, pertencente ao nó em questão.

    Além da SAN, podemos também utilizar SMB Fileshares para uma instalação em cluster. Clique aqui para mais informações.

    Também apartar do SQL Server 2012, podemos alocar a nossa TempDB em um disco local, o nos garante alguns benefícios.

    Baseado nas informações dadas, conseguimos perceber que o WFC é uma solução e alta disponibilidade (HA), e isso não inclui balanceamento de carga (LB) ou recuperação de desastres (DR). Para atingirmos um nível em que as três solução estarão em conjunto, o AlwaysON é uma excelente solução.

    Pressuposto
    Estarei assumindo que neste ponto nós já temos um cluster montado, com dois ou mais nós.
    Normalmente os DBAs recebem o ambiente pronto, criado pelos administradores de sistema. De qualquer forma, após esta série, irei escrever um ártigo de como se criar um cluster de dois nós do zero. Fique ligado!!

    Pré-Requisitos
    Antes de começarmos, temos que ter os seguintes pontos garantidos:

    • Um hostname virtual. No nosso exemplo usaremos: “SQL04″.
    • Um IP virtual, a.k.a vIP. No nosso exemplo usaremos: 192.168.123.124.
    • Shared Storage disponível. A boa prática é ter, pelo menos, um disco dedicado aos ficheiros de dados, outro para logs e uma para a TempDB. Essa seria uma configuração mínima aceitável para produção. No nosso exemplo irei utilizar um disco para tudo, mas isso é um péssima ideia.
    • Contas de Serviço: 
      • Uma para o SQL Server Engine outra para SQL Server Agent (boa prática). 
      • Usaremos as seguintes contas: SSLABSVCSQLSRVENG e SSLABSVCSQLAGT.
      • Atenção: as contas de serviço são contas de domínio. Não existe outra hipótese, nosso cluster deverá fazer parte de um domínio!

    Nosso Ambiente
    Neste guia, iremos utilizar o seguinte ambiente, baseado em máquinas virtuais:

    • Dois nós com Windows Server 2012 R2:
      • W2012SRV03 – 192.168.123.205
      • W2012SRV04 – 192.168.123.206
    • Ambos os nós irão fazer parte do seguinte cluster:
      • W2012CLT02 – 192.168.123.111
    • Storage:
      • Como estou utilizando um ambiente de laboratório, A minha SAN é uma Synology Diskstation. Apenas para informação, o IP da SAN é: 192.168.123.103.
    • Para o SQL Server:
      • Virtual Hostname – SQL04
      • vIP – 192.168.123.124
      • Versão do SQL Server: Microsoft SQL Server 2012 (SP1) – 11.0.3128.0 (X64)  -  Enterprise Edition


    Permissões para o login utilizado durante a instalação
    Para instalar o SQL Server, estarei utilizando um login pertencente ao domínio, SSLABDBA.
    Este login tem permissões administrativas em anos os nós do cluster (W2012SRV03 e W2012SRV04). 
    o login “SSLABdba” é um simples utilizador do domínio e não tem nenhum privilégio especial no domínio SSLAB.

    Próximo post
    Fica já marcado para a próxima terça-feira a continuação deste artigo. Passaremos finalmente para o primeiro passo: “Instalação de uma nova instância em cluster”.

    Até a próxima!!

    SMB File Share e SQL Server: Uma opção a se considerar

    Introdução
    Quando relacionamos file shares e bases de dados, muitas pessoas torcem o nariz – mas hoje a realidade é outra, e pormos utilizar file shares, em alguns casos, em produção.
    A Microsoft passou os últimos anos a trabalhar em melhorias no SMB (Service Message Block), que passou a ser muito mais confiável hoje em dia.

    No passado, era possível a utilização de shares para alojamento de ficheiros dados e logs, porém a trace flag 1807 deveria estar activa. De qualquer maneira, isso não era oficialmente suportado, por conta do risco de que erros na rede pudessem danificar a integridade das base de dados, alem de implicações a nível de performance.

    Hoje em dia a realidade é diferente. Apartir do SQL Servr 2012 é possível utilizar file shares de forma suportada para alojar as bases de dados de sistema, assim como user databases. Isso tudo graças as melhorias de feitas no SMB durante os últimos anos. E ainda melhor! Esta opção se aplica a instâncias stand-alone e em cluster ! Aliás, hoje em dia é possível se criar um cluster inteiro baseado em file shares (mesmo para o Quorum do WFC).

    Em cada versão do Windows, uma versão nova do SMB “vem agarrada”, e no actual Windows Server 2012 R2 nós já estamos na versão 3.02, mas foi na versão 3.0 que as grandes melhorias a nível de performance e funcionalidade vieram.

    Segue uma lista com as versões do Windows e SMB e a melhoria mais relevante trazida, no meu ponto de vista:

    • Windows Server 2008 (SMB 2.0)
      Durabilidade, que ajuda na recuperação de falhas ma rede.
    • Windows Server 2008 R2 (SMB 2.1)
      Melhorias de performance significantes, focando em estilos de carga como OLTP.
    • Windows Server 2012 (SMB 3.0)
      Suporte a failover transparente da file share, com zero downtime.
    • Windows Server 2012 R2 (SMB 3.02)
      O MTU vem activo por padrão, o que melhora significativamente a performance de grandes ficheiros sequenciais, a exemplo de data warehouse além de backups ou restores.


    Como funciona?

    Para começar a utilizar file shares para alojar as suas bases de dados, algumas regras devem ser seguidas. Para começar, as contas de serviço do SQL Server Engine a Agent devem ter FULL CONTROL  e permissões NTFS nas pastas partilhadas.

    Outra informação importante é sobre os Universal Naming Convention (UNC) suportados:

    • \ServerNameShareName
    • \ServerNameShareName

    Já os seguintes  não são suportados:

    • Não podemos utilizar loopback, ou seja, a share não pode pertencer a nenhum dos nós do cluster.
    • Shares administrativas, como \\servername\x$
    • Outros formatos de UNC, como \\?x:\
    • Network drives mapeados.

    O processo de se instalar uma instância utilizando SMB é tão simples quanto indicar a UNC ao invés de um disco mapeado por uma letra, como se mostra na imagem abaixo:


    outra opção é executar o comando “CREATE DATABASE” apontando para os ficheiros de dados e log que estão na rede:

    Note que para instalações de cluster as file shares não irão fazer parte do grupo do SQL Server, ou seja, não serão controladas pelo cluster.


    Atenção!

    Ao se utilizar file shares como opção de storage, a performance da rede passa a ser mais do que crítica. Em uma situação normal, nós já temos um bom trafego na rede, mas agora temos um tempero a mais – o acesso aos ficheiros é feito pela rede!

    Então o que se fazer? 
    Eu tenho duas sugestões:

    1. Criar uma rede dedica para acesso a file share. Desta forma a conexão dos clientes a instância, seus acessos RDP, a transferencias de ficheiros (como SP ou Hot-fixes) não irá interferir com o acesso aos dados.
    2. Monitorar! Como não temos controle do que acontece no servidor de file share, temos que monitorar o máximo possível, desta forma podemos despistar problemas. Podemos monitorizar os seguintes pontos:
      • Contadores do disco.
      • Utilização do CPU.
      • Utilização da memória.

    Para finalizar, como podemos aproveitar esta possibilidade?

    Antes de qualquer coisa, em um ambiente em cluster,  a utilização da SAN é a melhor opção, assim como em standalone discos locais são preferíveis.

    De qualquer forma, o uso do SMB pode ser benéfico em alguma situação específicas:

    • Montar instancias low-cost em cluster.
    • Servidores não produtivos ou de DR.
    • Alojamento de uma Bases de dados leve.
    • Ficheiros de dados com histórico.
    • Storage temporário – para emergências.
    • Migrações.

    Em Resumo
    Temos hoje mais uma opção para alojar as nonas bases de dados, para infâncias em cluster ou standalone. De qualquer forma, devemos planear com cuidado as nossas estratégias, porque infelizmente, o melhor ainda é moais custoso (€€).
    Tudo depende do orçamento, do propósito das bases de dados e suas características.

    Espero que o artigo tenha sido útil!

    Até a próxima!!