XenDesktop 5之痛---Database Transaction Log速增

简介:

单个虚拟桌面平均每小时间会产生62KB事务日志,平均交易记录计算方面如下:
虚拟桌面数*24小时*62KB
如:10个虚拟桌面:
10VDA*24*62K=14.8MB/day

解决方法:个人觉得仅能治标,不能治本。
把你的DataBase的Recovery Model(恢复模式)设置为"Simple"简单模式。



不足之处:Simple在数据库级别是不支持DB做“数据库镜像”的。

另外,需要频繁的对数据库事务日志进行备份。

备份模式:数据库完全备份+事务日志备份

当然,也不是没有一点办法,下篇文章将会讲述在XenDesktop5环境中,如果合理规划你的数据库、事务日志文件,在不同规模数据库文件及日志文件尺寸,以及如何设计数据库镜像等问题。

暂时给出解决方法:
1、log文件要设置以fixed-size. 
2、50%定期报警+备份+freeing it up 


本文转自 zhxhua 51CTO博客,原文链接:http://blog.51cto.com/virtualtop/518169 ,如需转载请自行联系原作者

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
【Unity3D 问题总结】Unity报错提示:Asset database transaction committed twice
也找不到代码哪里出错了,新建查空场景运行也会报错,真是离了个大谱! 然后打开UnityHub发现原来是许可证过期了!!
【Unity3D 问题总结】Unity报错提示:Asset database transaction committed twice
|
SQL 人工智能 JSON
深度解析Delta Transaction Log
深度解析Delta Transaction Log
深度解析Delta Transaction Log
|
SQL 存储 数据库
处理令人心烦的数据库事务日志 (SQL Server Transaction Log Files)
经常, 我们会被过快增长的数据库事务日志Transaction Log而困扰, 如果我们没有正确及时的处理, 可能会造成数据库交易无法进行, 服务器磁盘空间占光等问题. 在SQL Server的使用过程中, 我经常帮助用户和数据库的维护人员处理日志Transaction Log太大后造成的系统瘫痪的问题. 其实这个问题很容易避免. 今天我给大家分享下, 是什么造成了日志增长过大的问题. 和如何避免这种问题再次发生. 该文章的语句适用于SQL Server 2015 及其以后的版本 每一个数据库至少有两个文件: 一个是数据文件(Data file), 一个是事务日志文件(Transaction
1201 0
|
SQL Oracle 关系型数据库
WARNING: Too Many Parse Errors With error=911 When Running a JDBC Application Connected to an Oracle 19c database
WARNING: Too Many Parse Errors With error=911 When Running a JDBC Application Connected to an Oracle 19c database (
599 2