SQL Server 2008 中 CLR 中的线程

发布于 2024-12-07 07:45:14 字数 326 浏览 0 评论 0原文

我有一个在 SQL Server2008 下运行的 CLR 进程。它构建了多个表数据的缓存以保存在静态类中以供其他调用稍后使用。

我的问题是,我可以通过生成线程来加载缓存中的每个数据集/表来改进加载此缓存的过程吗?

我过去一直回避这一点,因为各种帖子建议将线程管理留给 SQL Server。不过我真的可以加快这个过程。 目前,它是加载每个数据集的顺序过程。如果我可以同时运行这些,那就非常方便了。我在 CLR 之外多次完成此过程,以获得一些额外的性能提升。

非常感谢任何想法帮助提示。

I have a CLR process which runs under SQL Server2008. It builds a cache of several tables data to hold in a static class for use later by other calls.

My question is could I improve the process of loading this cache by spawning threads to load each data set/ table in my cache?

I've steared clear of this in the past as various posts have suggested leave the thread management to SQL Server. However I could really do with speeding up this process.
Currently its a sequential process to load each data set. If I could run these concurrently it would be very handy. A process I've done many atime outside of the CLR cover to get some extra performance gains.

Any ideas help tips very much appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

分开我的手 2024-12-14 07:45:14

您可以使用线程,但它们必须正常工作。否则您将失去使用它们的好处。

来自CLR 主机环境

SQL Server 和 CLR 的工作原理一起

本节讨论 SQL Server 如何集成线程,
SQL 的调度、同步和内存管理模型
服务器和 CLR。特别是,本节检查
根据可扩展性、可靠性和安全性目标进行集成。
SQL Server 本质上充当 CLR 的操作系统
它托管在 SQL Server 内部。 CLR 调用低级例程
由 SQL Server 实现的线程、调度、同步、
和内存管理。这些与其余的原语相同
SQL Server 引擎使用。该方法提供了几种
可扩展性、可靠性和安全性优势。

可扩展性:通用线程、调度和同步

CLR 调用 SQL Server API 来创建线程,两者都用于运行用户
代码并供其自己的内部使用。为了实现之间的同步
在多个线程中,CLR 调用 SQL Server 同步对象。
这允许 SQL Server 调度程序在某个任务发生时安排其他任务
线程正在等待同步对象。例如,当
CLR启动垃圾收集,其所有线程等待垃圾
收集完成。因为CLR线程和同步
它们正在等待的对象对于 SQL Server 调度程序、SQL 来说是已知的
服务器可以调度正在运行其他数据库任务的线程
涉及 CLR。这也使 SQL Server 能够检测死锁
涉及 CLR 同步对象获取的锁并使用
消除死锁的传统技术。

托管代码在 SQL Server 中抢占式运行。 SQL Server 调度程序
能够检测并停止未产生的线程
大量的时间。将 CLR 线程挂钩到 SQL 的能力
服务器线程意味着 SQL Server 调度程序可以识别
CLR 中的“失控”线程并管理它们的优先级。如此暴走
线程被挂起并放回到队列中。线程是
多次被标识为失控的线程不允许运行一段时间
给定的时间段,以便其他执行工作人员可以运行。

You can use threads, but they must behave. Otherwise you'll lose the benefits of using them.

From the CLR Host Environment

How SQL Server and the CLR Work Together

This section discusses how SQL Server integrates the threading,
scheduling, synchronization, and memory management models of SQL
Server and the CLR. In particular, this section examines the
integration in light of scalability, reliability, and security goals.
SQL Server essentially acts as the operating system for the CLR when
it is hosted inside SQL Server. The CLR calls low-level routines
implemented by SQL Server for threading, scheduling, synchronization,
and memory management. These are the same primitives that the rest of
the SQL Server engine uses. This approach provides several
scalability, reliability, and security benefits.

Scalability: Common threading, scheduling, and synchronization

CLR calls SQL Server APIs for creating threads, both for running user
code and for its own internal use. In order to synchronize between
multiple threads, the CLR calls SQL Server synchronization objects.
This allows the SQL Server scheduler to schedule other tasks when a
thread is waiting on a synchronization object. For example, when the
CLR initiates garbage collection, all of its threads wait for garbage
collection to finish. Because the CLR threads and the synchronization
objects they are waiting on are known to the SQL Server scheduler, SQL
Server can schedule threads that are running other database tasks not
involving the CLR. This also enables SQL Server to detect deadlocks
that involve locks taken by CLR synchronization objects and employ
traditional techniques for deadlock removal.

Managed code runs preemptively in SQL Server. The SQL Server scheduler
has the ability to detect and stop threads that have not yielded for a
significant amount of time. The ability to hook CLR threads to SQL
Server threads implies that the SQL Server scheduler can identify
"runaway" threads in the CLR and manage their priority. Such runaway
threads are suspended and put back in the queue. Threads that are
repeatedly identified as runaway threads are not allowed to run for a
given period of time so that other executing workers can run.

云归处 2024-12-14 07:45:14

跨调用共享静态数据 - 对于 CLR 调用来说不是一个好的计划:
SQL Server 文档

编程模型限制

托管代码的编程模型
SQL Server 中涉及编写函数、过程和类型,这些函数、过程和类型
通常不需要使用跨多个持有的状态
跨多个用户会话的调用或状态共享。
此外,如前所述,共享状态的存在可能会导致
影响可扩展性和可靠性的关键异常
应用程序。

考虑到这些因素,我们不鼓励使用静态变量
以及 SQL Server 中使用的类的静态数据成员。为了安全和
EXTERNAL_ACCESS 程序集,SQL Server 检查该程序集的元数据
在 CREATE ASSEMBLY 时进行程序集创建失败
程序集(如果它发现使用静态数据成员和变量)。

Static data shared across invocations - not a good plan for CLR calls:
SQL Server documentation

Programming Model Restrictions


The programming model for managed code
in SQL Server involves writing functions, procedures, and types which
typically do not require the use of state held across multiple
invocations or the sharing of state across multiple user sessions.
Further, as described earlier, the presence of shared state can cause
critical exceptions that impact the scalability and the reliability of
the application
.

Given these considerations, we discourage the use of static variables
and static data members of classes used in SQL Server. For SAFE and
EXTERNAL_ACCESS assemblies, SQL Server examines the metadata of the
assembly at CREATE ASSEMBLY time and fails the creation of such
assemblies if it finds the use of static data members and variables.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文