XenDesktop 7 SQL Mirror事务日志增长量的计算

对其事务日志的增长量有一下几方面来进行计算:

  • DDC心跳服务信息
  • 站点心跳服务信息
  • 虚拟机工作心跳服务信息

DDC心跳服务信息

每一台XD7 的DDC服务器都有10个WindowsService每隔30秒就进行一次心跳连接,以证明DDC服务器还活动并且正在运行。

每一个心跳是606 bytes,所以每一台DDC的心跳字节是6060bytes,一个小时是120个心跳,那么每一台DDC一个小时的心跳字节就是727200 bytes。

站点心跳服务信息

有一个用户的登录请求等会话信息是由一台DDC来进行处理的,所以这种单独的站点服务所产生的字节不会生成双份,我们单独在这里进行计算;

Monitor: 6 site services = 384 header + 6 * 190 = 1524 bytes

Delegated Admin: 1 site service = 384 header+ 1* 190 = 574 bytes

Broker: 16 site services = 384 header + 16 *190 = 3424 bytes

Hosting: 1 site service = 384 + 190 = 574bytes

Desktop Update Manager: 1 site service = 384+ 190 = 574 bytes

Config Logging: 2 site services = 384 +2*190 = 764 bytes

AD Identity: 1 site service = 384 + 190 =574 bytes

由此我们可以计算出,一次Site Service请求消耗的心跳是8008 bytes,那么每一个小时就是960960 bytes,

虚拟机工作心跳服务信息

对于XD7的2中模式(HSD和HVD)来说,每个虚拟机工作心跳是每5分钟进行一次,心跳的大小为1150bytes,每一个工作心跳一个小时大约为13800 bytes。

综上所述,我们来总结一下

DDC心跳=DDC的数量 乘于727200 bytes;

站点心跳=960960bytes;

虚拟机工作心跳=虚拟机的数量 乘于 13800 bytes;

因此总空闲的增量=“DDC心跳”+“站点心跳”+“虚拟机工作心跳”

例如,对于一个10000台VM的VDI环境中,有2的DDC,最低的增长将是:

DDC心跳=2*727200字节=1454400字节

站点心跳=960960字节

虚拟机工作心跳=10000*13800字节=138000000 字节

每小时总空闲增长=1454400+960960+138000000=140415360字节或=134MB每小时

那么每天增长3.2GB。

英文原文:

http://blogs.citrix.com/2014/05/16/xendesktop-sql-transaction-log-usage/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+CitrixBlogs+%28Citrix+Blogs%29

XenDesktop 7 SQL Mirror事务日志增长量的计算

时间: 2024-10-13 15:36:38

XenDesktop 7 SQL Mirror事务日志增长量的计算的相关文章

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

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

XenDesktop SQL Server Mirror事务日志维护

当使用SQL Server高可用性功能的时候,例如,XenDesktop站点数据库使用完整的事务日志记录模式下运行的数据库镜像. 通过完整的事务日志记录模式下运行的事务日志会增长过大,直到数据库空间被填满或事务日志空间大小被填满.如果事务日志文件不会被监视的,默认情况下,SQL Server的配置日志文件会自动增长.这将导致2个问题: 1.事务日志文件会占用大量的磁盘空间 2.事物日志增长填满数据库空间,导致数据库不可用. 因此Citrix建议定期备份日志文件.这可以通过调度作业或维护计划来完成

Sql Server 事务日志

Sql Server事务日志文件是数据库文件的重要组成部分,事务日志主要用来存放数据库的修改记录.数据库为了得到更高的写入效率和性能,同时保证ACID特性,数据在写入时,会将更新先写入事务日志,因为事务日志是连写的,所以写事务会比较快.简单来说,顺序写入时,磁盘的磁头会保持在一定的区域内连续写入,而数据写入数据文件时,有随机性,磁盘的磁头移动消耗的时间要比数据写入日志文件时多. Sql Server对于事务日志文件的管理,是将日志文件在逻辑上分成若干个文件(VLFS),方便管理. 创建一个1M的

如何截断SQL Server2008+事务日志空间

SQL数据库事务日志记录数据库的任何更改,用户可回滚事务日志来恢复数据,但随着数据库使用时间变长,日志文件也会变得很大. 若要避免数据库的事务日志被填满,例行备份至关重要.做了日志备份后,会释放不活跃的VLF,增加日志的可用空间.但默认情况下备份日志,其日志文件的大小并未变化,如下图 备份前,总大小24.13MB 备份后,总大小仍然为24.13MB,但已用空间占比从93.1%降至11.0% 也就是,已使用日志空间是减小了,但未使用日志空间并未释放.其实,如果磁盘空间足够的话,可以不用收缩空间 那

SQL Server事务日志分析

SQL Server事务日志分析 fn_dblog()和fn_dump_dblog()函数介绍 SQL Server有两个未公开的函数fn_dblog()和fn_dump_dblog()非常有用并且提供的信息量很大.你可以使用这些函数来获取100多列大量的有用信息. fn_dblog()用于分析数据库当前的事务日志文件,它需要两个参数,分别为事务开始LSN和结束LSN,默认为NULL,表示返回事务日志文件的所有日志记录. 例如: SELECT * FROM fn_dblog(null,null)

Sql Server 事务日志(三)

SQL server的日志文件会随着数据修改的增加而变大,在处理日志文件时,我们常用的方式是将日志截断,并收缩. Backup log databasename to disk='' dbcc shrinkfile(databasename_log) 当然,如果磁盘空间紧张,可以将恢复模式改成‘simple’的方式使日志截断,然后再收缩日志 alter database test set recovery simple; DBCC shrinkfile(test_log) alter datab

人人都是 DBA(VI)SQL Server 事务日志

SQL Server 的数据库引擎通过事务服务(Transaction Services)提供事务的 ACID 属性支持.ACID 属性包括: 原子性(Atomicity) 一致性(Consistency) 隔离性(Isolation) 持久性(Durability) 事务日志(Transaction Log) 事务日志(Transaction Log)存储的是对数据库所做的更改信息,让 SQL Server 有机会恢复数据库.而恢复(Recovery)的过程就是使数据文件与日志保持一致的过程.

翻译:SQL Server事务日志管理的阶段,1级:事务日志概述

原文链接:http://www.sqlservercentral.com/articles/Stairway+Series/73775/ 原文作者: Tony Davis, 2013/10/30 (第一次出版: 2011/06/17) 该系列 本文是SQL Server中"Stairway系列:事务日志管理的阶梯"的一部分 当事情进展顺利的时候,没有必要特别意识到事务日志的作用或工作原理. 你只需要确信每个数据库都有正确的备份机制. 当事情出错时,对事务日志的理解对于采取纠正措施是非常

如何通过trn日志文件恢复SQL Server 事务日志 还原 备份

首先恢复时一个完整的备份,但在完整的备份里一定要选择with nonerecovery(企业管理器里选项中是第2项) sql 语句是: restore database mydata from disk = 'c:\temp\movedb.bak'  with norecovery 这时数据库就会变成恢复模式,这样你就可以一条一条的把trn文件添加进行恢复了. 语句是: restore log Mydata from disk =    "D:\Program Files\Microsoft S