Perguntas&respostas do SQLTamanho do banco de dados, espelhamento, transações marcadas e muito mais

Editado por Nancy Michell

Movendo um cluster

P. Preciso mover um cluster do SQL Server 2000 para novos endereços IP de ambos os servidores físicos abaixo dele, além do cluster do Windows® e do cluster do SQL Server™. Terei que recriar a solução inteira?

R. Não, tudo o que você tem a fazer é executar a instalação do SQL Server e modificar os endereços IP. Aqui está um artigo da Base de Dados de Conhecimento que explica como fazer isso.

Tamanho do banco de dados

P. Tenho o SQL Server 2000 SP4 em produção com um banco de dados essencial de quase 10 GB, um modelo de recuperação SIMPLES, um arquivo primário de 9,850 MB e um arquivo de log de transações de 88 MB. O backup do banco de dados também tem quase 10 GB. Devo reduzir o tamanho do banco de dados para obter um desempenho melhor? Em caso positivo, devo usar o DBCC SHRINKDATABASE ou o DBCC SHRINKFILE? (Infelizmente não tenho um horário fora do pico disponível para essa manutenção).

R. O DBCC SHRINKDATABASE ou o DBCC SHRINKFILE só ajudará se o banco de dados tiver muitas exclusões e atualizações que resultem em menor volume de dados. Mas a pergunta real é: o que isso importa? Um espaço de 10 GB em disco vale hoje, talvez, uns US$ 20. Não faria mais sentido adicionar outros 100 GB ou mais de espaço em disco e deixar executar? O desempenho ficará prejudicado conforme o espaço se tornar mais fragmentado, mas se você não puder fazer nenhuma manutenção, terá pouca opção. Às vezes as pessoas usam uma segunda cópia do banco de dados em situações como essa. Elas mantêm uma cópia de backup atualizada com replicação, fazem a manutenção da cópia de backup e, então, alternam os aplicativos para o backup. Isso obviamente requer algumas alterações ao código e à mudança do modelo de recuperação SIMPLES (para FULL ou BULK_LOGGED), mas pode ser uma boa solução de longo prazo.

Atualização e desempenho

P. Preciso mover dois aplicativos do SQL Server 2000 para o SQL Server 2005. Como posso evitar problemas de desempenho durante a atualização?

R. As armadilhas a seguir geralmente podem causar problemas de desempenho durante a atualização, portanto, procure evitá-las:

1. Você não recriou as estatísticas depois de atualizar para o SQL Server 2005.
2. Você tem cláusulas JOINS e WHERE que comparam dois tipos diferentes de dados, resultando em um desempenho ruim, sobretudo se o servidor havia executado o SQL Server 2000 SP3 ou anterior (consulte support.microsoft.com/kb/271566/).
3. A instância do SQL Server 2005 não está configurada corretamente; a memória, as extensões AWE, os drivers etc estão configurados incorretamente. A caixa que executava o SQL Server 2000 foi ajustada, a pessoa que fez o ajuste saiu e não o documentou, portanto, ele não foi feito à instância do SQL Server 2005.
4. O hardware está com defeito. Geralmente, um novo hardware é adquirido, porque parece bom no papel, mas isso não se mantém na prática.

Antes de colocar uma instância do SQL Server em produção, deve-se estabelecer uma linha de base de desempenho para confirmar se o desempenho esperado ocorrerá. Isso poderá, então, excluir a infra-estrutura como um possível problema. Você precisa observar os Contadores de desempenho, como Disco, E/S e memória, e compará-los entre instâncias.

Espelhamento do banco de dados

P. Estou usando espelhamento de banco de dados e desejo habilitar a opção de banco de dados READ_COMMITTED_SNAPSHOT. Quando tento habilitá-la depois que o espelhamento foi configurado, obtenho uma exceção informando que o banco de dados está em uma sessão de espelhamento e o comando não pode ser executado.

R. Isso acontece porque a configuração da opção READ_COMMITTED_SNAPSHOT requer que o banco de dados seja reiniciado para ter efeito. Você precisa, portanto, dividir a sessão de espelhamento, configurar a opção e reiniciar o banco de dados. Depois de concluir essas etapas, você poderá restabelecer o espelhamento. O banco de dados de espelhamento selecionará a opção depois que a sessão for restabelecida e a utilizará, se ocorrer failover.

