Perguntas[ola-hallengren](dba)

Eu sou novo no MaintenanceSolution de Ola Hallengren (que parece fantástico) e DBA-ing em geral. Eu criei um trabalho para ser executado dbo.DatabaseIntegrityCheck(semanal em ALL_DATABASES). Se houver erros encontrados DBCC CHECKDB, isso fará com que o proc dê erro e, portanto, o trabalho falhe, então receberei uma notificação da maneira normal da falha do meu trabalho? Ele continuará verificando a integridade de todos os outros bancos de dados ou parará no primeiro banco de dados problemático que encontrar?

Não consegui encontrar nenhuma nota na visão geral , desculpe se perdi algo óbvio.

Quando o @CleanupTimeparâmetro é usado no [dbo].[DatabaseBackup]procedimento, os arquivos de backup antigos de destino são excluídos após cada backup de banco de dados bem-sucedido? Ou todos os backups são processados ​​primeiro e depois a limpeza é realizada?

Estou tendo problemas com espaço livre em disco e tento fornecer ao administrador da rede uma especificação precisa para o tamanho do volume de backup.

Eu li Entendendo o CleanupTime nos scripts do SQL Server de Ola Hallengren em relação aos backups FULL e LOG antes de postar. Não encontrei resposta para minha pergunta lá. Se está lá, eu perdi. Basta lê-lo novamente, mas ainda não vê nada.

Eu tenho um trabalho de manutenção de índice para o banco de dados msdb para reconstruir esses índices fragmentados no banco de dados msdb.

Mas ainda encontrei alguma tabela relacionada ao backup no banco de dados msdb (por exemplo, backupmediafamily, backupset, backupfile) com alta fragmentação.

Depois de uma verificação mais aprofundada, descobri que foi ignorado pelo comando de manutenção Ola Index.

Minha pergunta é como posso fazer ola desfragmentar o índice em vez de escrever outro conjunto de manutenção de índice apenas para msdb?

Estou trabalhando em um projeto que requer uma redução de banco de dados. Após o encolhimento, verifiquei sys.dm_db_index_physical_statse posso ver que muitos dos meus índices estão mais de 99% fragmentados ( avg_fragmentation_in_percent).

Em resposta a isso, IndexOptimizeexecutei por Ola Hallengren, com o seguinte código:

EXECUTE [dbo].[IndexOptimize]
    @Databases = 'Dynamic.Migrate',
    @FragmentationLow = 'INDEX_REORGANIZE',
    @FragmentationMedium = 'INDEX_REBUILD_OFFLINE',
    @FragmentationHigh = 'INDEX_REBUILD_OFFLINE',
    @FillFactor = '80',
    @UpdateStatistics = 'ALL',
    @StatisticsSample = '100',
    @LogToTable = 'Y'

Isso foi concluído com sucesso, mas quando eu verifico sys.dm_db_index_physical_statsnovamente, os avg_fragmentation_in_percentvalores não foram alterados e afirmo que meus índices ainda estão fragmentados em mais de 99%.

Estou faltando alguma coisa aqui?

Estou tentando descobrir qual é a melhor opção CheckCommands para verificação de ServerIntegrity.

1. Devo deixar os padrões de trabalho como estão?

   EXECUTE [dbo].[DatabaseIntegrityCheck] @Databases = 'USER_DATABASES', @LogToTable = 'Y'
   

2. Devo executar a CHECKALLOC,CHECKTABLE,CHECKCATALOGopção separadamente ou está incluída no acima? O mesmo para a CHECKFILEGROUPopção.

Eu tenho um índice que tem o bloqueio de nível de página desabilitado e agora tenho problemas de fragmentação de índice para esse índice.

Eu sabia que não conseguiria Reorganizeindexar, mas acreditei que conseguiria rebuildindexar.

Agora acho que reconstruir também não está funcionando. Estou usando o fator de preenchimento padrão de 100. Meu banco de dados é enorme, então não quero que o tamanho da tabela/db aumente fornecendo um fator de preenchimento de 80% ou menos. Por não funcionar, quero dizer que a Fragmentação Avg permanece a mesma depois de executar o script de Ola na noite anterior.

Um pouco de fundo sobre por que o bloqueio de nível de página está desabilitado.

Eu estava recebendo muitas transações deadlocksneste índice naquela tabela em particular. Esta mesa era uma espécie de mesa de fatos onde insert, update and deleteacontecia a cada momento. E há algum foreign keyrelacionamento com algumas outras tabelas com CASCADE deletes. Então, eu estava recebendo muitos bloqueios/deadlocks e depois de desabilitar o bloqueio de nível de página, consegui me livrar de todos esses deadlocks.

Comecei a usar o script de Ola Hallengren Index maintenancee apliquei o Index Rebuild para todos os índices para os quais o Index Reorganize não está funcionando. Mas notei que o Index Rebuild também não está funcionando.

Agora, vejo um AvgPageFragmentaiton de 95,9413 e uma contagem de páginas de 1196826 para o índice, o que não é bom.

Informação adicional:

Estou usando o script do Ola Hall conforme mostrado abaixo.

 EXECUTE dbo.IndexOptimize
    @Databases = 'DB_NAME',
    @FragmentationLow = NULL,
    @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE',
    @FragmentationHigh = ''INDEX_REORGANIZE,INDEX_REBUILD_ONLINE'',
    @FragmentationLevel1 = 5,
    @FragmentationLevel2 = 30,
    @SortInTempdb = 'Y',
    @MaxDOP = 0,
    @WaitAtLowPriorityMaxDuration = 0,
    @WaitAtLowPriorityAbortAfterWait= 'NONE',
    @Indexes = 'DB_NAME.[dbo].TB1,DB_NAME.[dbo].TB2'

