在实施XenDesktop5项目过程中，发现XenDesktop5版本的数据库镜像事务日志很大，在XenDesktop4和XenApp版本中不存在该问题；于是我根据该现象探究XenDesktop5及以上版本镜像数据库事务日志为何如此之大以及我们今后实施的过程中该如何来维护这么庞大的数据库事务日志。
在XenDesktop解决方案中，对数据的处理是由专门的数据库来进行数据存储处理的，而对于数据库的高可用，有3种方式：
- SQL Mirror
- Virtual Machine HA（VMware FT）
- SQL Cluster
根据我的探究， XenDesktop 4 及以上的版本和XenDesktop 5 的系统架构不同，是导致这2个版本Mirror事务日志不一样的原因。
在XenDesktop 4 版本中，属于Citrix IMA系统架构，MetaFrame XP是第一个使用思杰的独立管理架构（ IMA ）的Citrix产品。MetaFrame XP即是XenApp的前身。在IMA架构中，运行着2个协议，一个ICA，一个IMA，ICA协议用于远程连接桌面和应用，而IMA协议则用于执行功能，如许可和服务器负载的更新，所有的这些都发生在服务器与服务器之间，是隐于幕后的通信协议。因此可以这样说，ICA协议是该架构的前端显示协议，IMA是后端的幕后协议。此外，IMA服务与Citrix管理控制台进行通信，允许管理员管理和配置服务器。
那么IMA架构数据库的Mirror事务日志有何关系呢？
接下来我们就来探究下Citrix的IMA架构：
这就是XenDesktop 4的架构图
在图中我们会发现，每一台主机都会有LHC这么一个东西，LHC就是本地主机缓存的意思，在IMA架构中，XD4及以前的版本和XenApp都是典型的ＩＭＡ架构的产品。IMA因为有这么一个LHC的存在，所有他的数据库事务日志不大。
在产生的数据中，分为静态的信息和动态的信息。
静态配置信息会存储在DB数据库和LHC（Local Host Cache）中，包括Farm 配置信息，策略配置，用户和桌面组、桌面组和虚拟机的绑定关系等静态信息。
动态会话信息会存储在本地的LHC中，不会更新到DB中。LHC即Imalhc.mdb（本地的磁盘文件），是一个Access database。动态信息包括虚拟机的注册状态、Session状态，license利用率等动态信息。
而数据库的事务日志大部分是动态的会话信息，XenDesktop 4由于架构的原因，动态的会话信息不回写入数据库里面，之写入本地的主机缓存里，所以XenDesktop 4及以前的版本和XenApp数据库事务日志不回很大。
那么为什么XenDesktop 5的事务日志很大呢？
XenDesktop 5 不再将 IMA 数据存储用作存储配置信息的中央数据库， 而是使用 Microsoft SQL Server 数据库作为配置信息和会话信息的数据存储。而且XenDesktop 5属于Citrix的FMA架构。FMA架构就没有本地主机缓存了，所有的数据信息全部写入数据库里面，包括静态的信息和动态的信息。
由以上的描述，我们知道XD4和XD5在结构上发送了较大的变化，由IMA管理架构变成了FMA管理架构，如果说XD5只是对FMA管理架构的一种尝试的话，那么XD7就是完全的认同了这样一种管理架构，在新版本的XD7中，XenApp和XenDesktop融合在一起，Citrix完全的抛弃了XenApp和XD4的这种IMA管理架构，全部转向FMA管理架构。
而由此可知，Mirror数据库事务日志从XD5开始比较大的原因就在于：FMA管理架构没有本地主机缓存（LHC），所有的数据信息都会写入到数据库中，通过数据库内保存的数据进行同步。包括用户对桌面的每一次登录信息、断开连接的会话信息都会写到事务日志里面，而不像IMA架构那样，不会写入到数据库里，而是写入到本地主机缓存里边。
写到这里，我想我有必要补充，事务日志是什么？SQL Server使用事务日志来存储修改数据库。这是对数据库连续不断的类似于数据流一样的对数据库的存储和修改。一般我们的数据库文件如果损坏了话，通过事务日志就可以对它进行恢复。而在数据库高可用解决方案中，数据库镜像的高可用方式就靠事务日志来进行维系。
由此我们大致明白了做数据库Mirror时为什么数据库日志那么大了吧，也明白了为什么XenApp的Mirror没有XenDesktop的Mirror事务日志那么大原因了吧。都是基于其架构设计的原因。
XenDesktop 5 SQL Server Mirror事务日志比较大的原因分析