P&R do SQLDisparadores de logon, desfragmentações de arquivos de dados e muito mais

Editado por Nancy Michell

Configurando a conta de serviço

Dica: senhas mais seguras

O mecanismo do SQL Server 2000 mantém duas cópias de cada senha de logon no SQL Server. Uma versão é a senha propriamente dita, fornecida pelo usuário; a outra é a senha com todas as letras maiúsculas.

Essa prática ajuda na validação de senhas sem diferenciação entre maiúsculas e minúsculas, pois o usuário pode fazer logon usando a senha com maiúsculas e minúsculas ou só com maiúsculas e ter o acesso ao servidor concedido. No entanto, essa conveniência gera um problema. Salvar senhas com todas as letras maiúsculas facilita os ataques maciços de quebra de senha, por reduzir o número de combinações de senhas possíveis.

O SQL Server 2005 armazena somente a cópia da senha original. A senha digitada pelo usuário deve corresponder àquela armazenada no servidor. Se não houver correspondência, o logon falhará e o usuário terá o acesso negado. Se o uso específico de maiúsculas e minúsculas for esquecido, a senha precisará ser redefinida.

Supondo que o nome de logon de um usuário seja SQLCOMMUNITY, é possível redefinir sua senha no SQL Server usando o comando a seguir:

Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';

Esse comando redefiniria a senha do logon SQLCOMMUNITY no SQL Server para "k3t9h4s8wJF7t".

P No SQL Server™ 2000, eu costumava definir a conta de serviço do SQL Server Engine e Agent usando o miniaplicativo Serviços, em Ferramentas Administrativas. No entanto, tenho ouvido falar que, no SQL Server 2005, devo usar a ferramenta Configuration Manager. Por que não posso simplesmente continuar usando as ferramentas do Windows?

R O SQL Server 2005 foi criado para ser mais seguro do que as versões anteriores. Em muitos ambientes, os usuários simplesmente definiam contas internas, como LocalSystem, para executar o SQL Server. Mas, em geral, essas contas têm, no Windows®, mais ou menos permissões do que realmente necessitam. Você deve criar uma conta do Windows sem privilégios elevados para executar os serviços do SQL Server 2005 Engine e Agent. Se essas contas forem selecionadas com o Configuration Manager, os direitos e as permissões adequados serão concedidos a elas automaticamente, tanto no SQL Server quanto no sistema operacional. Caso você use as ferramentas do Windows para gerenciar os serviços do SQL Server, talvez não conceda os direitos adequados, ou então conceda direitos demais.

Para obter mais detalhes, consulte a dica Alterando a conta de serviço.

Quem está fazendo logon no meu servidor?

P Quero saber quem está fazendo logon no meu servidor e quando. Quero também restringir alguns usuários específicos a determinados períodos e gostaria de saber como acionar um rastreamento para monitorar as atividades dos usuários. Isso é possível?

R Sim, você pode fazer tudo isso com o SQL Server 2005 se tiver o Service Pack 2 instalado.

O SQL Server 2005 permite criar disparadores de logon capazes de acionar um procedimento T-SQL ou armazenado em resposta a um evento LOGON. Você pode usar um disparador de logon para auditar e controlar os usuários, rastreando as atividades de logon, restringindo os logons no SQL Server ou limitando o número de sessões para logons específicos. Observe que o evento só é acionado depois que um logon é autenticado com sucesso, mas logo antes do estabelecimento efetivo da sessão do usuário. Por isso, todas as mensagens originadas no disparador (como mensagens ou erros), a partir da instrução PRINT, são enviadas para o log de erros do SQL Server. Se houver falha na autenticação de um logon, os disparadores de logon não serão acionados.

O exemplo a seguir mostra como você pode criar um disparador de logon e enviar uma mensagem para o log de erros do SQL Server assim que qualquer usuário fizer logon:

ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO

Para exibir todos os disparadores definidos em nível de servidor, use esta consulta:

SELECT * FROM sys.server_triggers;

Práticas recomendadas de desfragmentação

P Qual a melhor forma de corrigir a fragmentação dos arquivos de dados no SQL Server? Se usamos as ferramentas de desfragmentação do Windows, elas tratam o arquivo de dados SQL como um todo e não o desfragmentam de forma granular.

R Você pode fazer backup do banco de dados e depois restaurá-lo. Se houver espaço para um arquivo contíguo, então o banco de dados deve ser gravado de forma contígua. Isso posto, normalmente a tentativa de desfragmentar os arquivos físicos não vale a pena, devido ao tempo de inatividade necessário. Em geral, não há mesmo muita fragmentação externa. É mais útil reindexar seus dados regularmente para reduzir tanto quanto possível a fragmentação interna. Isso elevará ao máximo a eficácia dos read-aheads e a quantidade de dados que pode ser armazenada em buffer.

Os fatores mais importantes para uma E/S de disco eficiente são verificar se o alinhamento do disco e a configuração de RAID estão corretos, dimensionar suas matrizes de discos para manipular adequadamente a carga de E/S e manter um layout adequado dos arquivos Log, Data, TempDB e de backup. Se você evitar o uso do crescimento automático e da redução automática como métodos principais para dimensionar arquivos de dados, reduzirá o número de fragmentos de arquivos criados em nível de volume. Por exemplo, realizar 10 crescimentos automáticos de 500 MB cada um provavelmente adicionaria 10 novos fragmentos de arquivos físicos. Por outro lado, um único crescimento manual de 5 GB adicionaria apenas um.

Dica: alterando a conta de serviço

Você sabia que quando a conta de logon de serviço do SQL Server é configurada com uma conta do Windows NT®, o SQL Server define os direitos de usuário e as permissões do Windows em vários arquivos, pastas e chaves do Registro? Também é possível definir a conta de serviço do SQL Server no console Serviços, em Ferramentas Administrativas. No entanto, quando você fizer isso em Serviços, os direitos e as permissões não serão definidos e poderão ocorrer sérios problemas, devido à ausência de configurações adequadas de segurança nos itens já mencionados do SQL Server e do Windows.

Portanto, é altamente recomendável que você use o SQL Server Configuration Manager, e não o console Serviços, ao alterar a conta de serviço do SQL Server ou do SQL Server Agent. No entanto, se você já fez alterações na conta usando o console Serviços, ainda pode corrigir esse problema.

Etapa 1: aplique permissões totais às seguintes chaves do Registro e às suas subchaves:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>

Etapa 2: defina controle total para a conta de inicialização do serviço MSSQLServer e para o serviço SQLServerAgent (uma conta local do Windows NT ou uma conta de domínio do Windows NT) nesta pasta NTFS:

Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL

Contudo, em vez de fazer isso manualmente, é recomendável usar o SQL Server Configuration Manager para fazer alterações em contas de serviço do SQL Server/Agent.

Meus agradecimentos aos seguintes profissionais de TI da Microsoft por seus conhecimentos técnicos: Cary Gottesman, Saleem Hakani, Trayce Jordan, Peter Kalbach, Al Noel, Uttam Parui, Amber Sitko e Buck Woody.

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