Archives

Configurar instância SQL via script

Existem diferentes formas de configurar uma instância SQL Server, uma delas é através da procedure sp_configure. O interessante de utilizar a sp_configure é que o DBA não fica dependente da utilização de uma interface gráfica.

Ao executar a sp_configure sem parâmetros, são exibidas as configurações atuais da instância. Cada registro representa uma configuração e no campo run_value é possível visualizar o valor atual de cada configuração.

01_sp_configure

Num cenário padrão ao executar a sp_configure o resultado só exibe algumas das inúmeras opções de configuração; isso porque por padrão o SQL Server oculta opções avançadas. Para exibir todas as opções você deve executar:

USE master
GO
EXEC sp_configure 'show advanced option', '1';
GO
RECONFIGURE;
Veja que no comando acima é possível ter uma idéia da sintaxe desta procedure. A idéia básica é a seguinte:
EXEC sp_configure ‘nome da configuração’, ‘novo valor da configuração’

Uma das configurações que podemos alterar utilizando a sp_configure é o limite de memória utilizada pelo SQL Server, vamos exemplificar a alteração desta configuração:

Atualmente minha instância está configurada para utilizar no máximo 500 MB de memória. Ao executar o comando sp_configure é possivel verificar que a opção max server memory (MB) está com o valor 500 nos campos config_value e run_value.

02_sp_configure

Para alterar a quantidade máxima de memória que a minha instância poderá utilizar executo o seguinte comando:

EXEC sp_configure 'max server memory (MB)', '300';

No comando acima configurei o máximo de memória disponível para a instância para 300 MB, no entanto se executarmos a sp_configure verificaremos que a opção run_value ainda continua com 500. Para efetivar a alteração preciso executar o comando RECONFIGURE; assim a alteração entrará em vigor.

RECONFIGURE

Figura 1 – Monitorando o contador Target Server Memory durante execução do RECONFIGURE.

É importante salientar que apesar do comando RECONFIGURE ser obrigatório, nem todas as configurações são efetivadas somente com a execução do RECONFIGURE, para estas opções a efetivação só ocorre com a reinicialização do serviço do SQL Server. Para verificar quais são estas opções basta consultar a tabela sys.configurations (disponível no SQL Server 2005/2008). As configurações que tiverem o campo is_dynamic igual a 0 (zero) só entrarão em vigor quando o serviço do SQL Server for reiniciado. Note que se o comando RECONFIGURE não for executado, mesmo que a instância seja reiniciada a nova configuração não entrará em vigor.

Outras configurações possíveis através da sp_configure: habilitar a procedure xp_cmdshell,  procedures do Database Mail,  código gerenciado (CLR), configurar o número de processadores utilizados pela instância (paralelismo), configurar memória extendida (AWE), etc.

  • RECONFIGURE ou RECONFIGURE WITH OVERRIDE?

Se ao alterar uma configuração o DBA definir um valor que foge às recomendações do SQL Server, ao executar a opção RECONFIGURE o SQL Server irá rejeitar a alteração e notificar o usuário. Por exemplo, na versão 2000 era possível realizar alterações nas tabelas de sistema do SQL Server (isso mudou um pouco nas versões 2005 e 2008), para isso bastava executar o comando:

EXEC sp_configure 'allow updates', '1'

No entanto, por razões óbvias esta não é uma prática recomendada, então nessas situações, ao executar somente o RECONFIGURE, o SQL Server exibia a seguinte mensagem:

Configuration option ‘allow updates’ changed from 1 to 1. Run the RECONFIGURE statement to install.

Msg 5808, Level 16, State 1, Line 1

Ad hoc updates to system catalogs not recommended. Use the RECONFIGURE WITH OVERRIDE statement to force this configuration.

Logo o DBA só poderia concretizar essa operação se utilizasse o RECONFIGURE WITH OVERRIDE, ou seja, esta é a forma do SQL Server se proteger contra ações indevidas e dizer ao DBA:  “amigo, isso é por sua conta e risco”. Portanto, o WITH OVERRIDE é uma opção a ser evitada e só é recomendada em situações pontuais.

  • Conclusão

Conhecer as diferentes formas de configurar uma instância SQL Server dá ao DBA maior liberdade no momento de realizar estas tarefas, neste caso, além das ferramentas gráficas o DBA também poderá utilizar a sp_configure no SQLCMD, OSQL ou agendar alterações de configurações através de jobs e etc.

Para ter acesso a todas as opções de configurações disponíveis na sp_configure, consulte a tabela sys.configurations ou acesse o Books Online.

Bom trabalho, bons estudos.

DBA Checklist – Instalação e Atualização