P. Estou tentando configurar o espelhamento assíncrono mas obtenho o erro 1418. A execução do Netstat-ano mostra que o SQL Server está escutando na porta correta em todos os servidores. O erro é exibido quanto tento iniciar o espelhamento. O que pode estar acontecendo?

R. Uma possibilidade é o seu firewall estar bloqueando a comunicação; trata-se de um problema relativamente comum que você deverá investigar. Confira os seguintes white papers para obter ajuda: Troubleshooting Database Mirroring Setup (“Solucionando problemas de configuração de espelhamento de banco de dados”) e em MSSQLSERVER_1418.

Observe que esse problema não é específico do espelhamento assíncrono. Na verdade, ele pode ocorrer também com o espelhamento síncrono.

O erro que você está obtendo ("O endereço de rede do servidor "%.*ls" não pode ser acessado ou não existe. Verifique o nome do endereço de rede e envie o comando novamente") está correto. Geralmente, o que ocorre não é que o parceiro remoto não exista, mas que o parceiro remoto simplesmente não pode ser acessado.

Isso poderia acontecer se o parceiro remoto estivesse inoperante, não escutasse a porta ou mesmo se o ponto de extremidade estivesse inoperante (o que pode ocorrer se os parceiros não conseguirem negociar o mesmo mecanismo de criptografia ou se tiverem algum problema de autenticação). Também pode acontecer se o parceiro estiver bloqueado, o que pode ser o resultado do firewall no parceiro que inicia o comando.

Outros problemas que você poderia descartar incluem questões de DSN (nome da fonte de dados) e resolução de nomes. A recomendação genérica é usar nomes de domínio totalmente qualificados. Portanto, embora o seu firewall geralmente possa ser o problema, lembre-se de que existem muitas causas potenciais.

P. Quero usar o espelhamento do SQL Server 2005; entretanto, ouvi dizer que o espelhamento não é recomendado quando vários aplicativos conectam-se a vários bancos de dados na mesma instância do SQL Server. Está correto?

R. A resposta depende na verdade de cada aplicativo ter o seu próprio banco de dados ou de os aplicativos usarem transações em todos os bancos de dados ou transações DTC (Distributed Transaction Coordinator). Se forem usadas transações em todos os bancos de dados, o espelhamento poderá introduzir inconsistências lógicas nas quais as transações não são confirmadas como o esperado. Uma boa explicação sobre o que acontece nessas circunstâncias pode ser encontrada aqui.

Em uma situação de vários bancos de dados usados por vários aplicativos, onde cada aplicativo tem o próprio banco de dados, o espelhamento não causa esses problemas.

Transações marcadas

P. O que são exatamente Transações Marcadas? São alguma coisa que possa ser usada se um banco de dados for SQL Server e outro for Oracle?

R. Marcar uma transação é algo que o administrador de banco de dados faz periodicamente para colocar uma marca no mesmo local em todos os logs. Essa ação, combinada com a habilidade de restaurar uma tabela em uma marca de transação, permite que você restaure todos os bancos de dados ao mesmo ponto. Fazer isso pode ser muito doloroso porque você terá que restaurar todos os bancos de dados envolvidos e os dados serão perdidos em todos os bancos de dados, portanto, você deve evitar isso, assegurando-se de não perder os arquivos de log. As transações marcadas são específicas do SQL Server, assim, se suas transações distribuídas incluírem bancos de dados diferentes do SQL Server, elas não poderão participar da marcação de transação. Em geral, muito poucos sistemas de bancos de dados distribuídos usam marcas de transação. Eles só tratam a perda de um dos logs de transação quando um evento catastrófico requer muito trabalho manual para se recuperar.

Acesso à ferramenta de conversão T-SQL

P. Existe um ferramenta automatizada de conversão Access™-SQL para T-SQL disponível para procedimentos armazenados?

