Tuning ZFS for Database Products

Review the following considerations when using ZFS with a database product.

  • ZFS checksums every block stored on disk. This alleviates the need for the database layer to checksum data an additional time. If checksums are computed by ZFS instead of at the database layer, any discrepancy can be caught and fixed before the data is returned to the application.

  • Keep pool space under 90% utilization to maintain pool performance.

For a comprehensive information about best practices when using ZFS Storage in an Exadata environment, log in to your My Oracle Support account (https://support.oracle.com) and refer to the following documents:

  • Doc ID 2087231.1

  • Doc ID 1354980.1

To tune ZFS for an Oracle Database, see Configuring Oracle Solaris ZFS for an Oracle Database (https://www.oracle.com/technetwork/server-storage/solaris/config-solaris-zfs-wp-167894.pdf).

Review the following considerations when using ZFS with MySQL.

  • ZFS recordsize

    Match the ZFS recordsize property to the storage engine block size for better OLTP performance.

  • InnoDB

    With a known application memory footprint, such as for a database application, you might cap the ARC size so that the application will not need to reclaim its necessary memory from the ZFS cache.

  • Create a separate pool for the logs.

  • Set a different path for data and log in the my.cnf file.

  • Set the ZFS recordsize property to 16K for the InnoDB data files, and use the default recordsize value for InnoDB logs, prior to creating data files.