标签: maintenance

我需要从 PostgreSQL 数据库集群中删除一个数据库。即使有活动连接，我该怎么做？我需要一个-force标志，它将删除所有连接，然后删除数据库。

我该如何实施？

我dropdb目前正在使用，但其他工具也是可能的。

我的任务是为我们的 Sql Server 2005 数据库制定维护计划。我知道对于备份，我希望每 15 分钟执行一次完整的数据库备份和事务日志备份。我的问题是弄清楚我想做哪些其他任务以及我应该多久做一次。

所以，到目前为止，我已经想到了这一点。如果我的想法有任何缺陷或更好的方法，请纠正我。

1. 备份 - 所有表，完整备份（每日）
2. 备份 - 选定表，完整备份（每小时）
3. 备份 - 事务日志（每 15 分钟）
4. 检查数据库完整性（每天）
5. 重组索引（每日）
6. 更新统计数据（每日）
7. 收缩数据库（每周）
8. 重建指数（每周）
9. 维护清理（每日）

我记得前段时间（当我在另一份工作中制定类似计划时）读到其中一些任务不需要每天运行或不应该每天运行。至于哪些，它逃脱了我。我可以使用一些指导来创建更好的维护计划，以减少灾难中的数据丢失，但不会在高峰时段运行时对系统造成负担（并提高性能）。

我继承了执行以下操作的维护计划：

• 清理旧数据
• 检查数据库完整性
• 执行数据库和事务日志备份
• 重组我们的索引
• 更新统计
• 删除旧备份和维护计划文件

在 23 分钟的维护计划中，更新统计数据需要惊人的 13 分钟。在这 13 分钟期间，对数据库的访问被阻止（或者至少，从这个数据库到我们其他数据库的复制被暂停）。

我的问题是：

我们应该什么时候更新统计数据，为什么？

这似乎是我们应该比每天少做的事情。我试图让我们摆脱“仅仅因为”进行不必要维护的心态。

我知道收缩是魔鬼：它会颠倒页面顺序并导致皮肤癌、数据碎片化和全球变暖。名单还在继续……话虽如此，假设我有一个 100 GB 的数据库，我删除了 50 GB 的数据——不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖 90% 的数据表——这是否构成缩小数据库的适当用例？

如果没有，从数据库中删除如此高比例的数据后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计。还有什么？

我找了实际指导的设定值BUFFERCOUNT，BLOCKSIZE以及MAXTRANSFERSIZE该的BACKUP命令。我做了一些研究（见下文），我做了一些测试，我完全意识到任何真正有价值的答案都会以“好吧，这取决于……”开头。我对我所做的测试以及我发现的任何资源中显示的测试（见下文）的担忧是，测试是在真空中完成的，很可能是在没有其他负载的系统上完成的。

我很好奇关于这三个基于长期经验的选项的正确指导/最佳实践：数周或数月内的许多数据点。而且我不是在寻找特定值，因为这主要是可用硬件的功能，但我想知道：

• 各种硬件/负载因素如何影响应该做什么。
• 是否存在不应覆盖这些值中的任何一个的情况？
• 是否存在覆盖任何不明显的陷阱？使用了太多内存和/或磁盘 I/O？恢复操作复杂吗？
• 如果我有一台运行多个 SQL Server 实例的服务器（一个默认实例和两个命名实例），并且如果我同时运行所有 3 个实例的备份，这是否会影响我设置这些值的方式，而不是确保集体（BUFFERCOUNT* MAXTRANSFERSIZE) 不超过可用 RAM？可能的 I/O 争用？
• 在同一台服务器上拥有三个实例并再次同时运行所有三个实例的备份的相同场景中，在每个实例中同时运行多个数据库的备份如何影响这些值的设置？这意味着，如果三个实例中的每一个都有 100 个数据库，则每个实例同时运行 2 或 3 个备份，这样就有 6 到 9 个备份同时运行。（在这种情况下，我有许多中小型数据库，而不是一些大型数据库。）

到目前为止我收集到的：

• BLOCKSIZE：

  • 支持的大小为 512、1024、2048、4096、8192、16384、32768 和 65536 (64 KB) 字节。^[1]
  • 磁带设备的默认值为 65536，否则为 512 ^[1]
  • 如果您要进行备份并计划从 CD-ROM 复制和恢复，请指定 BLOCKSIZE=2048 ^[1]
  • 写入单个磁盘时，默认512就可以了；如果使用RAID阵列或SAN，则必须测试以查看默认或65536是否更好。^{[13（第 18 页）]}

  • 如果手动设置，该值需要 >= 用于创建数据文件的块大小，否则您将收到以下错误：

    消息 3272，级别 16，状态 0，第 3 行
    “C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\BackupTest.bak”设备的硬件扇区大小为 4096，但块大小参数指定不兼容的覆盖值 512。使用兼容的块大小重新发出语句。 …

VACUUM通常不会将磁盘空间返回给操作系统，除非在某些特殊情况下。
从文档：

VACUUM删除表和索引中的死行版本并标记可用空间以供将来重用的标准形式。但是，它不会将空间返回给操作系统，除非在表末尾的一个或多个页面完全空闲并且可以轻松获得排他表锁的特殊情况下。相比之下，VACUUM FULL通过编写一个没有死空间的完整新版本的表文件来主动压缩表。这最大限度地减少了表的大小，但可能需要很长时间。它还需要额外的磁盘空间用于表的新副本，直到操作完成。

问题是：如何实现这个数据库状态one or more pages at the end of a table become entirely free？这可以通过 完成VACUUM FULL，但我没有足够的空间来实现它。那么还有没有其他可能呢？

在备份数据库时，我想使用“备份集将过期： ”选项来删除/覆盖旧的数据库备份。我无法使用此选项。

关于如何在创建维护计划时使用“备份集将过期：”选项的任何建议将不胜感激。

我注意到一些 DBA 非常频繁地重新启动 SQL Server，有时甚至每晚都重新启动。我相信他们这样做是为了释放一些内存，或者也可能是为了加快查询速度。我知道在重新启动后必须重新编译查询计划，但即使包括这一点，我也想知道这种做法是否有净收益。

每天重新启动 SQL Server 会使其运行得更快吗？

我有一个 ASP.NET MVC 应用程序，它与 SQL Server 2008 R2 Express 版下的数据库一起使用。需要定期执行更新数据库中的某些记录的任务。

不幸的是，Express Edition 缺少 SQL Agent。
你会推荐什么方法？

在 SQL Server 中，统计信息会在Auto Update Statistics进入时自动更新True（这是默认设置）。是否有理由在什么情况下手动更新统计信息？