nerdexam
Oracle

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…

Performance Tuning

Question

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 information: [mysqld] datadir=/var/lib/mysql/ innodb_file_per_table=0 Three tables are stored in the InnoDB shared tablespace and the details are as follows:
  • 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.
shell> ls -l /var/lib/mysql/ -rw-rw---- 1 mysql mysql 744G Aug 26 14:34 ibdatal -rw-rw---- 1 mysql mysql 480M Aug 26 13:34 ib_logfile0 -rw-rw---- 1 mysql mysql 480M Aug 26 13:47 ib_logfile1 ... You attempt to free space from ibdatal by taking a mysqldump of the data_archive table and storing it on your backup partition. shell> mysqldump -u root -p applicationdb data_archive > /backup/data_archive.sql mysql> DROP TABLE data_archive; Unfortunately, this action does not free any actual disk space back to the file system and the server disk space is running out. Which set of actions will allow you to free disk space back to the file system?

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)
  • A
    61% (25)
  • B
    10% (4)
  • C
    22% (9)
  • D
    7% (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 .ibd files, but ibdata1 is still 744 GB on disk; no OS space is returned. Also note the ALTER references data_history, a table that doesn't exist in the scenario.
  • B - OPTIMIZE TABLE on a shared tablespace reorganizes pages internally but cannot shrink ibdata1 at the filesystem level.
  • C - Same fundamental problem as A: setting innodb_file_per_table=1 and rebuilding tables creates new .ibd files, but ibdata1 remains 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

#InnoDB tablespace management#Disk space reclamation#Table compression#innodb_file_per_table

Community Discussion

No community discussion yet for this question.

Full 1Z0-888 Practice