我有一个来自 DBA 对我的一个数据库所做的跟踪的 .trc 文件。我的 PC 上没有安装 SQL 分析器工具，因此无法查看内容和分析跟踪日志。如何在我的 PC 上未安装 SQL 分析器的情况下读取此文件？
假设我有一个大的交易表，其中有一个日期字段和一个按升序排列在该字段上的索引。如果我从表中选择该字段并按相反顺序排序，它是否能够以某种方式反向使用该索引，或者它是否必须执行表扫描或其他一些效率较低的方法来访问这些记录并对它们进行排序？
我有一个应用程序，它与运行所需的 SQL Server 实例之间的连接间歇性中断。解决此类问题的好方法是什么？如果 SQL Server 故意断开连接，是否会在其中记录某种日志。
我知道应用程序和数据库之间的任何东西都可能导致连接丢失。我不认为这是客户端和服务器之间的网络连接问题，因为该应用程序是通过 Citrix XenApp 提供的，并且在同一主机上运行的所有其他实例在我看到的那个时间点或那个时间点附近都没有问题问题。
如果重要的话，这就是 SQL Server 2005 - 企业版。我的应用程序是基于 Visual FoxPro 的应用程序，通过 Citrix XenApp 提供给客户端机器。此问题很少见且是间歇性的（每天 1-2 次，超过数百个客户）。
此外，SQL Server 和 Citrix 在虚拟化服务器基础架构上运行。
TL;DR：如何解决间歇性数据库连接丢失问题？
更新：这是问题发生时应用程序错误日志中的消息：
Connectivity error: [Microsoft][ODBC SQL Server Driver]Communication link failure
我之前看到该消息的唯一时间是 SQL Server 完全过载以及实际网络连接本身出现问题（断开连接）时。在这种情况下，我认为这两种情况都不是。
我有一个使用 SQL Server (2008 R2) 数据库的应用程序，我们定期遇到应用程序的性能问题，这与我们的 15 分钟事务日志备份一致。
该应用程序控制对延迟敏感的工业机械，我们发现当系统发生高交易量时，应用程序的查询运行时间过长（短时间超过 5 秒）。这些查询只会在事务日志备份发生的同时运行缓慢，因此它似乎与事务日志备份相关。当系统正常运行时，我们的事务日志备份需要 2-4 秒，而当我们处于较重的负载下并且出现问题时，它们需要 6-7 秒。这显然足以导致一些 FIFO 消息调度队列在应用程序上被填满。
首先，我的印象是事务日志应该对应用程序非常透明，没有锁定或其他任何事情。如果我们在执行事务日志备份时看到数据库延迟，这是否表明某种 IO 争用正在被调用。改用 5 分钟事务日志备份节奏而不是 15 分钟这样的方式的利弊是什么？
磁盘后端是带有一堆 600 GB 10k SAS 驱动器的 NetApp FAS2220。DBA 确信这是一个应用程序问题而不是数据库问题，所以我需要知道如何解决这个问题，无论是应用程序问题还是数据库问题。
TLDR：事务日志备份期间在重负载下看到的数据库或应用程序延迟。如何排查和解决？