Fewer rows of BINARY-type data can be stored on a page than is the case with BLOB-type data. Because of this, if search conditions are specified on some columns where the BINARY type cannot be retrieved, the BINARY type will require more frequent input/output operations than the BLOB type, thus reducing retrieval performance. However, if indexes are defined for columns that are not the BINARY type and an index scan is performed, the performance difference between the BINARY and BLOB types disappears.

Specify the BINARY type as the data type for the column when you use the CREATE TABLE definition SQL statement.

• The BINARY type cannot be used with the following items:
  
  • Tables with the FIX attribute
  • Index definitions
  • Partitioning keys
  • Columns that make external references
• If the binary data length exceeds one page, the data is stored in binary-only segments, which are different from the segments that store the base rows. When binary data that exceeds one page is stored, RDAREAs might run out of space if there are no unused pages in binary-only segments, even if there are unused pages in segments that store base rows. When an RDAREA does run out of space, you can check whether it was caused by binary data or base row data by using the database analysis utility (pddbst) to access the usage statuses of binary-only segments and segments that store base rows.
• When you define a BINARY type column, make a precise estimate of the column's defined length (maximum length). If it is unnecessarily long, you might be unable to execute data loads that use memory proportional to the column's defined length (when you execute data loads for tables that define BINARY columns, make sure that there is memory equivalent to the defined length of the BINARY columns).