Como alterar a collation da minha instância?

Introdução

Durante o meu dia de trabalho, tive a necessidade de alterar a collation de uma instância de SQL Server 2012. A causa era simples: Esta instância seria o DR de uma outra instância com uma collation diferente.

Principais consequências em alterar a collation
Infelizmente, para alterar a collation de uma instância é necessário fazer rebuild da base de dados de sistema “master”. Sim, a MASTER. E isso significa perder muita coisa…. como o os logins e o tracking das BDs montadas na instância (as BDs não são apagadas!).
Como faço para alterar a collation?
Temos duas opções:
  1. O referido rebuild da master.
  2. Reinstalar a instância.
Temos que medir o esforço e o tempo de indisponibilidade das duas opções, para fazer uma boa escolha…Isso varia dependendo da situação.
Aqui irei falar da opção 1 – O rebuild da master.
Basicamente o rebuild é uma tarefa simples. O seguinte comando deverá ser executado:

Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=<ID da instância> /SQLSYSADMINACCOUNTS=<Contas de dominio que serão Sysadmin separadas por virgula> [/SAPWD=<Password para a conta SA, se aplicável>] /SQLCOLLATION=<Nova Collation>

Exemplo:
Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS= DOMAINUser1,DOMAINUser2 /SAPWD=!37gh78ge /SQLCOLLATION=Latin1_General_CI_AS

Alguns factos importantes:

  • O comando deverá ser executado na console do Windows (cmd), na pasta que se encontram os binários de instalação do SQL Server.
  • O parâmetro “/INSTANCENAME” não é o nome da instância, e sim o seu ID.
    • Isso poderá ser descoberto ao executar o seguinte comando:
    • SELECTISNULL(ServerProperty(‘InstanceName’),‘MSSQLSERVER’)InstanceName
  • O serviço deverá estar offline.
  • Depois da execução do comando, o seguinte será mostrado, se o comando for bem sucedido:
    Microsoft (R) SQL Server 2012 11.00.2100.60
    Copyright (c) Microsoft Corporation.
    All rights reserved.
  • No caso de erro, uma mensagem será gerada, assim como um ficheiro com mais detalhes

Sumário

  • Se a instância é nova e o “problema” foi descoberto a tempo, esta tarefa é relativamente simples.
  • Se a instância já estiver bem consolidada, com logins, bases de dados, linked servers, etc… Teremos muito trabalho pela frente.
    • Se este for o seu caso, este link vai ajudar bastante na tarefa de guardar as definições da master.

 

 

Como apagar backups (.bak e .trn) arquivados pelo agente de backups?

Introdução

Muitas empresas utilizam agentes para fazer backups directamente do SQL Server, como o NetBackup, CommVault, etc…

Os agentes podem fazer o backup de uma forma directa, acedendo a instância de SQL Server, porém muitos DBAs preferem fazer o backup utilizando o SQL Server e passando os ficheiros para disco. Desta forma o agente irá buscar os ficheiros de full backup e log backup no disco.

As a principais vantagens da segunda abordagem são:

  • O controle dos backups continua nas mãos dos DBAs.
  • Os ficheiros estarão acessíveis em disco por um tempo definido, não sendo necessário envolver a equipe de backups, caso seja necessário efectuar um restore para uma janela temporal recente.
    • Ainda dentro deste ponto: Os ficheiros estarão no próprio servidor, não sendo necessário transferir uma grande quantidade de dados pela rede.
Na utilização desta abordagem, deve-se ter em atenção:
  • A periodicidade na qual o agente de backup irá buscar os ficheiros em disco.
    • Isso afecta o RPO (Recovery Point Objective).
  • O período de retenção dos ficheiros em disco.
    • Quanto mais melhor… Porém isso é limitado pelo espaço disponível para este fim.
    • Esta decisão afecta o RTO (Recovery Time Objective).
Mas afinal como limpar os ficheiros do disco de uma forma eficiente?
Sempre que o agente de backups copia um ficheiro, um propriedade “Archive” é alterada para false (o valor default é true). Baseado nisso, podemos identificar os ficheiros que já foram arquivados e remove-los.
O seguinte script em Power Shell faz exactamente isso (obrigado pela ajuda Laerte)!

dir ‘D:Backups’ -r -include ‘*.bak’, ‘*.trn’ | where {$_.attributes -match “Normal”} | Remove-Item -Force

Para testar, adicione -WhatIf no fim:

dir ‘D:Backups’ -r -include ‘*.bak’, ‘*.trn’ | where {$_.attributes -match “Normal”} | Remove-Item -Force -WhatIf

Criei um script que basicamente executa este comando num schedule definido. Faça download aqui.

Apenas altere a seguinte linha, definindo o valor do root folder dos backups:

SET @backup_files_root = N’d:sql_backup’ — Define the backup root folder

Após a criação do job, será necessário adicionar um schedule, que definirá a retenção dos ficheiros em disco.

Sumário

Utilizando esta solução conjunta com PowerShell e SQL Server Agent podemos atingir o objectivo de controle da retenção dos ficheiros de backup em disco. Neste pequeno artigo passei uma solução básica, mas que ainda poderá ser melhorada e adaptada as requerimentos do seu ambiente.

 

Espero ter ajudado! Até a próxima :)

Análise de backups

Introdução

Muitas vezes temos problemas com backups, mas na verdade o problema não é a operação de backup em sí ou o SQL Server. O grande vilão dos backups é o espaço reservado para esta operação.

Para um maior sucesso nestas operações, temos que levar em conta alguns factores, como tempo de retenção e o crescimento da base de dados.

Sobre o Script

O script que trago hoje ajuda neste trabalho, trazendo informações historiais sobre o tamanho do ficheiro de backup, o tempo que o backup leva para completar e é ainda o possível estimar o tamanho do backup, caso a opção de backup compression esteja activa.

Este script tem várias utilidades, e uma delas é verificar um padrão de crescimento do backup das bases de dados, o que permite prever as necessidades de disco no futuro. Outra possibilidades é o cálculo do tempo necessário estimado para a janela de backups, além de ser possível verificar se a activação do backup compression pode trazer ou não benefícios, em termos de espaço em disco.


SELECT TOP 30 database_name, 
              CASE
                WHEN type = 'D' THEN 'Full Backup'
                WHEN type = 'L' THEN 'Log Backup'
                WHEN type = 'D' THEN 'Database'
                WHEN type = 'I' THEN 'Differential database'
                WHEN type = 'L' THEN 'Log'
                WHEN type = 'F' THEN ' File or filegroup'
                WHEN type = 'G' THEN 'Differential file'
                WHEN type = 'P' THEN 'Partial'
                WHEN type = 'Q' THEN 'Differential partial'
              END
              AS backup_type, 
              backup_start_date, 
              backup_finish_date, 
              CONVERT(CHAR(5), backup_finish_date - backup_start_date, 108) 
              AS elapsed_time, 
              Cast(( backup_size / 1024 / 1024 ) AS DECIMAL(38, 2)) 
              AS backup_size_in_mb, 
              Cast(( compressed_backup_size / 1024 / 1024 ) AS DECIMAL(38, 2)) 
              AS
              compressed_backup_size_in_mb 
FROM   msdb..backupset 
ORDER  BY database_name, 
          backup_set_id DESC
Para fazer download do script clique aqui.

Sumário

Neste artigo foi passado uma forma de analisar o histórico de backups, de forma a recolher dados importantes para se traçar uma boa estratégia de backups.

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!!