标签: checkpoint

在 PostgreSQL 9.2.2（Windows 32 位）下，我有一个pg_restore命令可以系统地导致有关检查点频率的日志警告，例如：

LOG:  checkpoints are occurring too frequently (17 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

该数据库大小约为 3.3 Gb，具有 112 个表/160 个视图，并在大约 14 分钟内恢复。

在 a 期间发生这种情况是否正常pg_restore？

说来话长，但我们的长期顾问（前雇员）在几年前（2006 年左右）编写了一个自定义脚本来与 Tivoli Storage Manager 交互，它似乎正在检查名为truncate log on checkpoint. 他们声称它阻止脚本在 SQL 2012 实例上运行和执行备份。

我觉得这完全是废话，因为我找不到任何这样的选项，sp_configure而且备份在任何地方都可以工作，只有一个实例。但是，我想移除地雷，如果是这样的话，并移除其他过时的元素。我确实让他们与供应商核实，但我对他们所说的任何事情都没有高度的信心。

我所做的研究几乎没有得到更多的回报，它可能是 SQL 2000 或 Sybase 选项的一个选项。另一种说法是，当恢复模型是SIMPLE并且没有显式选项打开或关闭它时，它在更高版本（2008 及更高版本）上被隐式调用/使用。

由于TRUNCATE LOG如今事务日志的工作方式，该命令已过时，因此我认为此时甚至无法查询该选项。

由于我没有任何 SQL Server 2000 实例，我希望有人能回忆起这个，或者可以在他们周围的一个实例上检查它。我已经告诉他们，我没有什么可以推荐的。我也希望有人可以确认这已经过时了。

当我们从旧的全闪存阵列迁移到新的全闪存阵列（不同但成熟的供应商）时，我们开始看到检查点期间 SQL Sentry 中的等待增加。

版本：SQL Server 2012 Sp4

在我们的旧存储上，我们的等待时间约为 2k，在检查点期间“峰值”达到 2500，而新存储的峰值通常为 10k，峰值接近 50k。Sentry 将我们更多地指向PAGEIOLATCHwatis。做我们自己的分析，这似乎是PAGEIOLATCH and PAGELATCH等待的组合。使用 Perfmon，我们通常可以说我们检查点的页面越多，我们得到的等待就越多，但我们在检查点期间只刷新了大约 125 mb。我们的工作量主要是写入（主要是插入/更新）。

存储供应商已向我们证明，在这些检查点事件期间，光纤通道直连阵列的响应时间不到 1 毫秒。HBA 还会确认阵列的编号。我们也不认为这是 HBA 队列问题，因为队列深度从未超过 8。我们还尝试了更新的 HBA，更改 ZIO、执行限制和队列深度设置无济于事。我们还将服务器的内存从 500 GB 增加到 1 TB，没有任何变化。在检查点过程中，我们确实看到 2 - 4 个独立内核（共 16 个）飙升至 100%，但整体 CPU 约为 20%。BIOS 也设置为高性能。有趣的是，我们确实看到 CPU 通常处于 C2 睡眠状态，即使我们已经禁用了它，所以我们仍在研究为什么睡眠状态会超过 C1。

我们可以看到几乎所有的等待都在数据页上，偶尔会有 DCM 页面类型的 PFS。等待在用户数据库中，而不是 tempdb。我们还看到等待跨越多个数据页，一些 SPID 在同一页上等待。数据库设计确实有几个插入热点，但旧存储采用了相同的设计。

运行这个查询的循环 100 次，我们能够捕捉到有多少 SPID 在磁盘与内存上等待

SELECT
    [owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type] …

假设一个数据库使用完全恢复模式，当一条记录写入SQL Server（通过INSERT/ UPDATEetc）时，预写日志将确保在修改数据页之前将更改写入日志文件。

日志和数据页条目都在 RAM 中创建，稍后通过检查点提交到磁盘。

如果系统崩溃（为了论证而断电），脏页（在 RAM 中更改但未提交到磁盘的 IE 数据）会发生什么，因为 RAM 的内容无法在系统重新启动后幸存下来，这些数据是否丢失?

编辑

经过一些测试，我可以看到脏页没有丢失，但我不确定为什么：

使用本教程

创建一个测试数据库

CREATE DATABASE DirtyPagesDB
GO
USE DirtyPagesDB
GO

关闭自动检查点

DBCC TRACEON(3505, -1);
DBCC TRACESTATUS();

创建一个表，插入一些数据并发出一个检查点：

CREATE TABLE t1 (Speaker_Bio CHAR(8000))
GO
INSERT INTO t1 VALUES ('SQL'),('Authority')
GO
CHECKPOINT

确认没有脏页

-- Get the rows of dirtied pages
SELECT
database_name = d.name,
OBJECT_NAME =
CASE au.TYPE
WHEN 1 THEN o1.name
WHEN 2 THEN o2.name
WHEN 3 THEN o1.name
END,
OBJECT_ID =
CASE …

我们似乎遇到了一个莫名其妙的问题。检查点进程卡在 SLEEP_BPOOL_FLUSH 状态，并没有真正减少日志文件中的使用。

这在以前似乎从未发生过。

我知道 SLEEP_BPOOL_FLUSH 是磁盘子系统繁忙时对 CHECKPOINT 进程的正常等待。实际上，我们一直有一个非常繁忙的磁盘子系统，所以我不明白为什么这会成为一个问题。

（如果您手动运行检查点命令，同样的结果...您的用户进程在 SLEEP_BPOOL_FLUSH 中等待）。

我们可以做些什么来推动检查点发生？是否可以调整检查点的参数以免发生这种情况？

（SQL Server 2005，RAID 子系统，简单恢复模型）

我在我的 postgresql 配置上打开了 archive_mode 以测试备份服务器。由于 wal 文件占用了大量磁盘空间，因此在测试后我将其关闭并删除了 wal 文件。当我尝试重新启动 postgresql 时，出现以下错误。

 root@hooshang:/etc/postgresql/9.1/main# /etc/init.d/postgresql restart
 * Restarting PostgreSQL 9.1 database server
 * The PostgreSQL server failed to start. Please check the log output:
 2014-10-16 13:15:28 IRST LOG:  database system was shut down at 2014-10-15 15:51:53 IRST
 2014-10-16 13:15:28 IRST LOG:  could not open file "pg_xlog/00000001000007DC00000037" (log file 2012, segment 55): No such file or directory
 2014-10-16 13:15:28 IRST LOG:  invalid primary checkpoint record
 2014-10-16 13:15:28 IRST LOG:  could not open file …

通常，当开发人员或数据分析师之一需要执行非常大的数据更新或删除时（其中截断或截断/插入没有意义，因为要保留的数据集太大）我建议他们这样做类似于以下内容：

-- Delete 1 million rows 1 thousand at a time
DELETE TOP (1000) FROM TableA WHERE <condition>
WAITFOR DELAY '00:00:01'
GO 1000

对处于完全恢复模式的数据库执行此操作的结果是 1) 等待允许其他事务在需要时进行处理 2) 当日志备份运行时，它能够在日志文件中将已完成的操作标记为脏操作可以复用空间，防止日志增长过快。

