XenDesktop SQL Server Mirror事务日志维护

当使用SQL Server高可用性功能的时候,例如,XenDesktop站点数据库使用完整的事务日志记录模式下运行的数据库镜像。 通过完整的事务日志记录模式下运行的事务日志会增长过大,直到数据库空间被填满或事务日志空间大小被填满。如果事务日志文件不会被监视的,默认情况下,SQL Server的配置日志文件会自动增长。这将导致2个问题:

1、事务日志文件会占用大量的磁盘空间

2、事物日志增长填满数据库空间,导致数据库不可用。

因此Citrix建议定期备份日志文件。这可以通过调度作业或维护计划来完成。另外,可以使用SQLServer代理来监视日志使用的大小超过规定的阈值和运行备份作业。

我们可以这样做,在创建一个站点数据库镜像的时候,可以设定数据库日志的大小,比如设定日志的最大为4GB。新建一个警报,设置为日志备份到另一个文件时,该日志文件达到80%。就停止日志增长,利用脚本进行消耗空会话等垃圾信息,并且还停止它归零磁盘空间和拖延数据库。以达到截断事务日志的目的。

因此,对Mirror事务日志的维护,我们可以这样做:

根据Citrix的最佳实践,Citrix建议更改DDC之前的心跳设置来减少事务日志的增长过快。DDC之间的心跳默认是30秒通信一次,这一次的通信会被记录进事务日志里面,而且会产生大约6060字节的大小。

Citrix建议您使用数据库镜像时,更改默认的心跳超时。您可以通过更改注册表设置做到这一点。

这两个设置必须更改存储在HKEY_LOCAL_MACHINE \SOFTWARE\Citrix\ DesktopServer

这些设置是:

HeartbeatPeriodMs - 控制心跳的时间间隔。即多久通信一次。Citrix建议设置为10分钟。

MaxHeartbeatIntervalMs – 指定心跳最长时间可以不用通信,默认情况下,这是没有配置。

Citrix建议,如果使用完整恢复模式。那么建议设定一个固定大小的事务日志和一个怎对事务日志的SQL警告,这样,当事务日志达到50%或者80%时,事务日志自动备份并将以前的空数据释放掉。

使用固定大小的事务日志

给事务日志设定大小,这将阻止它填满磁盘空间。它还具有的优点就是在事务日志是预zero‘d并不会自动增长。

新建警报

登录数据库,选择“SQL Server代理 -> 新建 ->警报”。建立一个事件报警,本例中我们按数据库日志使用率超过80%就激活警报。

类型: SQL Server Performance Condition Alert

对象: MSSQL$CTXDB01:Databases

计数器: Percent Log Used

实例: XD

记数:高于80

选择左边的Response,勾选右侧的“Execute Job”,点击“New Job”。在“New Job”对话框中填入Job名称:XD-Log-Alert-Response-Job。点击左侧的“Steps”,点击右侧的“New…”

在弹出对话框里输入如下信息并点击OK。

Step Name: XD-Log-Alert-Response-Job-Step1

Type: Tnsact-SQLScript (T-SQL)

Database: XD

Command: Backup log [XD]to Disk = ‘C:\CitrixXenDesktopDB-Transactionlog.bak‘ with NOFORMAT,NOINIT,COMPRESSION, NAME = N‘Transcation Log backup‘, SKIP, NOREWIND, NOUNLOAD, STATS=10;

注:***的为XD数据库的名称。

  完成之后运行一下有无报错,无报错就证明设置成功,去C盘下看看是否创建了备份。如果备份出现,那么证明可以进行自动的数据库日志截断了,我们点击数据库进行切换,将备数据库换成主数据库,新建同样的警报,成功之后切回即可。

XenDesktop SQL Server Mirror事务日志维护

时间: 2024-10-12 20:43:49

XenDesktop SQL Server Mirror事务日志维护的相关文章

XenDesktop 5 SQL Server Mirror事务日志比较大的原因分析

在实施XenDesktop5项目过程中,发现XenDesktop5版本的数据库镜像事务日志很大,在XenDesktop4和XenApp版本中不存在该问题:于是我根据该现象探究XenDesktop5及以上版本镜像数据库事务日志为何如此之大以及我们今后实施的过程中该如何来维护这么庞大的数据库事务日志. 在XenDesktop解决方案中,对数据的处理是由专门的数据库来进行数据存储处理的,而对于数据库的高可用,有3种方式: SQL Mirror Virtual Machine HA(VMware FT)

SQL Server数据库事务日志序列号(LSN)介绍

