SQL Q+ATabelas temporárias, processamento de 64 bits, espelhamento e muito mais

Editado por Nancy Michell

Tabelas temporárias

P Ouvi dizer que para evitar problemas de contenção, nem sempre é aconselhável usar o banco de dados temporário, tempdb. É verdade? Costumo utilizá-lo porque preciso obter dados que se distribuam entre muitas tabelas e, até mesmo, sejam modificados ao longo do processo. Não consigo fazer isso facilmente com os modos de exibição.

R Realmente, um tempdb muito utilizado pode provocar contenção. Mas a contenção geralmente torna-se um problema somente em raras situações como, por exemplo, quando você obtém centenas de SPIDs (identificadores do processo do servidor), criando e excluindo grande número de tabelas temporárias, simultaneamente, conforme explicado no artigo Banco de dados de conhecimento, em support.microsoft.com/kb/328551.

Usar uma tabela temporária (que pode ou não estar no tempdb) pode realmente ser uma solução aceitável. A questão é se o aumento do desempenho que você obtém ao receber os dados da tabela temporária é mais importante do que a sobrecarga na criação da tabela.

É necessário considerar o tamanho, tempo de vida, freqüência de uso e principalmente o número de instâncias ativas das tabelas temporárias, antes de rejeitar a solução. O dimensionamento do servidor também é importante, considerando que a contenção do tempdb pode estar relacionada ao hardware.

Se você precisar de um grande número de tabelas pequenas, com vida curta, você pode tentar as variáveis de tabela que oferecem algumas vantagens sobre as tabelas temporárias. (Consulte a resposta da nossa próxima pergunta, para obter detalhes sobre as diferenças entre as variáveis de tabela e as tabelas temporária e consulte também "Perguntas freqüentes - SQL Server 2000 - Variáveis de Tabela" para obter mais informações) (em inglês).

No seu caso, se todas as consultas ao banco de dados tiverem que passar pelos procedimentos de criação de tabela temporária, também pode ser conveniente questionar o modelo de dados original, em vez de tentar apenas conviver com ele.

P O que são variáveis de tabela e quais suas funções? Realmente posso usá-las, em vez de usar as tabelas temporárias?

R As tabelas temporárias e as variáveis de tabela fornecem a mesma funcionalidade básica. Na verdade, as duas são materializadas como tabelas temporárias no banco de dados tempdb. No entanto, quando apenas um número pequeno de linhas é inserido, as variáveis de tabela podem fornecer desempenho superior. Isso ocorre porque as variáveis de tabela não mantêm as estatísticas ou os índices, resultando em sobrecarga menor. Se o conteúdo da tabela não exceder algumas páginas do banco de dados de 8KB, que o mecanismo do banco de dados manterá residente no cache de dados, então as variáveis serão preferenciais.

De acordo com os livros online do SQL Server™:

  • Uma variável de tabela atua como uma variável local. Possui um escopo bem definido, que é a função, o procedimento armazenado ou o lote no qual ela está declarada. Dentro desse escopo, uma variável de tabela pode ser usada como uma tabela regular.
  • As variáveis de tabela são removidas automaticamente no fim da função, procedimento armazenado ou lote no qual elas são definidas.
  • As variáveis de tabela usadas nos procedimentos armazenados provocam recompilações menores dos procedimentos armazenados, do que as tabelas temporárias que são usadas.
  • As tabelas de variáveis exigem poucos recursos de bloqueio e de log.
  • Em alguns casos, o desempenho pode aumentar, embora as estatísticas não sejam mantidas.

Espelhamento

P Estou pretendendo usar o espelhamento do SQL Server 2005 para suportar alta disponibilidade. O sistema será executado no modo de alta disponibilidade para suportar failover automático. Porém, também quero executar alguns outros aplicativos no servidor de espelhamento para utilizar totalmente o recurso. O servidor de espelhamento suportará dois bancos de dados: Banco de dados de produção, como o espelhamento para o servidor principal e Banco de dados temporário, como o banco de dados autônomo. Ele suportará dois tipos de cliente: um será configurado com o failover de espelhamento, para acessar o Banco de dados de produção e o outro será conectado diretamente ao Banco de dados temporário.

Além disso, alguns pacotes de SSIS (SQL Server Integration Services) serão executados no servidor de espelhamento. Eles acessarão os dois bancos de dados, transferindo os dados do Banco de dados temporário do local, para o Banco de dados de produção em execução no servidor principal. Durante o failover, os pacotes de SSIS transferirão os dados do Banco de dados temporário local para o Banco de dados de produção local (failover). Há algum problema em relação a essas configurações?

R De modo geral, o tipo de configuração não é recomendado, porque após o failover, o novo servidor principal não pode ser sobrecarregado.

Funcionalmente, parece que não haverá problemas a partir da perspectiva de espelhamento, mas você deve testar minuciosamente, se for continuar com esta solução. O teste deve ser feito em picos de carga, na configuração padrão e após-failover. E seu pico de carga deve ser um valor futuro estimado, não o pico de carga atual. Se você não considerar as necessidades dos negócios futuros, a solução será interrompida, se houver aumento de carga da capacidade anterior.