Minha pergunta é como reduzir a fragmentação em um índice se o bloqueio de nível de página estiver desabilitado para esse índice?

Percebi algum comportamento inesperado usando o trabalho de backup do banco de dados na solução de manutenção da Ola. Na instância de teste em que estou trabalhando, tenho o trabalho de backup do banco de dados do usuário agendado para ser executado às 2h todas as manhãs. Eu tenho o parâmetro @CleanupTime definido como 48 e não especifiquei o parâmetro @CleanupMode.

Se estou entendendo corretamente, isso deve ser executado diariamente e manter duas cópias do backup do banco de dados... Como o padrão é "AFTER_BACKUP", ele deve excluir o arquivo mais antigo após a conclusão do novo backup, deixando apenas o arquivo mais antigo se o backup mais recente falha. Portanto, deve começar com dois dias de arquivos na pasta, criar um terceiro arquivo (para o dia atual) e excluir o arquivo mais antigo dos três.

O estranho é que às vezes ele deixa dois dias de arquivos e às vezes deixa três, mesmo que todos os backups estejam sendo concluídos com êxito. Não é um grande problema, mas, para economizar espaço nessa unidade, prefiro manter apenas dois backups a qualquer momento. Quaisquer dicas ou sugestões seriam apreciadas.

Edit: Conforme solicitado nos comentários abaixo, aqui está a lista de parâmetros nessa etapa do trabalho...

EXECUTE [dbo].[DatabaseBackup]
@Databases = 'ALL_DATABASES',
@Directory = NULL,
@BackupType = 'FULL',
@Verify = 'N',
@CleanupTime = 48,
@CheckSum = 'Y',
@LogToTable = 'Y'

Criei um trabalho de manutenção do SQL usando o Azure Elastic Job Agent com a seguinte etapa:

EXEC jobs.sp_add_jobstep @job_name = @jobName,
@step_name = 'Optimize indexes and statistics',
@command=N'
    EXECUTE dbo.IndexOptimize
    @Databases = ''USER_DATABASES'',
    @FragmentationLow = NULL,
    @FragmentationMedium = ''INDEX_REORGANIZE,INDEX_REBUILD_ONLINE'',
    @FragmentationHigh = ''INDEX_REBUILD_ONLINE'',
    @FragmentationLevel1 = 10,
    @FragmentationLevel2 = 30,
    @MinNumberOfPages = 10,
    @TimeLimit = 3600,
    @UpdateStatistics = ''ALL'',
    @OnlyModifiedStatistics = ''Y'',
    @SortInTempdb = ''Y'',
    @MaxDOP = 1,
    @LogToTable = ''Y''
',
@credential_name = @jobStepCredName,
@target_group_name= @targetGroupName,
@retry_attempts  = 0,
@step_timeout_seconds = 3600,
@max_parallelism = 1 -- IMPORTANT! We don't want to run index optimization on multiple databases at the same time

O código usa o procedimento armazenado dbo.IndexOptimize fornecido por Ola Hallengren.

O trabalho está programado para ser executado diariamente às 5 da manhã e falha uma ou duas vezes por semana. O motivo da falha é o problema interno do Azure Elastic Job Agent: "Serviço de trabalhos reiniciado enquanto esta tarefa estava em andamento.". O serviço do Azure ainda está em versão prévia, portanto, são esperados erros de serviço internos.

Minha solução atual é definir @retry_attempts como um número maior que 0 para que o Job Agent possa repetir a etapa, mas não tenho certeza se é uma boa ideia tentar novamente uma etapa com falha para otimização de índice.

Em particular, não tenho certeza do que aconteceria com os processos INDEX REBUILD, INDEX REORGANIZE OU UPDATE STATISTICS se eles fossem cancelados ou eliminados.

Então, para resumir, tenho as seguintes perguntas:

1. É uma boa ideia tentar novamente a manutenção do índice se a etapa falhar?
2. O que acontece quando os processos INDEX REBUILD, INDEX REORGANIZE OU UPDATE STATISTICS falham ou são encerrados.

Agradeço o seu feedback sobre este assunto.

Estou usando os scripts de manutenção ola-hallengren. Estou logando na tabela e no arquivo. Eu quero mudar o local dos logs do arquivo. Posso fazer isso? Muito Obrigado

Estou configurando um novo servidor e a verificação de integridade do Ola está funcionando para bancos de dados de usuários (restaurei um banco de dados de cerca de 50 GB para testes) e está falhando para bancos de dados do sistema. Se eu olhar nos logs, funciona modele falha para mastere msdbcomThe database could not be checked as a database snapshot could not be created...

A conta do SQL Agent é sysadmin. Funciona se eu adicionar a conta do SQL Server e do SQL Agent como administradores do Windows Server, então faltam alguns direitos em algum lugar. É uma VM executando o Windows Server 2016 versão 1607, não tenho acesso ao host Hyper-V, mas provavelmente é a mesma versão.

Mesmo resultado com SQL Server 2017 e SQL Server 2014. Parece ser causado pelo Windows Server 2016, talvez algumas configurações de políticas de grupo.