24HOP Session - Database Administration Strategies

307 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
307
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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.
  • 24HOP Session - Database Administration Strategies

    1. 1. Database Administration Strategies Murilo Miranda, Database Administrator – The Pythian Group
    2. 2. Murilo Miranda Database Administrator @ The Pythian Group http://pt.linkedin.com/in/murilomiranda/ @murilocmiranda murilo.miranda@gmail.com
    3. 3. Agenda
    4. 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. 5. Desafios de um DBA
    6. 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. 7. Desafios de um DBA • Quando um DBA está de prevenção, o barulho do pager é… 7 7
    8. 8. Desafios de um DBA • Quando um DBA está de prevenção, o barulho do pager é… IRRITANTE 8 8
    9. 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. 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. 11. Desafios de um DBA As vezes é um desafio definir… Backups Performance Índices Manutenção Estatísticas Disaster Recovery 11
    12. 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. 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. 14. Configurando o SO
    15. 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. 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. 17. Config. o SO – Inst. File Initialization
    18. 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. 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. 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. 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. 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. 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. 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. 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. 26. Config. o SO - Network Então, qual a melhor abordagem?
    27. 27. Config. o SO - Network Então, qual a melhor abordagem? Dividir !
    28. 28. Config. o SO - Network Backups Network Front-End Network Back-End Network
    29. 29. Config. o SO – Storage Storage • Planeie uma arquitetura eficiente para o storage. • Normalmente, quanto mais segregado melhor.
    30. 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. 31. Config. o SO – Storage Mountpoints podem ser uma boa estratégia.
    32. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 42. Config. o SO – Storage Solução ideal: Hidden Sectors Stripe Size Dados (Block Size)
    43. 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. 44. Configurando a Instância
    45. 45. Instância - TempDB TempDB Dois comportamentos comuns: • Ignorar. • Sobrevalorizar.
    46. 46. Instância - TempDB “A TempDb é a casa de banho pública do SQL Server”
    47. 47. Instância - TempDB Então temos que tratar bem dela!
    48. 48. Instância - TempDB • É comum encontrar informações do tipo: “A TempDB deve sempre ter um ficheiro por cada CPU lógico.”
    49. 49. Instância - TempDB • É comum encontrar informações do tipo: “A TempDB deve sempre ter um ficheiro por cada CPU lógico.” DEPENDE….
    50. 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. 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. 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. 53. Instância - TempDB Quantos ficheiros devermos ter para a TempDB?
    54. 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. 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. 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. 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. 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. 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. 60. Configurando a Base de Dados
    61. 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. 62. Base de Dados – Transaction Log Tenha certeza de que você está gerindo o t-log adequadamente.
    63. 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. 64. Base de Dados – Disaster Recovery Pense em um plano de disaster recovery!
    65. 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. 66. Manutenção
    67. 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. 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. 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. 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. 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. 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. 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. 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. 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. 76. Perguntas?
    77. 77. Obrigado pela presença!

    ×