Questions tagged «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分钟内恢复。 这在正常情况下发生是正常的pg_restore吗？

15 postgresql  restore  configuration  checkpoint 

长话短说，但我们的长期顾问（前雇员）早在2006年左右就编写了一个自定义脚本来与Tivoli Storage Manager交互，并且似乎正在检查名为的SQL Server DB选项truncate log on checkpoint。他们的说法是，它阻止脚本在SQL 2012实例上运行和执行备份。 我觉得这是完整的BS，因为我找不到任何这样的选项，sp_configure并且备份在一个实例之外的任何地方都可以工作。但是，我想删除一个地雷（如果确实如此），并删除其他过时的元素。我确实让他们与供应商核实，但我对他们所说的话没有高度的信心。 我所做的研究只返回了SQL 2000或Sybase选项。另一个说法是，当恢复模型使用SIMPLE并且没有明确的选项打开或关闭它时，它在更高版本（2008及更高版本）中被隐式调用/使用。 由于该TRUNCATE LOG命令由于这些天的事务日志的工作方式已过时，因此我认为这不是一个可以查询的选项。 由于我没有任何SQL Server 2000实例，因此我希望有人可以回忆起此事，或者可以检查周围放置的实例。我告诉他们，我没有什么可以推荐的。我也希望有人可以确认这已经过时了。

11 sql-server  sql-server-2012  transaction  log  checkpoint 

当我们从一个较早的全闪存阵列迁移到一个较新的全闪存阵列（不同但信誉良好的供应商）时，我们开始发现检查点期间SQL Sentry中的等待时间增加了。 版本：SQL Server 2012 Sp4 在我们的旧存储中，检查点期间的等待时间约为2k，“峰值”为2500，而在新存储中，峰值通常为10k，峰值接近50k。哨兵将我们更多地指向PAGEIOLATCH瓦蒂斯。做我们自己的分析，似乎是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。 我们可以看到，几乎所有等待都在数据页面上，偶尔的PFS为DCM页面类型。等待在用户数据库中，而不在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] order by 1 GO 100 “好”的事情是，我们可以在具有相同模型阵列和相似服务器规格的性能环境中轻松重现该问题。对于任何其他地方或如何缩小问题的想法，我将不胜感激。现在，我们的下一个测试包括：带有更新的主板和更多CPU的新服务器；禁用SIOS数据保持器（即使旧存储中已安装该功能）；不同的HBA品牌。 exec sp_Blitz @outputtype = 'markdown' 优先级5：可靠性：-危险的第三方模块-Sophos Limited-Sophos缓冲区溢出保护-SOPHOS〜2.DLL-已安装可疑的危险第三方模块。 优先级200：信息性：-群集节点-这是群集中的节点。-TraceFlag On-跟踪标记1117全局启用。-跟踪标记1118全局启用。-跟踪标记3226全局启用。 优先级200：许可：-正在使用的企业版功能* xxxxx-[xxxxxx]数据库正在使用压缩。如果将此数据库还原到Standard Edition Server上，则还原将在2016 SP1之前的版本上失败。* …

9 sql-server  sql-server-2012  storage  waits  checkpoint 

假设数据库使用完全恢复模型，那么在SQL Server中（通过INSERT/ UPDATEetc）写入记录时，预先写入日志将确保在修改数据页之前将更改写入日志文件。 日志和数据页条目均在RAM中进行，然后由Checkpoint提交到磁盘。 如果发生系统崩溃（出于参数争用而断电），脏页（在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 …

8 sql-server  checkpoint