Hello Reindl,
On 6/24/2014 3:29 PM, Reindl Harald wrote:
Am 24.06.2014 21:07, schrieb shawn l.green:
It makes a huge difference if the tables you are trying to optimize have their
own tablespace files or if they live
inside the common tablespace.
http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_file_per_table
which is the most stupid default in case of innodb and only survivable
without a lot of work for people who realize that *before* start
operations and enable "innodb_file_per_table" from the very begin
having defaults which can't be changed later without complete re-import
of data and prevent from ever get disk space for long ago deleted data
free is the most wrong thing a software developer can do
The tables can be moved from the common tablespace into their own
tablespace at any time after the option is enabled. The space they once
occupied within the primary tablespace will remain and it will be marked
as 'available' for any general purpose (such as the UNDO log)
The only way to shrink the primary tablespace is, as you correctly
described, through a dump/restore of your data. This process to resize
the primary tablespace (such as to shrink it) must be followed precisely
or problems will result.
http://dev.mysql.com/doc/refman/5.6/en/innodb-data-log-reconfiguration.html
--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Hardware and Software, Engineered to Work Together.
Office: Blountville, TN
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
