P&R do SQLBest Practices Analyzer, processadores multi-core e muito mais

Editado por Nancy Michell

P Tenho algumas perguntas sobre a regra do BPA (Best Practices Analyzer) quanto ao uso de tabelas/exibições qualificadas por esquema. De acordo com a documentação do BPA, a regra não verifica a qualificação por esquema de tabelas temporárias. O relatório do BPA faz referência a tabelas temporárias criadas em procedimentos armazenados. Elas devem ser qualificadas? Em caso positivo, com que esquema? Acredito que as tabelas temporárias deveriam ser qualificadas por proprietários, assim como as outras tabelas.

R A recomendação do BPA de qualificar por esquema as referências de tabelas e exibições não se aplica ao SQL Server™ 2005, uma vez que a separação de esquemas de usuários corrigiu o problema que exigia essa prática nas versões anteriores do SQL Server. A qualificação por esquema era necessária para habilitar a reutilização de planos de consulta por diferentes usuários que, no SQL Server 2000, tinham esquemas padrão distintos. Eles podiam usar objetos dbo sem qualificação, mas o SQL Server precisava primeiro procurar os objetos nos esquemas padrão, impedindo a reutilização de planos de consulta. Como a separação dos esquemas de usuários permite que diferentes usuários compartilhem um esquema padrão e, tipicamente, que todos os usuários do banco de dados acessem objetos em seus esquemas padrão, os planos ad-hoc com nomes não-qualificados de tabelas e exibições normalmente serão compartilhados e reutilizados pelos usuários. Os nomes não-qualificados de tabelas e exibições dentro de procedimentos armazenados nunca foram afetados por esse problema, o que enfraqueceu ainda mais os argumentos a favor dessa prática. O BPA no SQL Server 2005 não incluirá regras como essa, pois não tem um analisador T-SQL. Em vez disso, verificará a existência de definições impróprias de configuração e segurança.

P Tenho me deparado com um comportamento estranho do SQL Server 2005 SP1. Se excluo registros em uma tabela e, ao mesmo tempo, realizo inserções na mesma tabela, as inserções são bloqueadas até que a transação de exclusão seja confirmada. Há alguma forma de descobrir o que está causando o bloqueio?

R Sim. Você pode executar o script de DMV (modos de exibição dinâmicos de gerenciamento) na Figura 1 para localizar bloqueios e bloqueadores.

Figure 1 Localizar bloqueios e bloqueadores

-- script to show blocking and locks
SELECT 
  t1.request_session_id AS spid, 
  t1.resource_type AS type, 
  t1.resource_database_id AS dbid, 
  (case resource_type 
   WHEN ‘OBJECT’ THEN object_name(t1.resource_associated_entity_id) 
   WHEN ‘DATABASE’ THEN ‘ ‘ 
   ELSE (SELECT object_name(object_id) 
      FROM sys.partitions 
      WHERE hobt_id=resource_associated_entity_id) 
  END) AS objname, 
  t1.resource_description AS description, 
  t1.request_mode AS mode, 
  t1.request_status AS status,
   t2.blocking_session_id
FROM sys.dm_tran_locks AS t1 LEFT OUTER JOIN sys.dm_os_waiting_tasks AS t2
ON t1.lock_owner_address = t2.resource_address 
GO

P Além do hyperthreading e da tecnologia dual-core, os fornecedores de chips estão começando a lançar processadores com núcleos adicionais (quatro, oito ou mais). Estou avaliando a possibilidade de adquirir um novo servidor com processadores multi-core para dar suporte a uma implantação do SQL Server 2005 Standard Edition e gostaria de saber se, ao utilizar um processador com quatro núcleos, somente poderei ter uma única CPU física (uma vez que a Standard Edition é limitada a quatro CPUs).

R Para fins de licenciamento e suporte à edição de CPUs, o SQL Server considera somente a quantidade de soquetes/CPUs físicos, independentemente da quantidade de núcleos do processador. Então, por exemplo, o fato de o SQL Server 2005 Standard Edition oferecer suporte a até 4 CPUs significa que oferecerá suporte a 4 soquetes de CPU físicos, independentemente da quantidade de núcleos em cada um (se você tiver 4 CPUs físicas com 4 núcleos cada uma, sua implantação do Standard Edition poderá utilizar até 16 CPUs lógicas). Além disso, embora você tenha 16 núcleos/CPUs lógicas, a licença exige que você pague somente pelas 4 CPUs físicas, e não pelos 16 núcleos. Para obter mais informações sobre o SQL Server e os processadores multi-core, consulte microsoft.com/sql/howtobuy/multicore.mspx.

P Estou prestes a adquirir alguns novos servidores de banco de dados. Minha organização deve optar pelas versões de 64 bits ou manter-se nas já conhecidas e testadas de 32 bits?

