Oracle SecureFile LOBs and MySQL Large Objects - Oracle to Aurora MySQL Migration Playbook
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Oracle SecureFile LOBs and MySQL Large Objects

Feature compatibility Amazon SCT / Amazon DMS automation level Amazon SCT action code index Key differences

Four star feature compatibility

Four star automation level

N/A

MySQL doesn’t support SecureFiles, automation and compatibility refer only to LOBs.

Oracle Usage

Large objects (LOB) is a mechanism for storing binary data in a database. Oracle 11g introduced SecureFile LOBs that provide more efficient storage. They are created using the SECUREFILE keyword as part of the CREATE TABLE statement.

The Primary benefits of using SECUREFILE lobs include:

  • Compression — Uses Oracle advanced compression to analyze SecureFiles LOB data to save disk space.

  • De-Duplication — Automatically detects duplicate LOB data within a LOB column or partition and reduces storage space by removing duplicates of repeating binary data.

  • Encryption — Combined with Transparent Data Encryption (TDE).

Examples

The following example creates a table using a SecureFiles LOB column.

CREATE TABLE sf_tab (COL1 NUMBER, COL2_CLOB CLOB) LOB(COL2_CLOB)
  STORE AS SECUREFILE;

The following example provides additional options for LOB compression during table creation.

CREATE TABLE sf_tab (COL1 NUMBER,COL2_CLOB CLOB) LOB(COL2_CLOB)
  STORE AS SECUREFILE COMPRESS_LOB(COMPRESS HIGH);

For more information, see Introduction to Large Objects and SecureFiles in the Oracle documentation.

MySQL Usage

MySQL doesn’t support the advanced storage, security, and encryption options of Oracle SecureFile LOBs. MySQL supports regular LOB datatypes and provides stream-style access.

The four Binary Large Object (BLOB) types are: TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB.

These types differ only in the maximum length of the values they can hold.

The four TEXT types are: TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT.

BLOB values are treated as binary or byte strings. They have the binary character set, collation, and comparison. Sorting is based on the numeric values of the bytes in column values.

TEXT values are treated as non-binary or character strings. They have a character set other than binary. Values are sorted and compared based on the collation of the character set.

For TEXT columns, index entries are space-padded at the end. If the index requires unique values, duplicate-key errors occur for values that differ only in the number of trailing spaces. For example, if a table contains 'b', an attempt to store 'b ' causes a duplicate-key error.

Because BLOB and TEXT values can be extremely long, there are some constraints:

  • Only the first max_sort_length bytes (default is 1024) of the column are used when sorting. You can make more bytes significant in sorting or grouping by increasing its value at server startup or runtime. Clients can change the value of this variable.

  • BLOB or TEXT columns in the result of a query that is processed using a temporary table causes the server to use a table on disk rather than in memory because the MEMORY storage engine does not support those data types. Use of disk incurs a performance penalty. Therefore, include BLOB or TEXT columns in the query result only if they are essential.

  • BLOB or TEXT types determine the maximum size, but the largest value that can be transmitted between the client and server is determined by the amount of available memory and the size of the communications buffers. Message buffer size can be changed by the max_allowed_packet variable, but it must be done for both server and client.

Example

The following example creates a table using a BLOB column with an index.

CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));

For more information, see CREATE TABLE Statement and The BLOB and TEXT Types in the MySQL documentation.