O teste pode muito bem detectar afunilamentos de rede, de disco e até mesmo de CPU, que se manifestam como tempo de resposta do aplicativo insuficiente, taxa de transferência inaceitável, erro de tempo limite ou filas de redo extremamente altas no servidor de espelhamento (que pode conduzir a tempos de failover longos, dependendo da taxa de redo real).

Além disso, durante o failover, os pacotes em execução perderão conectividade com o servidor principal defeituoso. Quando o failover for concluído e o banco de dados estiver disponível no novo servidor principal, os pacotes deverão ser reconectados ao novo servidor principal. Com isso presume-se que os pacotes sejam criados com mecanismos de repetição de conectividade e que eles irão tratar os erros de conectividade de forma eficiente, sendo capazes de fazer recuperação, a partir de condições de conexão "interrompidas".

Sistemas operacionais de 64 bits e SQL Server

P É verdade que se eu estiver executando em um sistema operacional Windows Server® com versão de 64 bits, devo usar o SQL Server 2000 Enterprise Edition (de 64 bits) e não posso usar o SQL Server 2000 de 32 bits?

R Do ponto de vista do SQL Server 2000, a única arquitetura nativa de 64 bits que é suportada é a ia64 da Intel. Dessa forma, quando o SQL Server 2000 menciona suporte de 64 bits, significa a ia64. A única versão de SQL Server 2000 que é suportada na ia64 nativa de 64 bits é a Enterprise Edition. Não há nenhum Standard Edition, SQL Server 2000 executado na ia64, ou nativamente como um aplicativo de 64 bits ou sob o Windows® ia64 no Windows (WOW, um subsistema do Sistema operacional que pode executar aplicativos de 32 bits).

Para uma máquina AMD x64, você tem duas opções com o SQL Server 2000. Você pode executar um sistema operacional de 32 bits. Neste caso, você pode executar qualquer edição do SQL Server 2000 e qualquer service pack (SP). Ou você pode executar um sistema operacional de 64 bits e o SQL Server 2000 (qualquer edição) SP4 sob WOW. Nesse ambiente, o SQL Server 2000 não é um aplicativo de 64 bits nativo. Ele está sendo executado em WOW, no modo de 32 bits. Dessa forma, ele nem sabe que existe um mundo de 64 bits.

Apenas para tornar as coisas mais complicadas, ia64 WOW e x64 WOW são dois subsistemas totalmente diferentes. No ia64, o WOW deve emular um espaço de endereço virtual restrito e tornar real a emulação da instrução da máquina. As instruções da máquina ia64 são totalmente diferentes da x86. Ela é uma máquina completamente diferente. O SQL Server não suporta nenhum de seus componentes (SQL Server 2000 ou SQL Server 2005) em execução no ia64 WOW.

No x64 WOW, a história é diferente. As arquiteturas da máquina x86 e x64 são muito parecidas. O conjunto de instruções é o mesmo (ou quase o mesmo). Dessa forma, somente o espaço de endereço virtual de 32 bits deve ser emulado, e há uma assistência de hardware para isso. Assim, há muitos componentes do SQL Server que suportam o x64 WOW, tais como o SQL Server 2000 SP4 e qualquer edição do SQL Server 2005.

Atualização para o SQL Server 2005

P Quero fazer atualização do SQL Server 2000 para o SQL Server 2005. Além da atualização do código SQL, quais alterações de aplicativo devo fazer? Por exemplo, se eu estiver estabelecendo conexão ao SQL Server 2005 usando um cliente do Microsoft® .NET Framework, tenho que atualizar meus clientes da área de trabalho do Windows XP SP2?

Estou executando o Windows XP SP1 e o Visual Basic® 6.0 e também alguns aplicativos que usam o .NET. O SQL Server Native Client, o .NET Framework 2.0 e o Windows XP SP2 são necessários? Em outras palavras, quais são os requisitos mínimos do cliente para uma atualização? Os requisitos do cliente mudam, caso eu decida adotar o espelhamento do SQL Server 2005?

R Para obter todas as vantagens do espelhamento, é necessário usar o SQL Native Client (para OleDb ou ODBC) ou o ADO.NET 2.0 SqlClient. E a seqüência de caracteres de conexão deve ser alterada para fazer referência ao servidor principal e ao servidor de espelhamento.

Mas você somente precisará do SQL Native Client ou do .NET Framework 2.0 para fazer o reconhecimento do espelhamento do cliente. Os clientes antigos podem se conectar, mas não poderão tentar automaticamente o espelhamento, se servidor principal estiver inativo.

Sem atingir os clientes, você pode adicionar uma opção BIG-IP entre os clientes e o servidor, para movê-los de uma caixa para outra, manualmente, durante o failover. Ou você pode alterar o código do aplicativo, para tentar uma conexão ao servidor de espelhamento durante a falha da conexão do servidor principal.