R Depende. É uma pergunta muito comum, agora que os fornecedores transformaram seu hardware x86 em x64. Em primeiro lugar, você deve perguntar quais serão as pressões sobre a memória dos seus servidores de banco de dados. Se a sua instância do SQL Server consumirá menos de 3 GB de RAM durante o ciclo de vida do hardware (geralmente três anos), então o x86 de 32 bits é razoável, desde que esse seja também o direcionamento dos outros servidores (controladores de domínio, servidores DNS, servidores de aplicativos, servidores Web, servidores de email). Se a instância do SQL Server consumirá mais de 16 GB ou haverá várias instâncias por servidor (ou cluster), você deve analisar seriamente a possibilidade de adotar as tecnologias de 64 bits. Se haverá mais de oito processadores, o IA64 é a recomendação padrão. No entanto, como as CPUS x64 com quatro e oito núcleos começam a chegar ao mercado em grande quantidade, talvez haja um argumento considerável para a adoção do x64 em vez do IA64, no que se refere a custos.

Ao migrar para x64 (ou IA64), talvez suas estimativas iniciais de custos não incluam a implantação da mesma arquitetura nos ambientes de desenvolvimento, teste e desempenho. Mas você deve avaliar também se quer ficar preso a tecnologias obsoletas na metade do ciclo de vida do seu hardware. Dentro de 18 meses, será quase impossível adquirir hardware totalmente x86. Se você optar agora por esse tipo de solução, fazer atualizações nos próximos anos será caro, além de obrigar à substituição de sistemas inteiros. Optar agora pelo hardware de 64 bits lhe permitirá mais opções nos próximos anos.

Então, um bom momento para fazer a transição para os 64 bits é quando você vai adquirir novo hardware, no início do ciclo de lançamento de um aplicativo essencial ou quando você vai fazer a atualização do SQL Server 2000 para o SQL Server 2005.

P Tenho o envio de log habilitado entre dois servidores. No fim de semana, um problema de hardware no servidor principal interrompeu o envio de log. Quando voltei a monitorar o envio de log, percebi que o LS_backup_dbname estava em execução normal, apesar das várias horas de inatividade.

Contudo, no servidor secundário, o trabalho de cópia parece estar funcionando bem, mas o trabalho de restauração parece estar ignorando arquivos e, por fim, apresentando falhas repetidas. Ele é executado, mas ignora todos os arquivos e então falha. O tempo desde a última restauração é agora de 849 minutos. Em situações semelhantes, no passado, simplesmente reiniciei a configuração de envio — ou seja, desliguei e liguei novamente e, para concluir, fiz um novo backup e o restaurei no servidor secundário, e o envio de log recomeçou. Existe uma forma melhor de lidar com esse cenário?

R Provavelmente você está percebendo os efeitos da ausência de arquivos de backup. Como você sabe, os trabalhos de backup, cópia e restauração do envio de log são executadas de forma independente. Os arquivos de backup antigos no local de cópia também são removidos com base na programação especificada. Se houve um período em que o trabalho de restauração não foi executado, ele pode ter excedido o intervalo e isso pode ter resultado na ausência de arquivos de backup. O trabalho de restauração do envio de log tem uma lógica que tenta recuperar-se de diversos tipos de falhas, causadas por condições operacionais distintas. Basicamente, examina os arquivos quando são encontrados erros e tenta encontrar os arquivos de backup corretos. Se um arquivo de backup correto não foi encontrado, suspeito que algo removeu os arquivos necessários ou, possivelmente, você reconfigurou a parte do envio de log referente ao backup.

Uma solução seria fazer a restauração manual, pelo log de transações, dos arquivos de backup criados acidentalmente pelo outro trabalho de backup. O problema em simplesmente copiá-los para o local de cópia do envio de log está nas convenções de nomenclatura reconhecidas pelo envio de log. Mas, depois de fazer a restauração manual até esse ponto, a restauração normal deverá recomeçar e continuar o processo.

P Preciso saber como usar o T-SQL para descobrir o tamanho da memória física total e livre. Existe um modo fácil de obter essa informação?

R Basta executar a consulta na Figura 2 e você obterá os dados que está procurando.

Figure 2 Obter memória

With VASummary(Size,Reserved,Free) AS 
(SELECT 
  Size = VaDump.Size, 
  Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0) 
  WHEN 0 THEN 0 ELSE 1 END), 
  Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0) 
  WHEN 0 THEN 1 ELSE 0 END) 
