标签: maintenance

在某些场合，并作出巨大的后update，insert或delete从一个表，我已经开始了VACUUM FULL ANALYZE，以确保DB没有得到太臃肿。在生产数据库中做这件事让我发现这不是一个好主意，因为我可能会阻塞表很长一段时间。所以，我取消了这个过程，也许只是尝试了VACUUM（不是完整的）或者让AUTOVACUUM以后做任何它可以做的事情。

问题是：如果我在“中途”停止 VACUUM 或 AUTOVACUUM，是否所有已经完成的处理都丢失了？

例如，如果VACUUM已经找到 1 M 个死行并且我停止它，那么所有这些信息都丢失了吗？VACUUM 是否以完全事务的方式工作（“全有或全无”，就像大量的 PostgreSQL 进程一样）？

如果可以安全地中断 VACUUM 而不会丢失所有工作，那么有什么方法可以vacuum增量工作吗？[工作 100 毫秒，停止，等待 10 毫秒以允许非阻塞世界其他地方......等等]。我知道您可以通过调整 autovacuum 参数来完成部分工作，但我正在考虑能够以编程方式控制这一点，以便能够在某些时间/在某些条件下执行此操作。

注意：在这种情况下，停止/取消/终止进程意味着：

• 如果使用 pgAdmin，请按“取消查询”按钮。
• 如果以编程方式工作，请调用 pg_cancel_backend()。

我假设两者是等价的。我没有使用任何 shell/系统级 kill 命令。

在运行 PostgreSQL 数据库系统时，我如何知道我的数据库作为一个整体具有 100% 的完整性？基本上我怎么知道我的数据文件和页面是否都是 100% 好，没有损坏？

在 Microsoft SQL Server 世界中，有一个命令可以执行 DBCC CHECKDB，它会告诉您是否存在问题。如果您有兴趣了解有关命令的更多信息，请访问这里的链接。DBCC CHECKDB (Transact-SQL)

我是一个偏执的数据库完整性的人（任何以 DBA 类型角色使用数据库的人都应该是），这种类型的东西让我很难在晚上睡个好觉。这样的实用程序是必须的！在 google 上搜索发现了一些类似这样的工具的尝试，在我看来，除非它是 PostgreSQL 项目官方接受的工具，否则我不会相信它来处理如此重要的事情。

这里有一些链接，指向人们提出类似问题，但我认为没有真正明确的答案。在我看来，PostgreSQL 需要有一些工具，而 Oracle 和 Microsoft SQL Server 似乎也有这些工具。

第一个链接是我在这个主题上发现的最有趣的链接。我认为对这篇文章的评论可能总结道：“在识别数据库损坏和修复它时，Postgres 非常蹩脚。检测它的唯一方法是通过转储数据库或从数据库中的每个表中选择 * .”

PostgreSQL 如何防止部分页面写入和数据损坏

检查数据和索引文件损坏 - Dev Shed

求助：我的桌子坏了！

PostgreSQL：损坏的主键，不一致的表

我相信 9.3 可能有一些损坏检查功能。如果选择，似乎有希望对页面文件进行总和检查。因此，如果您考虑使用 ZFS 和/或带有页面校验和的未来版本的 Postgres，事情看起来会很光明。 https://commitfest.postgresql.org/action/patch_view?id=759

更新：2012 年 1 月 14 日 - 似乎使用基于 ZFS 的文件系统可以通过对每个数据块进行校验和来检测损坏。我将不得不进一步研究这一点，看看这是否是一种解决方法，可以让人们在知道他们的数据库数据不会悄悄损坏的情况下晚上睡个好觉。

更新：2012 年 1 月 17 日 - 如何查找 ZFS 损坏的文件。http://docs.oracle.com/cd/E18752_01/html/819-5461/gbbwl.html#gbcuz

更新：14-APR-2014 9.3 确实获得了数据校验和。https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.3

我们在周五晚上 9 点运行每周备份作业，我们遇到了一些关于磁盘空间（有时会变得非常低）和性能方面的问题。我们正在考虑精简/优化所发生的事情，并感谢您的意见。

