有没有办法从数据库端或数据库服务器端限制 SQL Server 可用的动态端口范围？我们的 SOP 是跨网络防火墙使用静态端口，而供应商在锁定其端口时遇到了麻烦。从理论上讲，如果我们允许动态范围 (49152–65535) 内的 1000 个端口跨过防火墙，我将如何限制 SQL Server 仅分配该范围内的动态端口？
据我所知，版本存储只会清理比最旧的活动事务更旧的版本。问题：如果有一个较旧的事务仍然处于活动状态，那么 SQL Server 是否会保留所有版本，不管数据库如何？
背景故事 - SQL Server 2005 SP4 Enterprise 托管大约 40 个数据库。TempDB 目前为 102 GB，版本存储约为 98 GB。托管在数据库实例上的应用程序之一有一个基于 sys.dm...database_transactions 的 40 天前的未处理事务。两个独立的大型数据库在上个月的使用量非常大，我们看到与这些操作一致的 TempDB 增长。我们预计会有一些增长。我们没想到它会继续增长。 问题：这两个独立数据库中存储在 TempDB 版本存储中的版本是否仍然存在，因为第三个独立数据库具有 40 天前的连接并显示打开的 transaction_state？
Perfmon 计数器：在我今天早上跟踪的几个小时内，版本存储不断增长。版本生成速率 AVG 约为 30 kb/s，版本清理速率为 0 kb/s。
为 TempDB 留下大量空间，所有用户数据库的总数据文件约为 300 GB，自上次重新启动以来，TempDB 的 8 个数据文件中的每一个平均每天增长 350 MB。此行为异常，调查发现大版本存储
评论问题的答案，以免评论部分长时间运行：
问：为什么在 tempdb 上自动增长？答： TempDB 设置为以我们发现在大多数情况下都合适的大小进行初始化。我们允许自动增长以处理异常的数据库活动。我们也监控汽车增长。
问：你怎么知道事务是活动的，而不仅仅是活动的连接？A：transaction_state 表示在 sys.dm_tran_active_snapshot_database_transactions 和其他内容中处于活动状态。活动监视器说每个连接都有 1 个打开的事务。
问：为什么您的应用程序如此愚蠢？A：它的第三方。此实例中的众多实例之一。我不知道行为是否异常，或者很容易修复。
解析度
阻止任何版本存储清理的开放事务，所以 Jon 是对的，版本存储清理是独立于数据库完成的。关闭有问题的事务允许版本存储清理开始。背后的当前理论来自 Jon Seigel
版本存储只能根据整个实例中最旧的活动事务清除版本，以支持同时跨多个数据库使用事务级快照隔离。
如果有人确定或可以证明这一点，请做
参考问题：find-transactions-that-are-filling-up-the-version-store
参考文档：
TempDB 2005 WP
Teratrax 调优 tempDB
Idera Demystify Tempdb