FROM 
( 
  SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes)) 
    AS Size, 
    region_allocation_base_address AS Base 
  FROM sys.dm_os_virtual_address_dump 
  WHERE region_allocation_base_address <> 0x0 
  GROUP BY region_allocation_base_address 
  UNION 
  SELECT CONVERT(VARBINARY, region_size_in_bytes), 
    region_allocation_base_address 
  FROM sys.dm_os_virtual_address_dump 
  WHERE region_allocation_base_address = 0x0 
) 
AS VaDump 
GROUP BY Size)
 
SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB] ,CAST(MAX(Size) AS INT)/1024 
    AS [Max free size, KB] 
FROM VASummary 
WHERE Free <> 0 

P Eu gostaria de armazenar a senha SA (administrador do sistema) em um arquivo criptografado com uma chave simétrica, para simplificar a criação de bancos de dados a partir de um aplicativo. Isso é possível?

R Em primeiro lugar, você jamais deve usar a senha SA a partir de um aplicativo. Além disso, deve usar a Autenticação do Windows, e não a do SQL Server.

Se precisar realizar atividades com alto nível de privilégios, deve fazer o seguinte: definir as permissões mínimas necessárias para realizar a ação. Definir uma função de banco de dados que contenha essas permissões. Atribuir um usuário à função. Criar um procedimento armazenado com a cláusula EXECUTE AS, que realizará essas funções. Para obter uma explicação da cláusula Execute As, visite msdn2.microsoft.com/ms188354.aspx.

É claro que, sem levar em conta se a conta em questão é a conta SA e tendo em mente que a Autenticação do Windows nem sempre é uma opção possível, a pergunta fundamental é: como armazenar com segurança uma senha para uma conta de logon do SQL Server de forma a permitir o acesso do aplicativo que precisa usar a senha, mas não o de usuários ou aplicativos sem autorização?

Criptografar a senha é um passo na direção certa, mas apenas modifica o problema, que deixa de ser proteger a senha e passa a ser proteger a chave de criptografia.

Presumindo que se trate de um aplicativo baseado em Microsoft® .NET Framework, faça uma consulta à Enterprise Library em msdn2.microsoft.com/aa480453.aspx e às recomendações na seção de padrões e práticas do MSDN® em msdn.microsoft.com/practices. A Enterprise Library contém vários componentes de aplicativos que seriam úteis a você, inclusive um componente de configuração, um de criptografia e um de acesso a dados. Eles podem ajudá-lo, pelo menos, a armazenar suas senhas com segurança, e também a gerenciar seu acesso aos dados como um todo.

Se a Enterprise Library não for uma opção disponível (talvez você não esteja usando o .NET Framework), então você deve familiarizar-se com a CryptoAPI: msdn2.microsoft.com/aa380255.aspx. Aqui você encontrará funções essenciais de criptografia, distribuídas com o sistema operacional que permitirá vincular chaves de criptografia a um usuário principal ou a uma máquina. Isso pode simplificar o gerenciamento de chaves (que passa a ser o principal problema após a criptografia da senha).

P Quero mover meu servidor de cluster de dois nós do SQL Server 2000 (ativo/ativo — em hardware de 64 bits) do Domínio A para o Domínio B na mesma floresta. O banco de dados do SQL Server está na SAN. A arquitetura do Active Directory® solicita um domínio-raiz vazio com dois domínios filhos (Domínio A e Domínio B). No Domínio B serão colocados todos os componentes da infra-estrutura. É um ambiente Windows Server® 2003 Enterprise, com controladores de domínio adicionais executando Windows 2000.

É possível alterar a associação do servidor do SQL Server Cluster, passando-a do Domínio A para o Domínio B?

R Para começar, consulte "Como alterar domínios de um cluster de failover do SQL Server 2000" e "Como mover um servidor de cluster do Windows de um domínio para outro". O mesmo processo se aplica a um cluster de várias instâncias. A única diferença é que você precisará repetir as etapas para cada instância, conforme for adequado. Nunca é "recomendável" alterar o domínio de um cluster, devido às complexidades envolvidas, mas isso já foi feito muitas vezes. A única outra forma possível seria fazer o que você expôs, recriar uma nova instância lado a lado e migrar os dados.

Cada projeto é diferente e pode-se utilizar uma grande variedade de ferramentas para realizar a alteração de nível de domínio propriamente dita (incluindo as considerações quanto a segurança, migração de contas, mapeamento de identificadores de segurança e assim por diante). Geralmente essa é a parte mais difícil do processo, e não a alteração em si.

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Sunil Agarwal, Laurent Banon, Steve Bloom, Chad Boyd, Matt Burr, Shaun Cox, Cindy Gross, Bobby Gulati, Matt Hollingsworth, Arnost Kobylka, Mikhail Shir, Fernando Pessoa Sousa, Stephen Strong e Ramu Veeraraghavan.

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