This section contains corrections to the following Oracle Documentation:
Note the following changes with regard to the Oracle Automatic Storage Management Administrator's Guide, 11g Release 2 (11.2), part number E18951.
In the section "Extents" found in the section titled "About Oracle ASM Files" under the main section titled "Understanding Oracle ASM Concepts" should read as follows:
The contents of Oracle ASM files are stored in a disk group as a set, or collection, of extents that are stored on individual disks within disk groups. Each extent resides on an individual disk. Extents consist of one or more allocation units (AU). To accommodate increasingly larger files, Oracle ASM uses variable size extents.
Variable size extents enable support for larger Oracle ASM data files, reduce SGA memory requirements for very large databases, and improve performance for file create and open operations. The initial extent size equals the disk group allocation unit size and it increases by a factor of 4 or 16 at predefined thresholds. This feature is automatic for newly created and resized data files when specific disk group compatibility attributes are set to 11.1 or higher. For information about compatibility attributes, see "Disk Group Compatibility".
For disk groups with an AU size less than 4 MB, the extent size of a file varies as follows:
Extent size always equals the disk group AU size for the first 20000 extent sets (0 - 19999).
Extent size equals 4*AU size for the next 20000 extent sets (20000 - 39999).
Extent size equals 16*AU size for the next 20000 and higher extent sets (40000+).
Figure 1-4 shows the Oracle ASM file extent relationship with allocation units ...
For disk groups with AU sizes greater than or equal to 4 MB, the extent size of a file, depending on the redundancy of the disk group, varies as follows:
For the 4 MB AU size, the extent size equals the disk group AU size for the first 15658728, 6710880, and 3728269 extents for external, normal, and high redundancy disk groups respectively.
For the 8 MB AU size, the extent size equals the disk group AU size for the first 16777216, 7829368, and 4846749 extents for external, normal, and high redundancy disk groups respectively.
For the 16 MB AU size, the extent size equals the disk group AU size for the first 16777216, 8388608, and 5405989 extents for external, normal, and high redundancy disk groups respectively.
For the 32 MB AU size, the extent size equals the disk group AU size for the first 16777216, 8388608, and 5592405 extents for external, normal, and high redundancy disk groups respectively.
For all cases, the size of the remaining extent sets is 16*AU size. Extents with a size equal to 4*AU size are not created.
In the PROCESSES description found in the section titled "Oracle ASM Parameter Setting Recommendations" under the section titled "Configuring Initialization Parameters for Oracle ASM Instances," the following paragraph should be included:
For Oracle Grid Infrastructure, 11g Release 2 (22.214.171.124 and 126.96.36.199), the
PROCESSES initialization parameter defaults to a value equal to "available CPU cores * 80 + 40" in the Oracle ASM SPFILE. Because the default value for the
MEMORY_TARGET initialization parameter is based on the value of
PROCESSES, the value can be insufficient if there is a large number of CPU cores or a large number of disk groups. You should increase the value of the
MEMORY_TARGET initialization parameters before upgrading to or installing Oracle Grid Infrastructure, 11g Release 2 (188.8.131.52 and 184.108.40.206).
In the STORAGE.TYPE description found in the section titled "Disk Group Attributes," the restriction that "ZFS storage must be added through Direct NFS (dNFS)" no longer applies if the
COMPATIBLE.RDBMS disk group attributes are set to 220.127.116.11 or higher
Note the following changes with regard to Chapter 12 of the Oracle Automatic Storage Management Administrator's Guide, 11g Release 2 (11.2), part number E18951.
In the section "volcreate" found in the "ASMCMD Volume Management Commands" section, the following warning applies:
--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.
Note the following changes with regard to the Oracle Database Backup and Recovery User's Guide, 11g Release 2 (11.2), part number E10642.
In the section titled "TSPITR Restrictions, Special Cases, and Limitations," the first item under the point "You cannot use TSPITR to recover tablespaces containing any of the following objects:" must read as follows:
Objects with underlying objects (such as materialized views) or contained objects (such as partitioned tables) unless all of the underlying or contained objects are in the recovery set. Additionally, if the partitions of a partitioned table are stored in different tablespaces, then you must either drop the table before performing TSPITR or move all of the partitions to the same tablespace before performing TSPITR.
After Step 3 found in the section titled "How RMAN Duplicates a Database" under the section titled "Basic Concepts of Database Duplication" which is under the main section titled "Overview of RMAN Database Duplication," the following sentence must be included:
Note: If the control file in the source database contains disabled threads, then these threads will also be disabled in the duplicate database.
Note the following changes with regard to the Oracle Database Backup and Recovery Reference, 11g Release 2 (11.2), part number E10643.
Note:Oracle Database Reference, 11g Release 1 (11.1), part number B28320
The list of data types documented for the
CHAR_LENGTH column description for the
ALL_NESTED_TABLE_COLS, ALL_TAB_COLS, ALL_TAB_COLUMNS, DBA_TAB_COLS, and
DBA_TAB_COLUMNS views incorrectly included
NVARCHAR. The correct data type is
NVARCHAR2. The Oracle Database Reference manual is fixed in 11g Release 2 (11.2) and higher releases.
Note the following when reading the Oracle Clusterware Administration and Deployment Guide for 11g Release 2 (11.2), part number E41959.
In the section titled "Deleting a Cluster Node on Linux and UNIX Systems," under the section titled "Adding and Deleting Cluster Nodes on Linux and UNIX Systems," take note of the following:
After executing Step 5, you should check the content of the
inventory.xml file. If you have updated the
inventory.xml file by mistake or if you have missed Step 5 altogether and proceed to execute Step 6 (documented in the next bullet), deleting the node will deinstall the entire cluster.
The following step has been included:
6. Depending on whether you have a shared or local Oracle home, complete one of the following procedures as the user that installed Oracle Clusterware:
If you have a shared home, then run the following commands in the following order on the node you want to delete.
Run the following command to deconfigure Oracle Clusterware:
$ Grid_home/perl/bin/perl Grid_home/crs/install/rootcrs.pl -deconfig
Run the following command from the
/oui/bin directory to detach the Grid home:
$ ./runInstaller -detachHome ORACLE_HOME=Grid_home -silent -local
Manually delete the following files:
/etc/oraInst.loc /etc/oratab /etc/oracle/ /opt/ORCLfmap/ $OraInventory/
For a local home, deinstall the Oracle Clusterware home from the node that you want to delete, as follows, by running the following command, where
Grid_home is the path defined for the Oracle Clusterware home:
$ Grid_home/deinstall/deinstall –local
If you do not specify the
-local flag, then the command removes the Grid Infrastructure home from every node in the cluster.
This step was omitted in releases prior to 11g Release 2 (11.2).
In the section titled "Creating a Cluster by Cloning Oracle Clusterware," "Step 2: Deploy the Oracle Grid Infrastructure Home on the Destination Nodes" incorrectly instructs you to run the following commands to restore the cleared information:
chmod u+s Grid_home/bin/oracle chmod g+s Grid_home/bin/oracle chmod u+s Grid_home/bin/extjob chmod u+s Grid_home/bin/jssu chmod u+s Grid_home/bin/oradism
These instructions should be ignored. The Oracle Clusterware Administration and Deployment Guide is fixed in 12c Release 1 (12.1) and higher releases.