6. Desafios de um DBA
• O objectivo de um DBA é “não trabalhar”.
• Um bom DBA é um DBA preguiçoso.
• Nós queremos o mais
calmo ambiente:
• Bem planeado.
• Bem configurado.
• Bem monitorizado.
6
6
7. Desafios de um DBA
• Quando um DBA está de prevenção, o barulho do pager
é…
7
7
8. Desafios de um DBA
• Quando um DBA está de prevenção, o barulho do pager
é…
IRRITANTE
8
8
9. Desafios de um DBA
• Tarefas planeadas são aceitáveis…
• Alarmes são horríveis!!
•
•
•
•
Lentidão.
Problemas de falta de espaço.
Bases de Dados corrompidas.
Jobs de manutenção que falham.
9
9
10. Desafios de um DBA
• Tarefas planeadas são aceitáveis…
• Alarmes são horríveis!!
•
•
•
•
Lentidão.
Problemas de falta de espaço.
Bases de Dados corrompidas.
Jobs de manutenção que falham.
Não queremos isso!
10
10
11. Desafios de um DBA
As vezes é um desafio definir…
Backups
Performance
Índices
Manutenção
Estatísticas
Disaster Recovery
11
12. Desafios de um DBA
• Nos próximos slides iremos ver abordagens que irão
facilitar:
•
•
•
Minimizar alarmes.
Aumentar a disponibilidade.
Manter a manutenção recorrente bem encaminhada.
12
12
13. Desafios de um DBA
• Nos próximos slides iremos ver abordagens que irão
facilitar:
•
•
•
Minimizar alarmes.
Aumentar a disponibilidade.
Manter a manutenção recorrente bem encaminhada.
• Vamos ser proactivos primeiro, depois preguiçosos
13
13
15. Config. o SO – Inst. File Initialization
Instant File Initialization
A activação do IFI pode aumentar a velocidade de criação e
expansão de ficheiros de dados.
16. Config. o SO – Inst. File Initialization
A activação do IFI pode aumentar a velocidade de criação e
expansão de ficheiros de dados.
O mesmo não é válido para ficheiros de log!
18. Config. o SO – Anti-Virus
Anti-Virus
Não é incomum encontrar Anti-Virus
em servidores com SQL Server…
… mas, por vezes, o AV age tal e qual um
VIRUS!
19. Config. o SO – Anti-Virus
Porque não utilizar AV junto com o SQL Server?
•
•
•
•
O licenciamento custa €€.
A manutenção custa tempo.
Pode causar problemas.
Não protege de zero-day exploits.
20. Config. o SO – Anti-Virus
Qual é o grande problema para o SQL Server?
• Mais uma aplicação concorrendo por
recursos.
• Os ficheiros do SQL Server podem ser
sujeitos a varrimento e mesmo ficar
bloqueados.
21. Config. o SO – Anti-Virus
Qual seria nossa opção?
•
•
•
•
Manter os servidores atualizados.
Configurar a firewall corretamente.
Restringir o acesso ao servidor.
Podemos instalar o AV… em workstations apenas!
22. Config. o SO – Anti-Virus
Mas eu gosto de AV! O que posso fazer para
manter o SQL Server e o AV juntos?
23. Config. o SO – Anti-Virus
Mas eu gosto de AV! O que posso fazer para
manter o SQL Server e o AV juntos?
Configure Exceções!
24. Config. o SO – Anti-Virus
Basicamente, o AV deve excluir:
•
•
•
•
Ficheiros de dados e log do SQL (.mdf, .ndf e .ldf).
Ficheiros de backup (.bak and .trn).
Ficheiros do Full-text Catalog.
Ficheiros Trace (.trc), XE (.xem, .xel) e Audits
(.sqlaudit).
• Os ficheiros de ERRORLOG.
• A pasta contendo os binários do SQL Server.
• A pasta do Filestream.
Mais detalhes em: http://support.microsoft.com/kb/309422
25. Config. o SO - Network
Rede
• Por vezes esquecida, a rede tem uma função
especial na instância.
• É a auto-estrada por onde passam os nossos
dados.
• Não apenas dados aplicacionais, mas
manutenção, backups e outros serviços ….
• Tudo isso está viajando na rede.
26. Config. o SO - Network
Então, qual a melhor abordagem?
27. Config. o SO - Network
Então, qual a melhor abordagem?
Dividir !
28. Config. o SO - Network
Backups Network
Front-End Network
Back-End Network
29. Config. o SO – Storage
Storage
• Planeie uma arquitetura eficiente para o storage.
• Normalmente, quanto mais segregado melhor.
30. Config. o SO – Storage
Storage
• Planeie uma arquitetura eficiente para o storage.
• Normalmente, quanto mais segregado melhor.
Sugestão:
SQL BIN
SQL DATA
SQL IDX
SQL LOGS
SQL TMP
31. Config. o SO – Storage
Mountpoints podem ser uma boa estratégia.
32. Config. o SO – Storage
Mountpoints podem ser uma boa estratégia.
Prós:
•
•
•
•
Escalável.
Economiza letras (limitado a 26).
Fácil de adicionar.
Não necessita de reiniciar o SQL.
33. Config. o SO – Storage
Mountpoints podem ser uma boa estratégia.
Prós:
•
•
•
•
Contras:
Escalável.
• Parece uma pasta normal.
Economiza letras (limitado a 26). • É preciso ter uma abordagem
Fácil de adicionar.
diferente na monitoria.
Não necessita de reiniciar o SQL.
34. Config. o SO – Storage
Mountpoints podem ser uma boa estratégia.
Prós:
•
•
•
•
Escalável.
Economiza letras (limitado a 26).
Fácil de adicionar.
Não necessita de reiniciar o SQL.
Contras:
• Parece uma pasta normal.
• É preciso ter uma abordagem
diferente na monitoria.
No SQL Server 2014 temos ainda uma solução melhor:
• Clustered Shared Volumes (CSV)
35. Config. o SO – Storage
Alinhamento da partição
• Podemos perder até 30% em performance se não
definirmos o offset da partição de forma adequada.
•
Uma partição desalinhada pode ocasionalmente causar duas
operações de I/O ao invés de uma.
36. Config. o SO – Storage
Alinhamento da partição
• Podemos perder até 30% em performance se não
definirmos o offset da partição de forma adequada.
•
Uma partição desalinhada pode ocasionalmente causar duas
operações de I/O ao invés de uma.
• Definir o offset correctamente…
•
•
Aumenta a taxa de débito (bytes/s)
Reduz as queues do disco.
37. Config. o SO – Storage
Se não for explícitamente indicada ao formatar a partição, o
offset padrão (31,5 Kb) irá resultar em partições
desalinhadas. Isso acontece em versões do Windows até
2003 (inclusivé).
38. Config. o SO – Storage
Atenção!!
Alguns fabricantes intercetam o que o Windows tenta
fazer e estão ainda criando partições com o offset
errado em qualquer versão do Windows!
39. Config. o SO – Storage
Atenção!!
Alguns fabricantes intercetam o que o Windows tenta
fazer e estão ainda criando partições com o offset
errado em qualquer versão do Windows!
Verifique SEMPRE!
40. Config. o SO – Storage
Este
offset
é
associado
a
hidden
sectors,
que basicamente guardam informações sobre a partição.
Considerando que:
- Cada setor de um disco tem 512 bytes.
- O Windows 2003 tem 63 hidden sectors.
512 * 63 = 31,5 Kb
41. Config. o SO – Storage
Exemplo:
Valores ótimos
Stripe Unit Size:
Block Size:
64Kb*
64Kb
Hidden Sectors
Dados (Block Size)
Stripe Size
* Defined by storage team.
42. Config. o SO – Storage
Solução ideal:
Hidden Sectors
Stripe Size
Dados (Block Size)
43. Config. o SO – Storage
Boa prática
-
Definir um offset de 1024 Kb.
-
-
Este valor funciona com a maioria dos discos.
Block Size = Stripe Unit Size.
As regras:
Offset / Strip Unit Size
Strip Unit Size / Block Size
= Nº Inteiro
= Nº Inteiro
48. Instância - TempDB
• É comum encontrar informações do tipo:
“A TempDB deve sempre ter
um ficheiro por cada CPU lógico.”
49. Instância - TempDB
• É comum encontrar informações do tipo:
“A TempDB deve sempre ter
um ficheiro por cada CPU lógico.”
DEPENDE….
50. Instância - TempDB
• Porque ter cuidado com o número de ficheiros?
•
Operações como sorts ou guardar grandes tabelas temporárias podem ficar lentas.
51. Instância - TempDB
• Porque ter cuidado com o número de ficheiros?
•
Operações como sorts ou guardar grandes tabelas temporárias podem ficar lentas.
• A operação de round-robin passa a ser um constrangimento.
•
Quanto mais ficheiros, mais custoso.
52. Instância - TempDB
Os seguintes wait types são comuns na TempDB:
• PAGELATCH_*: Contenção relacionada com In-memory allocation bitmaps.
• PAGEIOLATCH_*: Contenção relacionada com o I/O subsystem.
54. Instância - TempDB
Quantos ficheiros devermos ter para a TempDB?
Uma boa abordagem seria…
• Servidor com até 8 cores:
Número de ficheiros = Número de Cores.
55. Instância - TempDB
Quantos ficheiros devermos ter para a TempDB?
Uma boa abordagem seria…
• Servidor com até 8 cores:
Número de ficheiros = Número de Cores.
• Servidor com mais do que 8 cores:
1. Adicionar 8 ficheiros.
2. Monitorizar o wait type PAGELATCH_*.
3. Adicionar mais 4 de uma vez, se necessário.
4. Retornar ao ponto 2 …
56. Instância - TempDB
Outras boas práticas para a TempDB:
• Isolar a TempDB em disco dedicado.
•
Dependendo da carga, pode ser boa idéia separar os ficheiros de
dados e o de log.
57. Instância - TempDB
Outras boas práticas para a TempDB:
• Isolar a TempDB em disco dedicado.
•
Dependendo da carga, pode ser boa idéia separar os ficheiros de
dados e o de log.
• Usar um disco rápido.
•
Já é possível a utilização de um disco local em clusters.
58. Instância - TempDB
Outras boas práticas para a TempDB:
• Isolar a TempDB em disco dedicado.
•
Dependendo da carga, pode ser boa idéia separar os ficheiros de
dados e o de log.
• Usar um disco rápido.
•
Já é possível a utilização de um disco local em clusters.
• Defina um valor inicial idêntico para todos os
ficheiros.
•
Atenção aos valores definidos no auto-growth.
59. Instância - TempDB
Outras boas práticas para a TempDB:
• Isolar a TempDB em disco dedicado.
•
Dependendo da carga, pode ser boa idéia separar os ficheiros de
dados e o de log.
• Usar um disco rápido.
•
Já é possível a utilização de um disco local em clusters.
• Defina um valor inicial idêntico para todos os
ficheiros.
•
Atenção aos valores definidos no auto-growth.
Analize os
prós e contras.
• Se existe uma operação pesada usando a
constantemente a TempDB, considere criar uma
tabela de staging dentro da própria BD.
61. Base de Dados – Ficheiros
Ficheiros
• Gerir os ficheiros de forma proactiva.
• Definir um tamanho inicial adequado.
• Definir uma taxa de crescimento adequada.
• Antecipar as operações de crescimento.
• Fazer isso em momento adequado e sem ultrapassar os
limites.
• Deixar o “Auto-growth” como salvaguarda.
• Monitorizar:
• Espaço em disco.
• Espaço utilizado Vs. Espaço alocado.
62
62. Base de Dados – Transaction Log
Tenha certeza de que você está gerindo o t-log adequadamente.
63. Base de Dados – Transaction Log
• Não há vantagem em ter vários ficheiros de log.
• Na perspetiva de performance.
• Full recovery pede backup de log.
• Controle o crescimento do ficheiro, ou então isso
poderá causar a fragmentação dos VLF.
• Problemas de performance (Inserts, Deletes e Updates lentos).
• Backups lentos.
• Recovery mais longo.
• Não defina o auto growth para ficheiros de log para
multiplos de 4Gb em versões antigas do SQL Server.
• Versões até 2008 SP1.
•
http://connect.microsoft.com/SQLServer/feedback/details/481594/log-growth-notworking-properly-with-specific-growth-sizes-vlfs-also-not-created-appropriately
64. Base de Dados – Disaster Recovery
Pense em um plano de disaster recovery!
65. Base de Dados – Disaster Recovery
Pense em um plano de disaster recovery!
O SQL Server tem opções “free”:
• Log Shipping (HA and DR)
• Database Mirroring (HA and DR)
•
Mirror aceita DB Snapshot.
• Replication (HA, DR and LB)
• AlwaysOn (HA, DR and LB)
• … ou em alternativa utilizar opções de replicação de
storage.
67. Manutenção
• Temos que ter resposta aos seguintes pontos:
•
•
•
•
Quais são os SLAs?
A perda de dados e aceitável?
E o tempo máximo de recuperação?
Qual a nossa janela de manutenção?
68. Manutenção
• Temos que ter resposta aos seguintes pontos:
•
•
•
•
Quais são os SLAs?
A perda de dados e aceitável?
E o tempo máximo de recuperação?
Qual a nossa janela de manutenção?
• Assim conseguiremos planear:
•
•
•
•
Actualização das STATISTCS.
Manutenção de INDEXES.
Verificação de INTEGRIDADE.
Efectuar BACKUPS.
69. Manutenção – Integrity Check
Integrity Check
• CHECKDB demora e utiliza muitos recursos.
• Execute o DBCC CHECKDB utilizando a opção WITH
PHYSICAL_ONLY.
• Limita a verificação de integridade a estrutura física das páginas e
header dos registos, além da consistência no alocamento da base de
dados.
• Rápido, mas incompleto. Um CHECKDB completo é necessário
periodicamente.
• Podemos dividir esta tárefa em vários dias, utilizando
“fragmentos do CHECKDB”:
• DBCC CHECKALLOC
• DBCC CHECKCATALOG
• DBCC CHECKTABLE
70. Manutenção - Backups
Backups
• O particionamento pode ajudar na manutenção.
• Tire vantagem em backups e restores.
•
Uma arquitetura em FG permite “piecemeal restores” com baixo TTR
• Piecemeal restore online:
• Após o restore do PRIMARY FG a BD fica online.
• O resto vai ficando disponível conforme os FG são
restaurados.
• Desenhe a base de dados correctamente.
•
•
Mantenha apenas o necessário no FG PRIMARY.
• Tabelas de configuração, dados indispensáveis, etc…
Pense na consistência: mantenha tabelas relacionadas no mesmo FG.
71. Manutenção - Backups
• Backup compression pode ser uma boa opção.
•
•
Menos tempo para fazer backups/restores (~40%).
Bom rácio de compressão.
•
•
•
•
SELECT backup_size/compressed_backup_size FROM msdb..backupset;
Mais CPU é utilizado nos backups/restores (~20%).
Um backupset não pode conter backups comprimidos e não
comprimidos.
Não há vantagem quando temos TDE activo.
72. Manutenção – Mais sobre Backups
• O MULTISTREAM BACKUP é mais uma opção para acelerar
os backups:
File 1
DB
E:
File 2
F:
File 3
G:
73. Manutenção – Mais sobre Backups
• Podemos utilizar o MIRROR para obtermos redundância nos
backups.
File 1
File 1
File 2
File 3
DB
E:
File 2
F:
File 3
G:
74. Manutenção – Índices
Índices
• Tente efetuar rebuild/defrag em índices realmente
fragmentados.
• Se for feito o defrag, não esquecer de executar o update stats.
Evite trabalho
desnecessário nas
janelas de manutenção.
• Tenha cuidado ao fazer manutenção de índices grandes,
se usar Log Shipping, DB Mirroring ou AlwaysOn.
• Contribuem para um grande crescimento do log.
• Os rebuilds de índices são sempre fully-logged quando temos DBM
configurado.
75. Manutenção
Uma boa opção para manutenção
• Os famosos scripts da Ola Hallengren.
• http://ola.hallengren.com
• Efectua de forma inteligente:
• Backups.
• Manutenção de índices e estatísticas.
• Integrity Checks para VLDBs.
• Muito utilizado e testado.
Track = Group of Sectors and CLustersCluster = File allocation Unit – Um Cluster tem N Sectors – Para um allocation unit de 64K -> 512 b (sector size) * 128 = 64K!!Sector = Smallest accessible unit in a physical disk (usually 512 bytes)Stripe Unit Size = Define o tamanhoqueos dados serãodistribuidos entre os discos de um grupo RAID-0, RAID-5, RAID-10
Track = Group of Sectors and CLustersCluster = File allocation Unit – Um Cluster tem N Sectors – Para um allocation unit de 64K -> 512 b (sector size) * 128 = 64K!!Sector = Smallest accessible unit in a physical disk (usually 512 bytes)Stripe Unit Size = Define o tamanhoqueos dados serãodistribuidos entre os discos de um grupo RAID-0, RAID-5, RAID-10
Track = Group of Sectors and CLustersCluster = File allocation Unit – Um Cluster tem N Sectors – Para um allocation unit de 64K -> 512 b (sector size) * 128 = 64K!!Sector = Smallest accessible unit in a physical disk (usually 512 bytes)Stripe Unit Size = Define o tamanhoqueos dados serãodistribuidos entre os discos de um grupo RAID-0, RAID-5, RAID-10
Track = Group of Sectors and CLustersCluster = File allocation Unit – Um Cluster tem N Sectors – Para um allocation unit de 64K -> 512 b (sector size) * 128 = 64K!!Sector = Smallest accessible unit in a physical disk (usually 512 bytes)Stripe Unit Size = Define o tamanhoqueos dados serãodistribuidos entre os discos de um grupo RAID-0, RAID-5, RAID-10
Track = Group of Sectors and CLustersCluster = File allocation Unit – Um Cluster tem N Sectors – Para um allocation unit de 64K -> 512 b (sector size) * 128 = 64K!!Sector = Smallest accessible unit in a physical disk (usually 512 bytes)Stripe Unit Size = Define o tamanhoqueos dados serãodistribuidos entre os discos de um grupo RAID-0, RAID-5, RAID-10
Track = Group of Sectors and CLustersCluster = File allocation Unit – Um Cluster tem N Sectors – Para um allocation unit de 64K -> 512 b (sector size) * 128 = 64K!!Sector = Smallest accessible unit in a physical disk (usually 512 bytes)Stripe Unit Size = Define o tamanhoqueos dados serãodistribuidos entre os discos de um grupo RAID-0, RAID-5, RAID-10
Track = Group of Sectors and CLustersCluster = File allocation Unit – Um Cluster tem N Sectors – Para um allocation unit de 64K -> 512 b (sector size) * 128 = 64K!!Sector = Smallest accessible unit in a physical disk (usually 512 bytes)Stripe Unit Size = Define o tamanhoqueos dados serãodistribuidos entre os discos de um grupo RAID-0, RAID-5, RAID-10DEMO
VLF:Até 64 Mb – 4 VLF (1 VLF = 16 Mb)Entre 64 Mb e 1 Gb – 8 VLF (1 VLF = entre ~8 Mb e 128 Mb)+ 1 Gb – 16 VLF (1 VLF = apartir de~64 Mb)VLF pequenoscausamfragmentação / VLFs grandesdemaiscausamlentidãoao se limpar um VLF (1 VLF the 4GB porexemplo, demoramuitomais tempo paraserlimpo do que um de 512 Mb)DBCC LOGINFO – Retornaumalinhaporcada VLF presente no log file.