4 Documentation Addendum

This section contains corrections to the following Oracle Documentation for this release:

Section 4.1, "Oracle Automatic Storage Management Administrator's Guide"

Section 4.2, "Oracle Clusterware Administration and Deployment Guide"

Section 4.3, "Oracle Database Administrator's Guide"

Section 4.4, "Oracle Database Backup and Recovery Reference"

Section 4.5, "Oracle Database Backup and Recovery User's Guide"

Section 4.6, "Oracle Database JDBC Java API Reference"

Section 4.7, "Oracle Database Net Services Reference"

Section 4.8, "Oracle Database New Features Guide"

Section 4.9, "Oracle Database Performance Tuning Guide"

Section 4.10, "Oracle Database PL/SQL Packages and Types Reference"

Section 4.11, "Oracle Database Reference (E40402, 11.2)"

Section 4.12, "Oracle Database Reference (E41527, 12.1)"

Section 4.13, "Oracle Database Utilities"

Section 4.14, "Oracle Database VLDB and Partitioning Guide"

Section 4.15, "Oracle Real Application Clusters Administration and Deployment Guide"

Section 4.16, "Oracle Text Application Developer's Guide"

Section 4.17, "Oracle Text Reference"

4.1 Oracle Automatic Storage Management Administrator's Guide

Note the following changes with regard to the Oracle Automatic Storage Management Administrator's Guide part number E41058.

4.1.1 Specifying Unprotected Redundancy

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

WARNING:

Specifying --redundancy unprotected means that Oracle ASM mirroring is not available for data recovery with the Oracle ADVM volume. The redundancy setting (normal) of the disk group does not provide mirroring for an unprotected Oracle ADVM volume. The unprotected configuration is not recommended for production environments as intermittent storage access failures can result in the loss of data. Backups are strongly recommended.

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_TARGET 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 Oracle Clusterware Administration and Deployment Guide

Note the following changes with regard to the Oracle Clusterware Administration and Deployment Guide part number E48819.

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:

Metric Description
name Name of the file system
mount Mount point where the file system is mounted
type Type of the file system that is mounted, whether it is Local or NTFS or EXT2
mft% Percentage of master file table utilization

4.3 Oracle Database Administrator's Guide

Note the following changes with regard to the Oracle Database Administrator's Guide part number E41484.

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.4 Oracle Database Backup and Recovery Reference

Note the following changes with regard to the Oracle Database Backup and Recovery Reference, 12c release 1 (12.1), part number E50791.

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 Oracle Database Backup and Recovery User's Guide

Note the following changes with regard to the Oracle Database Backup and Recovery User's Guide, 12c release 1 (12.1), part number E50658.

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.

Note:

Every virtual private catalog has access to all global stored scripts, and those non-global stored scripts that belong to those databases for which this virtual private catalog has privileges. Virtual private catalogs cannot access non-global stored scripts that belong to databases that they do not have privileges for, and they cannot create global stored scripts.

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

dbmsrmanvpc.sql Option Name Description
-vpd Grants the privileges required to support the VPD protected catalog.

Connect to the RMAN base catalog and perform UPGRADE CATALOG after the VPD privileges are granted.

-novpd Disables VPD functionality by cleaning up the base recovery catalog schema, revoking grants, and removing database objects.

This option can only be used when there are no existing VPC users registered in the base recovery catalog.

-scan Performs a scan of the RMAN base catalog owner schemas and reports on the roles granted and the status of VPC users.
-all Automatically detects the RMAN base catalog schemas and upgrades.

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.

Note:

If the recovery catalog is a virtual private catalog, then the RMAN client connecting to it must be at patch level 10.1.0.6 or 10.2.0.3. Oracle9i RMAN clients cannot connect to a virtual private catalog. This version restriction does not affect RMAN client connections to an Oracle Database 11g base recovery catalog, even if it has some virtual private catalog users.

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.

See Also:

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

  • Oracle Database Backup and Recovery Reference for details about RMAN version compatibility

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.6 Oracle Database JDBC Java API Reference

Starting Oracle Database 11gR2, JDBC clients can use OracleDriver to establish connections to a database from a java application.

Registering the JDBC drivers is no longer a prerequisite.

4.7 Oracle Database Net Services Reference

Note the following changes with regard to the Oracle Database Net Services Reference, 12c release 1 (12.1), part number E17611.

4.7.1 Chapter 5: Parameters for the sqlnet.ora File

In the sub-section titled "TCP.VALIDNODE_CHECKING" in the section titled "sqlnet.ora Profile Parameters", the following paragraphs need to be added to the Usage Notes:

This parameter and the depending parameters, TCP.INVITED_NODES and TCP.EXCLUDED_NODES must be set in the sqlnet.ora file of the listener. This is important in an Oracle RAC environment where the listener runs out of the Oracle Grid Infrastructure home. Setting the parameter in the database home does not have any effect in Oracle RAC environments. In such environments, the address of all Single Client Access Name (SCANs), Virtual IPs (VIPs), local IP must be included in the TCP.INVITED_NODES list.

In VLAN environments, the sqlnet.ora file present in the Oracle Grid Infrastructure home should include all the addresses of all the VLANs. The VLANs perform the network segregation, whereas the INVITED_NODES allows or restricts access to databases within the VLANs.

If multiple databases within the same VLAN require different INVITED_NODE lists, then separate listeners are required.

4.7.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.

4.7.2.1 Section Title: Connection Data Section

In the sub-section titled "HS" in the section titled "Connection Data Section," the Example should be changed to read:

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

The (HS=ok) clause is a top level clause, independent and at the same level as the ADDRESS or CONNECT_DATA clause.

4.7.2.2 SECURITY

In the sub-section titled "SECURITY" in the section titled "Security Section", the Usage Note should be changed to read "The parameters permitted under SECURITY are SSL_SERVER_CERT_DN and AUTHENTICATION_SERVICE."

4.7.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.7.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.7.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.7.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.8 Oracle Database New Features Guide

In the Oracle Database New Features Guide, part number E17906-16, the section titled "New Predefined PL/SQL Inquiry Directives" incorrectly documented the name of two inquiry directives available in Oracle Database 12c release 1 (12.1). The $$PLSQL_OWNER and $$PLSQL_TYPE inquiry directives should be $$PLSQL_UNIT_OWNER and $$PLSQL_UNIT_TYPE.

4.9 Oracle Database Performance Tuning Guide

In the Oracle Database Performance Tuning Guide, part number E49058, in the sub-section titled "Restrictions for the Result Cache, within the section titled "Requirements for the Result Cache, in the section titled "Configuring the Result Cache", in Chapter 15, the following note should be added:

Note:

Result cache does not work on an Active Data Guard standby database opened in read-only mode.

4.10 Oracle Database PL/SQL Packages and Types Reference

The listno parameter of the DBMS_UTILITY was inadvertently excluded from the Oracle Database PL/SQL Packages and Types Reference (part number E41829). For example, the GET_PARAMETER_VALUE function should read as follows:

GET_PARAMETER_VALUE Function

This function gets the value of specified initialization parameter.

Syntax

DBMS_UTILITY.GET_PARAMETER_VALUE (
    parnam       IN        VARCHAR2,
    intval       IN OUT    BINARY_INTEGER,
    strval       IN OUT    VARCHAR2,
    listno       IN        BINARY_INTEGER DEFAULT 1)
  RETURN BINARY_INTEGER;

Parameters

Parameter Description
parnam Parameter name.
intval Value of an integer parameter or the value length of a string parameter.
strval Value of a string parameter.
listno List item number. If retrieving parameter values for a parameter that can be specified multiple times to accumulate values, use this parameter to get each individual parameter.

4.11 Oracle Database Reference (E40402, 11.2)

Note the following with regard to Oracle Database Reference, 11g release 2 (11.2), part number E40402.

4.11.1 REDO_TRANSPORT_USER Initialization Parameter

In Chapter 1 Initialization Parameters, the REDO_TRANSPORT_USER initialization parameter description says that users must have the SYSDBA or SYSOPER privilege to use the parameter. This is incorrect. Users must have the SYSOPER privilege to use this parameter.

4.11.2 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.12 Oracle Database Reference (E41527, 12.1)

Note the following with regard to Oracle Database Reference, 12c release 1 (12.1.0.2), part number E41527.

4.12.1 DB_SECUREFILE Initialization Parameter

The description of the PERMITTED value for the DB_SECUREFILE initialization parameter is incorrect. The correct description for the PERMITTED value is as follows:

Has the same effect as choosing the PREFERRED value.

4.13 Oracle Database Utilities

Note the following with regard to Oracle Database Utilities, 12c release 1 (12.1), part number E41528.

4.13.1 Chapter 2: Data Pump Export

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

4.13.1.1 ACCESS_METHOD

The following Restriction is added to the ACCESS_METHOD parameter:

  • The ACCESS_METHOD parameter for Data Pump Export is not valid for transportable tablespace jobs.

4.13.1.2 EXCLUDE

In the sub-section titled "Excluding Constraints" for the EXCLUDE parameter, the bullet that reads:

  • EXCLUDE=CONSTRAINT excludes all (nonreferential) constraints, except for any constraints needed for successful table creation and loading.

Should be changed to read:

  • EXCLUDE=CONSTRAINT excludes all constraints, except for any constraints needed for successful table creation and loading.

4.13.1.3 NETWORK_LINK

The following bullet was inadvertently deleted from the Restrictions for the NETWORK_LINK parameter:

  • When transporting a database over the network using full transportable export, auditing cannot be enabled for tables stored in an administrative tablespace (such as SYSTEM and SYSAUX) if the audit trail information itself is stored in a user-defined tablespace.

4.13.1.4 REMAP_DATA

The first bullet in the Restrictions section of the REMAP_DATA parameter should read as follows:

  • The data types and sizes of the source argument and the returned value must both match the data type and size of the designated column in the table.

4.13.1.5 TRANSPORT_TABLESPACES

The following Restriction is added to the TRANSPORT_TABLESPACES parameter:

  • Transportable tablespace jobs do not support the ACCESS_METHOD parameter for Data Pump Export.

4.13.1.6 VIEWS_AS_TABLES

The second bullet in the Restrictions section of the VIEWS_AS_TABLES parameter should read as follows:

  • Tables created using the VIEWS_AS_TABLES parameter do not contain any hidden or invisible columns that were part of the specified view.

4.13.2 Chapter 3: Data Pump Import

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

4.13.2.1 ACCESS_METHOD

The following Restriction is added to the ACCESS_METHOD parameter:

  • The ACCESS_METHOD parameter for Data Pump Import is not valid for transportable tablespace jobs.

4.13.2.2 EXCLUDE

In the sub-section titled "Excluding Constraints" for the EXCLUDE parameter, the bullet that reads:

  • EXCLUDE=CONSTRAINT excludes all (nonreferential) constraints, except for any constraints needed for successful table creation and loading.

Should be changed to read:

  • EXCLUDE=CONSTRAINT excludes all constraints, except for any constraints needed for successful table creation and loading.

4.13.2.3 NETWORK_LINK

The following bullet was inadvertently deleted from the Restrictions for NETWORK_LINK:

  • When transporting a database over the network using full transportable import, auditing cannot be enabled for tables stored in an administrative tablespace (such as SYSTEM and SYSAUX) if the audit trail information itself is stored in a user-defined tablespace.

4.13.2.4 REMAP_DATA

The first bullet in the Restrictions section of the REMAP_DATA parameter should read as follows:

  • The data types and sizes of the source argument and the returned value must both match the data type and size of the designated column in the table.

4.13.2.5 TRANSPORT_TABLESPACES

The following Restriction is added to the TRANSPORT_TABLESPACES parameter:

  • Transportable tablespace jobs do not support the ACCESS_METHOD parameter for Data Pump Import.

4.13.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.13.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.13.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.14 Oracle Database VLDB and Partitioning Guide

Note the following changes in Oracle Database VLDB and Partitioning Guide part number E41057:

  • It was incorrectly documented that interval partitioning was supported with XMLIndex. XMLIndex only supports range, list, and hash partitioning with schemes.

  • Deferred segment creation does not apply for subpartitions of a composite interval partitioned table. When an interval partition is created, all subpartitions are materialized.

4.15 Oracle Real Application Clusters Administration and Deployment Guide

Note the following changes with regard to the Oracle Real Application Clusters Administration and Deployment Guide part number E48838.

4.15.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.15.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.15.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.15.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.15.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.15.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.16 Oracle Text Application Developer's Guide

Note the following changes with regard to Oracle Text Application Developer's Guide, 12c release 1 (12.1), part number E41398.

4.16.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.17 Oracle Text Reference

Note the following changes with regard to Oracle Text Reference, 12c release 1 (12.1), part number E41399.

4.17.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.17.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.17.3 Chapter 8: CTX_DDL Package

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

4.17.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.17.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.17.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