如何强制存储过程预先缓存并保留在内存中?

发布于 2024-09-28 18:11:33 字数 1086 浏览 2 评论 0原文

存储过程在首次使用时编译。

有一些选项可以清除缓存:

DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
--To Verify whether the cache is emptied
--DBCC PROCCACHE

或重新编译或减少重新编译。

但是是否可以强制将经常使用的存储过程的执行计划预先缓存并保留在内存中?

我知道如何在 ADO.NET 中执行此操作,即从 SQL Server 外部执行此操作,但这个问题是如何在 SQL Server 内部执行此操作 - 随着 SQL Server 本身的启动而启动。

(*) 例如,我在 SSMS 活动监视器中看到一个正在运行的进程(任务状态:RUNNING,命令:SELECT),该进程在 tempdb 数据库上下文中连续执行 T-SQL(根据 Profiler),尽管 SQL Server 代理已禁用并且 SQL服务器未加载任何内容,请参阅“中的“会话 54 的详细信息”所有这些 SQL Server 会话都来自哪里?”。

我将如何定期回收存储过程来执行类似的驻留进程(或者更确切地说,通过 SQL Server 启动服务或会话自动启动)?

相关问题:
存储过程首次运行时执行缓慢

更新:
也许我应该在 2 中分叉这个问题,但我主要好奇的是如何在禁用 SQL Server 代理的情况下进行定期/循环活动?
上面提到的 RUNNING SELECT session (*) 是如何制作的?

更新2:
我经常在执行查询极少量数据的存储过程时观察到相当大的延迟,这不能仅通过需要读取大量数据来解释。

我们是否可以将这一点(微不足道的小数据上的相当大的延迟)视为这个问题的背景?

Stored procedures are compiled on first use.

There are options to clear cache:

DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
--To Verify whether the cache is emptied
--DBCC PROCCACHE

or to recompile or to reduce recompilations.

But is it possible to force frequently used stored procedures' execution plans be pre-cached and stay in memory?

I know how to do it in ADO.NET, i.e. from outside of SQL Server, but this question is how to do inside SQL Server - to be launched with the start of SQL Server itself.

(*) For example, I see in SSMS Activity Monitor a running process (Task State: RUNNING, Command: SELECT) that is continuously executing T-SQL (according to Profiler) in context of tempdb database though SQL Server Agent is disabled and SQL Server is not loaded by anything, see "Details of session 54" in "Where are all those SQL Server sessions from?".

How would I do the similar resident process (or, rather, auto-starting by SQL Server start service or session) periodically recycling stored procedure?

Related question:
Stored procedure executes slowly on first run

Update:
Might be I should have forked this question in 2 but my main curiosity is how to have periodic/ looping activity with SQL Server Agent disabled?
How was it made with mentioned above RUNNING SELECT session (*)?

Update2:
Frequently I observe considerable delays while executing stored procedures querying very small amount of data which cannot be explained only through necessity to read huge amounts of data.

Can we consider this - considerable delays on insignificantly small data - as context of this question?

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

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

发布评论

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

评论(2

奢欲 2024-10-05 18:11:33

只需从脚本执行它即可。您可以在任何 sql 服务器重新启动后执行此操作。如果经常使用它们,那么之后应该不会有太大问题。

Just execute it from a script. You could do this after any sql server restart. If they are frequently used, it shouldn't be much of a problem after that.

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