我应该执行哪些步骤来准备将 MDF 作为（主要是）只读数据库分发？

Question

我所在的团队开发使用多个 SQL Server 数据库的产品。其中一些大多是只读的。表不会更改，但作为配置应用程序的一种方式，某些视图和存储过程会更改。这些视图缺少索引。它们不是物化视图。对表的更改仅在升级期间发生，并且涉及向客户端发送附加的新 MDF。我应该执行哪些步骤来使这些数据库处于“发货就绪”状态？更新请注意，这些 MDF 中有大量可用空间，因此会收缩，然后重新索引。

我们目前正在做以下工作：

• 数据库处于简单恢复模式（我们通常建议保留 MDF 的原始副本作为备份）
• 我们将数据库归为 sa 并删除所有登录名（部署过程添加适当的登录名）
• 我们DBCC SHRINKDATABASE在数据库上运行

• 我们运行Ola Hallengren 的完整性和维护脚本：

  EXECUTE dbo.DatabaseIntegrityCheck
      @Databases = 'DB_IN_QUESTION',
      @CheckCommands = 'CHECKDB',
      @ExtendedLogicalChecks = 'Y',
      @TabLock = 'Y'
  GO
  
  EXECUTE dbo.IndexOptimize
      @Databases = 'DATABASE_IN_QUESTION',
      @FragmentationLow = NULL,
      @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
      @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
      @FragmentationLevel1 = 5,
      @FragmentationLevel2 = 30,
      @SortInTempdb = 'Y',
      @MaxDOP = 0
  GO
  

我们应该为 Ola 的脚本使用其他参数吗？我们是否应该采取任何其他措施？将数据库设为只读会很麻烦，因为视图和存储过程经常由最终用户修改。

Answer 1

如果您想分发数据库的副本，为什么不使用 LocalDB？

缩小数据文件会导致非常高的碎片化。运行索引维护会使文件重新增长。你为什么要缩小它？

此外，如果您只打算发送 mdf 文件，为什么要使用 DBCC SHRINKDATABASE？SHRINKDATABASE 为数据库中的每个文件调用 DBCC SHRINKFILE。如果你不传送日志文件，你为什么要缩小它呢？好像是在浪费时间。

不支持仅提供 mdf 文件来共享数据库。始终存在无法重新附加文件的风险。传送备份或至少完整的文件集是传送数据库的最佳方式。