- Cuidados Indispensáveis para todo DBA na Manutenção do SQL Server
-
Para quem participou do TechEd 2008 e visitou a nossa apresentação gostaria de agradecer a presença. O Título de nossa apresentação foi “ Cuidados Indispensáveis para todo DBA na Manutenção do SQL Server ”.
Bom, para que todos tenham em linhas gerais o conhecimento o que foi apresentado vamos mostrar abaixo. Basicamente classificamos 10 itens que são importantes para a manutenção de um servidor SQL Server. São eles :
10. Gerenciamento de arquivos de dados
Pontos importantes para otimizar os arquivos de dados:
9. Gerenciamento de arquivos de log transacional
Otimizando os arquivos de Log
-
Alocar somente um arquivo de log
-
Isolar o arquivo de log em um drive separado (escritas sequenciais) dos dados
-
Desfragmentar o drive no qual o log reside
-
Pré-alocar um tamanho de log apropriado
-
Reduza o uso de auto-growth
- Otimize o RAID array aonde o arquivo de log reside:
considere RAID 1+0 em vez de RAID 1, RAID 5 não é recomendado
-
Tenha certeza em otimizar a fragmentação interna do arquivo existente – reduza VLFs (disk bound system pode experimentar alguma degradação de performance no backup de log)
8. Tempdb
Otimizando a base de dados Tempdb
-
Tempdb deve estar isolado, veja artigo KB 224071. Portanto, em drive diferente dos arquivos de log e dados.
-
No caso de servidores multi-processados, o Tempdb deve ser criado com múltiplos arquivos
-
Criar 1 para cada CPU física (sem Hyperthreading) ou número de cores.
-
Por exemplo, quad proc com dual core são 8 processadores cores, portanto o tempdb deve ser criado com 8 arquivos de dados para aliviar o gargalo dos recursos do sistema.
Com o limite recomendado de 10 arquivos de dados.
-
Para mais informações, veja o whitepaper Working with Tempdb e o artigo KB: 328551
7. Sua estratégia de indexação está funcionando?
Estratégia de índices
* Determine testes padrões preliminares do uso da tabela
* OLTP – poucos índices
* OLAP – mais e largos índices
* Criação de chaves clusterizadas
* Criar constraints – chave primária e chaves alternativas/candidatas
* Manualmente adicione índices para as colunas Foreign key
* Capture workload(s) e analise com Database Tuning Advisor (2005)
* Adicione índices extras para ajudar na performance de SARGs, joins, aggregations
Melhores Práticas de Indexação
* Não vá loucamente adicionando índices
* Somente porque você tem índices em todas as colunas (e/ou INCLUA todas colunas) – não significa que você pode !
* Pare de indexar após você ter configurado a estrutura básica da tabela e comece avaliar aonde quer ir ...
* Inexação exagerada pode ser pior que pouca indexação
* Índices que não possuem manutenção podem ser mais problemáticos em longa execução ( configurar manutenção )
* Lembre-se, um índice pequeno pode ter pouco uso…
* Um índice mais largo tem muito mais uso - você pode estar apto para fazer alguns índices existentes mais úteis deixando eles mais largos
(ok, você não pode diretamente adicionar colunas mas você pode criar novos índices e então eliminar aqueles que você não está usando).
6. Estatísticas
O que ocorre se os dados mudam?
* Atualização automática
* Caso o auto update statistics está ON (para ambos o DB e o índice não foram criados com “norecompute”)
* Caso o percentual de dados mudar
* Detalhes completos no whitepaper do TechNet
* Atualização das estatísticas manualmente
* Para tabelas altamente voláteis aonde a distribuição não é significamente alterada e você verifica vários eventos de “estatísticas”
* Desative “auto update” ou desative auto update através do acréscimo de STATISTICS_NORECOMPUTE na definição do índice ( melhor controle)
* Execute UPDATE STATISTICS
5. Fragmentação de Índices
Identificando Fragmentação
* As chaves para um sucesso são:
* Conhecer quais índices procurar
* Quais são usados para um range scans?
* Quais possuem densidade de página muito baixa ?
* Conhecer quais opções usar nos vários métodos
* Conhecer como interpretar os resultados
* Utilizar sys.dm_db_index_physical_stats DMV em 2005
* Utilizar DBCC SHOWCONTIG em 2000
* Continua na versão 2005, mas está obsoleto
* Simplesmente não reconstrua todos os índices diariamente!
4. Identificando corrupção
DBCC CHECKDB
* A única maneira de ler todas as páginas alocadas na base de dados
* Utiliza o force page checksums para ser avaliado (marcado)
* Escolha entre full checks e WITH PHYSICAL_ONLY
* Vários algoritmos para minimizar runtime e executar ONLINE
* Comparado com 6.5 ou 7.0
* Novas features em 2005
* Progress reporting, data purity, indexed views, last known good, no false failures…
3. Notificação de Problema
Como Dizer Algo que Vem Errado ?
* Você configurou um job regular para executar um DBCC CHECKDB – como você pode dizer se foi errado ?
* Existem alguns tipos de monitoramente caso contrário você nunca vai saber!
* Monitoração manual é tempo de consumo e pode ser esquecido em algum momento
* Solução: Alertas de agentes
* Crie alertas para :
* Erro de Severidade 19 e superiores
* Qualquer erro definido por usuário (ex. Mostrar que o job do CHECKDB ‘falhou’)
* Qualquer coisa que esteja interessado
* Escolha entre NET SEND (unreliable), email, pager
2. Fazendo backups
Utilize Backups
* Melhor maneira de evitar perca de dados (e talvez downtime)
* Várias opções disponíveis no SQL Server 2005
* Backup Full das bases de dados é um bom ponto de partida
* Série de Backups de log transacional são muito melhores
* Você deve ter backups para estar apto para usar-los
* Você deve ter backups válidos para estar apto para usar-los
* Tenha certeza que as bases de dados estão limpas antes do backup.
* Tenha certeza que os arquivos de backup não estejam corrompidos.
1 . Testando
É Tudo Sobre Testar
* Teste seu:
* Plano de disaster recovery
* Se os Backups são válidos
* Estratégia de Indexação
* Alertas
* Teste, teste, teste
* E então teste novamente dentro de alguns mêses.
* E novamente.
* Nós mencionamentos testar ? J
- Microsoft SQL Server: Edição, Versão, Service Pack e Build
-
O ponto de partida de qualquer projeto que envolve o Microsoft SQL Server é saber qual a Edição, Versão, Service Pack e Build que precisa ser instalado no ambiente. Por isso, é bom conhecer antes quais são as necessidades, capacidade de crescimento (capacity plan), disponibilidade do ambiente, dentre outras informações para adquirir e instalar a edição correta do produto.
Para lhe ajudar neste ponto, segue abaixo dois links muito interessantes que mostram as diferenças para cada Edição do SQL Server 2005 e 2008.
Choosing the Right Edition for Your Needs – SQL Server 2008
http://www.microsoft.com/sqlserver/2008/en/us/editions.aspx
SQL Server 2005 Features Comparison
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
Normalmente, quando temos algum problema em nosso ambiente e precisamos da ajuda de algum profissional SQL, uma das primeiras perguntas que eles fazem é : Qual é a versão do SQL ? Bom, isso pode ser resolvido com o seguinte artigo:
Como identificar a versão e a edição do seu SQL Server
http://support.microsoft.com/kb/321185
Mas, uma coisa que não pode confundir é Versão comEdição.
Veja o exemplo abaixo:
A versão do produto (por exemplo, 8.00.534).
O nível do produto {Service Pack} (por exemplo, "RTM" ou "SP2").
A edição (por exemplo, "Standard Edition").
Essas informações são muito importantes para começarmos a fazer uma correta avaliação do ambiente e do problema que está ocorrendo.
Em alguns casos pode ser questionada a versão do build / cumulative Pack do SQL Server.
Por exemplo, o build 9.00.3239 é mais antigo que o build 9.00.3282. Neste caso estamos comentando respectivamente o Cumulative Pack 7 do SQL Server 2005 SP2 e o Cumulative Pack 9 do SQL Server 2005 SP2. Cada build novo, é uma nova correção da versão do produto (fix).
Segue abaixo um link com a relação de todos os builds criados pós SQL Server 2005 Service Pack 2.
Lista dos builds que foram criados após o SQL Server 2005 Service Pack 2 (SP2)
http://support.microsoft.com/kb/937137/en-us
Para vocês terem um mapeamento completo desde a versão do SQL Server 7.0, segue abaixo a relação de todos as versões e Service Packs do Microsoft SQL Server.
Mais informações com uma lista de builds quase que completa, pode ser visto no link do blog abaixo listado: http://sqlserverbuilds.blogspot.com/ .
Não é um site oficial Microsoft, mas ajuda bastante.
Caso queria receber em seu e-mail, todas as atualizações dos produtos Microsoft, além do SQL Server entre no site http://kbalertz.com/Default.aspx e faça uma assinatura gratuita. O site kbAlertz.com é um sistema de notificação por e-mail que pesquisa a base de dados de conhecimento da Microsoft toda a noite e encaminha e-mails para você quando existem updates ou atualizações (fix) nas tecnologias que você optou em receber as notificações.
Com o conhecimento destas informações, os próximos posts irão ficar mais fáceis de se trabalhar. Porque, se tiver dúvidas, é só voltar neste post para saber um pouco mais sobre as Edições, Versões, Service Packs e Builds do Microsoft SQL Server.
Muito Obrigado,
Abraço
Ioannis V. Xylaras
- MSDN Experience SQL Server está no ar !
-
Tenho o prazer de informar que está no ar o MSDN Experience de SQL Server do MSDN Brasil: http://www.msdnbrasil.com.br/experience/sqlserver.
O Experience de SQL Server conta com 5 módulos, que cobrem desde à introdução ao SQL Server e suas ferramentas, passando pela escrita de consultas (simples e complexas), criação de views e stored procedures, programação CLR, arquitetura e componentes internos, indexação, gerenciamento de transações, análise de performance e troubleshooting, e como um extra, ainda temos duas sessões sobre o Service Broker.
São vários treinamentos dividos em módulos, com duração média de 50 minutos e mostra as experiência de vários profissionais de campo, fornecendo dicas
do dia a dia na prática. Tudo em português !
É uma excelente oportunidade para ajudarmos nossa comunidade a se atualizar tecnicamente e conhecerem melhor esse fantástico produto. O conteúdo do MSDN Experience pode ser aplicado tanto para o SQL Server 2005 e 2008, como em parte, para o SQL Server 2000.
Bom Treinamento. @:)
Abraço,
Ioannis V. Xylaras
- Apresentação PFE Ioannis V. Xylaras
-
Ola pessoal,
Eu sei que demoramos um bocado para colocar a página para funcionar. Mas agora é para valer. Vou me apresentar em algumas linhas e futuramente os outros engenheiros do
time de SQL Brasil irão fazer o mesmo.
Bom, para começar PFE é um titulo que os engenheiros de campo recebem "Premier Field Engineer". O nosso papel é ajudar os clientes Microsoft que possuem um contrato de suporte chamado "Premier". Atendemos casos em toda a America Latina e às vezes em outros continentes. O principal foco é o trabalho reativo, ajudando o cliente a resolver problemas que ocorrem no dia a dia. Também atuamos de forma proativa, realizando trabalho de análise de ambiente, recomendando melhores práticas para o uso do SQL Server.
Estou na equipe a quase 7 anos, atuando com SQL e outros software de Integração, como HIS, BizTalk ....
Possuo as certificações MCSA 2K/2k3, MCSE 2K/2K3, MCDBA 2K, MCTSe MCITP (Administrator).
A minha idéia aqui no blog é tentar não ser repetitivo como os outros blogs que já existem, mas sim fazer recomendações e passar dicas do que realmente vemos em campo.
É importante informar que não existem garantias para as recomendações, pois todas as recomendações devem ser feitas em laboratório, testadas, estressadas e se tudo
ocorrer bem, ai sim aplicadas em produção. Isso é muitíssimo importante!
Espero que gostem das dicas que iremos transmitir a partir de agora.
O meu e-mail para contato é ixylaras@hotmail.com.
Muito Obrigado,
Abraços
Ioannis V. Xylaras
- Apresentação do grupo
-
Olá comunidade!
Este é o blog dos engenheiros de SQL Server do grupo PFE Brasil. Como primeiro contato gostaríamos de apresentar o importante papel que desempenhamos e algumas características do nosso trabalho.
PFE, ou Premier Field Engineering, criado originalmente sob a denominação de ROSS (Rapid On-site Support Services), é o grupo de engenharia da Microsoft dedicado à tarefa de suportar os clientes que possuem contratos de suporte Premier. Esses contratos possibilitam, entre outros benefícios, que o cliente usufrua de suporte on-site em suas instalações executado por engenheiros da Microsoft.
O grupo de PFE está presente em todos os continentes e na América Latina conta com 35 engenheiros (julho de 2007) baseados nas principais capitais ou em pontos estratégicos para a locomoção: Cidade do México, Cidade do Panamá, Caracas, Bogotá, Santiago, Buenos Aires, Rio de Janeiro, Brasília e São Paulo. Os brasileiros somam 17 engenheiros. Os engenheiros são especialistas em diferentes áreas como: mensageria/correio-eletrônico, bancos de dados, segurança e desenvolvimento, sendo capacitados continuamente nas novas tecnologias e produtos da Microsoft.
A principal missão dos engenheiros PFEs é de estar disponíveis 24 horas por dia, 7 dias por semana e 365 dias por ano para atuar na solução de problemas críticos, conhecidos também como CritSit (critical situation). Quando não estão atuando na resolução de problemas, os engenheiros utilizam seu tempo transferindo conhecimento para as equipes técnicas dos clientes através de workshops ou revisando seus ambientes pró-ativamente para prevenir que novos problemas ocorram.
O grupo de PFE interage também com as comunidades técnicas. A primeira grande aparição pública do grupo se deu no evento TechEd de 2006 onde manteve uma sessão de palestras (track) dedicadas ao tema suporte. O grupo também vem atuando nos webcasts do TechNet/MSDN e em reuniões da comunidade TopIT.
O intuito desse blog é estreitar os laços entre o grupo de PFE e as comunidades técnicas focadas em tecnologias Microsoft, possibilitando o intercâmbio de idéias e conhecimento com os engenheiros altamente especializados do grupo. Esperamos que todos vocês gostem e nos ajudem a fazer deste espaço um centro de excelência para toda a comunidade!
Um forte abraço!
PFE SQL Brasil
