Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 能否监控到update执行的过程,类似admin show ddl jobs 的操作
Is there a tool that can monitor the progress of update or delete operations, similar to how admin show ddl jobs
can track the progress of index creation?
I don’t think so, I’ve never heard of such a feature.
Take a look at trace update/delete xxx.
This is quite interesting, but it’s not very intuitive. What I want to see is the process of a specific SQL being executed in the background, similar to admin show ddl jobs
, and be able to estimate when this SQL will be completed. Know yourself and know your enemy!
Oracle hasn’t been able to implement this feature, right? Oracle has a view called V$SESSION_LONGOPS that can show approximate information, but it’s not accurate either…
Progress should be unmonitorable, at most it can monitor statements.
The update and delete operations are very fast; I once mistakenly deleted a TiDB database (50GB), and it was gone in about a minute. Currently, most of the execution statements can be monitored.
Most of my operations here involve multi-table join updates using inner join update. The data volume is around 30 million, and the efficiency is relatively low. I want to monitor the execution process.
Could you provide the statements, related table indexes, and execution plan for analysis?
Can’t be monitored, right?
Can’t you check the execution time in the dashboard?
You can see it in Oracle EM’s SQL Monitor.
Uh, if I’m not mistaken, Oracle’s EM also reads the same system view, right… Anyway, if it’s a query, this is still somewhat useful. For updates or deletions, there are many situations with or without locks, right… He can only roughly guess…
These are all predictions, which can assist managers in making decisions.
Currently, we have not yet implemented views similar to Oracle Longops at the statement level and session level.
The execution time depends on the size of the update and delete batches, and it is also affected by the execution efficiency of multiple components such as TiDB and TiKV. If you need to recover, you can use various methods such as recovery and flashback, but the premise is that GC has not yet cleaned it up. Currently, the default for TiDB is 10 minutes. If you need to leave a certain buffer, you can consider extending this time.
You can use information_schema.cluster_processlist to check, where the time can show how long the process has been running. However, there is no way to estimate the remaining execution time.
Check if expensive SQL is recorded in the logs.
Also, use the manual analysis profile in the dashboard to see if you can find anything.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.