而不是这样做，我想知道是否可以使用检查点完成同样的事情。这句话是否会有效地导致同样的情况发生？

-- Delete 1 million rows 1 thousand at a time
WHILE EXISTS ( SELECT 1 FROM TableA WHERE <condition> )
BEGIN
DELETE TOP (1000) FROM TableA WHERE <condition>
WAITFOR DELAY '00:00:01'
CHECKPOINT
END

同样，这些是处于完全恢复模式的数据库。

我知道 PostgreSQL 检查点是什么以及它何时发生。

我需要一些有关log_checkpoints = on参数生成的日志的附加信息，因此请向我解释其中的一些要点：

2017-09-09 16:31:37 EEST [6428-6524] LOG: checkpoint complete: wrote 30057 buffers (22.9%); 0 transaction log file(s) added, 0 removed, 47 recycled; write=148.465 s, sync=34.339 s, total=182.814 s; sync files=159, longest=16.143 s, average=0.215 s

1. 我知道 22.9% 的共享缓冲区被写入（我有 1024 MB，shared_buffers所以这意味着 234 MB 被写出）。
2. 我知道有 47 个 WAL 文件被回收，即崩溃恢复不再需要它们，因为来自它们的真实数据已经在磁盘上。

质疑。但是write=148.465 s和sync=34.339呢？有什么不同？什么是write，为什么它的时间远远超过fsync()操作？

问题B。什么是sync files？哪些文件：WAL 文件？为什么sync files是159个，而回收的文件只有47个？它们之间有什么关系？

谢谢！

设置

3 节点 Alwayson 群集 - 1 个同步和 1 个异步辅助副本 - SQL Server 2012

情况

从异步辅助副本读取时，我们正在目睹 PageIOLatches。这主要是由于 SAN 的吞吐量受到限制造成的。托管合作伙伴告诉我们，由于硬件限制，无法立即缓解此限制。
主副本和同步副本使用具有更高吞吐量的其他 SAN。虽然这种情况远非理想，但这是一个很快就会解决的暂时情况，不是我的问题。

在调查 IO 等待时，我们注意到这些与检查点页数/秒的增加同时发生。

我的印象是检查点不会出现在 AG 中的辅助副本上，就像这里讨论的那样。

为了验证这种行为，我设置了一个扩展事件来监视异步副本上的检查点事件。正如预期的那样，没有为此数据库捕获任何检查点，也没有从其他数据库中找到与该模式匹配的任何检查点。

接下来，我在主副本上创建了相同的扩展事件，并启动了一个 perfmon 来验证我们是否可以见证相同的行为。在这里，我们能够捕获（自动）检查点，它们大约发生。每分钟一次。这些检查点与辅助（和主要）副本上检查点页数/秒的增加同时发生。似乎正在主副本上生成检查点并在辅助副本上重做。这意味着检查点确实隐式发生在 AG 中的辅助副本上。

题

我的假设是否正确，在 AG 检查点是在主副本上生成并在所有辅助副本上重做？
因此，如果TARGET_RECOVERY_TIME未设置数据库，recovery interval主副本的设置将规定这些数据库的所有辅助副本上的检查点。

我目前正在开发一个测试系统，并且由于我想要优化的查询的性质，我正在尝试尽可能模拟“冷”读取。其中一部分是在执行查询之前清除缓冲区缓存。从我可以找到的所有内容中，应该在检查点期间写入脏缓冲区页面。但是，即使在发出 CHECKPOINT 之后，缓冲池中似乎仍然有 169 个我的数据库的脏页（通过 评估SELECT * FROM sys.dm_os_buffer_descriptors WHERE database_id=7 AND is_modified=1）。

我对检查点或 sys.dm_os_buffer_descriptors 的内容有什么误解吗？如果没有，为什么我应该写掉它们之后我仍然有脏页？