SQL Q&AHorário de verão, Memória do servidor e mais

Editado por Nancy Michell

Horário de verão

P Considerando as alterações futuras no Horário de verão nos Estados Unidos de forma a obedecer ao Energy Policy Act de 2005, devo atualizar o SQL Server™?

R Não. Atualmente, não há atualizações específicas do SQL Server necessárias para oferecer suporte às alterações devido ao horário de verão. O SQL Server depende do sistema operacional subjacente para dados relacionados ao tempo, o que significa que, se o sistema operacional estiver reportando as datas e os horários corretos, o SQL Server reportará e usará os mesmos valores. Para estar em conformidade com as alterações futuras no horário de verão, você precisará atualizar as suas cópias do Windows® conforme descrito em support.microsoft.com/kb/928388. Isso será necessário em todos os sistemas operacionais Windows anteriores ao Windows Vista™ (que já inclui as alterações) para que eles mantenham a conformidade com as mudanças do horário de verão, incluindo os sistemas operacionais que executam o SQL Server. (A Austrália também está passando por algumas alterações. Consulte support.microsoft.com/kb/912475.)

Conectando-se com o Windows Vista

P Instalei o Windows Vista e, agora, não consigo me conectar com o SQL Server 2005 no meu sistema. Sou administrador local e era capaz de fazer essa conexão sem qualquer problema. O que aconteceu?

R Esse é um comportamento esperado no Windows Vista e no SQL Server 2005 sem o Service Pack 2 (SP2). O Windows Vista tem um novo modelo de segurança (Controle de contas de usuário) que, na verdade, captura sua associação no grupo do administrador local e solicita que você verifique as operações que exigem privilégios administrativos. Se você clicar no botão Permitir, as suas credenciais, que incluem o token de administrador, serão enviadas junto com o aplicativo. No caso do SSMS (SQL Server Management Studio), nenhuma caixa de diálogo é exibida porque a simples execução da ferramenta não exige permissões administrativas. O problema é que, por padrão, a função de administrador do sistema do SQL Server 2005 inclui o grupo de administradores locais a partir do sistema operacional, que a sua conta costumava usar no passado para acessar o SQL Server. Como o Windows Vista não está despachando essa permissão, você não obtém nenhum acesso.

Deve-se observar que a execução do SQL Server 2005 sem o SP2 não é suportada no Windows Vista e que o SP2 tem uma ferramenta que adicionará a sua conta para você. Se você ainda estiver aguardando o SP2, a correção será bastante simples. A sua conta de usuário Windows individual deverá ser adicionada ao SQL Server, no seu caso, à função do administrador do sistema. Para fazer isso, basta clicar com o botão direito no SQL Server Management Studio e selecionar Executar como Administrador. Conecte-se ao SQL Server e adicione a sua conta Windows à função do administrador do sistema. Consulte SQL Server Books Online para obter mais informações sobre como isso funciona.

Replicação transacional com modos de exibição

P Se eu tiver um modo de exibição publicado e atualizá-lo, sei que a transação será replicada. Entretanto, se eu atualizar a tabela base desse modo de exibição, essa transação será replicada? Além disso, se eu tiver uma tabela publicada e criar um modo de exibição dela e atualizar esse modo de exibição em vez da tabela base, essa transação será replicada?

R Supondo que a tabela base esteja configurada como um artigo em uma publicação (ou seja, você configurou a tabela base para replicação também), qualquer atualização na tabela base seria replicada.

Quando você replicar um modo de exibição, por padrão, tudo o que será replicado como parte de um modo de exibição é a parte de esquema desse modo de exibição ou código por detrás do modo de exibição e não os dados que dão suporte para ele (a menos que você tenha um modo de exibição indexado). Dessa forma, mesmo sem a replicação, a qualquer momento que você atualizar um modo de exibição, o que significa executar uma instrução DML (Data Manipulation Language) com o modo de exibição como destino, na verdade, apenas estará atualizando os dados na tabela adjacente e não o modo de exibição. Um modo de exibição é apenas um armazenamento lógico de uma instrução de consulta sem armazenamento físico conectado (novamente, a não ser que você esteja usando modos de exibição indexados).

Memória máxima do servidor

P Tenho uma máquina que executa o Windows Server® 2003 e o SQL Server 2000, com 5 GB de RAM. Digamos que eu use a opção /3GB para aumentar meu espaço de endereçamento virtual de modo do usuário, a opção /PAE para carregar a versão PAE (Physical Address Extension) do kernel do Windows e defina a opção AWE (Address Windowing Extensions) habilitada como 1 (e habilite páginas bloqueadas na memória). Com o AWE habilitado, a opção de memória máxima do servidor configurará apenas o tamanho do cache de dados ou o tamanho de todos os caches de buffer (dados, processos, sessões e assim por diante)? Como apenas o cache de dados pode usar a memória mapeada pelo AWE, se eu configurar a memória máxima do servidor como 4 GB, o cache de dados usará apenas 1 GB (a parte mapeada pelo AWE) ou ele pode usar esse 1 GB extra e continuar a usar ou competir com todos os outros consumidores de memória no espaço de endereçamento padrão?

