P&R do SQLClusters internos, paradas misteriosas, a conta SA e muito mais

Editado por Nancy Michell

P Preciso entender melhor como funcionam os clusters. Nosso ambiente consiste no Windows Server® 2003 de 64 bits executando SQL Server™ 2005, um Web farm SSRS (SQL Server Reporting Services) — implantação de escalonamento horizontal de servidores de relatórios —, um servidor de catálogo TempDB SSRS e um SQL Server que bombeia dados de um banco de dados de terceiros por meio de um servidor vinculado e armazena os dados para SSRS.

Queremos um cluster de 3 nós ativo/ativo/passivo. Node1 seria ativo e armazenaria os dados bombeados do banco de dados de terceiros. Node2 seria ativo e armazenaria o catálogo SSRS. Node3 seria passivo e funcionaria como um failover para Node1 ou Node2. Você pode nos ajudar?

R Infelizmente, muitas pessoas se enganam com os termos ativo/ativo e ativo/passivo em relação aos clusters do SQL Server. Elas pensam que os clusters SQL oferecem suporte ao escalonamento horizontal ("scale-out") de uma instância SQL ou banco de dados em vários servidores. Não é o caso. No SQL Server, não existe uma instância ou um banco de dados ativo/passivo. Uma "instância" é uma instalação de SQL Server com bancos de dados correspondentes. Nossa instância de cluster por SQL Server é ativa (1) para passiva (n) sempre (observe que o valor de n varia de 1 a 7, conforme a versão do SQL Server). É por isso que eles são chamados de clusters de failover.

Depois de entender isso, as pessoas podem começar a considerar a instalação de várias instâncias de clusters de failover em um conjunto de nós. Por exemplo, três servidores físicos usando discos compartilhados poderiam ter uma instância ativa por padrão no Node 1 e uma segunda instância ativa por padrão no Node 2, e as duas poderiam falhar no Node 3. As instâncias são totalmente separadas; elas não compartilham dados e não são ativas/ativas. Elas são ativas/passivas e compartilham a mesma instância failover. Se as duas instâncias falharem no Node 3, então o desafio com o tempo será saber se ele suportará a carga. Por design, o failover é criado para usar o mesmo poder de processamento para o failover. Se o pico de carga exigir dois nós para processamento sob condições de operação normais, dificilmente o Node 3 sobreviveria sob o pico de carga atribuído aos dois nós.

Dito isso, devido ao custo relativo de hardware capaz de executar um cluster, é compreensível que as pessoas considerem a possibilidade de os dois nós principais falharem simultaneamente e forçarem a carga inteira em um nó. Levando isso em conta, elas podem tomar a decisão mais econômica de assumir o risco, em vez de investir em uma capacidade de failover de 100%.

Felizmente, tenho uma boa notícia: o SQL Server 2005 oferece muito mais opções para alta disponibilidade, incluindo alternativas que possam falhar mais rapidamente do que um cluster e possam até mesmo significar cópias duplicadas de dados (os clusters contam com uma única SAN). As opções incluem espelhamento, replicação ponto a ponto e outras. Com essas novas alternativas, temos muito mais opções para satisfazer qualquer tipo de necessidade, incluindo algumas que combinem recursos de alta disponibilidade.

O Microsoft® Cluster Configuration Validation Wizard (ClusPrep), agora disponível para download, substitui o antigo teste HCL (lista de certificação de hardware), que poderia levar meses para validar uma configuração completa e considerá-la "com suporte" em clusters. Isso deixa a ferramenta de validação de hardware nas mãos do DBA, reduzindo o custo (em termos de dinheiro e tempo) de colocar um hardware certificado em funcionamento. Talvez até seja possível validar e implantar um hardware heterogêneo dentro de um conjunto de nós de cluster.

P Um procedimento de exclusão em um dos meus computadores parece estar parado depois de 12 horas. Não está bloqueado. O plano de consulta mais lento revela um disparador sendo executado por 87,327 segundos. Por isso, suponho que o procedimento tenha parado nesse disparador. Como saber exatamente qual declaração parou?

