There is nothing MySQL has that will indicate the progress of OPTIMIZE TABLE;
.
You may have to go the OS using Windows Explorer and look for a growing tmp table. Hint: Temp table are MyISAM tables that do not have a .frm
file with the name #sql-9999.MYD
and #sql-9999.MYI
. While these two fle exist, the query would be considered in progress. To know how far, one would have to know how many rows times the average row length to estimate the percentage done or left to be done.
MariaDB has some progress metering for the following:
ALTER TABLE
ADD INDEX
DROP INDEX
LOAD DATA INFILE
CHECK TABLE
REPAIR TABLE
ANALYZE TABLE
OPTIMIZE TABLE
I have discussed subject before in terms of MySQL operations
If you are trying to reduce the size of ibdata1 for InnoDB, dropping tables simply leaves big gaps in ibdata1. You must perform a full Cleanup of InnoDB Infrastructure.
UPDATE 2012-12-21 19:30 EDT
Since this database uses innodb, will there be a growing temp table I can look for?
Let's say you want to run
OPTIMIZE TABLE mydb.mytable;
Look at two scenarios involving innodb_file_per_table and this OPTIMIZE TABLE
Running OPTIMIZE TABLE
will cause all the data and index pages for mydb.mytable
to be appended contiguously to ibdata1. This will leave the space previously occupied to add further to the fragmentation madness.
In this scenario, the temp table would exist as InnoDB, and it would materialize in ibdata1. Thus, there would be nothing to visually monitor.
For each InnoDB table mydb.mytable you would have
- /var/lib/mysql/mydb/mytable.frm
- /var/lib/mysql/mydb/mytable.ibd
The .ibd
file contains the data and index pages for the table.
Running OPTIMIZE TABLE
will cause all the data and index pages for mydb.mytable
to be written to an external .ibd
file that you can see in Windows Explorer.
CAVEAT
Enabling innodb_file_per_table and running OPTIMIZE TABLE
will never reclaim the space formerly occupied within ibdata1. You will have to carry out the InnoDB Cleanup to recreate ibdata1 in such a way that data and indexes never, ever again reside in ibdata1.
CONCLUSION
As stated earlier, MariaDB can monitor OPTIMIZE TABLE;
If you want something you can monitor and you have innodb_file_per_table enabled, you can replace
OPTIMIZE TABLE LOGTABLEFOO1,LOGTABLEFOO2,LOGTABLEFOO3;
with the following mechanical equivalent:
CREATE TABLE LOGTABLEFOO1_NEW LIKE LOGTABLEFOO1;
INSERT INTO LOGTABLEFOO1_NEW SELECT * FROM LOGTABLEFOO1;
ALTER TABLE LOGTABLEFOO1 RENAME LOGTABLEFOO1_OLD;
ALTER TABLE LOGTABLEFOO1_NEW RENAME LOGTABLEFOO1;
DROP TABLE LOGTABLEFOO1_OLD;
ANALYZE TABLE LOGTABLEFOO1;
CREATE TABLE LOGTABLEFOO2_NEW LIKE LOGTABLEFOO2;
INSERT INTO LOGTABLEFOO2_NEW SELECT * FROM LOGTABLEFOO2;
ALTER TABLE LOGTABLEFOO2 RENAME LOGTABLEFOO2_OLD;
ALTER TABLE LOGTABLEFOO2_NEW RENAME LOGTABLEFOO2;
DROP TABLE LOGTABLEFOO2_OLD;
ANALYZE TABLE LOGTABLEFOO2;
CREATE TABLE LOGTABLEFOO3_NEW LIKE LOGTABLEFOO3;
INSERT INTO LOGTABLEFOO3_NEW SELECT * FROM LOGTABLEFOO3;
ALTER TABLE LOGTABLEFOO3 RENAME LOGTABLEFOO3_OLD;
ALTER TABLE LOGTABLEFOO3_NEW RENAME LOGTABLEFOO3;
DROP TABLE LOGTABLEFOO3_OLD;
ANALYZE TABLE LOGTABLEFOO3;
Please keep in mind the OPTIMIZE TABLE is nothing but ALTER TABLE ... ENGINE=InnoDB;
followed by ANALYZE TABLE.
With these steps, you know in advance what the temp tables are
LOGTABLEFOO1_NEW.ibd
LOGTABLEFOO2_NEW.ibd
LOGTABLEFOO3_NEW.ibd
Simply Monitor Each File's Existence and Size Until it Disappears.
This script will dynamically create the database prepended with the date format you want
SET @dbname = 'rolando';
SET @today = DATE(NOW());
SET @this_thurs = @today - INTERVAL WEEKDAY(@today) DAY - INTERVAL 3 DAY;
SET @ut1 = UNIX_TIMESTAMP(@this_thurs);
SET @ut2 = UNIX_TIMESTAMP(@today);
SET @last_thurs = @this_thurs - INTERVAL IF(@ut1=@ut2,1,0) WEEK;
SET @newDBNAME = CONCAT(DATE_FORMAT(NOW(),'%y%m%d_%H%i_'),@dbname);
SET @sql = CONCAT('CREATE DATABASE IF NOT EXISTS ',@newdbname);
PREPARE s FROM @sql;
EXECUTE s;
DEALLOCATE PREPARE s;
Just set the @dbname in the script.
If you want it as a Stored Procedure, here you go:
DELIMITER $$
DROP PROCEDURE IF EXISTS `MakeRestoreDB` $$
CREATE PROCEDURE `MakeRestoreDB`(GivenDBName VARCHAR(20))
BEGIN
SET @dbname = GivenDBName ;
SET @today = DATE(NOW());
SET @this_thurs = @today - INTERVAL WEEKDAY(@today) DAY - INTERVAL 3 DAY;
SET @ut1 = UNIX_TIMESTAMP(@this_thurs);
SET @ut2 = UNIX_TIMESTAMP(@today);
SET @last_thurs = @this_thurs - INTERVAL IF(@ut1=@ut2,1,0) WEEK;
SET @newDBNAME = CONCAT(DATE_FORMAT(NOW(),'%y%m%d_%H%i_'),@dbname);
SET @sql = CONCAT('CREATE DATABASE IF NOT EXISTS ',@newdbname);
PREPARE s FROM @sql;
EXECUTE s;
DEALLOCATE PREPARE s;
END $$
DELIMITER ;
Then, just call MakeRestoreDB('rolando');
, and you are good to go.
Give it a Try !!!
Hmmmmm ... some of these statements seem familiar :-)
Best Answer
Your best option is the following:
STEP 01
First let's create the SQL file. The SQL file will have these rules
@echo off
Here is the Windows batch file
Save the SQL script as
C:\Make_mysqldump.sql
STEP 02 and 03
I will demonstrate Steps 01 and 02
DEMONSTRATION
Here the databases on my Windows machine
Here is the text file:
Here is the creation of the batch file and its contents:
CAVEAT : I'll leave the rest to your imagination to run the mysqldump and execute
C:\TransferDB.sql
on the target DB server.Give it a Try !!!
UPDATE 2013-12-06 18:51 EST
Here is a crazy idea requiring some elbow grease
STEP #1
Remove the first line of
C:\Make_mysqldump.sql
do it looks like this:STEP #2
Create a new batch file (Call it
C:\MakeBackupJob.bat
) whose sole purpose is to make a dborigin variable and append the rest. It should have these lines:EPILOGUE
To use
C:\MakeBackupJob.bat
, simply specify the database tag name. Suppose the databases arerolando
,pamela
,dominique
,diamond
. Simply run the following:You should have 4 SQL files in C:\
Now, run the following:
Now,
C:\Exec_mysqldump.bat
contains 4 mysqldumps to separate files.Give it a Try !!!