点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)我们偶尔有一些批量扫描查询,它们...
点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)我们偶尔有一些批量扫描查询,它们...
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
我们偶尔有一些批量扫描查询,它们的优先级要低于实时用户查询。 但是当发生死锁时,ASE选择CPU使用率最低的进程作为受害者(根据P&T锁定和并发控制->死锁和并发->服务器任务死锁)。
但这与我们想要的相反,因为长时间运行的后台"扫描"查询通常具有更多的CPU。
在选择死锁受害者时,ASE是否注意任务优先级(sp_setpsexe)? (可能不是)
是否还有其他方法可以告诉ASE哪个进程应该成为死锁的首选受害者?
MSSQL具有" SET DEADLOCK_PRIORITY"选项。 只是说
Re:在设计良好的Application/Query中死锁应该很少见
我想我的应用程序当时设计不当;)严重的是,问题来自OLTP和DSS查询的混合,因此会出现这类问题。 也许在某些备用环境中,最好只为DSS查询设置数据库的复制副本,但这不是我所生活的世界。
Re:特别是对于使用DOL(即DPL和DRL)锁定方案的表。
仅数据页锁定绝对是一个有用的选项。 可能需要在当前没有它们的某些扫描查询中添加" order by"子句(因为结果可能不再以聚簇索引的顺序返回)。 并且" order by"表扫描也必须命中索引。 但是,仍然有可能通过数据页中的锁定循环导致死锁。
我仍然认为拥有诸如deadlock_priority之类的东西将非常有用。 我在SAP"影响力"页面上的建议中写道:
https://influence.sap.com/sap/ino/#/idea/219715
一周热门 更多>