原文:http://blog.csdn.net/tjvictor/article/details/5251463 ? ? 日志序列编号(LSN)是事务日志里面每条记录的编号. 当你执行一次备份时,一些LSN值就被同时存储在文件本身及msdb..backupset表中.你可以使用RESTORE HEADERONLY语法来从备份文件中获取LSN值. ? 注意:在SQL Server 2000中,有一列叫做DifferentialBaseLSN.但在SQL Server 2005中,相同的列名称变成了

如何读懂SQL Server的事务日志

简介 本文将介绍SQL Server的事务日志中记录了哪一些信息,如何来读懂这些事务日志中信息.首先介绍一个微软没有公开的函数fn_dblog,在文章的接下来的部分主要用到这个函数来读取事务日志. fn_dblog(@StartingLSN,@EndingLSN) [email protected]:表示起始的LSN号,如果为NULL值则表示从首日志记录开始查询. [email protected]:表示结束的LSN号,如果为NULL值则表示查询到尾日志记录. --需要注意的是我们平时所看到的L

SQL Server备份事务日志结尾(Tail)

原文:http://blog.csdn.net/tjvictor/article/details/5256906 ? 事务日志结尾经常提交数据库未备份的事务日志内容.基本上,每一次你执行事务日志备份时,你都在执行事务日志结尾的备份. 那为什么会这么设计呢?因为也许由于介质的损坏,当数据库已经不再可用时,麻烦就来了.如果下一个逻辑步骤正好就是要备份当前事务日志的话,可以应用这个备份来使数据库处于等待(Standby)状态.你甚至可以在数据库文件不可用的状态下使用NO_TRUNCATE来备份事务日志

SQL Server中事务日志管理的步骤,第5级:完全恢复模式管理日志

SQL Server中事务日志管理的步骤,第5级:完全恢复模式管理日志 作者:Tony Davis,2012/01/27 系列 本文是进阶系列的一部分:SQL Server中事务日志管理的步骤 当事情进展顺利时,无需特别注意事务日志的作用或工作方式.您只需要确信每个数据库都有正确的备份机制.当出现问题时,了解事务日志对于采取纠正措施很重要,特别是在需要紧急恢复数据库的时间点时!Tony Davis给出了每个DBA都应该知道的正确的细节级别. 在此级别中,我们将回顾在完全恢复模式下工作时进行日志备

十七周-SQL Server中事务日志管理的阶梯,级别5:以完全恢复模式管理日志

SQL Server中事务日志管理的阶梯,级别5:以完全恢复模式管理日志 By Tony Davis, 2012/01/27 http://www.sqlservercentral.com/articles/Stairway+Series/73785/ 该系列 文是SQL Server中"Stairway系列:事务日志管理的阶梯"的一部分 当事情进展顺利时,不需要特别意识到事务日志的作用或工作原理.你只需要确信每个数据库都有正确的备份机制.当事情出错时,对事务日志的理解对于采取纠正措施

SQL SERVER的事务日志

1 基本介绍 每个数据库都具有事务日志,用于记录所有事物以及每个事物对数据库所作的操作. 日志的记录形式需要根据数据库的恢复模式来确定,数据库恢复模式有三种: 完整模式,完全记录事物日志,需要定期进行日志备份. 大容量日志模式,适用于批量操作的数据库,可以以更压缩的方式处理日志,需要定期进行日志备份. 简单模式,也有日志文件,只是该模式下可以通过checkpoint自动重用virtual log file,所以日志文件会处于一直重复使用的过程,保持一定大小,但是,如果有一个事务启动,很久没有co

SQL Server数据库事务日志存储序列

原文 原文:http://blog.csdn.net/tjvictor/article/details/5251351 ? 如果你的数据库运行在完整或是批量日志恢复模式下,那么你就需要使用作业(job)来定期备份事务日志,保持你的事务文件大小处在一个可管理的范围.当你需要还原事务日志时,你就需要按照创建事务日志的顺序来恢复它们.你可以参考存在msdb..backupset表中的信息来确定还原文件的顺序,使用FirstLSN和LastLSN列的值作参考.当你备份时,这些备份信息就会存在backup

为什么SQL Server需要事务日志

为什么我们需要事务日志,可不可以删除或者不添加日志文件?答案是否定的,如果没有事务日志,你的数据库根本无法工作! 事务日志支持以下操作: 事务回滚 如果用户或程序使用了Rollback 语句或者是数据库检测到了失败的操作 . 这些日志文件就会被用来做回滚. 恢复未完成的事务 如果你在数据库发生错误时重新启动数据库服务器(服务),可能发现数据库处于恢复模式(In Recovery),这表明数据库正在回滚服务器(服务)重启之前未完成的事务,或者是继续执行那些已经写入到了日志文件却没有写入数据文件的事