R É bem possível que um loop dentro do disparador não esteja saindo por diversos motivos. Se a parada for muito longa e você desejar saber qual instrução está em execução, execute o código da Figura 1. Ele dirá qual instrução está em execução no momento; provavelmente, é ela que está causando a parada do computador.

Figure 1 Localize a instrução atualmente em execução

-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20), 
        @start int, 
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle, 
        @start = stmt_start, 
        @end = stmt_end 
FROM Master..sysProcesses(NOLOCK) 
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

P Preciso oferecer suporte à replicação transacional por meio de um firewall. O editor e o distribuidor estão fora do firewall e o assinante está dentro. O assinante está definido para escutar em 1433, e os nomes do meu computador são: Editor: PUBMACHINE; Distribuidor: DISTMACHINE; Assinante: SUBMACHINE. Que portas preciso abrir para permitir que a captura de tela inicial e o envio da inscrição sejam bem-sucedidos?

R Se você estiver usando uma inscrição de envio, abrir a porta (1433 no seu caso) do SQL Server deve ser suficiente, pois o agente de distribuição estará sendo executado no computador distribuidor (fora do firewall) e provavelmente terá acesso local aos arquivos de instantâneos gerados pelo Snapshot Agent. Mas, se você estiver usando uma inscrição de recebimento, o agente de distribuição no computador assinante precisará acessar os arquivos de instantâneos, de alguma forma, por meio do firewall. A seguir, veja as opções que você pode considerar.

Supondo que os arquivos de instantâneo já estejam acessíveis em um compartilhamento de arquivos fora do firewall, você pode abrir a(s) porta(s) de compartilhamento de arquivos do Windows® por meio do firewall para que o agente de distribuição executado dentro do firewall possa acessar os arquivos de instantâneos localizados fora (mas cuidado com implicações de segurança que isso pode acarretar para outras partes da sua infra-estrutura). Observe que, ao configurar um caminho local como o local de instantâneos padrão (SSMS padrão), será necessário usar a opção /AltSnapshotFolder do agente de distribuição para substituir o local de retirada de arquivos de instantâneo.

Você também pode configurar a replicação para que use FTP ao transferir arquivos de instantâneos (e, para isso, terá de abrir a porta 21).

P Gostaria de saber se existe alguma desvantagem em desabilitar a conta SA no SQL Server 2005 e se isso representa um ganho real em termos de segurança. Existe um white paper sobre essa questão?

R Em uma nova instalação do SQL Server 2005, quando o Modo Misto não está habilitado, a conta SA é desabilitada, por padrão, e uma senha aleatória é gerada para ela. Você também pode desabilitá-la manualmente. Não existe um white paper sobre isso, mas a questão de desabilitar e renomear logons é discutida em um documento de práticas recomendadas.

Para se proteger de tentativas de obtenção de acesso à conta SA, você também pode renomeá-la. Mas não se esqueça de que, se habilitar uma conta desabilitada, será necessário definir uma nova senha para ela.

Para responder à questão de representar um verdadeiro ganho de segurança, lembre-se de que a segurança adicional ao desabilitar a conta vem do fato de que é inútil tentar adivinhar a senha de uma conta desabilitada. Por mais tempo que um hacker ou vírus tenha, um ataque frontal contra uma conta bloqueada não terá êxito. O ato de renomear ou desabilitar a conta SA interromperá os aplicativos que dependem dela para sua conectividade. De qualquer forma, encontrar e corrigir ou eliminar esses aplicativos deveria ser considerado uma prioridade. Conforme mencionado, a conta não pode ser usada para se conectar ao banco de dados enquanto não for reabilitada. Além disso, como o processo de autenticação falha primeiro, uma tentativa fracassada exigirá menos do sistema atacado.

P Um de meus maiores bancos de dados OLTP (processamento de transações online) possui um arquivo de log com o dobro do tamanho do arquivo de dados. Tentei usar os seguintes comandos para que o arquivo de log tivesse um tamanho razoável, mas preciso reduzi-lo ainda mais:

backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