R A memória máxima do servidor sempre limitará o tamanho do pool de buffer inteiro. Entretanto, o único consumidor que pode usar a memória mapeada pelo AWE é o cache de dados e nada mais.

Portanto, para a primeira pergunta, mesmo com o AWE habilitado, a memória máxima do servidor ainda limita o pool do buffer inteiro, mas os consumidores que não fazem parte do cache de dados nem mesmo usarão nenhuma parte da memória mapeada pelo AWE.

Para a segunda pergunta, o cache de dados ainda usará a memória mapeada pelo AWE além de qualquer outra memória no pool de buffer que o SQL Server determinar apropriada. Ele não ficará limitado apenas à memória do AWE e acabará sendo o único consumidor que usará a memória do AWE. Se você não tiver certeza sobre a função da opção /3GB, consulte o blog de Raymond Chen.

Criação de perfil e desempenho

P Tenho o SQL Server 2005 espelhado em produção. Quando inicio o SQL Server Profiler na máquina do banco de dados e escrevo os dados de rastreio em um arquivo, vejo uma queda drástica no desempenho. Por quê?

R O motivo da queda no desempenho depende do local em que o Profiler está sendo executado. Se você o estiver executando interativamente na máquina do servidor, a interface do usuário do Profiler estará consumindo memória e CPU no servidor, o que prejudicará o desempenho.

Se você estiver executando o Profiler interativamente em uma estação de trabalho, estará movendo as informações de eventos pela rede. Isso afeta o rendimento. Se for a mesma rede usada para espelhamento, você verá também perceberá um certo impacto. Além disso, se estiver armazenamento a saída do Profiler em um compartilhamento de rede, estará movendo dados pela rede e prejudicando o desempenho.

Provavelmente, a melhor maneira de aliviar tudo isso é executar o Profiler de forma não interativa no servidor que está executando a instância para a qual o perfil será criado e, então, canalizar a saída para um arquivo local. Você ainda estará consumindo recursos do servidor, mas essa abordagem geralmente apresenta o menor impacto. Isso funciona muito melhor do que o rastreio do Profiler (na memória). O rastreio de arquivos usa a memória do sistema de forma mais eficiente. Ele tem buffers maiores e os descarrega no disco de forma mais eficaz. Também não depende de processos externos (como o SQL Server Profiler).

Por fim, os dados de rastreio são gravados em um arquivo de disco enquanto o Profiler ainda está criando perfis. O arquivo de rastreio é compartilhado de forma que outras pessoas possam ver os dados de perfil em tempo real remotamente. Se você estiver chamando o arquivo de rastreio interativamente, significa que o Profiler foi chamado manualmente e a saída está sendo visualizada na tela. Rastreios podem ser criados programaticamente sem saída visual, o que explica por que você deve executar as coisas não interativamente.

É possível criar um compartilhamento sobre um diretório local, e outras pessoas podem acessar os arquivos que se encontram nesse local; em geral, esse procedimento não apresenta problemas. Como mencionado anteriormente, você não deseja enviar a saída de rastreio a um arquivo no compartilhamento remoto, especialmente para um que seja acessado por meio do mesmo canal de rede usado para espelhamento.

Você também deve selecionar apenas o conjunto mínimo de eventos necessários para a sua investigação. Para o local do arquivo de rastreio, é necessário escolher a unidade mais rápida no sistema (de preferência, diferente das unidades de logs de transações e de banco de dados do SQL Server). Se você ainda perceber uma degradação significativa no desempenho, divida os eventos em dois ou mais rastreios, cada um direcionado para uma unidade de disco rígido diferente. Mesmo que os rastreios estejam direcionados para a mesma unidade de disco rígido, você ainda terá os benefícios de uma divisão devido ao fato de que cada rastreio tem o seu próprio conjunto de buffers. Consulte sp_trace_create e todos os seus parentes no SQL Server Books Online para obter mais informações.

Problemas de armazenamento em cluster

P Estou tentando instalar o SQL Server em um cluster que executa o Windows Server 2003. Sempre que tento fazer isso, recebo um erro que afirma a falha na instalação ao executar as operações necessárias nos nós em cluster. Sqlstp.log indica:

Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...

O que pode estar ocorrendo?

R Existem vários motivos possíveis para essa falha. A instalação instala o Serviço do Windows NT® em todos os nós selecionados para gerenciar remotamente o processo de instalação nas máquinas individuais. Portanto, é necessário ficar atento a uma série de possíveis dificuldades.

