我是Ola Hallengren 的 MaintenanceSolution（看起来很棒）和 DBA 的新手。我创建了一个要运行的作业dbo.DatabaseIntegrityCheck（每周针对 ALL_DATABASES）。如果发现错误，DBCC CHECKDB这是否会导致 proc 出错并因此作业失败，所以我会以正常方式收到作业失败的通知？它会继续验证所有其他数据库的完整性，还是在它发现的第一个问题数据库上停止？
我在概述中找不到任何注释，如果我遗漏了一些明显的东西，我很抱歉。
程序中使用该@CleanupTime参数时[dbo].[DatabaseBackup]，每次数据库备份成功后，是否会删除目标旧备份文件？还是先处理所有备份，然后执行清理？
我在可用磁盘空间方面遇到问题，并试图为我的网络管理员提供备份卷大小的准确规格。
在发布之前，我通读了 Ola Hallengren 的 SQL Server 脚本中关于 FULL 备份和 LOG 备份的理解 CleanupTime。我在那里找不到我的问题的答案。如果它在那里，我错过了它。只是再次阅读它，但仍然看不到任何东西。
我正在做一个需要缩小数据库的项目。在缩小之后，我检查sys.dm_db_index_physical_stats并可以看到我的很多索引都超过 99% 是碎片化的 ( avg_fragmentation_in_percent)。
对此，我IndexOptimize由 Ola Hallengren 执行，代码如下：
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'
这成功完成，但是当我sys.dm_db_index_physical_stats再次检查时，avg_fragmentation_in_percent值没有改变，并且状态我的索引仍然碎片化超过 99%。
我在这里错过了什么吗？
我试图找出用于 ServerIntegrity 检查的最佳 CheckCommands 选项是什么。
我应该保留工作默认值吗？
EXECUTE [dbo].[DatabaseIntegrityCheck] @Databases = 'USER_DATABASES', @LogToTable = 'Y'我应该单独运行该
CHECKALLOC,CHECKTABLE,CHECKCATALOG选项还是将其包含在上述选项中？选项也一样CHECKFILEGROUP。
我有一个禁用页面级锁定的索引，现在我有该索引的索引碎片问题。
我知道我不能Reorganize索引，但我相信我能rebuild索引。
现在我认为重建也不起作用。我使用的默认填充因子为 100。我的数据库很大，因此我不希望通过提供 80% 或更少的填充因子来增加表/数据库的大小。通过不工作，我的意思是平均碎片在前一天晚上运行 Ola 的脚本后保持不变。
关于为什么禁用页面级锁定的一些背景知识。
deadlocks我在那个特定表中的这个索引上得到了很多交易。这张表有点像一个事实表，insert, update and delete每时每刻都在发生。并且与其他一些表有一些foreign key关系CASCADE deletes。所以，我得到了很多锁/死锁，在禁用页面级锁之后，我能够摆脱所有这些死锁。
我开始使用 Ola Hallengren 的脚本，Index maintenance并对 Index Reorganize 不起作用的所有索引应用 Index Rebuild。但我注意到索引重建也不起作用。
现在，我看到索引的 AvgPageFragmentaiton 为 95.9413，页数为 1196826，这并不好。
附加信息：
我正在使用 Ola Hall 的脚本，如下所示。
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'
我的问题是，如果为该索引禁用了页面级锁定，如何减少索引中的碎片？
我注意到使用 Ola 维护解决方案中的数据库备份作业的一些意外行为。在我正在处理的测试实例上，我将用户数据库备份作业安排在每天凌晨 2:00 运行。我将@CleanupTime 参数设置为48，但我没有指定@CleanupMode 参数。
如果我理解正确，那应该每天运行并保留数据库备份的两份副本......由于默认值为“AFTER_BACKUP”，它应该在新备份完成后删除最旧的文件，如果只留下最旧的文件最新的备份失败。所以它应该从文件夹中两天的文件开始，创建第三个文件（当天），然后删除三个文件中最旧的文件。
奇怪的是，有时它会留下两天的文件，有时会留下三天，即使所有备份都已成功完成。这不是一个大问题，但为了节省该驱动器上的空间，我宁愿在任何给定时间只保留两个备份。任何提示或建议将不胜感激。
编辑：根据下面评论中的要求，这是该作业步骤中的参数列表...
EXECUTE [dbo].[DatabaseBackup]
@Databases = 'ALL_DATABASES',
@Directory = NULL,
@BackupType = 'FULL',
@Verify = 'N',
@CleanupTime = 48,
@CheckSum = 'Y',
@LogToTable = 'Y'
我使用Azure Elastic Job Agent创建了一个 SQL 维护作业，步骤如下：
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
该代码使用 Ola Hallengren 提供的存储过程dbo.IndexOptimize。
该作业计划每天早上 5 点运行，每周失败一到两次。失败的原因是 Azure 弹性作业代理的内部问题：“作业服务在此任务进行时重新启动。”。Azure 的服务仍处于预览阶段，因此预计会出现内部服务错误。
我当前的解决方案是将 @retry_attempts 设置为大于 0 的某个数字，以便 Job Agent 可以重试该步骤，但是我不确定重试失败的步骤以进行索引优化是否是个好主意。
特别是，我不确定如果 INDEX REBUILD、INDEX REORGANIZE 或 UPDATE STATISTICS 进程被取消或终止，它们会发生什么情况。
所以总结一下，我有以下问题：
- 如果步骤失败，重试索引维护是个好主意吗？
- 当 INDEX REBUILD、INDEX REORGANIZE 或 UPDATE STATISTICS 进程失败或终止时会发生什么。
感谢您对此事的反馈。
我正在配置一个新服务器，Ola 的完整性检查对用户数据库有效（我已经恢复了大约 50 GB 的数据库用于测试）并且对系统数据库失败。如果我查看日志，它适用于并且model失败了mastermsdbThe database could not be checked as a database snapshot could not be created...
SQL 代理帐户是 sysadmin。如果我将 SQL Server 和 SQL Agent 帐户添加为 Windows Server 的管理员，它就可以工作，所以它在某处缺少一些权限。这是一个运行 Windows Server 2016 版本 1607 的虚拟机，我无权访问 Hyper-V 主机，但它可能是相同的版本。
SQL Server 2017 和 SQL Server 2014 的结果相同。似乎是由 Windows Server 2016 引起的，可能是一些组策略设置。