dbtools api and java?

[Former Member]

Hello,

we have webinterface to manage our different client installations and also copy over whole databases via the dbbackup command.

The serverside is all written in java (And vaadin) Sometimes we have very lengthy backup processes (500MB databases over 20MBit/sec Lines) and wish to show a progres bar.

Is there a way to use dbtools from java to get some sort of progress informations ? (As on the commandline of dbbackup for example)

Or is there another way to make backups across the wire and show some progress?

André

[VolkerBarth]

Is that a client-side or server-side backup (dbbackup -s)?

[Former Member]

Currently it's a client side backup, but I could transform it into a server side backup and then download the db files with sftp or similar...

[VolkerBarth · Accepted solution]

As DBTools is a C-based API, I guess a usage from Java will require some kind of JNI interface or the like - can't tell more, haven't done that...

Another approach with a looser coupling might be to make use of the MESSAGE statement to pass messages to other connections. ODBC apps can process such messages by using a particular callback - that works well IMHO. SA 11 JDBC clients seems to be able to read them as well, but I don't have a sample at hands.

The basic idea would be to

• have a JDBC app that waits for input
• turn the connection id of that waiting connection to a program that can call a C DLL
• use a classic DBTools C DLL that calls DBBackup() and uses the callbacks to build according MESSAGE statements for a given connection ID, such as:
  

extern short _callback MessageRtn(char * messagestr)
{
if (messagestr != NULL)
{
// build message string from messagestr, such as
// sqlstr = "MESSAGE messagestr + " TO CLIENT FOR CONNECTION " + MyConnId + " IMMEDIATE"
// use ODBC or whatever C DB APO to execute that SQL statement
}
return (0);
}

So the DBTools DLL could "send" the progress messages of the backup to the JDBC connection.

Apparently, one could also make the DBTools API DLL to write messages to a file or send them via some IPC mechanism, and make the JDBC app read them...

[Former Member · Accepted solution]

Ok, that would be a way to go, but it looks like a long way and a stony one (ASA wersion dependent etc.)

I think we will take a simpler track: - Ask the asa server for the size of the .db and .log files - Start a server side backup - Via java remoting (which we already have) poll on the backup file sizes - Then transfer the backupfiles via sftp or java remoting back to the management server

Since we already have the java remoting file transfer in place, it will not require that much changes.

Thanks

André

[jeff_albion · Accepted solution]

Be aware that the size of the backed up transaction log / database may not exactly match the size of the database prior to the backup. (e.g. the database size can change depending on the 'CHECKPOINT LOG COPY' options, and the transaction log grows while the backup is taking place on the database file).

[Former Member · Accepted solution]

I did now still do a remote dbbackup (From remote to local) First I ask the dbserver for the size of the DB file and then watch it grow as it is copied to the local system. (Apparently dbbackup does not preallocate the space)

With these two I can detect the current DB file size:

SELECT PropName, PropDescription, Value FROM sa_db_properties() where propname='FileSize'

and

SELECT PropName, PropDescription, Value FROM sa_db_properties() where propname='PageSize'

Is there a similar possibility to ask teh DB server for the size of the transaction log file ?

[VolkerBarth · Accepted solution]

select DB_EXTENDED_PROPERTY('FileSize', 'translog')

[Former Member · Accepted solution]

Almost realtime support, cool 🙂

And thanks a lot

[Former Member]

The PROGRESS connection property can give you this information. This property was introduced in version 12.0.0.

FWIW: In order to get such messages, the according progress_messages database option must have been set to Raw or Formatted.

[Former Member]

Hmm... unfortunally the servers are mainly v9 and v11