Is it possible to monitor the execution process of an update, similar to the admin show ddl jobs operation?

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 能否监控到update执行的过程,类似admin show ddl jobs 的操作

| username: Running

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?

| username: hey-hoho | Original post link

I don’t think so, I’ve never heard of such a feature.

| username: h5n1 | Original post link

Take a look at trace update/delete xxx.

| username: Running | Original post link

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!

| username: tidb菜鸟一只 | Original post link

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…

| username: Kongdom | Original post link

Progress should be unmonitorable, at most it can monitor statements.

| username: 会飞的土拨鼠 | Original post link

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.

| username: Running | Original post link

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.

| username: Kongdom | Original post link

Could you provide the statements, related table indexes, and execution plan for analysis?

| username: 裤衩儿飞上天 | Original post link

Can’t be monitored, right?

| username: buddyyuan | Original post link

Can’t you check the execution time in the dashboard?

| username: 我是咖啡哥 | Original post link

You can see it in Oracle EM’s SQL Monitor. :grin:

| username: tidb菜鸟一只 | Original post link

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…

| username: Running | Original post link

These are all predictions, which can assist managers in making decisions.

| username: Minorli-PingCAP | Original post link

Currently, we have not yet implemented views similar to Oracle Longops at the statement level and session level.

| username: Hacker_xUwtuKxa | Original post link

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.

| username: Hacker_xUwtuKxa | Original post link

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.

| username: Hacker_xUwtuKxa | Original post link

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.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.