DX Unified Infrastructure Management

David, does this work with RA 9.0.161 DSA? It just hangs after showing the 'NetQoS' ASCII logo. We have 38k tables, but it doesn't even get as far as backing up the frm files.

Yes, DBToolv3 was designed to work with all the MySql port 3308 databases.

Alright. Can we call support to get help on why it's not working?

Stuart_Weenig wrote:

Alright. Can we call support to get help on why it's not working?

This tool along with other "Support Tools" are not officially supported, they are use 'as is' tools developed by a Support Engineer to help out where possible.
Feedback however is always helpful as the tools can be improved over time where possible.

CA Development does not write these tools and CA QA does not test them, this was try for the older set of backup tools as well like DBbackuptMT.

We can try to assist it getting these tools working, but if they are not working there are many ways to backup a MySql database, ie MySqldump, Stopping Mysql and doing and just backing up the MySql\data directories, etc...

From our experience we have found this tool works best in most situations, however every environment is unique.

-Chris

In that case, could we get the source code?

It is not doing anything fancy, just standard calls.

For NV it starts by copying the .MGR files (not applicable to your case with DSA), then it copies the .frm files. After that it is a dump of the tables to standard mysql .sql files.

In your case you mentioned it is not copying the .frm files, so if W2K8 open the command box with the 'Run as Admin' option. Still no go try using Process Monitor from SysInternals to log dbtoolv3 activity and get a record every call it makes and hopefully identify the failure point. The 'Tech Tips' message board may not be the best place for this dialog.

Is it that hard to get the source code if it's all standard calls? I'll split the thread in a minute. It eventually ran. It just takes forever before starting to copy the frm files. It doesn't even log anything to the log file. I'm trying to figure out what happens before it tries to copy the FRM files so we can figure out why it's taking so long to run.

Stu,

Another engineer wrote the code so it is not up to David or I. Plus I'd imagine it would have to go through Legal.

Most of the time it just takes patience, the old tool was multi threaded but then ran away with resources on the servers in many cases which is why this does not give you that option.

So, what do i have to do to officially request that the source code for those scripts be released?

To know what dbtoolv3 is doing use the previously mentioned Process Monitor.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

No install, just extract, run, Filter > Process Name > dbtoolv3.exe.
Now run the backup and ProcMon will capture it and you can see exactly what it is doing.

Its a great tool.
have fun.

A DSA can take a long time to back up if the database is very large.

Also for your previous post about the Backup not working because it said it was already up to date, if you point the backup to a folder which already has the backup files in it, it won't overwrite them.
So you need to either point it to a new folder or move the old files out I believe.