Obs: Estas recomendações são apenas um direcionamento básico para uma boa operação do servidor de banco de dados e não deve ser considerado como único padrão de avaliação, monitoração, e configuração do banco de dados que deve ser realizado por o DBA responsável.
1 - COLLATION
Nota: Os Logins RM e SYSDBA deveram ser criados, conforme script de Acerta Usuários: BD0016_SQL_Server_Acerta_Usuário
2. SERVER AUTHENTICATION
Verifique a autenticação que está sendo realizada para conexão do SQL.
Para isso, basta clicar com o botão direito no nome do servidor (Management Studio) e clicar em propriedades.
Na guia Security, na opção Server authentication, marque a opção SQL Server and Windows Authentication mode. A base de dados RM utiliza o usuário do banco de dados para realizar a autenticação do sistema, por este motivo, precisamos da autenticação do SQL para acessar o sistema. Verifique se o serviço vai reiniciar após confirmar esta opção.
3. PARÂMETROS
Partindo do pressuposto que a base vazia foi criada com o nome de Base_RM e o script de usuários também já foi executado na mesma, vamos conferir alguns parâmetros do banco:
Selecione o menu propriedades da base RM (Nesse menu estarão disponíveis todas as informações gerais da base de dados):
Sugerimos que seja parametrizado para o crescimento automático (Enable Autogrowth) e no File Growth utilizar o In Percent (10), já no Maximum File Size devemos ter muito critério ao marcar a opção de Unrestrict File Growth, apesar de recomendarmos, pois enquanto tiver espaço em disco e o banco necessitar ele irá expandir sem problemas, porém se o espaço estourar poderá danificar o banco de dados:
Verificando os demais parâmetros:
4. MANUTENÇÃO:
Exemplos de como executar a procedure Index_defrag2:
/** Executando com parâmetros defaults **/
execute RMIndexDefrag
/** Executando com opção de recalculo do Fill Factor **/
execute RMIndexDefrag @recalcfillfactor = 1
/** Executando sem output **/
execute RMIndexDefrag @debugmode = 0
Exemplo de como executar a procedure RMatualizaestatisticas:
Exec RMatualizaestatisticas
Recomendamos que o DBA avalie a periodicidade para execução destas procedures, caso não possua DBA, execute as mesmas na seguinte periodicidade:
5. RECOVERY MODEL:
O log do SQL Server poderá crescer mais ou menos a depender do recovery model escolhido.
O recovery model simple, irá logar as transações realizadas, porém ao escolher este nível de recuperação o SQL Server entende que sua tolerância para perda de dados não envolve recuperação point in time ou backups full e diferencial são suficientes. Desta forma, ao atingir um certo volume o SQL Server automaticamente realiza um checkpoint em background e confirma as transações pendentes no log para o arquivo de dados. Caso seu recovery esteja como simple e seu log esteja crescendo rapidamente e não retornando a um tamanho gerenciável existem algumas ações a serem realizadas:
Caso ainda assim, tenha dificuldade em reduzir o log, pode existir alguma configuração na instância relacionada a replicações realizadas no passado ou alguma outra configuração voltada a este cenário impactando o processo de checkpoint.
Caso esteja utilizando o recovery full, o responsável mais comum por realizar o processo de checkpoint sem a intervenção do DBA é o processo de backup do log de transação. Ao se realizar o backup, o processo de checkpoint é realizado de forma automática no momento deste backup, mantendo os arquivos de log em produção em tamanhos gerenciáveis. Para isso, é necessário escolher a periodicidade do backup de log conforme o seu negócio.
Caso o seu recovery model seja full e o processo de backup de log não esteja sendo realizado, este pode ser o problema relacionado ao crescimento dos arquivos.
Caso não seja o DBA da empresa, sugiro que alinhe estas informações com o mesmo para tomada de decisão.
6. IMPORTÂNCIA DA VERIFICAÇÃO DA INTEGRIDADE DA BASE DE DADOS
Seguem algumas dicas para evitar esse tipo de problema:
1. Faça a verificação diária da integridade da base antes de realizar os backups. Pode ser criado um plano de manutenção ou pode um job que executa o comando dbcc checkdb nas bases de dados;
2. O Recovery Model Full é requisitado em casos extremos, como o restore de páginas corrompidas, porém poderá acarretar em um alto consumo do disco;
O log do SQL Server poderá crescer mais ou menos a depender do recovery model escolhido. O recovery model simple, irá logar as transações realizadas, porém ao escolher este nível de recuperação o SQL Server entende que sua tolerância para perda de dados não envolve recuperação point in time ou backups full e diferencial são suficientes. Desta forma, ao atingir um certo volume o SQL Server automaticamente realiza um checkpoint em background e confirma as transações pendentes no log para o arquivo de dados. Caso seu recovery esteja como simple e seu log esteja crescendo rapidamente e não retornando a um tamanho gerenciável existem algumas ações a serem realizadas:
Caso ainda assim, tenha dificuldade em reduzir o log, pode existir alguma configuração na instância relacionada a replicações realizadas no passado ou alguma outra configuração voltada a este cenário impactando o processo de checkpoint. Caso esteja utilizando o recovery full, o responsável mais comum por realizar o processo de checkpoint sem a intervenção do DBA é o processo de backup do log de transação. Ao se realizar o backup, o processo de checkpoint é realizado de forma automática no momento deste backup, mantendo os arquivos de log em produção em tamanhos gerenciáveis. Para isso, é necessário escolher a periodicidade do backup de log conforme o seu negócio. Caso o seu recovery model seja full e o processo de backup de log não esteja sendo realizado, este pode ser o problema relacionado ao crescimento dos arquivos. Caso não seja o DBA da empresa, sugiro que alinhe estas informações com o mesmo para tomada de decisão. |
3.Verifique a integridade física dos dispositivos de armazenamento. Utilize softwares como o ScanDisk do Windows para avaliar possíveis problemas como bad sectors;
4. Realize verificações periódicas nas baterias dos no-breaks;
5. Faça testes de restauração dos backups para prevenir qualquer tipo de eventualidade. Exemplo: falhas de integridade, problemas na compactação, defeitos na mídia etc.
Sendo assim, a verificação da integridade da base de dados é tão importante quanto à realização do próprio backup. Não deixe de inserir essa verificação nas suas rotinas de manutenção.
Links Complementares: