Vou descrever abaixo algumas boas práticas que podemos atuar dentro de uma administração em banco de dados.
- Manutenção de banco de dados inclui um conjunto de tarefas pró-ativas que precisam ser realizadas periodicamente para garantir um desempenho ótimo das bases de dados e manter a alta disponibilidade.
- Banco de dados e arquivos de log devem ser manualmente pré-dimensionados para o tamanho final quando eles são criados. Só use aumento automático(autogrowth) para cobrir eventos inesperados, e não para gerir o crescimento do arquivo.
- Como ocorre com bancos de dados de produção, o tempdb deve ser pré-dimensionadas para o seu tamanho normal, de modo que quando SQL Server é reiniciado, o tempdb é instantaneamente dimensionados corretamente.
- Não ative a opção de banco de dados "Auto Shrink", nem criar automaticamente um JOB para diminuir qualquer do banco de dados ou arquivos de log.
- O banco de dados msdb pode crescer ao longo do tempo, e os dados mais antigos precisam ser excluídos usando ao SP's: sp_delete_backuphistory, sp_purge_jobhistory, e sp_maintplan_delete_log.
- Reconstruir (REBUILD) ou reorganizar (REORGANIZE) índices para eliminar a fragmentação. Só desfragmentar índices que forem necessários. Índices e estatísticas devem ser mantidos. Se você usar REBUILD para desfragmentar índices, esta estatística é automaticamente atualizado. Se você usar REORGANIZE para desfragmentar índices, as estatísticas devem ser atualizados separadamente.
- Todos os bancos devem ter a opção CHECKSUM ligado.
- Executar o comando DBCC CHECKDB para controle de possiveis inconsistências na base de dados.
- Realize backups completos diários do banco de dados e logs de transações por hora (ou conforme necessário para atender metas de alta disponibilidade).
- Ao agendar um JOB de manutenção no banco de dados, programa-los para que eles não se sobrepõem, e que eles sejam executados durante o tempo de menor trafego no banco.
- Confira todos os processos, como: cluster, replicação, o service broker, log shipping, espelhamento de banco de dados, para verificar se estão funcionando corretamente.
- Monitorar o espaço em disco para garantir que seus servidores SQL não vão ficar sem espaço em disco. Para melhor desempenho, todos os discos devem ter 15% ou mais de espaço livre.
- Durante o dia, monitorar periodicamente o desempenho do SQL Server usando o Monitor de desempenho, Profiler / SQL Trace, ou monitoramento do desempenho de outros ferramentas.
- Manter um registro de todas as alterações feitas nos servidores, incluindo a documentação de qualquer espécie e se necessário identificar e corrigir.
- Regularmente restaurar backups para um servidor de teste, a fim de verificar se é possível restaurá-los. Você não precisa de restaurar todos os backups de todos os dias, mas fazê-lo muitas vezes para garantir que você está confiante de que boas cópias de segurança estejam disponivéis.
- Tire algum tempo para aprender algo novo como um DBA para promover seu desenvolvimento profissional.
- Criar uma "receita" de como reconstruir cada instância em caso de uma reinstalação.
Essas são somente algumas dicas do que atuar durante o nosso dia a dia. Poderia ficar citando muitos mais itens, mas acredito que esses são os principais.
Bom trabalho!!!
Até mais,
Marco Pinheiro.
quinta-feira, 30 de setembro de 2010
quarta-feira, 8 de setembro de 2010
Comandos RESTORE II
Continuando ainda com os comandos RESTORE, não podia deixar de comentar sobre o comando para voltar um backup, ou RESTORE DATABASE.
No SQL Server, o processo para voltar um backup é muito tranquilo. Temos uma ferramenta gráfica bem intuitiva que é o Management Studio (SQL 2005 e 2008).
Contudo, podemos ter um questionamento do outro post: "Qual o tamanho exato dos arquivos de dados e de log?" Porque deste questionamento....
Hoje nem tanto, devido ao baixo custo de espaço em HD's que não é tão pesado. Mas num passado não muito distante fazer um upgrade em estações e/ou servidores era (e ainda é um pouco....) uma barreira em várias corporações. Falou em custo a empresa não quer nem ouvir!!!! kkkkkkk....
Mas o intuito deste post é tentar suprir um pouco destes problemas de espaço. Vamos a um exemplo prático...
Temos uma empresa que presta suporte a vários clientes que usam bases de dados SQL Server. Um dia um desses clientes entra em contato informando um sério problema em seu sistema. A equipe de suporte não consegue resolver o problema do cliente e solicita sua base de dados para uma analise mais aprofundada da situação tentando simular o mesmo ambiente do cliente.
Entretanto, a base chega com um tamanho de 50GB e ao mandar restaurar pelo Management Studio ocorre o erro de espaço em disco insuficiente.
Acredito que o exemplo acima já deve ter ocorrido com muitaaaaa gente...
A resposta para solucionar esta questão vem com outra pergunta: Tenho alguma outra máquina (digo: Qualquer outra máquina!!!) com este espaço de 50GB disponiveis? Se a resposta é SIM, excelente!!!! Problema resolvido. Basta copiar o arquivo de 50GB para a outra máquina e pronto!!!!!
Mas.....NÃOOOOOOOOOO....Resposta errada!!!! Assim fica muito fácil.....Vamos dificultar um pouco...hehehehe
O que iremos fazer é uma restauração pela rede. Como????? Através do comando RESTORE DATABASE.
Inspirado no nosso exemplo vamos montar a sintaxe do comando:
RESTORE DATABASE BaseCliente FROM DISK = N'\\SERVIDOR1\BASECLIENTE\Backup.bak'
WITH
MOVE N'Oficial_Data' TO N'E:\ClienteX\Oficialdata1.mdf',
MOVE N'Oficial2_Log' TO N'E:\ClienteX\Oficial_log2.ldf',
NOUNLOAD, STATS = 10
Explicando o comando:
1) "RESTORE DATABASE BaseCliente"...Onde 'BaseCliente' é o nome que vou dar para a base de dados que irei restaurar.
2) "FROM DISK = N'\\SERVIDOR1\BASECLIENTE\Backup.bak'"....Onde '\\SERVIDOR1\BASECLIENTE\Backup.bak' é o caminho de rede onde está o arquivo de backup que o cliente enviou.
3) "MOVE N'Oficial_Data' e MOVE N'Oficial2_Log'"....Onde 'Oficial_Data' e
'Oficial2_Log' são os nomes lógicos que vieram na base. Para saber estes nomes use o comando RESTORE FILELISTONLY do último post.
4) "'E:\ClienteX\Oficialdata1.mdf' e 'E:\ClienteX\Oficial_log2.ldf'"....onde esta descrição é o caminho que irá salvar os arquivos de dados e de log. Caso você queira, este caminho também poderá ser salvo em uma outra máquina, basta informar o caminho de rede desejado.
Lembrando que onde envolver um caminho de rede, é necessário a sua devida permissão de compartilhamento.
Então com o comando acima podemos restaurar uma base na rede enviando os arquivos de dados e de log para qualquer máquina da rede. Assim ganhamos um leque de facilidades dentro dos processos do nosso ambiente corporativo.
Então é isso. Conseguimos restaurar um backup utilizando várias máquinas. Pode ter uma que é apenas o servidor de arquivos, outra o servidor de banco e outra como uma simples estação de trabalho.
Para maiores detalhes do comando RESTORE DATABASE vide o books online do SQL.
Até mais pessoal,
Abraço.
Marco.
No SQL Server, o processo para voltar um backup é muito tranquilo. Temos uma ferramenta gráfica bem intuitiva que é o Management Studio (SQL 2005 e 2008).
Contudo, podemos ter um questionamento do outro post: "Qual o tamanho exato dos arquivos de dados e de log?" Porque deste questionamento....
Hoje nem tanto, devido ao baixo custo de espaço em HD's que não é tão pesado. Mas num passado não muito distante fazer um upgrade em estações e/ou servidores era (e ainda é um pouco....) uma barreira em várias corporações. Falou em custo a empresa não quer nem ouvir!!!! kkkkkkk....
Mas o intuito deste post é tentar suprir um pouco destes problemas de espaço. Vamos a um exemplo prático...
Temos uma empresa que presta suporte a vários clientes que usam bases de dados SQL Server. Um dia um desses clientes entra em contato informando um sério problema em seu sistema. A equipe de suporte não consegue resolver o problema do cliente e solicita sua base de dados para uma analise mais aprofundada da situação tentando simular o mesmo ambiente do cliente.
Entretanto, a base chega com um tamanho de 50GB e ao mandar restaurar pelo Management Studio ocorre o erro de espaço em disco insuficiente.
Acredito que o exemplo acima já deve ter ocorrido com muitaaaaa gente...
A resposta para solucionar esta questão vem com outra pergunta: Tenho alguma outra máquina (digo: Qualquer outra máquina!!!) com este espaço de 50GB disponiveis? Se a resposta é SIM, excelente!!!! Problema resolvido. Basta copiar o arquivo de 50GB para a outra máquina e pronto!!!!!
Mas.....NÃOOOOOOOOOO....Resposta errada!!!! Assim fica muito fácil.....Vamos dificultar um pouco...hehehehe
O que iremos fazer é uma restauração pela rede. Como????? Através do comando RESTORE DATABASE.
Inspirado no nosso exemplo vamos montar a sintaxe do comando:
RESTORE DATABASE BaseCliente FROM DISK = N'\\SERVIDOR1\BASECLIENTE\Backup.bak'
WITH
MOVE N'Oficial_Data' TO N'E:\ClienteX\Oficialdata1.mdf',
MOVE N'Oficial2_Log' TO N'E:\ClienteX\Oficial_log2.ldf',
NOUNLOAD, STATS = 10
Explicando o comando:
1) "RESTORE DATABASE BaseCliente"...Onde 'BaseCliente' é o nome que vou dar para a base de dados que irei restaurar.
2) "FROM DISK = N'\\SERVIDOR1\BASECLIENTE\Backup.bak'"....Onde '\\SERVIDOR1\BASECLIENTE\Backup.bak' é o caminho de rede onde está o arquivo de backup que o cliente enviou.
3) "MOVE N'Oficial_Data' e MOVE N'Oficial2_Log'"....Onde 'Oficial_Data' e
'Oficial2_Log' são os nomes lógicos que vieram na base. Para saber estes nomes use o comando RESTORE FILELISTONLY do último post.
4) "'E:\ClienteX\Oficialdata1.mdf' e 'E:\ClienteX\Oficial_log2.ldf'"....onde esta descrição é o caminho que irá salvar os arquivos de dados e de log. Caso você queira, este caminho também poderá ser salvo em uma outra máquina, basta informar o caminho de rede desejado.
Lembrando que onde envolver um caminho de rede, é necessário a sua devida permissão de compartilhamento.
Então com o comando acima podemos restaurar uma base na rede enviando os arquivos de dados e de log para qualquer máquina da rede. Assim ganhamos um leque de facilidades dentro dos processos do nosso ambiente corporativo.
Então é isso. Conseguimos restaurar um backup utilizando várias máquinas. Pode ter uma que é apenas o servidor de arquivos, outra o servidor de banco e outra como uma simples estação de trabalho.
Para maiores detalhes do comando RESTORE DATABASE vide o books online do SQL.
Até mais pessoal,
Abraço.
Marco.
Assinar:
Postagens (Atom)