R. Tente o SSMA (Assistente de Migração do SQL Server) para Access que você pode baixar. Lá você também encontrará o Assistente de Migração do SQL Server para Oracle, o Assistente de Migração do SQL Server para Sysbase e o Migrating Informix Databases para Microsoft® SQL Server 2000.

Para fazer upsize do Access para o SQL Server, você pode usar o Assistente de Upsizing do Office; no entanto, o SSMA para Access, mostrado na Figura 1, tem mais recursos, incluindo relatórios de avaliação de conversão e verificação de rede. O SSMA para Access também corrige vários problemas não tratados corretamente pelo Assistente de Upsizing do Office.

Figura 1** Assistente de Migração do SQL Server para Access **(Clique na imagem para aumentar a exibição)

Índices não agrupados

P. Tenho uma tabela em que a chave primária é feita de dois GUIDs (digamos, GUID1 e GUID2). Já tive meu índice agrupado exclusivo em GUID1 e GUID2. Agora, por motivos de desempenho, quero criar o segundo índice não agrupado em GUID2 e GUID1. Haverá alguma sobrecarga de desempenho se eu declarar o índice como exclusivo?

R. Não há nenhuma penalidade para o desempenho na declaração do índice não agrupado como exclusivo. Na verdade, fazer isso pode resultar em menos níveis na árvore de índice.

Quando um índice não agrupado é declarado como não exclusivo, o localizador de linha é anexado à parte de chave das entradas de índice, nas páginas raiz e não-folha. Isso é feito para facilitar a exclusão e atualizar as entradas de índice, o que evita a verificação de uma cadeia de sinônimos quando existirem duplicatas de uma chave: a entrada específica a ser alterada pode ser localizada por uma operação de pesquisa no sistema, relacionada à chave e ao localizador. Resultado: essas entradas são maiores (consideravelmente maiores com a chave do cluster que você escolheu). Como resultado, as páginas raiz e não-folha serão naturalmente lotadas de forma mais rápida. Se o índice for exclusivo, você deverá declará-lo como tal.

A questão é que, independentemente de a tabela ter um índice agrupado, qualquer índice não agrupado na tabela que não seja declarado como exclusivo terá o localizador anexado às entradas de índice nas páginas raiz e não-folha.

Além disso, se você usar uma coluna de identificador int como uma chave substituta e, em seguida, adicionar dois índices exclusivos (GUID1, GUID2) e (GUID2, GUID1), isso provavelmente melhorará o desempenho, pois os índices terão uma chave de cluster de 4 bytes, e não de 32 bytes.

Atualizar bloqueios

P. Tenho procedimentos armazenados com a seguinte estrutura:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances 
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId ) 
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION

Esse procedimento permite que apenas um chamador assuma o bloqueio e faça todos os demais chamadores esperar. Posso obter o mesmo comportamento reduzindo o nível de isolamento?

Parece que READ COMMITTED é o nível de isolamento correto, pois essa transação tem apenas uma consulta e, se alguma outra transação estiver em processo de atualização do mesmo registro, essa transação aguardará a outra. Está correto?

R. Não é a configuração serializável no seu exemplo que faz outros chamadores aguardar, é a própria atualização. Sim, você pode configurar o isolamento em READ COMMITTED e a atualização naturalmente assumirá um bloqueio de atualização de qualquer índice que utilizar. Isso causará problemas a outros processos que estejam executando a mesma instrução; eles, portanto, serão bloqueados até a atualização estar concluída. (Você também não precisa da transação explícita aqui, se a atualização for a única instrução; cada instrução estará implicitamente na própria transação, se não se tratar de uma transação explícita).

Entretanto, se não houver linhas que correspondam à cláusula WHERE na instrução UPDATE, o uso do nível de isolamento serializável impediria que essas linhas fossem inseridas ou modificadas nas demais transações. Se você fosse executar o UPDATE em isolamento READ COMMITTED, isso não aconteceria, e outras transações estariam aptas a introduzir linhas que se qualificariam para a atualização. Se o código de procedimento armazenado for semelhante ao código que você mostrou, pode não fazer sentido empreender nenhuma dessas ações (serializável ou transação); basta executar a atualização

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip e Frankie Yuen.

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