具体来说：

1. 备份过程大约需要 4 小时才能在备份期间更新统计信息。我们可以安全地禁用此过程以节省时间吗？

2. 我们经常会遇到磁盘空间不足的情况，想知道是否应该重新调整这个过程。目前它创建备份，然后删除以前的备份，这就是占用磁盘空间的原因。我们可以安全地删除前一首，然后做备份？

非常欢迎任何其他评论或意见编辑：服务器上 SQL 文件的总大小约为 35GB。一个 db 的大小约为 25GB，而其他 6 个共享组成了另外 10GB 左右。

尝试运行我的维护计划时，我收到以下错误：

执行查询“”失败，出现以下错误：“无法重新组织表“”上的索引“”（分区 1），因为禁用了页级锁定。”

我们目前在此索引上启用了行级锁定。我可以启用页面级别锁定，但我不确定影响是什么。

我的问题是：这两种锁定方案有什么区别，它们在现实世界（生产中）的后果是什么？

有时，在我们的索引维护期间，作业会失败并出现 SEV 17 错误，其中无法为正在重建的对象分配足够的空间。数据库布局如下：

Data_file1    PRIMARY    0 growth         0% free                Max Size UNLIMITED
Data_file2    PRIMARY    0 growth         0% free                Max Size UNLIMITED
Data_file3    PRIMARY    0 growth         Less than 1% free      Max Size UNLIMITED
Data_file4    PRIMARY    250 MB growth    Less than 1% free      Max Size UNLIMITED

本质上，4 个数据文件中的 3 个已满且不允许增长，第四个已满且允许增长。文件分布在不同的 LUN 上（原因是杂乱无章）。所以当在线索引重建开始时，我的理解是，如果需要任何额外的空间，它会增长到 Data_file4 并且很好，但它显然试图增长到一个不同的文件，其中不允许增长并且失败。我无法重现此错误，但我想知道是否有人了解发生这种情况的原因。

完整的 SQL Server 版本是 2008 R2 Enterprise, SP2 CU 4 (10.50.4270)。我们使用 Ola Hallengren 的重建脚本，我们在线重建，但没有在tempdb.

PostgreSQL 内置的备份机制并不总是很合适。有时，您希望将应用程序置于静止状态，因为它具有您要在备份 PG 数据的同时进行备份的外部数据。但是将应用程序置于静止状态的唯一方法是“锁定”数据库。PG 缺乏数据库范围或集群范围的锁定机制。将 PG 置于只读状态将是以下解决方案中的一部分：

1. 停止应用程序数据（禁用登录）
2. 停顿数据库（通过使其只读）
3. 执行 PG 检查点或 pg_xlog_switch()
4. 创建应用程序和数据卷的快照
5. 恢复数据库（再次使其为 RW）
6. 继续申请
7. 备份快照

在 SQL Server 2005 上，如果所有数据库都处于完整模式（每小时事务日志备份），是否可以确定重建数据库的所有索引是否可以增加数据库的日志文件？它可以增长多少？

如果没有直接的答案，那么任何方向都将不胜感激。

提前致谢。

我们有一个“有机”的环境，这意味着人们在代码上堆积了十年，而几乎没有监督或文档。我使用的服务器有几个我认为不再使用的数据库；我很想删除它们，只留下我实际使用的三个。

在鲁莽的极端情况下，我可以禁用这些数据库并等待有人尖叫；另一方面，我可以让它们永远运行“以防万一”。在确定是否正在使用服务器方面，您发现哪些步骤很有价值，以及如何使用？

此外，您建议采取哪些步骤来确保在禁用系统的过程中，它们在一段时间内保持方便地可逆（例如，重命名对象而不是彻底删除它们）？

谢谢！

我想知道 SQL Server 代理作业的所有者的可能用途是什么？

删除，并将其留空，作业仍然成功

如果数据库与实例永久分离，是否应该完成任何清理任务？