4 Documentation Addendum

4.1.1 Specifying Unprotected Redundancy

In the section "volcreate" under "ASMCMD Volume Management Commands," the following warning applies:

4.1.2 Extended Partition Tables Are Not Supported

Extended partition tables are not supported with Oracle ASM filter driver (ASMFD) in Oracle Automatic Storage Management 12.1.

4.1.3 ASM_DISKGROUPS Initialization Parameter

The ASM_DISKGROUPS parameter is dynamic. If you are using a server parameter file (SPFILE), then you do not have to manually alter the value of ASM_DISKGROUPS except in Oracle Flex ASM configuration.

In Oracle Flex ASM configuration, Oracle ASM automatically adds a disk group to the parameter when the disk group is successfully created or mounted. Oracle ASM also automatically removes a disk group from the parameter when the disk group is dropped. However, the SPFILE is not updated on a manual dismount.

4.1.4 About Automatic Memory Management for Oracle ASM

In Chapter 3, "Administering Oracle ASM Instances", in the section titled "About Automatic Memory Management for Oracle ASM", the following should be added:

An Oracle ASM instance can automatically increase the values set for MEMORY_TARGET and MEMORY_MAX_TARGET if an ORA-04031 error is raised and automatic memory management is enabled. If MEMORY_MAX_TARGET has been explicitly set to a value, then every time ORA-04031 is raised, the MEMORY_TARGET value is increased by 10% of the existing MEMORY_TARGET value or 128 MB, whichever is greater, but not greater than the customer specified MEMORY_MAX_TARGET value. If MEMORY_MAX_TARGET is not explicitly set, then both MEMORY_TARGET and MEMORY_MAX_TARGET are increased by 10% of the existing MEMORY_TARGETT value or 128 MB, whichever is greater, for a maximum of five increases. The Oracle ASM instance must be rebooted to use the new MEMORY_TARGET and MEMORY_MAX_TARGET settings.

4.1.5 THIN_PROVISIONED Attribute

In Chapter 4, "Administering Oracle ASM Disk Groups", in the section titled "THIN_PROVISIONED", the Note should be changed to read as follows:

The THIN_PROVISIONED attribute is supported only with Oracle ASM Filter Driver (Oracle ASMFD) in Oracle Grid Infrastructure 12.2 and later releases on Linux. For information about Oracle ASMFD, refer to the section titled "Oracle ASM Filter Driver".

4.2.1 Database Checks

In Appendix A, the section titled "cluvfy comp healthcheck", the text indicates that you must create a user CVUSYS using a script to make the database checks work. This is incorrect. You must create a user DBSNMP (using uppercase characters) to make the database checks work.

4.2.2 Changing the GNS Subdomain

In Chapter 2, the section titled "Administering Grid Naming Service", the procedure was not documented regarding how to change the Grid Naming Service (GNS) subdomain when moving from an IPv4 network to an IPv6 network. The steps are:

1. Add an IPv6 subnet using the SRVCTL modify network command.

   srvctl modify network ¿subnet ipv6_subnet/
      ipv6_prefix_length[/interface] -nettype autoconfig
   

2. Update the GNS ___domain.

   srvctl stop gns -f
   srvctl stop scan -f
   srvctl remove gns -f
   srvctl add gns -vip gns_vip -___domain gns_subdomain
   srvctl start gns
   

3. Update the Single Client Access Name (SCAN) with a new ___domain.

   srvctl remove scan -f
   srvctl add scan -scanname new_domain
   srvctl start scan
   

4. Convert the network IP type from IPv4 to both IPv4 DHCP and IPv6 autoconfig.

   srvctl modify network -iptype both
   

5. Transition the network from using both protocols to using only IPv6 autoconfig using the following command:

   srvctl modify network -iptype ipv6
   

4.2.3 OCRCONFIG Utility

In Appendix I, in the section titled "About OCRCONFIG", Log Files, the correct text should be:

The OCRCONFIG utility creates a log file in <GI ORACLE_BASE>/diag/crs/<host>/crs.

To change the amount of logging, edit the path in the <GI ORACLE_BASE>/crsdata/<host>/crsdiag/<program>.ini file (for example, ocrconfig.ini).

Similar changes also apply to the last paragraph of the section titled "Using the OCRCHECK Utility" and the third paragraph of the section titled "Using the OCRDUMP Utility to View Oracle Cluster Registry Content" in Appendix I.

4.2.4 Deleting a Cluster Node

In Chapter 7, in the section titled "Deleting a Cluster Node on Linux and UNIX Systems", add the following as Steps 9 (or 7) and 10 (or 8):

Step 9 (or 7): After deleting the node where the CRS daemon is down, check if the vip for the deleted node still exists using the following command:

srvctl config vip -node deleted_node

Step 10 (or 8): Remove the vip if it still exists using the following commands:

srvctl stop vip -node deleted_node
srvctl remove vip -node deleted_node -f

Also in Chapter 7, in the section titled "Deleting a Cluster Node on Windows Systems", add the same steps as Steps 7 and 8.

4.2.5 Adding a Node to a Cluster on Windows Systems

Step 4 in the section titled "Adding a Node to a Cluster on Windows Systems" in Chapter 7 must be changed to:

C:\> ORACLE_HOME/bin/srvctl stop instance -node newly_added_node_name

4.2.6 Deleting a Rapid Home Provisioning Client

In the Chapter titled "Rapid Home Provisioning," a section with the following text describing how to delete a Rapid Home Provisioning Client should be added:

To delete a Rapid Home Provisioning Client, execute the following steps:

1. On the Rapid Home Provisioning Server:

   1. To query the list of working copies that have been provisioned on the Rapid Home Provisioning Client cluster, execute the following command:

      $ rhpctl query workingcopy -client <client_name>
      

   2. For each of the working copies listed in the output of the command in Step 1.a, execute the following command:

      $ rhpctl delete workingcopy -workingcopy <workingcopy_name>
      

   3. To query the list of users from the Rapid Home Provisioning Client cluster, execute the following command:

      $ rhpctl query user -client <client_name>
      

   4. To delete the user listed in the output of the command in Step 1.c, execute the following command:

      $ rhpctl delete user -user <username> -client <client_name>
      

2. On the Rapid Home Provisioning Client cluster, execute the following:

   1. Stop the Rapid Home Provisioning Client daemon with the following command:

      $ srvctl stop rhpclient
      

   2. Delete the Rapid Home Provisioning Client configuration using the following command:

      $ srvctl remove rhpclient
      

3. On the Rapid Home Provisioning Server cluster, execute the following command to delete the client site configuration:

   $ rhpctl delete client -client <client_name>
   

4.2.7 cluvfy comp cfs Command is Deprecated

The cluvfy comp cfs command is deprecated in release 12.1.0.2. In previous releases, you used cluvfy comp cfs component verification command to check the integrity of a clustered file system (OCFS2)

4.2.8 Automatically Manage Restart Attempts Counter for Resources

In Chapter 9, the section titled "Automatically Manage Restart Attempts Counter for Resources", replace the first three lines with the following:

When a resource fails, Oracle Clusterware attempts to restart the resource the number of times specified in the RESTART_ATTEMPTS resource attribute. Note that this attribute does not specify the number of attempts to restart a failed resource (always one attempt), but rather the number of times the resource fails locally, before the Clusterware attempts to fail it over. The CRSD process maintains an internal counter to track how often Oracle Clusterware restarts a resource. The number of times Oracle Clusterware has restarted a resource locally is reflected in the RESTART_COUNT resource attribute.

4.2.9 Table: FILESYSTEMS View Metric Descriptions

In Appendix J, the table titled "FILESYSTEMS View Metric Descriptions" in the section titled "OCLUMON Command Reference", add the following entries:

4.3.1 -force Option is Not Implemented With the remove service Command

You can ignore references to the -force option with regard to the SRVCTL remove service command. The -force option is not implemented with the remove service command.

4.3.2 Chapter 2: Creating and Configuring an Oracle Database

In the sub-section titled "About Selecting a Character Set", note the following additional information related to selected the right character set for your database:

Oracle recommends that you use AL32UTF8 as the database character set and do not use UTF8 as the database character set, because UTF8 is not a proper implementation of the Unicode encoding UTF-8. AL32UTF8 and UTF8 character sets are not compatible with each other because they have different maximum character widths. AL32UTF8 has a maximum character width of 4 bytes, whereas UTF8 has a maximum character width of 3 bytes.

4.3.3 Chapter 15: Transporting Data

In the sub-section titled "Limitations on Transportable Tablespaces", the following statements are incorrect and are not applicable for Oracle Database 12.1:

• Transportable tablespaces cannot transport encrypted tablespaces.

• Transportable tablespaces cannot transport tablespaces containing tables with encrypted columns.

4.3.4 Chapter 15: Transporting Data

In the sub-section titled "Limitations on Transportable Tables", the following statements are incorrect and are not applicable for Oracle Database 12.1:

• You cannot transport tables that are in encrypted tablespaces.

• You cannot transport tables with encrypted columns.

4.3.5 Chapter 20: Managing Tables

In the sub-section titled "Adding and Dropping Columns in Compressed Tables", the following statement is incorrect and is not applicable for Oracle Database 12.1:

• Basic table compression: You cannot specify a default value for an added column.

4.3.6 Chapter 24: Managing Views, Sequences, and Synonyms

In the sub-section titled "DELETE Statements and Join Views", note the following additional information related to the DELETE statement used for join views in the documented example:

• The DELETE statement is successful, even if it does not use the WHERE clause.

• The DELETE statement is successful, even if it uses a different column in its WHERE clause than the one that was used to create the view as a join condition.

• The DELETE statement operates on the second table in the FROM clause in all the cases, because no primary key is defined on the second table.

• If a primary key is defined on the second table, then the DELETE statement operates on the first table in the FROM clause.

4.3.7 Chapter 25: Repairing Corrupted Data

In the sub-section titled "About Repair Tables or Orphan Key Tables", the following statement is incorrect:

The ADMIN_TABLE procedure is used to create, purge, or drop a repair table or an orphan key table.

Replace this statement with the following corrected statement:

The ADMIN_TABLES procedure is used to create, purge, or drop a repair table or an orphan key table.

4.3.8 Chapter 38: Creating and Removing PDBs with SQL*Plus

In the sub-section titled "Cloning a Remote PDB or Non-CDB", it says: "The CDB and the non-CDB must be running Oracle Database 12c Release 1 (12.1.0.2) or later." However, this statement is incomplete. In addition to this functionality being available after release 12.1.0.2, if you want to clone a non-CDB to a CDB, then the non-CDB must be the same Oracle Database release. For example, while you can clone a PDB from an earlier release to a later release, and upgrade the PDB, you cannot clone a non-CDB from an earlier release to a later release, because it is not possible to upgrade the non-CDB as part of a cloning operation. If you attempt to clone an earlier release non-CDB to a later release, then you receive the following error:

ORA-65353: The undo tablespace is missing from the XML mettadata file

4.4.1 Chapter 2: RMAN Commands: @ (at sign) to QUIT (BACKUP)

The INCREMENTAL FROM SCN integer syntax element in the Semantics section of the BACKUP command should include the following statement:

Backups created using the INCREMENTAL FROM SCN integer syntax element are not displayed when you run a LIST command in the database on which the backups were created.

4.4.2 Chapter 2: RMAN Commands: @ (at sign) to QUIT (DUPLICATE)

The FOR STANDBY syntax element in the Semantics section of the DUPLICATE command should include the following Note:

Note: You cannot use the SKIP TABLESPACE, TABLESPACE, SKIP PLUGGABLE DATABASE, and PLUGGABLE DATABASE options when creating a standby database.

4.5.1 Chapter 13: Managing a Recovery Catalog

The content of the entire section titled "Creating and Managing Virtual Private Catalogs" should be replaced with the following content.

13.5 Creating and Managing Virtual Private Catalogs

RMAN provides multiple commands to create and manage virtual private catalogs.

13.5.1 Overview of Virtual Private Catalogs

By default, all of the users of an RMAN recovery catalog have full privileges to read, select, insert, update, and delete any metadata in the catalog. For example, if the administrators of two unrelated databases share the same recovery catalog, each administrator could, whether inadvertently or maliciously, destroy catalog data for the other's database. In many enterprises, this situation is tolerated because the same people manage many different databases and also manage the recovery catalog. But in other enterprises where clear separation of duty exists between administrators of various databases, and between the DBA and the administrator of the recovery catalog, you may desire to restrict each database administrator to modify only backup metadata belonging to those databases that they are responsible for, while still keeping the benefits of a single, centrally-managed, RMAN recovery catalog. This goal can be achieved by implementing virtual private catalogs.

Every RMAN recovery catalog starting with Oracle Database 11g supports virtual private catalogs, but they are not used unless explicitly created. There is no restriction on the number of virtual private catalogs that can be created beneath one recovery catalog. Each virtual private catalog is owned by a database schema user which is different than the user who owns the recovery catalog.

After you set up a virtual private catalog user, the administrator for the recovery catalog grants each virtual private catalog the privilege to use that catalog for one or more databases that are currently registered in the recovery catalog. The administrator of the recovery catalog can also grant the privilege to register new databases while using a virtual private catalog.

13.5.2 About Using the VPD Model for Virtual Private Catalogs

RMAN uses the Virtual Private Database (VPD) functionality to implement virtual private catalogs.

The VPD functionality is not enabled by default when the RMAN base recovery catalog is created. You need to explicitly enable the VPD model for a base recovery catalog by running the $ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql script after upgrading the base catalog schema.

The format of the dbmsrmanvpc.sql script is as follows:

$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql [[-vpd | -novpd | -scan ] 
base_catalog_schema_name[...]] | -all

The RMAN base catalog schema names are provided as command-line parameters when running dbmsrmanvpc.sql. You can specify a maximum of ten base catalog schema names each time you run the script.

Table 13-2 describes the options that you can use when running the dbmsrmanvpc.sql script. You must use one of the command line options or provide a catalog schema name.

Table 13-2 dbmsrmanvpc.sql Options

Example 13-1 Enabling VPD Model for VPC User Schemas

Connect to SQL*Plus and use the following command to enable the VPD model for all the virtual private catalogs of the RMAN base catalog rman_cat.

SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rman_cat

13.5.3 Creating Virtual Private Catalogs

Creating a virtual private catalog is a multi-step process in which you first create the database user who will own the virtual private catalog and then create the virtual private catalog.

Assume that the following databases are registered in the base recovery catalog: prod1, prod2, and prod3. The database user who owns the base recovery catalog is rco. You want to create database user vpc1 and grant this user access privileges only to prod1 and prod2. By default, a virtual private catalog owner has no access to the base recovery catalog.

The base RMAN recovery catalog must be created before you create virtual private catalogs.

To create a virtual private catalog:

1. Create the database user who will own the virtual private catalog and grant access privileges to this user.

   1. Start SQL*Plus and connect to the recovery catalog database with administrator privileges.

   2. Create the user who will own the virtual private catalog.

      For example, if you want database user vpc1 to own the virtual private catalog, then execute the following command (replacing password with a user-defined password):

      SQL> CREATE USER vpc1 IDENTIFIED BY password
        2  DEFAULT TABLESPACE vpcusers
        3  QUOTA UNLIMITED ON vpcusers;
      

      Note:

      Create a password that is secure. See Oracle Database Security Guide for more information.

   3. Grant the CREATE SESSION privilege to the user who owns the virtual private catalog and then exit SQL*Plus.

      The following example grants the role to user vpc1:

      SQL> GRANT CREATE SESSION TO vpc1;
      SQL> EXIT;
      

   4. Start RMAN and connect to the recovery catalog database as the base recovery catalog owner (not the virtual private catalog owner).

      The following example connects to the base recovery catalog as rco:

      % rman
      RMAN> CONNECT CATALOG rco@catdb;
      
      recovery catalog database Password: password
      connected to recovery catalog database
      

   5. Grant desired privileges to the virtual private catalog owner.

      The following example gives user vpc1 access to the metadata for prod1 and prod2 (but not prod3):

      RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1;
      RMAN> GRANT CATALOG FOR DATABASE prod2 TO vpc1;
      

      You can also use a DBID rather than a database name. The virtual private catalog user does not have access to the metadata for any other databases registered in the recovery catalog.

      You can also grant the user the ability to register new target databases in the recovery catalog. For example:

      RMAN> GRANT REGISTER DATABASE TO vpc1;
      

2. Create the virtual private catalog.

   1. Start RMAN and connect to the recovery catalog database as the virtual private catalog owner (not the base recovery catalog owner).

      The following example connects to the recovery catalog as vpc1:

      % rman
      RMAN> CONNECT CATALOG vpc1@catdb;
      

   2. Create the virtual private catalog.

      The following command creates the virtual private catalog:

      RMAN> CREATE VIRTUAL CATALOG;
      

   3. If you intend to use a 10.2 or earlier release of RMAN with this virtual private catalog, then execute the following PL/SQL procedure (where base_catalog_owner is the database user who owns the base recovery catalog):

      SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;
      

3. (Optional) Enable the VPD model for the virtual private catalog by running the dbmsrmanvpc.sql script with the vpd option.

13.5.4 Registering a Database with a Virtual Private Catalog

To store backup metadata for a target database in a virtual private catalog, you must register the database with the virtual private catalog.

Create the virtual private catalog before you register a target database with it.

To register database with a virtual private catalog and store backup metadata:

1. Start RMAN and connect to the recovery catalog database as the virtual private catalog owner (not the base recovery catalog owner). Connect to the database that you want to register as TARGET.

   %rman
   RMAN> CONNECT TARGET /
   RMAN> CONNECT CATALOG vpc1@catdb;
   

2. Register the database whose metadata must be stored in the virtual private catalog.

   The following example registers the database with the virtual private catalog owner vpc1.

   RMAN> REGISTER DATABASE;
   

3. Back up the database using the BACKUP command with the required clauses.

   Metadata related to the backup is stored in the virtual private catalog.

13.5.5 Revoking Privileges from a Virtual Private Catalog Owner

After you create a virtual private catalog, you can revoke catalog access privileges as necessary.

Assume that two databases are registered in the base recovery catalog: prod1 and prod2. As owner of the base recovery catalog, you have granted the vpc1 user access privileges to prod1. You have also granted this user the right to register databases in his virtual private catalog. Now you want to revoke privileges from vpc1.

To revoke privileges from a virtual private catalog owner:

1. Start RMAN and connect to the recovery catalog database as the recovery catalog owner (not the virtual private catalog owner).

   The following example connects to the recovery catalog as rco:

   % rman
   RMAN> CONNECT CATALOG rco@catdb;
   

2. Revoke specified privileges from the virtual private catalog owner.

   The following command revokes access to the metadata for prod1 from virtual private catalog owner vpc1:

   REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
   

   You can also specify a DBID rather than a database name. The catalog vpc1 retains all other granted catalog privileges.

   You can also revoke the privilege to register new target databases in the recovery catalog. For example:

   REVOKE REGISTER DATABASE FROM vpc1;
   

13.5.6 Dropping a Virtual Private Catalog

When you drop a virtual private catalog, you do not remove the base recovery catalog itself, but only drop the security policies that restrict access to the base recovery catalog.

This section assumes that you have created a virtual private catalog and now want to drop it.

To drop a virtual private catalog:

1. Start RMAN and connect to the recovery catalog database as the virtual private catalog owner (not the base recovery catalog owner).

   The following example connects to the recovery catalog as user vpc1:

   % rman
   RMAN> CONNECT CATALOG vpc1@catdb;
   

2. Drop the catalog.

   If you are using an Oracle Database 11g or later RMAN executable, then drop the virtual private catalog with the DROP CATALOG command:

   RMAN> DROP CATALOG;
   

   If you are using an Oracle Database 10g or earlier RMAN executable, then you cannot use the DROP CATALOG command. Instead, connect SQL*Plus to the catalog database as the virtual private catalog user, then execute the following PL/SQL procedure (where base_catalog_owner is the database user who owns the base recovery catalog):

   SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.DELETE_VIRTUAL_CATALOG;
   

13.5.7 Upgrading Virgual Private Catalogs

RMAN uses the Virtual Private Database (VPD) functionality to implement virtual private catalogs. If your database has not been upgraded to Oracle Database 12c release 2 (12.2) or you created a recovery catalog and virtual private catalogs using a version lower than Oracle Database 12c release 1 (12.1.0.2), then you must upgrade these virtual private catalogs. RMAN provides scripts, located in the $ORACLE_HOME/rdbms/admin directory, to upgrade virtual private catalogs.

To upgrade virtual private catalogs to Oracle Database 12c release 2 (12.2):

1. Use SQL*Plus to connect to the recovery catalog database as the SYS user with SYSDBA privilege.

2. Run the dbmsrmansys.sql script to grant additional privileges that are required for the RECOVERY_CATALOG_OWNER role.

   SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql
   

3. Connect RMAN to the base recovery catalog, upgrade the base recovery catalog, and then exit RMAN.

   Assume that the database user who owns the base recovery catalog is rco. The following command upgrades the base recovery catalog. The UPGRADE CATALOG command must be entered twice to confirm the upgrade.

   $ rman CATALOG rco@catdb
   recovery catalog database password: 
   RMAN> UPGRADE CATALOG;
   RMAN> UPGRADE CATALOG;
   RMAN> EXIT;
   

4. Use SQL*Plus to connect to the recovery catalog database as the SYS user with SYSDBA privilege.

5. Run the dbmsmanvpc.sql script to upgrade virtual private catalog schemas to the VPD model.

   The base recovery catalog schema name must be provided as an input parameter to this script. You can specify a maximum of 10 schema names. Alternately, you can use the -all option to automatically detect base catalog schemas and upgrade all associated virtual private catalog schemas.

   The following command upgrades the virtual private catalog schemas of the base recovery catalog owned by rco:

   SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql rco
   

   See Also:

   About Using the VPD Model for Virtual Private Catalogs for information about the dbmsrmanvpc.sql script and its options

4.5.2 Chapter 24: Duplicating a Database

In the sub-section titled "Step 2: Choosing a Strategy for Naming Duplicate Files" of the section titled "Preparing to Duplicate a Database", the parameter name in the second bullet needs to be changed from DB_FILE_CREATE_DEST to DB_CREATE_FILE_DEST.

4.9.1 Chapter 5: Parameters for the sqlnet.ora File

Note the following changes with regard to Section 5.2 titled "sqlnet.ora Profile Parameters".

1.2

undertermined | 3.0 | 1.0 | 1.1 | 1.2

1.0 or 3.0 | 1.2 or 3.0 | 1.1 or 1.0 | 1.2 or 1.0 | 1.2 or 1.1 | 1.1 or 1.0 or 3.0 | 1.2 or 1.0 or 3.0 | 1.2 or 1.1 or 1.0 | 1.2 or 1.1 or 3.0 | 1.2 or 1.1 or 1.0 or 3.0

SSL_VERSION=1.2

4.9.2 Chapter 6: Local Naming Parameters in the tnsnames.ora File

Note the following changes with regard to Oracle Database Net Services Reference, part number E17611.

net_service_name=
  (DESCRIPTION=
    (ADDRESS=...)
    (ADDRESS=...)
    (CONNECT_DATA=
      (SID=sales6)
    (HS=ok)))

4.9.3 Chapter 7: Oracle Net Listener Parameters in the listener.ora File

In the sub-section titled "Control Parameters", the following section should be added:

SSL_VERSION

Purpose

To limit allowable SSL or TLS versions used for connections.

Usage Notes

Clients and database servers must use a compatible version. This parameter should only be used when absolutely necessary for backward compatibility. The current default uses TLS version 1.2 which is the version required for multiple security compliance requirements.

Default

1.2

Values

undetermined | 3.0 | 1.0| 1.1 | 1.2

If you want to specify one version or another version, then use ”or”. The following values are permitted:

1.0 or 3.0 | 1.2 or 3.0 | 1.1 or 1.0 | 1.2 or 1.0 | 1.2 or 1.1 | 1.1 or 1.0 or 3.0 |

1.2 or 1.0 or 3.0 | 1.2 or 1.1 or 1.0 | 1.2 or 1.1 or 3.0 | 1.2 or 1.1 or 1.0 or 3.0

Example

SSL_VERSION=1.2

The remaining version numbers correspond to the TLS versions, such as, TLSv1.0, TLSv1.1, and TLSv1.2.

4.9.4 Chapter 8: Oracle Connection Manager Parameters (cman.ora)

In the sub-section titled "INBOUND_CONNECT_TIMEOUT" in the section titled "Oracle Connection Manager Parameters", the first bullet under Values must read as follows:

• 60 secs is the default. Use value 0 to disable timeout.

4.9.5 RECV_BUF_SIZE Parameter

In Chapter 6, the sub-section titled "RECV_BUF_SIZE" in the section titled "Optional Parameters for Address Lists", the documented default value for the RECV_BUF_SIZE parameter is incorrect. The correct default for Linux 2.6 operating system is 87380 bytes.

In Chapter 7, the sub-section titled "RECV_BUF_SIZE" in the section titled "Protocol Address Parameters", the documented default value for the RECV_BUF_SIZE parameter is incorrect. The correct default for Linux 2.6 operating system is 87380 bytes.

4.9.6 SQLNET.EXPIRE_TIME Parameter

In Chapter 5, the section titled "SQLNET.EXPIRE_TIME", add the following point as a limitation in the Usage Notes:

• The use of SQLNET.EXPIRE_TIME with TCPS is unsupported.

4.15.1 Chapter 2: Data Pump Export

Note the following with regard to the section titled "Parameters Available in Export's Command-Line Mode".

4.15.2 Chapter 3: Data Pump Import

Note the following with regard to the section titled "Parameters Available in Import's Command-Line Mode".

4.15.3 Chapter 13: SQL*Loader Express

The default documented for the DIRECT parameter in the section titled "SQL*Loader Express Mode Parameter Reference" is not FALSE. There is no default.

4.15.4 Chapter 15: The ORACLE_LOADER Access Driver

The syntax for the FIELD NAMES clause in the section titled "record_format_info Clause" should appear as follows:

FIELD NAMES {FIRST FILE | FIRST IGNORE | ALL FILES | ALL IGNORE | NONE}

The FILE keyword was missing from FIRST and the FILES keyword was missing from ALL. The option descriptions following the syntax diagram should also be corrected accordingly.

4.15.5 Chapter 18: DBVERIFY: Offline Database Verification Utility

In the sub-section titled "DBVERIFY Parameters When Validating Blocks of a Single File" in the section titled "Using DBVERIFY to Validate Disk Blocks of a Single Data File", the description for the USERID parameter must read as follows:

Specifies your username and password. This parameter is not necessary for Oracle ASM files.

4.16.1 Chapter 4: Performing Privilege Analysis to Find Privilege Use

The section titled "What Is Privilege Analysis?" incorrectly states that the privilege analysis feature is included in Oracle Database Vault. See Oracle Database Licensing Information User Manual for current licensing information for privilege analysis.

4.16.2 Appendix C: Postinstallation Oracle Database Vault Procedures

In the section titled "Deinstalling Oracle Database Vault, the following should be added:

You cannot deinstall Database Vault from databases in a multitenant environment. This procedure only applies to legacy, non-CDB Oracle Database environments.

4.18.1 Restricted Service Registration

In Chapter 5, the section titled "Restricted Service Registration", a note should be added with the following information:

The save_config command cannot make the settings of the valid node checking for registration (VNCR) parameter to persist.

4.18.2 Database Fails to Start After Using a New Private NIC

In the Appendix titled "Troubleshooting Oracle RAC", the following section should be added:

Database Fails to Start After Using a New Private NIC

After installing Oracle Clusterware and Oracle Flex ASM, when a new private network interface card (NIC) that was added is used, the database fails to start the ora.storage resource. Manually update the listener after adding the new NIC for Oracle Flex ASM.

4.18.3 Stopping Instances and Services

In Appendix A, the section titled "srvctl stop instance", the paragraph and the syntax should read as follows:

The srvctl stop instance command stops instances and stops any services running on specified instances.

Syntax

srvctl stop instance -db db_unique_name {-node node_name
    | -instance "instance_name_list"} [-stopoption stop_options] [-force] [-failover]

Parameters

-failover
 
-force

If you specify -failover, then the services fail over to an available instance when the instance stops.

-force is required only to forcibly stop the instance and any running services if the stop instance command fails with an error.

4.18.4 Overview of In-Memory Column Store with Oracle RAC

In the section titled "Overview of In-Memory Column Store with Oracle RAC", the paragraph that begins with "On an Engineered System an object ..." needs to be changed to read as follows:

On an Engineered System, it is possible to duplicate or mirror objects populated in memory across the In-Memory Column Store (IM column store) in the cluster. This provides the highest level of redundancy. The DUPLICATE clause is used to control how an object should be duplicated across the IM column stores in the cluster. If you specify just DUPLICATE, then one mirrored copy of the data is distributed across the IM column stores in the cluster. If you want to duplicate the entire object in each IM column store in the cluster, specify DUPLICATE ALL.

4.18.5 Converting Databases to Oracle RAC Using Oracle Enterprise Manager

In Chapter 14, the section titled "Converting Databases to Oracle RAC Using Oracle Enterprise Manager", remove step 4 and replace step 3 with the following:

3. On the Database home page, from the Availability menu, select Convert to Cluster Database.

4.18.6 Starting and Stopping Listeners

In Appendix A, the sections titled "srvctl start listener" and "srvctl stop listener", the following text is incorrect in the tables:

"If you do not specify this parameter, then the listener name defaults to LISTENER for a database listener; LISTENER_ASM for an Oracle ASM listener; or LISTENER_LEAF for a Leaf Node listener."

• The correct text for "srvctl start listener" should be:

  "If you do not specify this parameter, then all the known listeners are started."

• The correct text for "srvctl stop listener" should be:

  "If you do not specify this parameter, then all the known listeners are stopped."

4.20.1 Chapter 11: Using XML Query Result Set Interface

The first paragraph in the section titled "Using the XML Query Result Set Interface" should be changed to read:

The CTX_QUERY.RESULT_SET() and CTX_QUERY.RESULT_SET_CLOB_QUERY() APIs enable you to obtain query results with a single query, rather than running multiple CONTAINS() queries to achieve the same result. The two APIs are identical except that one uses a VARCHAR2 query parameter, and the other uses a CLOB query parameter to allow for longer queries.

4.21.1 Chapter 1: Oracle Text SQL Statements and Operators

Note the following changes:

• In the sub-section titled "Notes" under the main section titled "ALTER INDEX", the following item should be documented in the bulleted list:

  • You cannot have embedded blanks in section and field names.

  According to Bug 21330358, field names cannot use embedded blanks. For example, my section is an invalid section name since there is a blank just after my. This applies to field names that are defined using "".

• Although the ALTER INDEX OPTIMIZE operation for Text Indexes was desupported in Oracle Database 12c release 1 (12.1), it was not removed from the Oracle Text Reference document.

4.21.2 Chapter 2: Oracle Text Indexing Elements

This chapter should include the following section:

Token Limitations

All Oracle Text index types store tokens in a table column of type VARCHAR2 (64 BYTE). This means that the maximum size of an indexed token is 64 characters for single–byte character sets, and is less with multibyte or variable-length character sets. Any longer tokens are truncated at 64 bytes. That does not mean that the token cannot be searched for, but rather that the system cannot distinguish between the two tokens which have the same first 64 bytes.

4.21.3 Chapter 8: CTX_DDL Package

For the ADD_STOPCLASS procedure, English is the only language supported for stopclasses.

4.21.4 Chapter 9: CTX_DOC Package

In the Syntax 1 and Syntax 2 examples for the POLICY_SNIPPET and SNIPPET procedures, the default value for max_length is 150 and not 250.

4.21.5 Chapter 12: CTX_QUERY Package

This chapter should contain the following new section:

RESULT_SET_CLOB_QUERY

This procedure executes an XML query and generates a result set based on a CLOB query parameter in XML.

The RESULT_SET_CLOB_QUERY procedure is identical to the RESULT_SET procedure except that the data type of its query parameter is CLOB instead of VARCHAR2 to handle longer queries.

Syntax

CTX_QUERY.RESULT_SET_CLOB_QUERY (
   index_name            IN VARCHAR2,
   query                 IN CLOB,
   result_set_descriptor IN CLOB,
   result_set            IN OUT CLOB,
   part_name             IN VARCHAR2 DEFAULT 
);

4.21.6 Appendix B: Section: Oracle Text Supported Document Formats

In Appendix B titled "Oracle Text Supported Document Formats", Oracle Text does not extract text for the following file formats:

• IBM Lotus Notes NSF (File ID) 7.x, 8.x

• IBM Lotus Notes NSF (Windows, Linux x86-32 and Oracle Solaris 32-bit only with Notes Client or Domino Server) 8.x