Go to main content

Oracle® Solaris 11.4 Tunable Parameters Reference Manual

Exit Print View

Updated: January 2019
 
 

Tuning ZFS for Database Products

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

  • If the database uses a fixed disk block or record size for I/O, set the ZFS recordsize property to match it. You can do this on a per-file system basis, even though multiple file systems might share a single pool.

  • With ZFS's copy-on-write design, tuning down the recordsize is a way to improve OLTP performance at the expense of batch reporting queries.

  • 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 the white paper at 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.