Tabled=tables
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge Bastos Sent: domingo, 3 de Agosto de 2008 18:30 To: 'DBMail mailinglist' Subject: RE: [Dbmail] Db growing size It wasn’t me who talked about tabled being locked during optimize Andrea, It was Peter Rabbitson on the email on day 02-08-2008 around 13:03 GMT+1 I still haven’t runed optimize on dbmail_mimeparts because I have less free space than the size of dbmail_mimeparts. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrea Brancatelli Sent: domingo, 3 de Agosto de 2008 18:05 To: DBMail mailinglist Subject: RE: [Dbmail] Db growing size Il giorno dom, 03/08/2008 alle 13.03 +0100, Jorge Bastos ha scritto: I'm not whining! You're having a wrong point of view from me. Yes but you still haven't run an optimize table on all the tables in the dbmail database. I dont' know why you talk about locking during the optimize table but my memory says that the table aren't locked during the optimize table, especially because the original one is just read. I'd run it directly on the production db without all the hassle of the backup copy. http://www.dbmail.org/dokuwiki/doku.php?id=mysql_notes WITH innodb_file_per_table you have one (well, actually two) file per each InnoDB table. Each table/index file will stay in the database directory [...] When you run an OPTIMIZE TABLE the InnoDB engine will start to create a NEW .idb file with a temporary name, using only the space it actually needs to store the real datas. When the optimize table has ended, it will simply delete the old .idb file and rename the temporary one to the correct name. This mean that if your old table’s .idb file had grown up to 3, 4, 5, 100 GB but you have only 100 MB of real datas in it, the new .idb file will be 100MB while the one that will be deleted was 3, 4, 5, 100GB.
_______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
