1Z0-888 · Question #57
The 'applicationdb' is using InnoDB and consuming a large amount of file system space. You have a / backup partition available on NFS where backups are stored. You investigate and gather this…
The correct answer is A. Enable compression on the table, causing InnoDB to release unused pages on disk to the file system: mysql> SET GLOBAL innodb_file_per_table=1; mysql> SET GLOBAL innodb_file_format=Barracuda; mysql> ALTER TABLE data_current ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; mysql> ALTER TABLE data_history ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8. Important note: The stated correct answer (A) appears to be incorrect - D is the right answer. With innodb_file_per_table=0, all data lives inside ibdata1, and the InnoDB shared tablespace file never shrinks - not from DROP TABLE, not from OPTIMIZE TABLE, and not from moving…
Question
- The table data_current has 1,000,000 rows.
- The table data_reports has 1,500,000 rows.
- The table data_archive has 4,500,000 rows.
Options
- AEnable compression on the table, causing InnoDB to release unused pages on disk to the file system: mysql> SET GLOBAL innodb_file_per_table=1; mysql> SET GLOBAL innodb_file_format=Barracuda; mysql> ALTER TABLE data_current ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; mysql> ALTER TABLE data_history ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;
- BExecute OPTIMIZE TABLE so that the InnoDB engine frees unused pages on disk back to the file system: mysql> OPTIMIZE TABLE data_current, data_reports;
- CSet the server to use its own tablespace, and then alter the table so that data is moved from the shared tablespace to its own: mysql> SET GLOBAL innodb_file_per_table=1; mysql> ALTER TABLE data_current ENGINE=InnoDB; mysql> ALTER TABLE data_reports ENGINE=InnoDB;
- DTake a backup, stop the server, remove the data files, and restore the backup: shell> mysqldump -u root -p applicationdb > /backup/applicationdb.sql shell> /etc/init.d/mysql stop shell> cd /var/lib/mysql/ shell> rm ibdatal ib_logfil0 ib_logfile1 shell> /etc/init.d/mysql start shell> mysql -u root -p applicationdb < /backup/applicationdb.sql
How the community answered
(41 responses)- A61% (25)
- B10% (4)
- C22% (9)
- D7% (3)
Explanation
Important note: The stated correct answer (A) appears to be incorrect - D is the right answer.
With innodb_file_per_table=0, all data lives inside ibdata1, and the InnoDB shared tablespace file never shrinks - not from DROP TABLE, not from OPTIMIZE TABLE, and not from moving tables out into per-file tablespaces. Even if you migrate data_current and data_reports to their own .ibd files (as both A and C attempt), ibdata1 stays at 744 GB. The only way to reclaim that disk space is Option D: dump all databases, stop MySQL, delete ibdata1 and the redo logs, restart (which creates a fresh, small ibdata1), and restore from the dump - leaving you with a compact tablespace containing only the surviving data.
Why the distractors fail:
- A - Enabling compression and ALTERing tables does move them to per-file
.ibdfiles, butibdata1is still 744 GB on disk; no OS space is returned. Also note the ALTER referencesdata_history, a table that doesn't exist in the scenario. - B -
OPTIMIZE TABLEon a shared tablespace reorganizes pages internally but cannot shrinkibdata1at the filesystem level. - C - Same fundamental problem as A: setting
innodb_file_per_table=1and rebuilding tables creates new.ibdfiles, butibdata1remains full-size.
Memory tip: Think of ibdata1 as a warehouse that never demolishes empty shelves - you can move inventory out, but the building stays the same size. The only fix is to tear it down and rebuild it (dump → delete → restart → restore).
Topics
Community Discussion
No community discussion yet for this question.