Os requisitos do sistema incluem o seguinte: Windows Installer 3.0, Microsoft Windows XP SP1 ou posterior, Microsoft Windows 2000 SP4 ou posterior, ou Microsoft Windows Server 2003. Para obter informações sobre requisitos, consulte "Usando o ADO com o SQL Native Client"; "Atualização de um aplicativo para SQL Native Client do MDAC" e "Requisitos do sistema para SQL Native Client"

Memória insuficiente do SQL Server 2000

P Estou tendo exceções de memória insuficiente em meu SQL Server 2000 Enterprise Edition SP4 de produção, no Windows Server 2003 SP1. Figura 1 mostra o erro que obtive dos logs.

Figure 1 Erro de memória insuficiente

2006-06-23 14:41:40.72 spid77    WARNING:  Failed to reserve contiguous memory of Size= 24641536.
2006-06-23 14:41:40.85 spid77    Buffer Distribution:  Stolen=4800 Free=1744 Procedures=39391
                                Inram=0 Dirty=90621 Kept=0
                                I/O=0, Latched=99, Other=3063345
2006-06-23 14:41:40.85 spid77    Buffer Counts:  Commited=3200000 Target=3200000 Hashed=3154065
                                InternalReservation=587 ExternalReservation=0 Min Free=1024 Visible= 173320
2006-06-23 14:41:40.85 spid77    Procedure Cache:  TotalProcs=9555 TotalPages=39391 InUsePages=1031
2006-06-23 14:41:40.85 spid77    Dynamic Memory Manager:  Stolen=44191 OS Reserved=7648 
                                OS Committed=7619
                                OS In Use=7603
                                Query Plan=39088 Optimizer=0
                                General=4183
                                Utilities=140 Connection=7651
2006-06-23 14:41:40.85 spid77    Global Memory Objects:  Resource=1617 Locks=313 
                                SQLCache=1836 Replication=204
                                LockBytes=2 ServerGlobal=42
                                Xact=63
2006-06-23 14:41:40.85 spid77    Query Memory Manager:  Grants=0 Waiting=0 Maximum=94533 Available=94533
2006-06-23 14:41:40.88 spid77    Error: 17803, Severity: 20, State: 12
2006-06-23 14:41:40.88 spid77    Insufficient memory available..

Meu servidor tem RAM suficiente (32GB). Este problema parece ocorrer de forma aleatória; o procedimento armazenado que causa esse erro, faz isso talvez uma ou duas vezes em 20 execuções.

Os contadores de desempenho do servidor indicam muita memória disponível. O gravador lento não está paginando o disco com rapidez suficiente? Por que o processo solicita essa grande quantidade de memória ao executar meu procedimento armazenado? Pode ser o número de instruções select ou o uso de tabelas temporárias?

R A quantidade de memória física da máquina não é relevante aqui. Dependendo de como seu arquivo boot.ini é configurado, os aplicativos terão entre 2 e 3 GB de espaço de endereço virtual. O espaço de endereço virtual é um recurso precioso nos sistemas de 32 bits. Por padrão, o pool de buffers consumirá tudo, exceto os 384 MB do espaço de endereço virtual. Esses 384 MB são atribuídos para pilhas de threads e alocações dos componentes que são muito grandes para serem atendidos pelo pool de buffers, ou não sabem como alocar a partir do pool de buffer (xprocs de terceiros, servidores vinculados, componentes COM).

O aviso indica que houve falha em uma alocação de aproximadamente 23 MB. Se as alocações deste tamanho são ou não bem-sucedidas, depende do número e da colocação de outras alocações dentro do bloqueio de 384 MB.

Você pode considerar a remoção de alguns xprocs de terceiros que estão carregados no sistema, ao determinar se há utilização dos componentes COM através de sp_oacreate ou dos servidores vinculados.

É muito provável que o processo esteja solicitando essa quantidade de memória, ao executar seu procedimento armazenado de SQL, devido ao uso da cláusula FOR XML em seu sproc (que não mostramos aqui). No entanto, se você quiser mais informações, Process\sqlservr\Virtual Bytes fornecerá uma indicação da quantidade de espaço de endereço virtual que ainda está disponível. E há uma ferramenta chamada VMStat (incluída no CD do livro Programming Applications for Microsoft Windows de Jeffrey Richter) que determinará o maior tamanho de bloco do endereço virtual. O gravador lento não está envolvido nessa alocação; a área de memória que está sendo usada para a alocação não está no bpool.?

Agradecemos aos seguintes profissionais de TIs da Microsoft pelo conhecimento técnico: Ramon Arjona, Stephen Borg, Sandu Chirica, Robert Djabarov, Guillaume Fourrat, Osamu Hirayama, Alejandro Mihanovich, Maxwell Myrick, Uttam Parui, Shashi Ramaka, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson, Madhusudhanan Vadlamaani, Jian Wang e Dave Wickert.

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