Questions tagged «transaction-log»

事务日志是由数据库管理系统执行的修改列表/历史记录，以确保ACID属性在崩溃或硬件故障时得以保留。

4
为什么事务日志持续增长或空间不足？
在大多数论坛和整个网络中，这似乎是一个常见问题，在这里以多种格式询问，通常听起来像这样： 在SQL Server中- 事务日志变得如此之大的一些原因是什么？ 为什么我的日志文件这么大？ 有什么方法可以防止出现此问题？ 当我使自己的潜在原因步入正轨并希望将事务日志文件调整为正常大小时，该怎么办？
5
为什么将ALTER COLUMN设置为NOT NULL会导致大量日志文件增长？
我有一个表，其中有64m行，其数据占用磁盘上4.3 GB的空间。 每行大约是30个字节的整数列，外加一个NVARCHAR(255)用于文本的可变列。 我添加了一个NULLABLE列，具有data-type Datetimeoffset(0)。 然后，我为每一行更新了该列，并确保所有新插入的内容在该列中都放置了一个值。 一旦没有NULL条目，我就运行以下命令使我的新字段成为必填项： ALTER TABLE tblCheckResult ALTER COLUMN [dtoDateTime] [datetimeoffset](0) NOT NULL 结果是事务日志大小从6GB大幅增加到36GB以上，直到空间用完为止！ 有谁知道SQL Server 2008 R2在做什么，以使这个简单的命令取得如此巨大的增长？
4
由于“ XTP_CHECKPOINT”，数据库“ database_name”的事务日志已满
我有一个问题XTP_CHECKPOINT。 我正在使用SQL Server2014。我有一个处于简单恢复模型模式的数据库。它也在被复制。 没有公开交易。我已经跑了DBCC OPENTRAN，它返回： “没有活跃的公开交易。” 但是，每当我尝试创建或删除表或删除数据时，我都会不断收到此消息：（ 我用单词替换了实际的数据库名称database_name） “由于'XTP_CHECKPOINT'，数据库'database_name'的事务日志已满” 有谁知道为什么会发生这种情况，更重要的是，我如何才能阻止这种情况发生？ 是的，数据库确实处于SIMPLE恢复模型模式。即，事务日志应自动截断。 顺便说一句，我处于完全恢复模式的另一个数据库做了同样的事情，开始返回同样的错误： 由于“ XTP_CHECKPOINT”，数据库“ database_name”的事务日志已满 我试图将日志增长设置更改为无限制增长，但它不允许我返回相同的错误。 除了文件组之外，我完全不需要任何XTP东西就可以重现该问题。方法如下：http : //pastebin.com/jWSiEU9U
4
为什么在每晚备份的简单恢复模式下事务日志会继续增长
在立即将其标记为重复之前，我已阅读Mike Walsh的“ 为什么事务日志保持增长或空间不足？，但我认为这无法解决我的情况。我浏览了十几个类似的问题，但相关的问题大多只是说“重复”并指出了麦克的问题。 详细信息：我在SQL Server 2008 R2上有一堆约500MB的数据库，全部处于简单恢复模式（不是我的选择），每晚进行完整备份，并具有约200MB的数据文件和约300MB的日志文件。日志不会立即增长到300MB，而是会在几个月后缓慢增长。至少根据sp_who2和活动监视器，它们中的任何一个都没有打开的事务。如果我右键单击数据库并选择属性，它会告诉我大约有50MB可用空间。特别是在备份之后，整个日志是否不应该免费？在简单模式下，只要没有未完成的事务，日志是否不应该免费？ log_reuse_wait_descfrom sys.databases说“什么都没有”，根据上面提到的问题和答案，它说它不应该等待任何东西来重用空间。 如果我执行“ DBCC SHRINKFILE”，则日志文件会缩小到1MB，因此它愿意回收空间。我可以设置一些可以每周缩小日志并防止事情失控的事情，但是我对为什么SQL Server可以做到这一点感到困惑。 我可以理解是否有一些需要300MB记录的疯狂交易，但是我们没有做任何极端的事情，只是基本的OLTP。来自Mike的问题/答案： 简单恢复模型-通过上面的介绍，最简单的是首先讨论简单恢复模型。在此模型中，您要告诉SQL Server-可以使用事务日志文件进行崩溃和重新启动恢复（您确实没有选择。在这里查找ACID属性，应该很快就可以理解），但是一旦您没有，出于崩溃/重新启动恢复目的而不再需要它，请继续并重用日志文件。 SQL Server在简单恢复中侦听此请求，并且仅保留进行崩溃/重新启动恢复所需的信息。一旦SQL Server确定它可以恢复，因为数据已经被硬化到数据文件中（或多或少），则已硬化的数据将不再在日志中被使用，并被标记为截断-这意味着它将被重新使用。 它一直在说应该重新使用日志空间，但是随着几个月来的缓慢增长，似乎并没有。 我想念什么？是否可以阻止SQL Server将数据识别为“已强化”并释放日志？ （编辑） 行动后报告-又一点知识是危险的 在发现这是一个“普遍的问题”之后，感觉就像我对7个月前发生的事情以及我所学到的希望为其他人节省一些悲痛的事情做了解释。 首先，当您查看数据库的属性时，在SSMS中看到的可用空间就是数据文件中的可用空间。您可以通过在数据库上运行以下命令来查看此文件，然后发现SSMS报告的可用空间是FileSizeMB与UsedSpaceMB之间的差异： SELECT DB.name, MF.physical_name, MF.type_desc AS FileType, MF.size * 8 / 1024 AS FileSizeMB, fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB, mf.name LogicalName FROM sys.master_files …
6
缩小日志文件不会减小大小
我有一个数据库，该数据库具有350 MB数据文件（.mdf）和4.9 GB日志文件（.ldf）。恢复模型设置为FULL。 当我尝试收缩日志文件时，它没有收缩。 我知道收缩数据库是不好的，不应该这样做。但是我仍然在尝试缩小日志文件。 我跑的时候 DBCC SQLPerf(logspace) 我发现日志大小为4932 MB，使用的日志空间为98.76％！ 然后我尝试了这个命令 USE <databasename>; DBCC loginfo; 现在几乎所有的VLF均为“状态2”，这意味着所有VLF都在使用中。 我尝试进行日志备份，然后缩小日志文件。缩小并没有减小尺寸。 我将恢复模型更改为SIMPLE并尝试再次缩小，但这也无济于事。 我检查了未结交易 DBCC opentran (database); 并发现现在没有任何交易打开。 是什么阻止了我缩小日志文件？我该如何解决？
6
如何防止索引重组期间事务日志变满？
我们有多台机器，我们已将事务日志的大小预分配为50gb。我尝试重新整理的表格大小为55-60 GB，但会不断增加。我要重组的主要原因是要回收空间和任何性能收益，因为这是额外的好处。 该表的碎片级别为30-35％。在其中一些计算机上，我收到“事务日志已满”错误，并且重组失败。事务日志大小达到48gb。有什么好方法可以解决这个问题？我们没有打开自动增量功能，我不愿意这样做。 我可以将日志大小增加到一个更大的值，但是随着将来表大小的增加，该值可能会不够。如果我要平等地增加日志大小，它也会破坏进行重组以回收空间的目的。关于如何有效应对这一问题的任何想法？由于无法接受数据丢失，因此无法使用批量模式。
2
SQL Server如何在将列更新为int时解决事务日志填满的问题
我有一个称为SQL Server 2005的表BRITTNEY_SPEARS_MARRIAGES，它具有以下列： MarrigeId tinyint, HusbandName varchar(500), MarrigeLength int 现在我有另一张桌子 BRITTNEY_SPEARS_MARRIAGE_STORIES StoryId int, MarriageId tinyint, StoryText nvarchar(max) 问题是我们想将MarrigeId列从中更新int为tinyint。我们只是觉得在说完一切之前，布兰妮将会有很多婚姻。 现在BRITTNEY_SPEARS_MARRIAGE_STORIES表中有1800万行（嘿，女孩遇到了一些问题），因此当我们进行更新时，事务日志已填满，SQL Server框消失了。 我们如何解决这个问题？ 无论如何都说“嘿，SQL Server，我将更新此列并将其扩大。在此SQL Server上相信我。请在尝试验证所有内容时不要填写事务日志？”
2
使用AlwaysOn可用性组时缩小事务日志
我们正在使用AlwaysOn Availability GroupSQL Server 2012的功能。每天在辅助数据库上进行常规的完整数据库备份和事务日志备份。 我在这里已经阅读了在主副本或辅助副本上执行事务日志备份的操作，会将这两个副本的事务日志标记为可重用。无论如何，事务日志备份的大小很大，可以使用收缩文件来减小它： 我已在本地还原数据库并执行收缩操作。日志文件大小减少到160 MB。 我的问题是我应该在哪个数据库上对事务日志文件（主，次或两者）执行收缩操作？ 我猜过去几年没有备份日志文件，因此它是如此之大。执行中，DBCC SQLPERF (LOGSPACE)我可以看到仅使用0.06%了该文件-对于我而言，保留如此大的日志文件毫无意义。在[sys].[database_files]我检查其max_size设置为-1与growth对65536，所以我想，当它需要更多的空间，它会得到。无论如何，为了防止将来的增长，我可以将其缩小到例如5％。我试图找到一些确认，我认为这样做不是一个坏主意。 实际上，备份（在数据库和日志文件上）仅在辅助数据库上执行，因此对它们执行收缩文件会更容易，但是主日志文件的大小也会减少吗？
5
完全备份和仅复制完全备份之间的区别
我在SQL Server中央线程中看到了完整备份会截断日志吗？完全备份不会截断日志： 否。完全备份或差异备份都不会截断事务日志。- 林恩佩蒂斯 否-一个完整的备份不会截断日志。- 乍得·克劳福德 那么完全备份和仅复制完全备份有什么区别？ 对于日志备份，有仅复制备份，可以防止在不截断日志的情况下破坏日志链。那么什么是仅复制完整备份？
1
为什么CHECKDB读取具有内存优化表的数据库上的事务日志文件？
tl; dr：为什么CHECKDB读取具有内存优化表的用户数据库的事务日志？ 似乎CHECKDB在检查我的一个数据库-特别是使用内存中OLTP表的数据库时，正在读取用户数据库的事务日志文件。 该数据库的CHECKDB仍会在相当长的时间内完成，因此我主要是对行为感到好奇。但绝对是此实例上所有数据库中CHECKDB的最长持续时间。 从Paul Randal的史诗《从各个角度看CHECKDB：完整描述所有CHECKDB阶段》中，我看到SQL 2005以前的CHECKDB 用于读取日志，以便获得数据库的一致视图。但是由于这是2016年，因此它使用内部数据库快照。 但是，快照的先决条件之一是： 源数据库不得包含MEMORY_OPTIMIZED_DATA文件组 我的用户数据库具有这些文件组之一，因此看起来快照不在桌面上。 根据CHECKDB文档： 如果无法创建快照，或者指定了TABLOCK，则DBCC CHECKDB将获取锁以获取所需的一致性。在这种情况下，需要排他数据库锁来执行分配检查，并且需要共享表锁来执行表检查。 好的，所以我们正在执行数据库和表锁定而不是快照锁定。但这仍然不能解释为什么它必须读取事务日志。那有什么呢？ 我在下面提供了一个脚本来重现该场景。它用于sys.dm_io_virtual_file_stats标识日志文件读取。 请注意，大多数情况下，它读取日志的一小部分（480 KB），但偶尔读取的日志则更多（48.2 MB）。在我的生产场景中，当我们运行CHECKDB时，它每天晚上在午夜读取大多数日志文件（约占2 GB文件的1.3 GB）。 这是到目前为止我通过脚本获得的输出示例： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:12:29.203 106 50545664 或这个： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:25:14.227 1 491520 如果我用常规表替换内存优化的对象，则输出如下所示： collection_time num_of_reads num_of_bytes_read 2018-04-04 15:21:03.207 0 0 为什么CHECKDB读取日志文件？尤其是为什么它偶尔会读取日志文件的很大一部分？ 这是实际的脚本： -- let's have …
2
SQL Server-增长数据库文件的最佳实践
我已经通过SQL Server 2008 R2中的数据收集器监视文件增长了两个星期。该数据库以每天约35（MB）的速度持续增长。该数据库尚未达到2 GB的初始大小。 数据库文件的自动增长设置为5MB，我想尝试另一种方法，所以我正在寻找建议和/或评论。 每个星期天晚上1:30 AM都会运行一项调优任务。该任务将： 检查数据库完整性 缩小日志文件–（可以，因为日志记录模式很简单） 收缩数据库 重组索引 重建索引 更新统计 清理历史 我想在每周调整计划中增加两个步骤： 如果使用的空间达到某个阈值或总大小，则将数据库文件增加500 MB。 如果使用的空间达到总大小的特定阈值，则将日志文件增加250 MB（缩小后）。 通过将增长负担放在离线时间，我希望通过减少重负载下的自动增长事件的数量来提高性能。 我有两个有关自动增长文件的问题。 放置文件增长步骤的最佳位置是在当前步骤之前还是之后？ 如果我使用ALTER DATABASE|MODIFY FILE来增大文件，那么如何确定是否SpaceUsedInFile >= (TotalFileSpace-@AllowanceThreshold)呢？
2
无法从完全备份还原SQL Server数据库，日志处理失败，数据库处于“还原”状态
我试图在我的PC的本地SQL Server Developer Edition 12.0.2000.8上建立数据库以用于开发目的。我有完整的数据库备份和单独的仅事务日志备份文件，这些文件是通过网络发送给我的。 尝试从完全备份还原时，经过一段时间（大约1个小时，数据库的大小约为270 GB），出现错误： System.Data.SqlClient.SqlError：处理数据库“数据库名称”的日志时发生错误。如果可能，请从备份中还原。如果没有备份，则可能有必要重建日志。（Microsoft.SqlServer.SmoExtended） 此后，数据库处于“正在还原..”状态。 我想运行类似的东西（从这个问题中得到它） ALTER DATABASE recovery_test_2 SET EMERGENCY; ALTER DATABASE recovery_test_2 SET SINGLE_USER; DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS; 针对它，但是自然地我不能，因为数据库处于'Restoring ..'状态。在数据库上重新启动还原过程会导致相同的错误消息，再次删除和还原也无济于事。 如何启动数据库并正常工作？事务的一致性对我来说并不重要。 SSMS自动生成的还原脚本： USE [master] RESTORE DATABASE [database_name] FROM DISK = N'D:\database_name.bak' WITH FILE = 1, MOVE N'database_name' TO N'D:\MSSQL\MSSQL12.MSSQLSERVER\MSSQL\DATA\database_name.mdf', MOVE N'database_name_index' …
2
为什么插入索引表时无法获得最少的日志记录
我正在测试在不同情况下的最小日志记录插入量，以及从我读过的使用TABLOCK和SQL Server 2016+将具有非聚集索引的INSERT INTO SELECT读取到堆中的最少记录，但是在我这样做的情况下，完整日志记录。我的数据库处于简单恢复模型中，并且在没有索引和TABLOCK的堆上成功获取了最少日志记录的插入。 我正在使用Stack Overflow数据库的旧备份进行测试，并使用以下模式创建了Posts表的副本... CREATE TABLE [dbo].[PostsDestination]( [Id] [int] NOT NULL, [AcceptedAnswerId] [int] NULL, [AnswerCount] [int] NULL, [Body] [nvarchar](max) NOT NULL, [ClosedDate] [datetime] NULL, [CommentCount] [int] NULL, [CommunityOwnedDate] [datetime] NULL, [CreationDate] [datetime] NOT NULL, [FavoriteCount] [int] NULL, [LastActivityDate] [datetime] NOT NULL, [LastEditDate] [datetime] NULL, [LastEditorDisplayName] [nvarchar](40) NULL, …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.