I am feeling like loadercli is not getting attention it needs. I've posted several topics related to it and wasted a lot of time due to design problems I have reported. Is no one at SAP / MySQL actively taking this topic and responding on the list?
Interesting discovery I made regarding loadercli: Our FULL database backups are around 12GB in size without logs. Using high compression schemes we can get this file down to 2GB. Here is output from "info state": Data (KB) = 11787600 Perm Data (KB) = 11787280 Temp Data (KB) = 320 Data (Pages) = 1473450 Perm Data (Pages) = 1473410 Temp Data (Pages) = 40 Data (%) = 56 I found that using tableextract PAGES of all tables I get 4.7GB. Is this because the indexes are left behind? 12GB vs 4.7GB is pretty big difference. Furthermore, this 4.7GB compresses to an amazing 700MB! This is a big deal for us, as our database recovery / backup often requires us to download over the internet using a 512Kbps link.. and 2.5GB vs. 700MB saves a lot of time. These dramatic differences in space required and I/O performed make loadercli attractive as a backup solution in some situations. However, the table locking... I understand all the issues of trying to do 'real backups' and the need to consider the ongoing activity / logging. However, I am sure I'm not the only one who wants a better solution for 'snapshot' of production database. I don't care about the activity goes on during backups... or inconsistencies. The inability to do a backup and restore to an alternate platform creates this desire. If it were possible to do a backup on Windows 2000 and restore directly on Solaris I wouldn't have been spending so much time or concern on loadercli ... Thank you. Stephen Gutknecht On Wed, 25 Feb 2004 10:45:23 , [EMAIL PROTECTED] sent: > >Hi, > >We seem to have discovered that loadercli tableextract locks the table it is >extracting. > >we can do a backup disk to disk, but tablextract disk to disk causes all the clients >to halt. > >Is there a way to tell loadercli to not do this and act more like the backup? > >Thank you. > > Stephen Gutknecht > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
