Palestrando no InfraSecDay – 26-07-2014

evento infrasecday 01 evento infrasecday

infrasecday3

 

Pessoal, tive a honra de receber o convite para palestrar sobre SQL Server no InfrasecDay que ocorreu em Recife-PE no dia 26-07-2014.

Aproveitei o convite e compartilhei o mesmo com Diego Uchoa que atua no mesmo time que eu na  Intradb Consultoria, empresa a qual atualmente trabalho no time de Plataforma de Dados.

 

Tema: Você realmente sabe o que tem no seu SQL Server?

 

Link do evento: http://infrasecday.com.br/infrasecday/index.php/palestras

 

SQL Server – Cannot show request dialog property owner is not available for Database

Pessoal,  dias atrás peguei um probleminha quando ao tentar exibir a  propriedade da base de dados  o SSMS exibia o seguinte erro: cannot show request dialog  property owner is not available for Database.  Este erro geralmente  ocorre  quando a base de dados está sem owner. O que fiz para resolver?  Executei o comando abaixo:

use basededados
EXEC sp_changedbowner ‘usuariodesejado’

 

Abraços, Maycon Alves.

Desabilitar / Habilitar Trigger de uma tabela no SQL Server?

Estes dias em  minha caminhada em consultoria, um cliente me perguntou se era possível desabilitar  e habilitar as trigger de uma tabela sem dar drop e depois create. Eu respondi que é possível sim. Citei os dois comandos abaixo para que ele rodasse no ambiente dele, e depois fizesse a importação de dados que ele desejava.

Exemplo:

disable trigger all on nome_da_tabela — desabilita

enable trigger all on nome_da_tabela — habilita 

Abraços, Maycon Alves.

Autogrow e Autoshrink no SQL Server?

Vivo andando por empresas e sempre é recorrente esta pergunta : Maycon, qual o recomendado para autogrow e autoshrink? Sempre respondo que depende do ambiente. Estava aqui lendo uma artigo muito interessante e que que comprova muito do que eu falo para as pessoas. Cito abaixo , um trecho do KB que acabo de ler:

Considerações sobre as configurações “autogrow” e “autoshrink” no SQL Server

Como isso afeta o desempenho?

  • Se você executar uma transação que exija mais espaço em log do que o disponível e se tiver ativado a opçãoautogrow do log de transações do banco de dados, o tempo gasto para a conclusão da transação incluirá o tempo que o log de transações leva para atingir o tamanho configurado. Se o incremento de crescimento for grande ou se houver algum outro fator que faça com que o processo demore muito, poderá ocorrer falha na consulta em que a transação é aberta devido a um erro de tempo limite. O mesmo tipo de problema pode resultar do crescimento automático da parte de dados do banco de dados. Para alterar a configuração autogrow, consulte o tópico “ALTER DATABASE” nos Manuais Online do SQL Server.
  • Se você executar uma transação grande que exija o aumento do log, outras transações que exigem uma gravação no log de transações também precisarão aguardar a conclusão da operação de crescimento.
  • Se combinar as opções autogrow e autoshrink, você poderá criar uma sobrecarga desnecessária. Garanta que os limites que acionam as operações de crescimento e redução não causem alterações de tamanho frequentes. Por exemplo, você pode executar uma transação que faça com que o log cresça 100 MB até o momento da confirmação. Algum tempo depois, a opção autoshrink é iniciada e reduz o log de transações em 100 MB. Em seguida, você executa a mesma transação, o que faz com que o log de transações aumente 100 MB novamente. Nesse exemplo, você está criando sobrecarga desnecessária e provavelmente está causando a fragmentação do arquivo de log. Em ambos os casos, o desempenho pode ser afetado negativamente.
  • A fragmentação física resultante da alteração do tamanho dos arquivos de dados ou de log pode ter um grande impacto no desempenho. Isso acontecerá se você usar as configurações automáticas ou se aumentar e diminuir manualmente os arquivos com frequência.
  • Se aumentar o banco de dados por pequenos incrementos ou se aumentá-lo e, em seguida, reduzi-lo, você poderá causar a fragmentação do disco. Em algumas circunstâncias, a fragmentação do disco pode resultar em problemas de desempenho. Um cenário de pequenos incrementos de crescimento também pode prejudicar o desempenho do sistema.
  • No SQL Server 2005 ou em versões posteriores, você pode habilitar a inicialização imediata de arquivos. A inicialização imediata agiliza as alocações apenas para arquivos de dados. Ela não se aplica a arquivos de log.
  • Se houver muitas operações de aumento nos arquivos de log, talvez você tenha uma quantidade excessiva de arquivos de log virtuais (VLF). Isso pode levar a problemas de desempenho na inicialização do banco de dados ou na replicação, no espelhamento, no CDC (Change Data Capture) e nas operações online. Além disso, às vezes isso pode causar problemas de desempenho na modificação de dados.

