Questions tagged «transaction-log»

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

4
缩小SQL Server 2008 R2后手动设置日志文件大小
目前正在成为某种非自愿的DBA，确实需要一些帮助。 我们在完全恢复模式下拥有40GB的数据库，未配置日志备份，并且拥有84GB的巨大日志文件。到目前为止，我要挽救这种情况的计划是在数据库上运行完整的日志备份，缩小日志文件，并发起维护计划，以每晚在数据库备份的情况下运行日志备份，以帮助使其处于受控状态。 我的问题是我不希望日志文件缩小到什么都不会花在星期一的第一个早晨不断增长。我对文件应该是什么（大约是数据库的20％）进行了粗略估计，并希望从一开始就进行设置，以确保尽可能多的连续空间。这仅仅是在数据库属性->文件下更改“初始大小”的一种情况吗？我猜想数据库是否需要脱机才能发生这种情况？ 提前致谢
1
无法截断事务日志log_reuse_wait_desc-AVAILABILITY_REPLICA
今天早上，我被我们的数据库之一的事务日志已满警报惊醒。该服务器是Alwayson群集，也是事务复制订阅服务器。我检查了log_reuse_wait_desc，它显示了logbackup。某人四天前不小心禁用了日志备份作业，我重新启用了日志备份作业，日志被清除。从凌晨4点开始，我想我将在那天早上晚些时候去上班，因为日志已经增长到400GB，所以请顺便去。 上午10点-我在办公室，我在缩小之前检查日志使用率，大约是16％。我很惊讶，检查显示复制的log_reuse_wait_desc。我很困惑，因为这是一个复制订户。然后，我们看到该数据库已启用CDC，并认为这可能是原因，因此禁用了CDC，现在log_reuse_wait_desc显示了AVAILABILITY_REPLICA。 同时，日志使用量仍在稳定增长，目前为17％。我检查了Alwayson仪表板，并检查了已发送和重做队列，两者实际上都为零。我不确定为什么日志重用显示为AVAILABILITY_REPLICA并且无法清除日志。 知道为什么会这样吗？
1
按计划备份和截断事务日志的最佳方法
我不是DBA，但是无论如何，我必须戴上DBA的帽子，并在SQL Server实例上设置维护计划。 因此，一段时间以来，我一直在SSIS过夜过程中运行“ 执行SQL任务”以执行备份-基本上运行master.dbo.xp_create_subdir以确保目标文件夹存在，然后运行BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT。 每当该任务失败时，其余过程都会中止，并且我会收到通知，并于第二天早上来通知事务日志的驱动器已满，因此我将手动截断它们并继续前进。 ..直到故事重演，并且事务日志再次超出了可用磁盘空间。 “手动截断”脚本如下所示： use Staging; alter database Staging set recovery simple alter database Staging set recovery full dbcc shrinkfile ('Staging_log', 0, truncateonly); go 因此，我对此感到厌倦，因此决定尝试正确地做事，并按照此处的步骤创建一个实际的维护计划： 问题是，我之前从未做过此事，所以我有几个问题： 像这样备份事务日志会自动截断它们，还是我需要做其他事情？ 可以同时运行数据和事务日志备份吗？如果没有，那么执行此操作的正确方法是什么？ 备份文件将在一夜之间被另一个过程获取，该过程将捕获服务器上的所有文件并将它们存储在其他位置-2天后使备份集过期是个好主意吗？我是否需要使它们全部过期？ 清理任务分别删除的子文件夹下的“旧” .bak和.trn文件G:\Backups。那有意义吗？ 最好在SSIS中执行此操作，以便在备份失败时/我可以在ETL中失败吗？还是我的ETL流程应该在乎？ 抱歉，如果一个帖子中有太多问题，如果需要，我将编辑并询问多个问题-我认为它们都是紧密相关的。
1
进行还原时是否尾日志备份？
通常，在将数据库从生产服务器还原到非生产服务器时，我将使用WITH REPLACE选项，就像我忘记了有关未备份尾日志的错误时一样。 根据MSDN，在恢复之前，我确实应该备份我的尾日志： 如果数据库处于联机状态，并且您打算对数据库执行还原操作，请先备份日志尾部。为避免在线数据库出错，必须使用BACKUP Transact-SQL语句的…WITH NORECOVERY选项。 我这样做的方式有哪些危险或不利之处？为什么备份尾部日志对我来说是最有利的？ 我正在使用SQL Server 2008R2，但我假设此查询与SQL Server的大多数较新版本相关，因此最初并未对其进行标记。
3
切换到简单恢复时的事务日志维护
背景： 我最近继承了450多个数据库中的50多个SQL Server。每晚备份大约为8TB，不用说，我们使用的磁盘空间比我们想要的要多。所有数据库均设置为“完全恢复”，并且从未备份过事务日志。我已经遍历了所有SQL Server，并确定了低优先级的服务器，这些服务器仅需要每晚进行备份并且可以接受一天的数据丢失。 题： 我将许多低优先级数据库SIMPLE从切换到恢复模式FULL。现有事务日志会被截断吗（创建检查点时）？一些现有的事务日志为50-100GB；为了继续前进，确定我应该缩小到什么范围的最佳方法是什么？我显然不想让它们那么大。还是随着时间的推移它们会自行收缩（我不认为会收缩）？
1
我可以在镜像数据库上收缩事务日志文件吗？
这是先前问题的后续问题，该问题为何我无法缩小主体数据库上的日志文件。 简而言之，我设置了数据库镜像，但是忘记确保备份事务日志的作业再次运行，并且事务日志增长到将近60GB。 由于已建立镜像，因此在镜像服务器上重复进行了此大小增加，最终占用了所有磁盘空间，并使镜像数据库不可用。 每这一问题有关镜像数据库事务日志的维护，你不能备份日志上镜，但是当在特别要求评论有关如何收缩镜像数据库上一个杂草丛生的日志文件，一个注释中留下了 一种方法是将故障转移到镜像数据库并在该数据库上进行收缩。在非生产环境中进行彻底测试，以确保它具有您想要/期望的行为。 这似乎表明可能还有其他方法可以将镜像文件收缩到镜像上，并且这种方法在生产服务器上不一定是安全的。 有没有办法安全地缩小数据库镜像上的事务日志文件？
2
SQL Server“创建数据库”语句。如何继承自动增长设置？
我正在使用SQL Server 2008 R2，并通过连续部署来创建数据库。 在我们的系统中，SQL Server中的默认1Mb / 10％自动增长设置无法很好地处理我们的数据。特别是因为我们有一个遗留应用程序，使我们无法太多更改架构。我们希望在实例级别配置数据库设置，以便我们可以针对分阶段部署进行更改。 我已经在几个地方阅读过，新数据库的默认设置基于'model'的设置，但是看来这只能通过单击SQL Management Studio UI中的新数据库来实现，而不是通过脚本（例如CREATE DATABASE [MyDb]）来实现。 msdn.microsoft.com/zh-CN/library/ms186388(v=sql.105).aspx sqlservercentral.com/Forums/Topic1065073-391-1.aspx /programming/8828557/possible-to-configure-database-autogrowth-settings-at-the-instance-level/8828604#comment15586568_8828604 有人真的可以使用它来创建脚本吗？还有其他方法可以为每个服务器实例设置自动增长吗？
3
在某些表上禁用日志记录
我正在使用SQL Server2005。我有两个包含聚合信息的表。信息不断更新，每天生成近5GB的日志数据。（这比整个数据库要大！）我想禁用对这些表的日志记录，因为回滚并不是必须的。但是，我想继续登录数据库中的其他表。 是否可以禁用数据库中某些表的日志记录？如果不是，是否可以将两个表放在相同的架构中，然后禁用该架构的日志记录？将两个表移到一个单独的数据库并在那里禁用日志记录的唯一选择是吗？ 更新： 我想我会解释为什么我真的不需要在这些表上记录活动。 这两个表充满了GPS数据，因此它们变得很大。第一个表格是从该字段的六个Android表格中捕获原始位置。每个平板电脑的新数据每5-10秒就会出现一次。然后将该信息汇总为locationA，locationB，travelTime。目标是根据实际驾驶数据最终使所有位置之间的行驶时间最短。该数据仅适用于一个小城市，并且只能精确到小数点后四位，因此是可管理的。但是，随着新的原始数据的到来，需要更新的行进时间变慢，并且需要插入新的行进时间。 原始数据汇总后，将被清除。我们不会退缩到更长的旅行时间，所以这就是为什么在这些表中回滚没有太大关系。
3
将事务日志文件放在单独的驱动器上是否会对性能产生好处？
有许多博客文章和最佳实践文章赞扬将SQL Server数据文件放在一个硬盘驱动器上并将事务日志放在另一个硬盘驱动器上的优点。给出的原因是，数据库文件将经历随机读写，而事务日志将仅具有顺序写。 但是，如果您有数百个数据库怎么办？将数百个事务日志文件放在单独的磁盘上，是否会对性能产生真正的好处？如果要写入多个事务日志，那么我认为事务日志的写入将与数据库写入的一样随机。
3
RAM或物理文件中的事务日志？
我是交易的初学者，只是有关交易日志的问题。我们知道在提交事务时，更改将写入事务日志，但是事务日志是否在RAM或物理文件中？如果它在RAM中并且发生系统故障时，显然RAM将被重新擦除，因此我们丢失了事务信息，那么如何恢复提交？
1
执行跨数据库事务时，信息存储在哪个事务日志中？
给出以下代码段： -- error checking omitted for brevity begin tran exec database1..my_stored_procedure exec database2..my_other_stored_procedure if (@@error <> 0) rollback commit 交易信息将插入到哪个数据库的交易日志中？ 我希望两个日志都可以获取所有数据，因为如果您尝试重播database1的事务日志就没有任何意义，它只会影响该数据库。我也希望您将无法database1在database2不存在的服务器上重播的事务日志，反之亦然。 ..但我愿意接受更正！
3
备份数据库是否会缩小事务日志的大小？
我正在尝试收集有关SQL数据库的一些知识，并且对事务日志文件（LDF）有一些疑问。 首先，在创建数据库时，必须为数据库和日志文件定义初始文件大小。从我的看到，一旦在磁盘上创建了文件，它们将具有指定的大小，而不管数据库中是否有实际数据或是否有任何事务（日志）。 我的理解是备份数据库： 截断事务日志，并 缩小尺寸 通过“清空”磁盘中的日志来清除磁盘上的LDF文件。 现在，由于日志文件的大小似乎固定，因此我似乎无法正确理解。我的实际问题是这样的： 截断日志实际上对日志文件（LDF）有什么作用？该过程应防止磁盘装满。 如果我对某些概念的理解不正确，请纠正我。 谢谢！
2
为所有用户创建的数据库设置简单的恢复模式并收缩日志文件
希望您能指出正确的方向。我不是T-SQL的经常用户，但是我做了一些Google搜索，并在下面找到了脚本。我纠正了一下脚本。 我希望脚本执行以下操作： 选择除系统数据库之外的所有数据库。 要将恢复设置为简单。 收缩每个db（.ldf）的日志文件，系统db除外 剧本： USE MASTER declare @isql varchar(2000), @dbname varchar(64) declare c1 cursor for select name from master..sysdatabases where name not in ('master','model','msdb','tempdb','ReportServer','ReportServerTempDB') open c1 fetch next from c1 into @dbname While @@fetch_status <> -1 begin select @isql = 'ALTER DATABASE @dbname SET RECOVERY SIMPLE' select @isql …
2
当物理事务日志文件是镜像中的主体时，如何缩小物理事务日志文件？
我们在周末设置数据库镜像，但是忘记重新启用备份事务日志的作业。今天早上我来的时候，事务日志已经膨胀到58GB，并占用了大部分驱动器空间。 我将事务日志手动备份到磁盘以使数据库再次运行，但是运行DBCC SHRINKFILE似乎并没有减小事务日志文件的物理大小。 DBCC SHRINKFILE (N'MyDatabaseName_Log', 1000) 如果我使用以下命令查看日志使用情况 DBCC SQLPERF(LOGSPACE) 我可以看到仅使用了当前日志的22％ 数据库名称日志大小（MB）使用的日志空间（％）状态 MyDatabaseName 55440.87 22.38189 0 如果我log_reuse_wait_desc在sys.databses中签出，则看到的唯一记录是DATABASE_MIRRORING，因此我猜测镜像在为什么日志文件的物理大小不会缩小的过程中发挥了作用？ SELECT log_reuse_wait_desc FROM sys.databases WHERE name = N'MyDatabaseName'; 我还注意到我的主要数据库镜像状态为Suspended，并且尝试立即恢复它失败，并出现以下错误： 数据库'MyDatabaseName'的远程镜像伙伴遇到错误5149，状态1，严重性25。数据库镜像已被挂起。解决远程服务器上的错误并恢复镜像，或者删除镜像并重新建立镜像服务器实例。 镜像服务器上的错误日志也包含此错误，但是还包含有关日志文件驱动器已满的错误 尝试扩展物理文件时，“修改文件”遇到操作系统错误112（磁盘上没有足够的空间。）。 和 F：\ Databaselogs \ MyDatabaseName_1.ldf：遇到操作系统错误112（磁盘上没有足够的空间。）。 主体服务器在日志文件驱动器上有60GB（此处托管了其他数据库），而镜像服务器只有45GB。 备份日志文件使数据库再次可用，但是我还想减小磁盘上物理日志文件的大小，并恢复镜像。 如何在不损害镜像或备份链的情况下缩小物理事务日志文件的大小？ 我正在运行SQL Server 2005
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.