Obtains the progress of ORACLE Import/Export (imp/exp) data.

Yesterday I chatted with my colleagues about ORACLE data backup. The imp/exp Command did not provide progress information and only showed the name of the currently processed object (tables, views, etc. So I thought of a backup recovery applet I wrote a few years ago and provided the backup progress display function. Its implementation logic has always made me feel funny.

The function implementation is very simple, that is, to start a Process to call cmd to execute the imp/exp command and hide the cmd interface.

However, the customer always asks for a progress bar to display the progress, because the process takes several minutes. At that time, I studied the parameters of the imp/exp command, found some information on the Internet, and did not find a solution. Later, I was forced to think of a log file. Haha, didn't you think of it?

That is, before each backup, read the log file size in the target folder and record it. Then, add the log parameter to the imp/exp statement to overwrite the existing log. During the backup process, the program monitors the size of the new log file in a timely manner and compares it with the size of the original log file to calculate the progress information. The assumption here is that the data volume does not change much, and the log file size generated by each backup is close.

The imp statement is written as follows: imp user1/pass @ realty file = user1.dat log = user1.log

Problem:

What if the selected backup folder is new or the log does not exist during the first backup operation? In this case, you can set an estimated log size in the program, for example, 4 K. The specific value depends on the backup data size.

Critical vulnerabilities:

What should I do if the data variable volume is large and the log size is different? This problem is indeed difficult to solve. Although it does not affect the function usage, the information prompts do not match the actual progress. Fortunately, the project data at that time was equivalent to a "dead Database" with little changes, so this function was also recognized by users. But I always think this solution is absurd. If you have a good idea, please let me know.

Conclusion:

1. ORACLE does not provide progress display. My personal estimation is to increase the data processing speed and is unwilling to estimate the data volume and real-time computing progress.

2. The above solution is generally only applicable to situations with small data variables. Otherwise, users may feel cheated. Haha