选择更新时石英阻塞

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。

我学会了忽略它们并担心其他问题。