Here is my presentation of 24HOP on November, 2013.

1. Database
Administration
Strategies
Murilo Miranda, Database Administrator – The Pythian Group

2. Murilo Miranda
Database Administrator @ The Pythian Group
http://pt.linkedin.com/in/murilomiranda/
@murilocmiranda
murilo.miranda@gmail.com

3. Agenda

4. Agenda
•
•
Desafios de um DBA.
Configurando o SO.
•
•
•
•
•
Configurando a Instância.
•
•
TempDB.
Configurando a base de dados.
•
•
•
•
Instant File Initialization.
Anti-Virus.
Rede.
Storage.
Gestão de ficheiros.
Transaction Log.
Disaster Recovery (Overview).
Manutenção.
•
•
•
Verificação de integridade.
Backups.
Índices.
4

5. Desafios de um DBA

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

14. Configurando o SO

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!

17. Config. o SO – Inst. File Initialization

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

44. Configurando a Instância

45. Instância - TempDB
TempDB
Dois comportamentos comuns:
• Ignorar.
• Sobrevalorizar.

46. Instância - TempDB
“A TempDb é a casa de banho
pública do SQL Server”

47. Instância - TempDB
Então temos que tratar bem dela!

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.

53. Instância - TempDB
Quantos ficheiros devermos ter para a TempDB?

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.

60. Configurando a
Base de Dados

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.

66. Manutenção

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.

76. Perguntas?

77. Obrigado pela presença!