R Você deve alterar o banco de dados de backup para uma instrução de log de backup. Se preferir, você pode colocar o banco de dados em um modo de recuperação simples e emitir a instrução shrinkfile. Depois de concluir a redução do log, defina o banco de dados com seu modelo de recuperação anterior e faça backup do banco de dados. Se ainda assim ele não for reduzido, verifique se não há alguma transação aberta (use dbcc opentran). O seguinte artigo da Base de Dados de Conhecimento fornece mais informações: support.microsoft.com/kb/907511.

P Se ocorrer um failover durante um trabalho programado do SQL Server Agent, o que acontecerá com esse trabalho depois? Precisarei reiniciá-lo manualmente?

R Sim, você terá de iniciá-lo manualmente se não tiver outro processo disponível. Para não precisar reiniciar os trabalhos manualmente, você pode escrever um script que atualize uma tabela após a conclusão do trabalho. Se o valor for = 1, o trabalho foi executado; qualquer outro valor indica que ele não foi concluído e um segundo trabalho acontecerá posteriormente e emitirá o comando start. Assim, embora os trabalhos devam ser executados novamente quando ocorre um failover durante sua aprovação, ao escrever um script, você pode aliviar a preocupação com aqueles trabalhos cruciais no meio da noite que, invariavelmente, precisam ser concluídos antes do próximo dia útil.

Dica: atualização e DBCC UPDATEUSAGE

Você está fazendo a atualização do SQL Server 2000 para o SQL Server 2005?

Nesse caso, não deixe de executar o DBCC UPDATEUSAGE assim que seus bancos de dados forem atualizados.

O DBCC UPDATEUSAGE relata e corrige imprecisões de contagem de páginas e de linhas nas exibições de catálogo. Essas imprecisões precisam ser corrigidas porque podem causar relatórios de uso de espaço incorretos a serem retornados pelo procedimento armazenado do sistema sp_spaceused. No SQL Server 2005, esses valores são sempre mantidos corretamente, de forma que esses bancos de dados nunca experimentem contagens incorretas. Entretanto, os bancos de dados atualizados para o SQL Server 2005 podem ter contagens inválidas e, por isso, você deve executar o DBCC UPDATEUSAGE após a atualização.

Veja como o DBCC UPDATEUSAGE funciona. Ele corrige as contagens de linhas, páginas usadas, páginas reservadas, páginas de folha e páginas de dados para cada partição em uma tabela ou em um índice. Se não houver imprecisões nas tabelas do sistema, o DBCC UPDATEUSAGE não retornará nenhum dado. Se imprecisões forem encontradas e corrigidas, mas você não usou WITH NO_INFOMSGS, o DBCC UPDATEUSAGE retornará as linhas e colunas que estão sendo atualizadas nas tabelas do sistema.

O DBCC UPDATEUSAGE também pode ser usado para sincronizar contadores de uso de espaço. Como o DBCC UPDATEUSAGE pode demorar algum tempo para ser executado em grandes tabelas ou bancos de dados, ele deve ser usado, em geral, quando você suspeitar que sp_spaceused está retornando valores incorretos. Observe que sp_spaceused aceita um parâmetro opcional para executar DBCC UPDATEUSAGE antes de retornar as informações de espaço para a tabela ou o índice.

O DBCC CHECKDB foi aprimorado no SQL Server 2005 para detectar quando a contagem de página ou de linha se torna negativa. Quando números negativos são detectados, o DBCC CHECKDB emite um aviso e uma recomendação para executar o DBCC UPDATEUSAGE a fim de sanar o problema. Embora possa parecer que a atualização do banco de dados para o SQL Server 2005 cause esse problema, saiba que as contagens inválidas já existiam antes do procedimento de atualização.

Por exemplo, veja como atualizar as contagens de página, de linha ou ambas para todos os objetos no banco de dados atual. O comando a seguir especifica 0 para o nome do banco de dados e o DBCC UPDATEUSAGE relata as informações atualizadas para o banco de dados atual:

DBCC UPDATEUSAGE (0);
GO

Para atualizar as contagens de página, de linha ou ambas para, digamos, AdventureWorks, e também suprimir mensagens informativas adicionais, execute um comando semelhante ao seguinte, que especifica AdventureWorks como o nome do banco de dados e, em seguida, suprime todas as mensagens informativas:

USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO

Para obter mais informações, pesquise DBCC UpdateUsage no SQL Server Books Online.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..