24hop session - database administration strategies

Database

Administration

StrategiesMurilo Miranda, Database Administrator – The Pythian Group

Murilo MirandaDatabase Administrator @ The Pythian Group

http://pt.linkedin.com/in/murilomiranda/

@murilocmiranda

[email protected]

Agenda

4

Agenda

• Desafios de um DBA.

• Configurando o SO.• Instant File Initialization.

• Anti-Virus.

• Rede.

• Storage.

• Configurando a Instância.• TempDB.

• Configurando a base de dados.• Gestão de ficheiros.

• Transaction Log.

• Disaster Recovery (Overview).

• Manutenção.• Verificação de integridade.

• Backups.

• Índices.

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

7

Desafios de um DBA

• Quando um DBA está de prevenção, o barulho do pager

é…

7

8

Desafios de um DBA

• Quando um DBA está de prevenção, o barulho do pager

é…

IRRITANTE

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

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

11

Backups

Índices

Estatísticas

Disaster Recovery

Performance

As vezes é um desafio definir…

Desafios de um DBA

Manutenção

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

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

Configurando o SO

A activação do IFI pode aumentar a velocidade de criação e expansão de ficheiros de dados.

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.


O mesmo não é válido para ficheiros de log!

Config. o SO – Anti-Virus

Não é incomum encontrar Anti-Virus

em servidores com SQL Server…

… mas, por vezes, o AV age tal e qual um

VIRUS!

Anti-Virus

• O licenciamento custa €€.

• A manutenção custa tempo.

• Pode causar problemas.

• Não protege de zero-day exploits.

Porque não utilizar AV junto com o SQL Server?


• Mais uma aplicação concorrendo por

recursos.

• Os ficheiros do SQL Server podem ser

sujeitos a varrimento e mesmo ficar

bloqueados.

Qual é o grande problema para o SQL Server?


• Manter os servidores atualizados.

• Configurar a firewall corretamente.

• Restringir o acesso ao servidor.

• Podemos instalar o AV… em workstations apenas!

Qual seria nossa opção?


Mas eu gosto de AV! O que posso fazer para

manter o SQL Server e o AV juntos?


Configure Exceções!

Mas eu gosto de AV! O que posso fazer para

manter o SQL Server e o AV juntos?


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


Config. o SO - Network

• 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.

Rede


Então, qual a melhor abordagem?


Então, qual a melhor abordagem?

Dividir !


Backups Network

Front-End Network

Back-End Network

• Planeie uma arquitetura eficiente para o storage.

• Normalmente, quanto mais segregado melhor.

Config. o SO – Storage

Storage

Sugestão:

SQL BIN SQL DATA SQL IDX SQL LOGS SQL TMP


Storage

• Planeie uma arquitetura eficiente para o storage.

• Normalmente, quanto mais segregado melhor.

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.



Prós:


Contras:

• Parece uma pasta normal.• É preciso ter uma abordagem

diferente na monitoria.



Prós:


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)

• Podemos perder até 30% em performance se nãodefinirmos 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.

Alinhamento da partição


• Podemos perder até 30% em performance se nãodefinirmos 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.

Alinhamento da partição


Se não for explícitamente indicada ao formatar a partição, ooffset padrão (31,5 Kb) irá resultar em partiçõesdesalinhadas. Isso acontece em versões do Windows até2003 (inclusivé).


Alguns fabricantes intercetam o que o Windows tentafazer e estão ainda criando partições com o offseterrado em qualquer versão do Windows!


Atenção!!

Alguns fabricantes intercetam o que o Windows tentafazer e estão ainda criando partições com o offseterrado em qualquer versão do Windows!

Verifique SEMPRE!


Atenção!!

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


Exemplo:

Stripe Unit Size: 64Kb*Block Size: 64Kb

* Defined by storage team.

Valores ótimos

Stripe Size

Dados (Block Size)


Hidden Sectors

Solução ideal:

Stripe Size

Dados (Block Size)


Hidden Sectors

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 = Nº InteiroStrip Unit Size / Block Size = Nº Inteiro


Configurando a Instância

Dois comportamentos comuns:• Ignorar.• Sobrevalorizar.

Instância - TempDB

TempDB

Instância - TempDB

“A TempDb é a casa de banhopública do SQL Server”

Então temos que tratar bem dela!

Instância - TempDB

“A TempDB deve sempre terum ficheiro por cada CPU lógico.”

Instância - TempDB

• É comum encontrar informações do tipo:

“A TempDB deve sempre terum ficheiro por cada CPU lógico.”

Instância - TempDB

• É comum encontrar informações do tipo:

DEPENDE….

• Porque ter cuidado com o número de ficheiros?• Operações como sorts ou guardar grandes tabelas temporárias podem ficar lentas.

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.

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.

Instância - TempDB

Quantos ficheiros devermos ter para a TempDB?

Instância - TempDB


Uma boa abordagem seria…• Servidor com até 8 cores:

Número de ficheiros = Número de Cores.

Instância - 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 …

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.

Instância - TempDB



dados e o de log.

• Usar um disco rápido.• Já é possível a utilização de um disco local em clusters.

Instância - TempDB



dados e o de log.


• Defina um valor inicial idêntico para todos osficheiros.• Atenção aos valores definidos no auto-growth.

Instância - TempDB



dados e o de log.


• Defina um valor inicial idêntico para todos osficheiros.• Atenção aos valores definidos no auto-growth.

• Se existe uma operação pesada usando a constantemente a TempDB, considere criar umatabela de staging dentro da própria BD.

Analize osprós e contras.

Instância - TempDB

Configurando a

Base de Dados

62

Base de Dados – 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.

Ficheiros

Tenha certeza de que você está gerindo o t-log adequadamente.

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 issopoderá 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 paramultiplos de 4Gb em versões antigas do SQL Server.

• Versões até 2008 SP1.• http://connect.microsoft.com/SQLServer/feedback/details/481594/log-growth-not-

working-properly-with-specific-growth-sizes-vlfs-also-not-created-appropriately

Base de Dados – Transaction Log

Pense em um plano de disaster recovery!

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.

Base de Dados – Disaster Recovery

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?

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.

Manutenção

• 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árioperiodicamente.

• Podemos dividir esta tárefa em vários dias, utilizando“fragmentos do CHECKDB”:

• DBCC CHECKALLOC• DBCC CHECKCATALOG• DBCC CHECKTABLE

Manutenção – Integrity Check

Integrity Check

• 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.

Manutenção - Backups

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.

Manutenção - Backups

• O MULTISTREAM BACKUP é mais uma opção para aceleraros backups:

DB

File 1

File 2

File 3

E:

G:

F:

Manutenção – Mais sobre Backups

• Podemos utilizar o MIRROR para obtermos redundância nosbackups.

DB

File 1

File 2

File 3

E:

G:

F:

File 1

File 2

File 3

Manutenção – Mais sobre Backups

• Tente efetuar rebuild/defrag em índices realmentefragmentados.

• Se for feito o defrag, não esquecer de executar o update stats.

• 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.

Manutenção – Índices

Evite trabalhodesnecessário nas

janelas de manutenção.

Índices

• 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.

Manutenção

Uma boa opção para manutenção

http://ola.hallengren.com

http://ola.hallengren.com

Perguntas?

Obrigado pela presença!

24hop session - database administration strategies

Technology