Question

我有一个很大的应用程序，其中4个节点使用quartz来安排作业。

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

＆＃39; SELECT * FROM QRTZ_LOCKS WHERE LOCK_NAME =＆＃39; TRIGGER_ACCESS＆＃39;对于更新＆＃39;

阻挡了15-20分钟。有时几个小时我看到我的工作也在等待锁定。

我们使用的是Quartz 1.8.3，这是一个非常古老的版本。这是我正在使用的Quartz设置

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启用调试日志。但是没有从中获得太多。

有没有人遇到类似的问题？如何确保选择更新＆＃39;查询正在快速执行？

Answer 1

您可以忽略这些查询。

很多年前，我在这个问题的另一边。我是数据库团队的成员，他找到了一个长时间运行的查询，并要求Java开发人员修复它。我无法记住细节，但我记得有一个很好的解释，为什么它以这种方式工作，并且没有任何东西需要解决。

当我们按GV$SQL.ELAPSED_TIME降序排序时，查询始终显示在效果报告中。但经过仔细检查，我们发现他们没有使用任何重要的资源。他们没有使用CPU，I / O或任何其他宝贵资源。当ELAPSED_TIME列具有误导性时，这是极少数情况之一。

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

石英阻塞选择更新

1 个答案: