1 System Requirements and Preinstallation Instructions

This section shows the disk requirements for a manual installation and for an installation through OUI.

Table 1-1 shows the disk space that is consumed by the files of one Oracle GoldenGate installation in a manual build. A manual build does not use OUI. The person installing Oracle GoldenGate uncompresses the files and creates the working directories.

Table 1-2 shows the disk space that is consumed by the files of one Oracle GoldenGate installation when OUI is used.

In addition to the disk space required for the files and binaries that are installed by Oracle GoldenGate, allow an additional 1 GB of disk space on any system that hosts the Oracle GoldenGate trail (or trails). A trail is a set of self-aging files that contain the working data at rest and during processing. You may need more or less than this amount, because the space that is consumed by the trails depends on the volume of data that will be processed. See the guidelines for sizing trails in Administering Oracle GoldenGate for Windows and UNIX.

Disk space is also required for the Oracle GoldenGate Bounded Recovery feature. Bounded Recovery is a component of the general Extract checkpointing facility. It caches long-running open transactions to disk at specific intervals to enable fast recovery upon a restart of Extract. At each bounded recovery interval (controlled by the BRINTERVAL option of the BR parameter) the disk required is as follows: for each transaction with cached data, the disk space required is usually 64k plus the size of the cached data rounded up to 64k. Not every long-running transaction is persisted to disk. For complete information about Bounded Recovery, see the BR parameter in Reference for Oracle GoldenGate for Windows and UNIX.

To install Oracle GoldenGate into a cluster environment using the Oracle GoldenGate MASA, you need only to install the Oracle GoldenGate read only home directory and then create custom deployment specific directories. For more information, see Preparing to Install Oracle GoldenGate Within a Cluster.

By default, Oracle GoldenGate maintains data that it writes to disk in the dirtmp sub-directory of the Oracle GoldenGate installation directory. When total cached transaction data exceeds the CACHESIZE setting of the CACHEMGR parameter, Extract will begin writing cache data to temporary files. The cache manager assumes that all of the free space on the file system is available. This directory can fill up quickly if there is a large transaction volume with large transaction sizes. To prevent I/O contention and possible disk-related Extract failures, dedicate a disk to this directory. You can assign a name to this directory with the CACHEDIRECTORY option of the CACHEMGR parameter.

It is typically more efficient for the operating system to swap to disk than it is for Extract to write temporary files. The default CACHESIZE setting assumes this. Thus, there should be sufficient disk space to account for this, because only after the value for CACHESIZE is exceeded will Extract write transaction cached data to temporary files in the file system name space. If multiple Extract processes are running on a system, the disk requirements can multiply. Oracle GoldenGate writes to disk when there is not enough memory to store an open transaction. Once the transaction has been committed or rolled back, committed data is written to trail files and the data are released from memory and Oracle GoldenGate no longer keeps track of that transaction. There are no minimum disk requirements because when transactions are committed after every single operations these transactions are never written to disk.

• Your source database compatibility must be set to 11.2.0.0.0 or higher. Support for named collections and VARRAYs embedded within those data types.

The support of the range and precision for floating-point numbers depends on the host machine. In general, the precision is accurate to 16 significant digits, but you should review the database documentation to determine the expected approximations. Oracle GoldenGate rounds or truncates values that exceed the supported precision.

• If an extended VARCHAR column is part of unique index or constraint, then direct path inserts to this table may cause Replicat to abend with a warning. Verify that the extended VARCHAR caused the abend by checking all_indexes/all_ind_columns for a unique index or all_cons_columns/all_constraints for a unique constraint. Once you determine that an extended VARCHAR, you can temporarily drop the index or disable the constraint:

  For Unique Index:

  drop index t2u;

  For Unique Constraint:

  alter table v32ind modify constraint sys_c0010125 disable;

• Extended (32K) VARCHAR2 and NVARCHAR2 columns are supported when Extract is in integrated capture mode. All modes of Replicat support 32K VARCHAR2 and NVARCHAR2 columns. The following limitations apply:

  • Oracle GoldenGate does not support 32K VARCHAR2 and NVARCHAR2 columns as part of a key or unique index, nor as a column in a KEYCOLS clause of the TABLE or MAP parameter. 32K columns cannot be used as row identifiers because they are not supplementally logged even when part of a primary key.

  • 32K columns are not supported as resolution columns in a CDR (conflict resolution and detection) configuration nor as the basis for any other work that requires a column value to be present in the transaction log.

  • Oracle GoldenGate does not limit the number of 32K columns, but each trail record has a length limit of 4MB for inline records. The number of 32K columns that reaches this limit is approximately 160 columns, but the number of columns also depends on the actual size of the extended VARCHAR2 column.

• For Oracle GoldenGate to support multi-byte character data, the source and target databases must be logically identical in terms of schema definition for the tables and sequences being replicated. Transformation, filtering, and other manipulation are not supported. The character sets between the two databases must be one of the following:

  • Identical, for example SHIFT-JIS on the source and on the target.

  • Equivalent, which is not the same character set but containing the same set of characters, for example SHIFT-JIS and EUC-JP.

  • Target is superset of the source: For example, UNICODE is a superset of all character types, and therefore of any other character set.

• Multi-byte data is supported whether the length semantics are in bytes or characters.

For additional configuration requirements, see Handling Special Data Types.

• Oracle GoldenGate does not support negative dates.

• INTERVAL DAY and INTERVAL YEAR are supported only if the size of the target column is equal to, or greater than, that of the source.

• Oracle GoldenGate supports the capture and replication of TIMESTAMP WITH TIME ZONE as a UTC offset (TIMESTAMP '2011-01-01 8:00:00 -8:00').

• TIMESTAMP WITH TIME ZONE as TZR (Region ID) is supported for the replication of data changes, but not for initial loads, for SQLEXEC, or for operations where the column must be fetched from the database. In these cases, the region ID is converted to a time offset by the database when the column is selected. Replicat replicates the timestamp as date and time data with a time offset value.

• Oracle GoldenGate supports timestamp data from 0001/01/03 00:00:00 to 9999/12/31 23:59:59. If a timestamp is converted from GMT to local time, these limits also apply to the resulting timestamp. Depending on the time zone, conversion may add or subtract hours, which can cause the timestamp to exceed the lower or upper supported limit.

• Oracle GoldenGate supports time offset values between +12:00 and -12:00.

To support TIMESTAMP WITH TIME ZONE specified as TZR properly, and also to handle TIMESTAMP WITH LOCAL TIMEZONE properly.

• Oracle GoldenGate does not support the filtering, column mapping, or manipulation of large objects larger than 4K.

• Assuming DDL support is enabled, Oracle GoldenGate replicates the CTAS statement and allows it to select the data from the underlying target table(s). This is controlled using the GET_CTAS_DMLS parameter and applies to all typed tables. If the parameter is used, the OIDs are preserved.

• BASICFILE option LOBs are captured from the redo log, but are fetched from the database in the following circumstances:

  • Extract determines the LOB is invalid.

  • The LOB data is not in the redo log, which occurs when the BASICFILE LOB is created with the NOLOGGING option.

  • The LOB is created with the CACHE option.

  • The LOB is only partially updated. Oracle GoldenGate does not support partial column data. Extract assumes LOB data to be incomplete if the LOB does not start with a LOB reset record, or if the LOB does not start at the first byte and does not end at the last byte, according to the new LOB length. Partial updates can be generated by the following OCI calls: OCILOBWrite(), OCILobAppend(), OCiLobCopy(), OCILobLoadFromFile(), OCILobTrim(), and by updates made through procedures in the dbms_lob package.

  • Extract detects an anomaly in the LOB data.

• SECUREFILE option LOBs are captured from the redo logs only when the update is complete and the LOB is not transformed (the column is not compressed or encrypted or deduplicated) and stored out-of-row. SECUREFILE LOBs are fetched from the database in the following circumstances:

  • The LOB is stored in-row.

  • The LOB is transformed either with compression or encryption.

  • The LOB is created with the CACHE attribute.

  • Extract determines that a LOB instance is invalid.

  • LOB data is missing from the redo log. This can occur if the LOB is created with any of following options: DEDUPLICATE, NOLOGGING, FILESYSTEM_LIKE_LOGGNG.

  • The LOB is updated using OCILOBWrite(), OCILobAppend(), OCiLobCopy(), OCILobLoadFromFile(), OCILobTrim(), or through procedures in the dbms_lob package.

  • Any other anomalies as detected by Extract.

• When changing a SECUREFILE LOB from one storage to another (such as from ENCRYPT to DECRYPT), Oracle updates the whole table, and Extract captures those updates from the log. Therefore, it will appear as though Oracle updated all of the data blocks that are associated with the table. This also can happen when an ALTER TABLE command sets a DEFAULT value to a column that has null values.

• In a manage bundled agents (XAG) high availability environment that has tables containing JavaScript Object Notation (JSON) columns, Extracts can extract this data though the default Replicat mode cannot replicate the data. You must set the DBOPTIONS NOSKIPTEMPLOB parameter to avoid Replicat abending.

The following are not supported:

• Filtering and manipulation are not supported. You can map the XML representation of an object to a character column by means of a COLMAP clause in a TABLE or MAP statement.

• Oracle recommends the AL32UTF8 character set as the database character set when working with XML data. This ensures the correct conversion by Oracle GoldenGate from source to target.

• Hierarchy-enabled tables are managed by the Oracle XML database repository and are supported with procedural logging.

• Assuming DDL support is enabled, Oracle GoldenGate replicates the CTAS statement and allows it to select the data from the underlying target table(s). This is controlled using the TRANSLOGOPTIONS GETCTASDML parameter and applies to all typed tables. If the parameter is used, the OIDs are preserved. For XMLType tables, the row object IDs must match between source and target, which cannot be maintained when Replicat uses logical SQL statements. XMLType tables created by an empty statement (that does not insert data in the new table) can be maintained correctly.

• XMLType tables with primary key-based object identifiers (OID)

• Relational tables with a single XML column

• SQL* Loader direct-path insert for XML Binary and XML Object Relational

• XML Schema-based XMLType are supported, but changes made to XML Schemas are not replicated and must be registered on both source and target databases with the DBMS_XMLSCHEMA package.

• Tables that contain XMLType columns must have at least one unique key constraint that is made up of scalar columns, or the combination of all scalar columns must guarantee uniqueness. Extract or Replicat cannot use unique or primary key constraints made up of XML attributes for row identification purposes.

• XML OR and XML Binary, for native capture. XML binary/OR will be fetched if compatible with releases greater than 11.2.0.3.

• XML CLOB, source database compatibility is with releases greater than 11.0.0.0.0.

• The maximum length for the entire SET value of an update to an XMLType is 32K, including the new content plus other operators and XQuery bind values.

• For XML Binary, Oracle GoldenGate fetches additional row data from the source database. Because the fetched data may not part of the original transaction, it may lead to inconsistency.

• XML Object Relational is not supported in classic capture mode.

See Handling Special Data Types for additional information about replicating XML.

• Redo-based supports most attribute types, but falls back to fetching from source table when UDT contains:

  • Nested Table

  • SDO_TOPO_GEOMETRY

  • SDO_GEORASTER

• Fetch-based does not support UDT that contains:

  • ANYDATA

  • TIMESTAMP WITH TIMEZONE

  • TIMESTAMP WITH LOCAL TIMEZONE

  • INTERVAL YEAR TO MONTH

  • INTERVAL DAY TO SECOND

  • BINARY FLOAT

  • BINARY DOUBLE

  • BFILE

• Oracle GoldenGate does not support UDTs that contain:

  • CFILE

  • REF

  • OPAQUE (with exception of XMLType and ANYDATA:

• A table that contains a UDT must have one of the following: a primary key, column(s) with a unique constraint, or a unique index.

• Object or relational tables where the key contains a UDT, or where a UDT is the only column, are not supported.

• The RMTTASK parameter does not support UDT.

• CHAR and VARCHAR attributes that contain binary or unprintable characters are not supported.

• UDTs, including values inside object columns or rows, cannot be used within filtering criteria in TABLE or MAP statements, or as input or output for the Oracle GoldenGate column-conversion functions, SQLEXEC, or other built-in data-manipulation tools. Support is only provided for like-to-like Oracle source and targets.

• UDT and nested tables are supported with the following limitations:

  • Nested table UDTs cannot contain CHAR, NVARCHAR2, or NCLOB attributes.

  • Nested tables are not supported if there are extended (32k) VARCHAR2 or RAW attributes in UDTs.

  • Nested tables are not supported if there are CLOB or BLOB attributes in UDTs.

  • Nested table columns/attributes that are part of any other UDT are not supported.

• When data in a nested table is updated, the row that contains the nested table must be updated at the same time.

• When VARRAYS and nested tables are fetched, the entire contents of the column are fetched each time, not just the changes.

Integrated Capture Only (Redo-based)

• Redo-based captures object tables from redo when compatible with Oracle Database 12.2 and greater, but falls back to fetching from source table when an object table contains the following attributes:

  • Nested table
  • SDO_TOPO_GEOMETRY
  • SDO_GEORASTER

  These objects are only fetched if they are compatible with Oracle GoldenGate 12.2.x.

• To fully support object tables created with CREATE TABLE as SELECT (CTAS) statement, Integrated Capture must be configured to capture DML from the CTAS statement. For more information about CTAS, see CREATE TABLE AS SELECT.

• An Oracle object table can be mapped to a non-Oracle object table in a supported target database.

Classic and Integrated Capture (Fetch-based)

• Fetch-based fetches all leaf-level attributes, as well as, root-level LOB, XML, UDT, ANYDATA, and collection attributes.

• Fetch-based does not support object tables that contain the following leaf-level attributes:

  • ANYDATA
  • TIMESTAMP WITH TIMEZONE
  • TIMESTAMP WITH LOCAL TIMEZONE
  • INTERVAL YEAR TO MONTH
  • INTERVAL DAY TO SECOND
  • BINARY FLOAT
  • BINARY DOUBLE

• Oracle GoldenGate supports object tables in uni-directional and active-active configurations. Object tables are captured from the redo log, but certain data types that are fetched from the database when in regular relational tables, such as LOBs and collection types, are also fetched when in object tables. Similarly, current limitations that apply to collection types when in regular tables also apply to these types when in object tables.

• A primary key must be defined on the root-level object attributes of the object table, and cannot include leaf-level attributes. If no key is defined, Oracle GoldenGate will use all useable columns as a pseudo-key.

• Oracle GoldenGate does not support the replication of DDL operations for an object table. This limitation includes the database object versioning that is associated with ALTERs of object tables.

• Synonyms are not supported for object tables or object types that contain object tables.

Oracle GoldenGate supports SDO_GEOMETRY, SDO_TOPO_GEOMETRY, and SDO_GEORASTER (raster tables).

See additional configuration information in Handling Special Data Types in Installing and Configuring Oracle GoldenGate for Oracle Database.

These limitations apply to integrated and classic capture modes.

• Oracle GoldenGate supports tables that contain any number of rows.

• A row can be up to 4 MB in length. If Oracle GoldenGate is configured to include both the before and after image of a column in its processing scope, the 4 MB maximum length applies to the total length of the full before image plus the length of the after image. For example, if there are UPDATE operations on columns that are being used as a row identifier, the before and after images are processed and cannot exceed 4 MB in total. Before and after images are also required for columns that are not row identifiers but are used as comparison columns in conflict detection and resolution (CDR). Character columns that allow for more than 4 KB of data, such as a CLOB, only have the first 4 KB of data stored in-row and contribute to the 4MB maximum row length. Binary columns that allow for more than 4kb of data, such as a BLOB the first 8 KB of data is stored in-row and contributes to the 4MB maximum row length.

• Oracle GoldenGate supports the maximum number of columns per table that is supported by the database.

• Oracle GoldenGate supports the maximum column size that is supported by the database.

• Oracle GoldenGate supports tables that contain only one column, except when the column contains one of the following data types:

  • LOB

  • LONG

  • LONG VARCHAR

  • Nested table

  • UDT

  • VARRAY

  • XMLType

• Oracle GoldenGate supports tables with unused columns, but the support is disabled by default, and Extract abends on them. See Handling Other Database Properties.

• Oracle GoldenGate supports tables with these partitioning attributes:

  • Range partitioning

  • Hash Partitioning Interval Partitioning

  • Composite Partitioning

  • Virtual Column-Based Partitioning

  • Reference Partitioning

  • List Partitioning

  See Handling Other Database Properties.

• Oracle GoldenGate supports tables with virtual columns, but does not capture change data for these columns or apply change data to them: The database does not write virtual columns to the transaction log, and the Oracle Database does not permit DML on virtual columns. For the same reason, initial load data cannot be applied to a virtual column. You can map the data from virtual columns to non-virtual target columns. See Handling Other Database Properties.

• Oracle GoldenGate will not consider unique/index with virtual columns.

• Oracle GoldenGate supports replication to and from Oracle Exadata. To support Exadata Hybrid Columnar Compression, Extract must operate in integrated capture mode. To support Exadata Hybrid Columnar Compression, the source database compatibility must be set to 11.2.0.0.0 or higher.

• Oracle GoldenGate supports Transparent Data Encryption (TDE).

  • Extract supports TDE column encryption and TDE table space encryption without setup requirements in integrated capture mode. For integrated capture, the source database must be Oracle version 11.1.0 with compatibility setting of 11.0.0.0 or higher.

  • In classic capture mode, Extract supports column encryption for all versions of Oracle 11.1 and 11.2. Tablespace encryption is supported for all versions of Oracle 11.2.0.1. TDE in classic capture mode requires some setup. .

• Oracle GoldenGate supports TRUNCATE statements as part of its DDL replication support, or as standalone functionality that is independent of the DDL support. See Handling Other Database Properties.

• Oracle GoldenGate supports the capture of direct-load INSERT, with the exception of SQL*Loader direct-path insert for XML Binary and XML Object Relational as described in Limitations of Support — Integrated and Classic Capture Modes. Supplemental logging must be enabled, and the database must be in archive log mode. The following direct-load methods are supported.

  • /*+ APPEND */ hint

  • /*+ PARALLEL */ hint (Not supported for RAC in classic capture mode)

  • SQLLDR with DIRECT=TRUE

• Oracle GoldenGate fully supports capture from compressed objects when Extract is in integrated capture mode. The source database version must be 11.2.0.0 or higher if capturing from a downstream mining database or 11.2.0.3 if the source database is the mining database. Extract in classic capture mode does not support compressed objects.

• Oracle GoldenGate supports XA and PDML distributed transactions in integrated capture mode. Extract in classic capture mode does not support PDML or XA on RAC.

• Oracle GoldenGate supports DML operations on tables with FLASHBACK ARCHIVE enabled. However, Oracle GoldenGate does not support DDL that creates tables with the FLASHBACK ARCHIVE clause or DDL that creates, alters, or deletes the flashback data archive itself.

These limitations apply to classic capture mode.

• IOT with key compression enabled (indicated by the COMPRESS keyword in the key_compression clause) is not supported in classic capture mode, but is supported in integrated capture mode.

These limitations apply to integrated and classic capture modes.

• Oracle GoldenGate supports capture from a view when Extract is in initial-load mode (capturing directly from the source view, not the redo log).

• Oracle GoldenGate does not capture change data from a view, but it supports capture from the underlying tables of a view.

• Oracle GoldenGate can replicate to a view as long as the view is inherently updateable. The structures of the source tables and a target view must be identical.

Materialized views are supported by Extract in classic and integrated modes with the following limitations.

• Materialized views created WITH ROWID are not supported.

• The materialized view log can be created WITH ROWID.

• The source table must have a primary key.

• Truncates of materialized views are not supported. You can use a DELETE FROM statement.

• DML (but not DDL) from a full refresh of a materialized view is supported. If DDL support for this feature is required, open an Oracle GoldenGate support case.

• For Replicat the Create MV command must include the FOR UPDATE clause

• Either materialized views can be replicated or the underlying base table(s), but not both.

Indexed clusters are supported in both integrated and classic capture modes while hash clusters are not supported in either modes. In classic capture mode the following limitations apply:

• Encrypted and compressed clustered tables are not supported in classic capture.

• Extract in classic capture mode captures DML changes made to index clustered tables if the cluster size remains the same. Any DDL that causes the cluster size to increase or decrease may cause Extract to capture subsequent DML on that table incorrectly.

These limitations apply to integrated and classic capture modes.

• Oracle GoldenGate does not support the replication of sequence values in an active-active bi-directional configuration.

• The cache size and the increment interval of the source and target sequences must be identical. The cache can be any size, including 0 (NOCACHE).

• The sequence can be set to cycle or not cycle, but the source and target databases must be set the same way.

See configuration requirements in Handling Special Data Types in Installing and Configuring Oracle GoldenGate for Oracle Database.

The following names or name prefixes are considered Oracle-reserved and must be excluded from the Oracle GoldenGate DDL configuration. Oracle GoldenGate will ignore objects that contain these names.

Excluded schemas:

  "ANONYMOUS", // HTTP access to XDB
  "APPQOSSYS", // QOS system user
  "AUDSYS", // audit super user
  "BI", // Business Intelligence
  "CTXSYS", // Text
  "DBSNMP", // SNMP agent for OEM
  "DIP", // Directory Integration Platform
  "DMSYS", // Data Mining
  "DVF", // Database Vault
  "DVSYS", // Database Vault
  "EXDSYS", // External ODCI System User
  "EXFSYS", // Expression Filter
  "GSMADMIN_INTERNAL", // Global Service Manager
  "GSMCATUSER", // Global Service Manager
  "GSMUSER", // Global Service Manager
  "LBACSYS", // Label Security
  "MDSYS", // Spatial
  "MGMT_VIEW", // OEM Database Control
  "MDDATA",
  "MTSSYS", // MS Transaction Server
  "ODM", // Data Mining
  "ODM_MTR", // Data Mining Repository
  "OJVMSYS", // Java Policy SRO Schema
  "OLAPSYS", // OLAP catalogs
  "ORACLE_OCM", // Oracle Configuration Manager User
  "ORDDATA", // Intermedia
  "ORDPLUGINS", // Intermedia
  "ORDSYS", // Intermedia
  "OUTLN", // Outlines (Plan Stability)
  "SI_INFORMTN_SCHEMA", // SQL/MM Still Image
  "SPATIAL_CSW_ADMIN", // Spatial Catalog Services for Web
  "SPATIAL_CSW_ADMIN_USR",
  "SPATIAL_WFS_ADMIN", // Spatial Web Feature Service
  "SPATIAL_WFS_ADMIN_USR",
  "SYS",
  "SYSBACKUP",
  "SYSDG",
  "SYSKM",
  "SYSMAN", // Adminstrator OEM
  "SYSTEM",
  "TSMSYS", // Transparent Session Migration
  "WKPROXY", // Ultrasearch
  "WKSYS", // Ultrasearch
  "WK_TEST",
  "WMSYS", // Workspace Manager
  "XDB", // XML DB
  "XS$NULL",
  "XTISYS", // Time Index

Special schemas:

  "AURORA$JIS$UTILITY$", // JSERV
  "AURORA$ORB$UNAUTHENTICATED", // JSERV
  "DSSYS", // Dynamic Services Secured Web Service
  "OSE$HTTP$ADMIN", // JSERV
  "PERFSTAT", // STATSPACK
  "REPADMIN",
  "TRACESVR" // Trace server for OEM

Excluded tables (the * wildcard indicates any schema or any character):

  "*.AQ$*", // advanced queues
  "*.DR$*$*", // oracle text
  "*.M*_*$$", // Spatial index
  "*.MLOG$*", // materialized views
  "*.OGGQT$*",
  "*.OGG$*", // AQ OGG queue table
  "*.ET$*", // Data Pump external tables
  "*.RUPD$*", // materialized views
  "*.SYS_C*", // constraints
  "*.MDR*_*$", // Spatial Sequence and Table
  "*.SYS_IMPORT_TABLE*",
  "*.CMP*$*", // space management, rdbms >= 12.1
  "*.DBMS_TABCOMP_TEMP_*", // space management, rdbms < 12.1
  "*.MDXT_*$*" // Spatial extended statistics tables

Oracle GoldenGate does not support the following:

• DDL on nested tables.

• DDL on identity columns.

• ALTER DATABASE and ALTER SYSTEM (these are not considered to be DDL) When using Integrated Dictionary you can replicate ALTER DATABASE DEFAULT EDITION and ALTER PLUGGABLE DATABASE DEFAULT EDITION. All other ALTER [PLUGABLE] DATABASE commands are ignored.

• DDL on a standby database.

• Database link DDL.

• DDL that creates tables with the FLASHBACK ARCHIVE clause and DDL that creates, alters, or deletes the flashback data archive itself. DML on tables with FLASHBACK ARCHIVE is supported.

• Classic capture mode does not support DDL that includes password-based column encryption, such as:

  • CREATE TABLE t1 (a number, b varchar2(32) ENCRYPT IDENTIFIED BY my_password);

  • ALTER TABLE t1 ADD COLUMN c varchar2(64) ENCRYPT IDENTIFIED BY my_password;