Sql server 在SQL Server上长时间运行（约10分钟）存储过程有多危险（性能/资源）？

我正在研究在SQL Server上部署一些资源不密集但已知运行时间较长的存储过程的想法。通过长跑，我的思维范围是10分钟

它们运行时间长但不占用资源的原因是，它们通过C#SQLCLR代码访问外部系统，而这些外部系统的性能是导致性能问题的原因，SQL Server将大部分时间都花在等待外部系统的结果上

我100%意识到，在SQL Server上执行此类操作可能是“不推荐”的，类似PowerShell的操作更合适，但我希望将问题限制在这样做是否实际上对SQL Server的整体性能/资源有害，如果是，有害程度如何

在我的场景中，总体服务器负载不会很高，可能最多会运行20个其他查询，其中大多数是针对SQL表的正常查询-最多可能有3个用户运行其中一个慢速查询

因此，我的问题是：在SQL Server上提供此类查询是否存在任何真正的风险，是否有任何与阻塞、连接等相关的问题需要注意

编辑：

为了便于讨论，让我们假设它运行在一个4CPU、8GB内存箱上

这样做的动机（从业务角度）是，它有助于将SQL用作访问多个异构外部系统的公共抽象层，从而消除了对众多最终用户安装各种本地专有客户端软件的依赖，或者对所涉及的各种系统的晦涩调用语法有所了解

我真的希望人们不要因为一个人是否“应该”这样做的哲学观点而投票结束这个问题。能够使用SQL Server实现这一点在经济上是有价值的。但是，如果它实际上在技术上是危险的，那么不可能描述一些危险的细节吗

编辑2 在主持人的要求下，我将提供一些额外的细节，以缩小我所要求的范围

情景：

我的公司环境中有20种不同的系统。这些系统中的每一个都有一个专门的API，需要安装软件来访问系统，并且需要具备正确语法的专门知识，以便查询系统中的数据。每个系统都有一个可以通过C访问的API

由于公司内的每个人都非常熟悉SQL server，因此为所有这些系统提供行业标准的API在经济上是有利的，因为它消除了在每个客户端桌面上安装特殊软件的要求，以及最终用户学习查询每个不同系统的复杂语法的要求。在这种情况下，常见的API是SQL Server存储过程（实现为C#SQL CLR存储过程，但对调用方完全透明）。这些过程的接口（参数）很简单，并且有很好的文档记录，并且完全将用户与底层系统调用实现和语法的复杂性隔离开来

对任何给定基础系统的实际调用的执行时间范围从少于1秒到长达10分钟，具体取决于被调用的特定过程和系统。在这个SQL过程中没有额外的昂贵处理，长时间的运行只是等待远程系统完成查询并返回结果的过程

典型的结果集大小为1到50000行，平均大约为1000行。非常大的结果集大小为5MB

在任何给定时间，此服务器上最多可能有25个并发执行的查询处于活动状态，其中至少有20个查询将执行“常规”TSQL存储过程，读取本地数据库中的常规SQL server表，而其中最多有5个查询可能是这些“特殊”查询访问外部系统的C#SQL CLR查询

所有查询都是读取，没有写入，并且不执行事务性的多命令查询

25个最大并发查询x 5 MB最大结果集大小=在任何给定时间内存中最多125 MB的“纯数据”，加上任何附带的SQL Server“开销”

运行此服务器的典型服务器是运行SQL server 2012的4CPU、8GB内存箱。如果我愿意的话，我有极大的余地来大幅增加这个盒子的威力——在这种情况下没有预算限制

那么，考虑到这个场景，是否有人知道这个实现不起作用的任何具体的技术原因，或者关于可能出现一些技术限制的合理推测

顺便说一句……我不知道是否有人听过Jeff和Joel在SO首次开发时做的StackoverFlow播客，但这个问题多少让人想起Joel讲述的关于在SQL Server中做一些不寻常的事情的轶事（有一个非常具体但有效的原因），所有的答案基本上都是“你不应该那样做！”：）

可能感兴趣人士的参考资料：

同样，我当然意识到这个问题非常不寻常，但如果从纯技术角度考虑，我认为它不应该有那么大的争议

Mods：请告诉我这些额外的细节是否足以减少误解。我真的希望这个问题能够保持开放，因为它是善意的、合法的，并且涉及我认为非常有趣的问题