Em primeiro lugar, os usuários de contas de domínios têm uma diretiva de grupo que nega a permissão "fazer logon como serviço". (Lembre-se de que a diretiva de domínio substitui a diretiva da máquina local.) Certifique-se de usar uma conta sem essas restrições.

Em segundo lugar, a conta conectada da máquina a partir da qual você executa a instalação deve ter acesso de administração em todos os nós devido ao seguinte fator: o processo de instalação Master requer acesso ao registro remoto a todas as máquinas; a instalação copia cnvsvc.exe para o diretório Windows da máquina remota ou a instalação usa as APIS padrão do Windows que usam apenas a permissão da conta conectada para acessar máquinas remotas. Por esses motivos, você deve fazer logon como administrador em todos os modos por padrão.

Plano de recuperação após desastres

P Estou considerando se devo usar o espelhamento do banco de dados (modo assíncrono) ou o transporte de logs para implementar minha estratégia de DR (recuperação após desastres) para meus bancos de dados SAP. Meus locais de produção e de DR terão uma conexão de banda larga de 100 Mb não dedicada à sessão de espelhamento. A conexão será compartilhada com diferentes sessões de espelhamento ou até mesmo com outros servidores de DR.

Se houver um problema de rede que impeça o envio do registro de log ao banco de dados espelho, haverá uma nova tentativa?

Quando a sessão de espelhamento for suspensa, haverá um período de retenção? E, além dos modos de exibição do sistema, existem informações de registro de log que eu possa usar para monitorar o tráfego de espelhamento e a transmissão de registros de log?

R Vamos começar respondendo a pergunta: qual é a lógica de novas tentativas do espelhamento de bancos de dados? É possível considerá-la de duas maneiras: Em primeiro lugar, se houver um problema de rede temporário, o estado da sessão de espelhamento será desconectado. Existe um valor de tempo limite padrão de 10 segundos, ou seja, um registro de log não pode ser enviado a partir do banco de dados principal ao banco de dados espelho. Nesses casos, o principal continuará a executar "exposto" e a transação será confirmada no lado do cliente. Quando o problema de rede for resolvido, a sessão de espelhamento será repetida automaticamente sem nenhuma intervenção do usuário. Ela tentará recuperar-se usando os registros de log, os parceiros serão sincronizados primeiro e, quando forem recuperados, o estado será sincronizado.

Em segundo lugar, se houver um problema de retrabalho, o estado da sessão de espelhamento será suspenso. Um problema de retrabalho significa que o banco de dados espelho não consegue confirmar os registros de log em seu banco de dados. Problemas de retrabalho são principalmente causados por um arquivo físico que não foi encontrado ou por espaço em disco insuficiente. Nesses casos, o principal continuará a executar exposto e, portanto, a transação será confirmada no lado do cliente. Após a correção manual do problema de retrabalho no servidor espelho, a sessão do espelho exigirá intervenção:

ALTER DATABASE <db> SET PARTNER RESUME; 

No que se refere aos períodos de retenção, a resposta é que, independentemente de a sessão do espelho estar desconectada ou suspensa, os registros de log serão mantidos até que essa sessão seja restaurada e todos os registros desde o momento em que ela foi suspensa até o momento em que ela foi reinicia sejam estabilizados no espelho. Basicamente, enquanto a sessão de espelhamento estiver desconectada ou suspensa, o log no principal não pode ser truncado, porque isso quebraria a cadeia de retrabalho de logs. Isso significa que o log do principal crescerá ilimitado até a restauração da sessão. Portanto, não existe na verdade um limite de retenção na sessão de espelhamento. A única restrição real é o espaço em disco que o servidor principal possui para armazenar o log, pois o log não pode ser truncado.

Por fim, não há um arquivo de log específico que possa ser usado para monitorar o espelhamento. O SQL Server 2005 fornece uma ferramenta de GUI chamada Monitor de espelhamento de banco de dados para essa finalidade, que permite aos administradores de sistema visualizar e atualizar o status e configurar limites de aviso em várias métricas de desempenho do sistema. A partir dessa ferramenta, você recebe um alerta quando o espelhamento não apresenta um bom desempenho. A principal preocupação de desempenho com relação ao espelhamento do banco de dados é se os registros de log são processados de maneira oportuna. Para obter mais informações sobre o monitoramento do espelhamento de bancos de dados, consulte o artigo sobre monitoramento do status do espelhamento em msdn2.microsoft.com/fr-fr/library/ms365781.aspx.

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Chad Boyd, Sandu Chirica, Alan Doby, Kaloian Manassiev, Luciano Moreira, Ivan Penkov, Sivagaminathan Rajarethinam, Deborah To, Patrick Woodward, Buck Woody, Stanley Yau e Warren Young.

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