选择更新时石英阻塞

Question

我有一个大型应用程序，其中 4 个节点使用quartz 来调度作业。

我经常收到来自我们数据库团队的邮件

'从 QRTZ_LOCKS 中选择*，其中 LOCK_NAME='TRIGGER_ACCESS' 进行更新'

阻塞15-20分钟。有时是几个小时。 我发现我的工作也陷入了等待锁定的状态。

我们使用的是 Quartz 1.8.3，这是相当旧的版本。这是我正在使用的石英设置

org.quartz.scheduler.instanceName = DefaultQuartzScheduler
org.quartz.scheduler.instanceId = AUTO
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 25
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

org.quartz.jobStore.misfireThreshold = 60000

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT

org.quartz.jobStore.driverDelegateClass=com.xyx.abc.common.scheduler.impl.CDAJDBCDelegate
org.quartz.jobStore.useProperties=false
org.quartz.jobStore.tablePrefix=QRTZ_
org.quartz.jobStore.isClustered=true
org.quartz.jobStore.clusterCheckinInterval = 20000

# these 3 are required by customSchedulerFactory class
org.quartz.dataSource.myDS.connectionProvider.class=com.xyz.abc.common.scheduler.impl.CustomPoolingConnectionProvider
org.quartz.jobStore.dataSource=myDS
org.quartz.jobStore.nonManagedTXDataSource=myDS

我尝试为 Quartz 启用调试日志。但并没有从中得到太多。

有人遇到过类似的问题吗？如何确保“选择更新”查询快速执行？

Answer 1

您或许可以忽略这些询问。

很多年前我就站在这个问题的另一边。我是数据库团队中的那个人，他发现了一个长时间运行的查询，并要求 Java 开发人员修复它。我不记得细节了，但我记得有一个很好的解释为什么会这样，而且没有什么需要修复的。

当我们按

GV$SQL.ELAPSED_TIME

降序排序时，查询始终显示在性能报告中。但经过仔细检查，我们发现他们没有使用任何“重要”资源。他们没有使用 CPU、I/O 或任何其他宝贵的资源。这是 ELAPSED_TIME 专栏产生误导的罕见情况之一。我学会了忽略它们并担心其他问题。

Answer 2