db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike matrigali <mikema...@gmail.com>
Subject Re: How to get expected time or processing percentage of Backup | Restore | a long running query
Date Fri, 09 Jan 2015 22:17:27 GMT
On 1/8/2015 11:16 PM, kosurusekhar wrote:
> Hi folks,
> We have application using derby database, which has backup | restore |
> cleanup (delete processed records from DB) options. The users of our
> application asking to show the processing percentage or estimated time to
> get know whether process is working or hanged.
> Is there any kind of feature or script to get this.
> Please let me know the possibilities.

I am not aware of any Derby features that will give you this 
immediately.  Some suggestions that you could work on:

Almost all of derby backup time is about copying the files.  Derby 
provides a mechanism for you to implement your own backup, by simply
calling an interface to tell derby when you are starting and when
you are stopping.  You could do this and then depending on what
mechanism you are using compare % progress vs total db size.

The following may depend on OS permissions.  You could use derby default
backup and in separate thread again monitory source size vs dest size.
The caveat here is to make sure your monitoring does not get in the way
of the I/O that derby is doing and make the backup fail.

It would be interesting to file a JIRA for this request and explain what
kind of interface you are looking for.  The backup part of derby is very
self contained and this could be a good project for someone new looking
to contribute.  At the lowest level for derby implemented backup it just
does a file by file and page by page copy of the databse so it should 
not be too hard to implement logic to understand how big the db is to 
start, how much has gone so far and how much time it has taken so far.
Not sure best way to communicate this to the caller.  Anyone know how 
other products deal with this?

restore has 2 parts, first again is just an I/O bound phase of copying
the whole db (if that is restore mode).  this would lend itself to ideas
above.  The second is some database log level restore code which would
need to be handled at low level of the log.  Since restore is a boot 
time operation it is much harder to communicate to calling routine as
there is not a connection yet.

i am not sure what you mean by this one.  is it the progress of a single
delete statement?
> Thanks in advance.
> Regards
> Sekhar.
> --
> View this message in context: http://apache-database.10148.n7.nabble.com/How-to-get-expected-time-or-processing-percentage-of-Backup-Restore-a-long-running-query-tp143571.html
> Sent from the Apache Derby Users mailing list archive at Nabble.com.

View raw message