Práticas recomendadas

  • Para sistemas de produção gerenciada, considere autogrow uma mera contingência do crescimento inesperado. Não use autogrow para gerenciar o crescimento diário de dados e de log.
  • Você pode usar programas de monitoramento ou alertas para controlar o tamanho dos arquivos e aumentar arquivos de forma pró-ativa. Isso ajuda a evitar a fragmentação e permite transferir essas atividades de manutenção para horários que não sejam de pico.
  • AutoShrink autogrow devem ser cuidadosamente avaliados por um Administrador de Banco de Dados (DBA) treinado; eles não devem ficar sem gerenciamento.
  • O incremento autogrow deve ser grande o suficiente para evitar as penalidades de desempenho listadas na seção anterior. O valor exato a ser usado na definição de configuração e a seleção do aumento de uma porcentagem ou do aumento de um tamanho específico em MB depende de muitos fatores do ambiente. Um método confiável usado para testes é definir a configuração autogrow como aproximadamente um oitavo do tamanho do arquivo.
  • Ative a configuração <MAXSIZE> de todos os arquivos para impedir que eles cresçam demais, a ponto de usar todo o espaço em disco disponível.
  • Mantenha as transações com o menor tamanho possível para evitar o crescimento não planejado de arquivos.

Por que preciso me preocupar com espaço em disco se as configurações de tamanho são controladas automaticamente?

  • A configuração autogrow não pode aumentar o tamanho do banco de dados além dos limites do espaço em disco disponível nas unidades para as quais os arquivos são definidos. Portanto, mesmo que use a funcionalidade autogrowpara dimensionar seus bancos de dados, você deve verificar independentemente o espaço em disco rígido disponível. A configuração autogrow também é limitada pelo parâmetro MAXSIZE selecionado para cada arquivo. Para reduzir a possibilidade de ficar sem espaço, você pode monitorar o contador do Monitor de Desempenho SQL Server: Objeto de Banco de Dados: Tamanho dos Arquivos de Dados (KB) e configurar um alerta para quando o banco de dados atingir um determinado tamanho.
  • O crescimento não planejado de arquivos de dados ou de log pode ocupar um espaço que deveria estar disponível para outros aplicativos, o que pode causar problemas para esses aplicativos.
  • O incremento de crescimento do log de transações deve ser grande o suficiente para suprir as necessidades das unidades de transação. Mesmo com autogrow ativado, você poderá receber uma mensagem informando que o log de transações está cheio, caso ele não consiga crescer de modo suficientemente rápido para satisfazer às necessidades de sua consulta.
  • O SQL Server não realiza testes constantes para detectar bancos de dados que tenham atingido o limite configurado para autoshrink. Em vez disso, ele examina os bancos de dados disponíveis e localiza o primeiro configurado para autoshrink. Ele verifica esse banco de dados e o reduz, se necessário. Em seguida, ele aguarda alguns minutos antes de verificar o próximo banco de dados configurado para autoshrink. Em outras palavras, o SQL Server não verifica todos os bancos de dados de uma só vez, mas reduz todos ao mesmo tempo. Os bancos de dados são processados em rodízio (round robin) para que seja possível organizar a carga ao longo de um período. Portanto, dependendo do número de bancos de dados de uma determinada instância do SQL Server configurados para autoshrink, o processo que ocorre entre momento em que o banco de dados atinge o limite e a redução efetiva desse banco de dados poderá demorar várias horas.

fonte: http://support.microsoft.com/kb/315512/pt-br

Espero ter ajudado, abraços Maycon Alves.