Essa série de Check List para DBAs SQL Server foi escrita por Brad McGehee para o site http://www.simple-talk.com/ . É um texto sucinto, mas muito completo. Tomei a liberdade de adicionar algumas observações(em itálico) que normalmente apontam para outros conteúdos em português. O texto original pode ser lidoaqui.

Instalação

  • Sempre documente todo o processo de instalação do SQL Server, para que numa situação de emergência o processo possa ser facilmente reproduzido.
  • Se possível, instale e configure todas as suas instâncias do SQL Server seguindo um padrão que foi acordado e aceito por sua organização. Opcionalmente, utilize o SQL Server 2008 Policy-based Management para fazer com que todas as normas sejam cumpridas.
  • Não instale serviços do SQL Server que não serão usados, como o Microsoft Reporting Services ou Analysis Services (se você não usá-los).
  • Para o melhor desempenho do SQL Server, desabilite todos os serviços do Windows que não são necessários.
  • Para o melhor desempenho do SQL Server, dedique seu servidor físico à sua instância SQL Server, não rode outras aplicações nele.
  • Para o melhor desempenho de I/O, coloque os arquivos .mdf e .ldf em volumes de discos separados para evitar conflitos de escrita e leitura.
  • Se a TEMPDB for muito utilizada, coloque esta base em discos separados. Além disso, faça uma estimativa para o tamanho desta base, de forma que não ocorra crescimento automático. Divida a TEMPDB em vários arquivos, de forma que o número de arquivos físicos represente 50% a 100% do número de núcleos da CPU do seu servidor. Cada arquivo físico deve ter o mesmo tamanho.
  • Não instale o SQL Server num controlador de domínio.
  • Nos arquivos de dados e logs não utilize compactação, nem EFS (criptografia em sistemas de arquivos NTFS) .

Atualizando

  • Para evitar problemas potenciais, execute o Upgrade Advisor em qualquer banco de dados que você pretende atualizar.
  • Antes de realizar uma atualização do SQL Server, teste seu aplicativo num ambiente de testes para garantir compatibilidade. Antes de realizar a atualização faça as alterações necessárias.
  • Antes de qualquer atualização, verifique se você tem um plano ‘B’ para o caso de uma falha.
  • O upgrade ‘in place’ pode funcionar bem, mas instalar o novo SQL Server num novo hardware é menos arriscado (side-by-side).
    • Para entender mais sobre as técnicas de upgrade no SQL Server, veja essa ótima apresentação de José Ricardo Ribeiro (download em português):
  • Depois do upgrade, você deverá atualizar todas as estatísticas dos seus bancos de dados, usando o UPDATE STATISTICS. Isso é necessário porque as estatísticas não são automaticamente atualizadas durante o processo de atualização. Além disso, executar o UPDATE STATISTICS pode corrigir a contagem interna das páginas.

DBA Checklist – Sobre a profissão e a rotina

Essa série de Check List para DBAs SQL Server foi escrita por Brad McGehee para o site http://www.simple-talk.com/ . É um texto sucinto, mas muito completo. Tomei a liberdade de adicionar algumas observações (em itálico) que normalmente apontam para outros conteúdos em português. O texto original pode ser lido aqui.

Dicas de boas práticas para tornar-se um DBA Excepcional

  • Junte-se a um grupo de usuários de SQL Server.
  • Participe pelo menos uma vez ao ano de uma conferência profissional.
  • Faça pelo menos um treinamento por ano.
  • Leia pelo menos quatro livros de SQL Server por ano.
  • Leia o e-book How to Become an Exceptional DBA.
    • Livro escrito pelo autor que dá diversas dicas de como torna-se um DBA Excepcional (download em inglês).
  • Saiba tudo o que puder sobre o seu trabalho, principalmente naquelas áreas que ninguém gosta ou quer dominar.
  • No seu trabalho, seja voluntário, envolva-se em novas tarefas e aceite desafios, isso fará com que você conheça mais sobre a organização da sua empresa.
  • Instale o SQL Server no computador da sua casa ou em seu notebook e pratique, aprendendo novas funcionalidades do SQL Server, principalmente no SQL Server 2008.
  • Participe de fóruns sobre SQL Server (fazendo e respondendo perguntas).

Dia-a-dia

  • Verifique os logs do Windows, do SQL Server e logs de segurança.
  • Verifique se todos os jobs foram executados com sucesso.
  • Veja se os backups foram executados com sucesso e se foram salvos em local seguro.
  • Monitore o espaço em disco para garantir que o SQL Server não fique sem espaço. Para um melhor desempenho, todos os discos devem ter pelo menos 20% de espaço livre.
  • Durante todo o dia, periodicamente, monitore o desempenho do seu servidor. Use o System Monitor, Profiler, DMVs, ou o SQL Server 2008 Performance Data Collector.
  • Use o Management Studio ou o Profiler para monitorar e identificar problemas de locks [bloqueios].
  • Mantenha um registro de todas as alterações feitas em seus servidores, incluindo uma documentação de todos os problemas de desempenho que você encontrar e corrigir.
  • Crie alertas no SQL Server para notificá-lo através de e-mail sobre problemas potenciais. Ao receber os e-mails tome as medidas necessárias.
  • Dedique um tempo do seu dia para aprender algo novo e promover seu desenvolvimento profissional.


