V$SQL_MONITOR.STATUS

SQL Monitor report shows DONE(ERROR) for long running parallel queries after 30 minutes. (Doc ID 1900060.1)

SYMPTOMS

  • Running DBMS_SQLTUNE.REPORT_SQL_MONITOR
    For example:

    SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(SESSION_ID=>&1,
                  SESSION_SERIAL=>&2,    
                  INST_ID=>&3,
                  report_level=>'ALL',
                  type =>'ACTIVE') as report 

      
  • Query is running in parallel (PX)
  • After 30 minutes V$SQL_MONITOR.STATUS shows DONE(ERROR) even though the query is still running

CHANGES

CAUSE

This was filed under Bug 13523091 INCORRECT STATUS IN V$SQL_MONITOR WITH PARALLEL QUERY and closed as not a bug

The DONE(ERROR) occurs when one of the parallel slaves has been inactive for more than 30 minutes.
When MMON finds out that an entry that has active plan is idle for more than 30 minutes, it marks the entry as possible for reclamation with potential error. It is marked as error because there could have been an error in this plan that MMON was unable to detect,
considering that it is spending such a long time (30 minutes) as "idle". 
If there are no other errors during the execution the monitor report will be correct and will contain all the usual information.
The error does not indicate that SQL monitoring failed, nor does it indicate that the monitored SQL failed.

Following are the possible statuses for V$SQL_MONITOR.STATUS:

  • QUEUED - SQL statement is queued
  • EXECUTING - SQL statement is still executing
  • DONE (ERROR) - Execution terminated with an error
  • DONE (FIRST N ROWS) - Execution terminated by the application before all rows were fetched
  • DONE (ALL ROWS) - Execution terminated and all rows were fetched
  • DONE - Execution terminated (parallel execution)

SOLUTION

This is expected behavior for parallel queries where one (or more) of the slaves are inactive for more than 30 minutes.

Oracle Database Online Documentation 12c Release 1 (12.1)
Database Reference
V$SQL_MONITOR

V$SQL_MONITOR

  • 5
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
这是一个 SQL 查询语句,它的作用是查询当天上传文件的用户信息和文件上传统计信息。具体解释如下: 1. 查询语句包含两个部分,用 `UNION ALL` 连接起来。第一个部分查询普通用户上传的文件信息,第二个部分查询系统上传的文件信息。 2. 第一个部分的查询语句如下: ``` select tu.id as userId, tu."name", tm.totalUploaded, tm.categories, tm.totalProcessed from t_user tu left join ( select tm.user_id userId, count(tm.user_id) totalUploaded, string_agg(distinct tm.label_id,',') categories, COUNT(CASE WHEN tm.status != 10 THEN 1 END) totalProcessed from t_monitor tm where date(tm.create_time) = CURRENT_DATE group by tm.user_id ) tm on tu.id = tm.userId ``` 该查询语句使用了 `LEFT JOIN` 连接了 `t_user` 表和一个子查询。子查询使用了聚合函数 `COUNT` 和 `string_agg` 对 `t_monitor` 表中的数据进行统计。具体来说,子查询中的 `count(tm.user_id)` 统计了每个用户上传的文件总数,`string_agg(distinct tm.label_id,',')` 统计了每个用户上传文件所属的类别,`COUNT(CASE WHEN tm.status != 10 THEN 1 END)` 统计了每个用户已经处理的文件数(`status != 10` 表示文件不处于处理中状态)。 3. 第二个部分的查询语句如下: ``` select 0 as userId, 'python上传' as name, count(tm.user_id) totalUploaded, string_agg(distinct tm.label_id,',') categories, COUNT(CASE WHEN tm.status != 10 THEN 1 END) totalProcessed from t_monitor tm where date(tm.create_time) = CURRENT_DATE and tm.user_id = 0 group by tm.user_id; ``` 该查询语句统计了系统上传的文件信息,使用了 `COUNT` 和 `string_agg` 函数对 `t_monitor` 表中的数据进行统计,`COUNT(CASE WHEN tm.status != 10 THEN 1 END)` 统计了系统上传的文件中已经处理的文件数(`status != 10` 表示文件不处于处理中状态)。注意到该查询语句中的 `userId` 被设置为 0,表示该部分查询结果不属于任何用户。 4. `UNION ALL` 连接两个部分的查询结果,返回最终的查询结果。 总体来说,该查询语句主要用于上传文件的统计和展示,可以用于监控系统性能和用户上传情况。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值