Propriedades do arquivo

No SQL Server 2000 existe uma procedure não documentada que traz as propriedades de um arquivo, como data de criação, data de alteração e etc; sem dúvidas um recurso bastante interessante.

Veja um exemplo da chamada:

xp_getfiledetails ‘C:\WINDOWS\EXPLORER.EXE’

Problemas? Sim… essa proc não está mais disponível a partir da versão 2005.
Esse sem dúvidas é um bom motivo para não nos apegarmos à funcionalidades não documentadas… depois dá uma dor de cabeça enorme e um monte de DBA indignado correndo atrás de uma solução similar.

(Bom, mas pra quem continua com o SQL Server 2000, ainda é uma ótima opção! :D )

Comparando text / ntext

 

No SQL Server 2005 temos os novos campos do tipo VAR…(MAX) que vieram aliviar o trabalho de muita gente. Um dos problemas mais comuns na versão anterior (2000) é quando precisamos comparar dados de campos do tipo text ou ntext, aí nos deparamos com um erro do tipo:

Server: Msg 306, Level 16, State 1, Line 1

The text, ntext, and image data types cannot be compared or sorted, except when using IS NULL or LIKE operator.

Eu já vivi essa situação algumas vezes e deixo aqui a forma como tentei resolver (Se tiverem outras sugestões fiquem a vontade para expor, ok?).

(Não fiz testes de perfomance nessa solução, o foco está somente em comparar as colunas tipo text / ntext.)

Imagine que eu tenha duas tabelas:

CREATE TABLE #tb_msg_tela
(id INT IDENTITY(1,1), texto TEXT)

GO

CREATE TABLE #tb_msg_impressao
(id INT IDENTITY(1,1), texto TEXT)

Com os seguintes dados:

INSERT INTO #tb_msg_tela VALUES (NULL)
INSERT INTO #tb_msg_tela VALUES (‘Campo text’)
INSERT INTO #tb_msg_tela VALUES (‘Teste comparação‘)
INSERT INTO #tb_msg_tela VALUES (‘Se caísse para o exterior, para o limite do universo, encontraria uma perto e pôsteres que indicassem BECO SEM SAÍDA?’)

INSERT INTO #tb_msg_impressao VALUES (”)
INSERT INTO #tb_msg_impressao VALUES (‘Campo text’)
INSERT INTO #tb_msg_impressao VALUES (‘Teste comparacao‘)
INSERT INTO #tb_msg_impressao VALUES (‘Se caisse para o esterior, p/ o limite do universo, encontraria uma perto e pôsteres que indicassem BECO SEM SAÍDA?’)

Observe que existem diferenças em alguns textos (em vermelho).

Para realizar o relacionamento das duas tabelas e encontrar os campos diferentes não podemos simplesmente utilizar:

SELECT * FROM #tb_msg_tela a, #tb_msg_impressao b
WHERE a.id = b.id AND a.texto <> b.texto

Essa consulta retornará um erro porque estamos comparando os campos text utilizando o <>.

Então o primeiro passo é encontrar o maior texto nessa coluna, para isso podemos usar as funções DATALENGHT e MAX:

SELECT MAX(DATALENGTH(texto)) FROM #tb_msg_tela
SELECT MAX(DATALENGTH(texto)) FROM #tb_msg_impressao

O resultado será:

———–

658

———–

656

Então sabemos que o maior texto dessa coluna não ultrapassa 700 caracteres, logo, podemos utilizar esse número como apoio no próximo passo, onde utilizaremos a função SUBSTRING:

SELECT
                *
FROM  
                #tb_msg_tela a,
                #tb_msg_impressao b
WHERE
                a.id = b.id
                AND ISNULL(SUBSTRING(a.texto, 0, 700),”) <> ISNULL(SUBSTRING(b.texto, 0, 700),”)

 

A função ISNULL é importante pois sem ela os campos Nulos serão ignorados.

Veja que a consulta só ira retornar os campos com as diferenças.

É um processo simples, mas que pode dar dor de cabeça por conta das limitações do tipo de dados. Pra quem ta iniciando o desenvolvimento utilizando o SQL Server 2005 a recomendação é: substitua os datatypes ntext, text, image por nvarchar(Max), varchar(Max) e varbinary(Max). Além de outras vantagens, com os novos datatypes não existem as antigas diferenças entre varchar e text.