Default Locations for Dump, Log, and SQL Files

Because Data Pump is server-based rather than client-based, dump files, log files, and SQL files are accessed relative to server-based directory paths. Data Pump requires that directory paths be specified as directory objects. A directory object maps a name to a directory path on the file system. DBAs must ensure that only approved users are allowed access to the directory object associated with the directory path.

The following example shows a SQL statement that creates a directory object named dpump_dir1 that is mapped to a directory located at /usr/apps/datafiles.

The reason that a directory object is required is to ensure data security and integrity. For example:

If you were allowed to specify a directory path location for an input file, then you might be able to read data that the server has access to, but to which you should not.

If you were allowed to specify a directory path location for an output file, then the server might overwrite a file that you might not normally have privileges to delete.

On UNIX and Windows operating systems, a default directory object, DATA_PUMP_DIR , is created at database creation or whenever the database dictionary is upgraded. By default, it is available only to privileged users. (The user SYSTEM has read and write access to the DATA_PUMP_DIR directory, by default.)

If you are not a privileged user, then before you can run Data Pump Export or Data Pump Import, a directory object must be created by a database administrator (DBA) or by any user with the CREATE ANY DIRECTORY privilege.

After a directory is created, the user creating the directory object must grant READ or WRITE permission on the directory to other users. For example, to allow the Oracle database to read and write files on behalf of user hr in the directory named by dpump_dir1 , the DBA must execute the following command:

Note that READ or WRITE permission to a directory object only means that the Oracle database can read or write files in the corresponding directory on your behalf. You are not given direct access to those files outside of the Oracle database unless you have the appropriate operating system privileges. Similarly, the Oracle database requires permission from the operating system to read and write files in the directories.

Data Pump Export and Import use the following order of precedence to determine a file’s location:

If a directory object is specified as part of the file specification, then the location specified by that directory object is used. (The directory object must be separated from the file name by a colon.)

If a directory object is not specified as part of the file specification, then the directory object named by the DIRECTORY parameter is used.

If a directory object is not specified as part of the file specification, and if no directory object is named by the DIRECTORY parameter, then the value of the environment variable, DATA_PUMP_DIR , is used. This environment variable is defined using operating system commands on the client system where the Data Pump Export and Import utilities are run. The value assigned to this client-based environment variable must be the name of a server-based directory object, which must first be created on the server system by a DBA. For example, the following SQL statement creates a directory object on the server system. The name of the directory object is DUMP_FILES1 , and it is located at ‘/usr/apps/dumpfiles1’ .

Then, a user on a UNIX-based client system using csh can assign the value DUMP_FILES1 to the environment variable DATA_PUMP_DIR . The DIRECTORY parameter can then be omitted from the command line. The dump file employees.dmp , and the log file export.log , are written to ‘/usr/apps/dumpfiles1’ .

If none of the previous three conditions yields a directory object and you are a privileged user, then Data Pump attempts to use the value of the default server-based directory object, DATA_PUMP_DIR . This directory object is automatically created at database creation or when the database dictionary is upgraded. You can use the following SQL query to see the path definition for DATA_PUMP_DIR :

If you are not a privileged user, then access to the DATA_PUMP_DIR directory object must have previously been granted to you by a DBA.

Do not confuse the default DATA_PUMP_DIR directory object with the client-based environment variable of the same name.

Oracle RAC Considerations

Keep the following considerations in mind when working in an Oracle RAC environment.

To use Data Pump or external tables in an Oracle RAC configuration, you must ensure that the directory object path is on a cluster-wide file system.

The directory object must point to shared physical storage that is visible to, and accessible from, all instances where Data Pump and/or external tables processes may run.

The default Data Pump behavior is that worker processes can run on any instance in an Oracle RAC configuration. Therefore, workers on those Oracle RAC instances must have physical access to the location defined by the directory object, such as shared storage media. If the configuration does not have shared storage for this purpose, but you still require parallelism, then you can use the CLUSTER=NO parameter to constrain all worker processes to the instance where the Data Pump job was started.

Under certain circumstances, Data Pump uses parallel query slaves to load or unload data. In an Oracle RAC environment, Data Pump does not control where these slaves run, and they may run on other instances in the Oracle RAC, regardless of what is specified for CLUSTER and SERVICE_NAME for the Data Pump job. Controls for parallel query operations are independent of Data Pump. When parallel query slaves run on other instances as part of a Data Pump job, they also require access to the physical storage of the dump file set.

Using Directory Objects When Oracle Automatic Storage Management Is Enabled

If you use Data Pump Export or Import with Oracle Automatic Storage Management (Oracle ASM) enabled, then you must define the directory object used for the dump file so that the Oracle ASM disk group name is used (instead of an operating system directory path). A separate directory object, which points to an operating system directory path, should be used for the log file. For example, you would create a directory object for the Oracle ASM dump file as follows:

Then you would create a separate directory object for the log file:

To enable user hr to have access to these directory objects, you would assign the necessary privileges, for example:

You would then use the following Data Pump Export command (you will be prompted for a password):

If you simply want to copy Data Pump dump files between ASM and disk directories, you can use the DBMS_FILE_TRANSFER PL/SQL package.

The Export DIRECTORY parameter

The Import DIRECTORY parameter

Oracle Database SQL Language Reference for information about the CREATE DIRECTORY command

Oracle Database PL/SQL Packages and Types Reference for more information about the DBMS_FILE_TRANSFER PL/SQL package

The DATA_PUMP_DIR Directory Object and Pluggable Databases

The default Data Pump directory object, DATA_PUMP_DIR , does not work with pluggable databases (PDBs). You must define an explicit directory object within the PDB that you are using Data Pump to export or import.

How to create a directory in Oracle in Windows desktop

I need to create an oracle directory in Windows desktop C:\Users\slopegar\Desktop . I have tried create directory image_files as ‘C:\Users\slopegar\Desktop\images’ but don’t work.

EDIT: Don’t appear any error in the execution ( Directory IMAGE_FILES creado. ) but the directory is no created-in desktop. The Oracle Server is local for tests.

3 Answers 3

but the directory is no created in desktop

CREATE DIRECTORY creates a «directory object» inside the database.

It does not create a physical directory in the filesystem of the Oracle server:

For file storage, you must also create a corresponding operating system directory [. ] Oracle Database does not verify that the directory you specify actually exists. Therefore, take care that you specify a valid directory in your operating system.

So you need to create the directory on your hard disk manually.

«Don’t work» is less than descriptive. What happened when you tried it?

Anyway: a directory, as an Oracle object, (ideally) has to reside on the database server. If not, the server has to have access to it (hint: you’d use UNC to create such a directory).

So, if your own computer is the database server (for example, if you run Oracle 11g XE on it), then creating a directory in such a manner (the one you used) should work. Otherwise, it most probably won’t.

How did you create that directory? Did you connect as SYS? If not, you should have.

Also, as you didn’t mention it: did you grant required privileges on that directory to user(s) which will be using it? For example,

Работа с объектом Directory в Oracle

В этой статье речь пойдет об объекте directory.

Использование

• Экспорт/импорт объектов базы данных с помощью утилит DataPump (expdp/impdp)
• Работа с типом данных BFILE (внешний большой объект, файл операционной системы)
• Использование с пакетом UTL_FILE в PL/SQL-коде

Объект Directory является логической ссылкой в базе данных на каталог файловой системы сервера, где установлена БД Oracle. Владельцем всех объектов Directory в базе данных является пользователь SYS, даже если объект Directory создан другим пользователем. Имена объектов Directory уникальны внутри всей БД. Все объекты Directory хранятся в табличном пространстве SYS.

Поскольку файлы и каталоги в действительности располагаются ВНЕ базы данных, процессы СУБД Oracle должны иметь необходимые права доступа к указанным каталогам файловой системы.

Синтаксис

Создание объекта Directory:

где:
dir_name — имя создаваемого объекта Directory;

path — физический путь на файловой системе сервера БД;

опция OR REPLACE — используется для того, чтобы создать объект Directory с именем, которое уже существует в базе данных (пересоздать объект Directory).

ВНИМАНИЕ: в качестве пути path может быть использовано имя несуществующего каталога операционной системы. СУБД Oracle не проверяет наличие указанного каталога. В этом случае создание объекта Directory завершится успешно, но при дальнейшем его использовании, например, с утилитой expdp, будет выдана ошибка (см. Связанные ошибки).

2 Managing Oracle Home Directories

The Oracle Universal Installer (OUI) supports the installation of several active Oracle home directories on the same host. An Oracle home is a directory into which all Oracle software is installed and is referenced by an environment variable. The Oracle home consists of the following:

Directory location where the products are installed.

Corresponding system path setup.

Program groups associated with the products installed in the home (where applicable).

Services running from the home.

The Oracle base location is the location where the binaries are stored. During installation, you are prompted for the Oracle base path. Typically, an Oracle base path for the database is created during Oracle Grid Infrastructure installation.

To prepare for installation, Oracle recommends that you only set the ORACLE_BASE environment variable to define paths for Oracle binaries and configuration files. OUI creates other necessary paths and environment variables in accordance with the Optimal Flexible Architecture (OFA) rules for well-structured Oracle software environments.

For example, with Oracle Database 11g, Oracle recommends that you do not set an Oracle home environment variable allow OUI to create it instead. If the Oracle base path is /u01/app/oracle , then by default, OUI creates the following Oracle home path:

Ensure that the paths you select for Oracle software, such as Oracle home paths and the Oracle base path, use only ASCII characters. Because installation owner names are used by default for some paths, this ASCII character restriction applies to user names, file names, and directory names.

The following topics are discussed:

2.1 Installing an Oracle Product

When you install an Oracle product, an Oracle home is created.

To install the product and create the Oracle home, perform the following steps:

Run Oracle Universal Installer.

In the Specify Installation Location page, enter the Oracle home settings for the installation session. See Table 2-1 for a description of the fields in this section of the screen.

Continue with your installation. See Chapter 4, «Installing Products» for detailed information.

Table 2-1 Oracle Installation Settings for ‘Specify Home Details’ Page

Рекомендовано для: Oracle Database 8i Oracle Database 9i R1 Oracle Database 9i R2 Oracle Database 10g R1 Oracle Database 10g R2 Oracle Database 11g R1

Enter a name for the Oracle home. This name identifies the program group associated with a particular home and the Oracle services installed on this home. The Oracle home name must be between 1 to 127 characters long, and can include only alphanumeric characters and underscores.

Enter the full path to an Oracle home, or select an Oracle home from the drop-down list of existing Oracle homes. The Oracle home location is the directory where products are installed.

Data files may or may not be installed within an Oracle home. You can use the Browse button to choose a directory to install your product.

Oracle recommends that you designate an Oracle home location that is an empty or non-existing directory. If you select a directory for the Oracle home location that is not empty or already exists, you will be warned and asked if you want to proceed.

For silent installations, if a non-empty, existing directory is specified, an error is logged in the console and in the installActions .log file. Also, the Oracle Universal Installer aborts. To override this condition, use the -force option on the command line. The effect of using the -force option is the same as selecting Yes while installing in interactive mode. You receive a warning message, but the installation continues.

2.2 Determining the Default Oracle Home

By default, when you start Oracle Universal Installer, the software searches your system to determine the default Oracle home where Oracle software should be installed.

In all cases, the ORACLE_HOME name is taken first from the command line if it is specified, or else from the response file if specified. (See Chapter 3, «Creating and Customizing a Response File,» for instructions for creating a response file.) If not specified, the value of DEFAULT_ORACLE_HOME_NAME in the oraparam.ini file is examined. Typically, the following convention is used for the name:

Where is the short product marketing name as specified in the oraparam.ini file; for example, «Db11g», and is a counter derived from the Central Inventory. For example, the ORACLE_HOME name could be OraDb11g_1 .

The ORACLE_HOME path is taken first from the command line if specified, or else from the response file if specified. If not, the ORACLE_HOME environment variable is used. If neither is specified, the following conventions are used for the path:

If ORACLE_BASE has been specified in the environment:

For example: $ORACLE_BASE/product/11.2.0/Db_1 .

If ORACLE_BASE has not been specified in the environment:

Where is the short product name; for example, «Db», and is picked up based on the existence of the files. For example, the ORACLE_HOME path could be $HOME/product/11.2.0/Db_1 .

The instance-related directory location is accepted first from the response file, if specified. If not, the oradata , flash_recovery_area , admin , and doc directories are created under ORACLE_BASE . If ORACLE_BASE has not been specified, the default is the $ORACLE_HOME/oradata directory. If the parent directory of the Oracle home is writable, these directories are created in the parent directory of the Oracle home.

2.3 Managing Multiple Oracle Homes

Oracle Universal Installer supports the installation of several active Oracle homes on the same host as long as the products support this at run-time. Multiple versions of the same product or different products can run from different Oracle homes concurrently. Products installed in one home do not conflict or interact with products installed on another home. You can update software in any home at any time, assuming all Oracle applications, services, and processes installed on the target home are shut down. Processes from other homes may still be running.

2.3.1 Target Home

The Oracle home currently accessed by Oracle Universal Installer for installation or deinstallation is the target home. To upgrade or remove products from the target homes, these products must be shut down or stopped.

2.4 Oracle Universal Installer Inventory

The Oracle Universal Installer inventory stores information about all Oracle software products installed in all Oracle homes on a host, provided the product was installed using Oracle Universal Installer.

Inventory information is stored in Extensible Markup Language (XML) format. The XML format enables easier diagnosis of problems and faster loading of data. Any secure information is not stored directly in the inventory. As a result, during removal of some products, you may be prompted to enter the required credentials for validation.

Oracle recommends placing the central inventory on a local file system that is not shared by other systems, since the central inventory is a system-specific inventory of the installations on this system.

It is strongly recommended that you place the central inventory on a local disk so that installations from other systems do not corrupt the inventory. You should not place the central inventory in the Oracle Base.

The following OUI inventory topics are presented:

2.4.1 Structure of the Oracle Universal Installer Inventory

The Oracle Universal Installer inventory has the following hierarchical structure:

2.4.1.1 Central Inventory Pointer File

Every Oracle software installation has an associated Central Inventory where the details of all the Oracle products installed on a host are registered. The Central Inventory is located in the directory that the inventory pointer file specifies. Each Oracle software installation has its own Central Inventory pointer file that is unknown to another Oracle software installation.

For Oracle homes sharing the same Central Inventory, the Oracle Universal Installer components perform all read and write operations on the inventory. The operations on the Central Inventory are performed through a locking mechanism. This implies that when an operation such as installation, upgrade, or patching occurs on an Oracle home, these operations become blocked on other Oracle homes that share the same Central Inventory.

Table 2-2 shows the location of the default inventory pointer file for various platforms:

Table 2-2 Default Inventory Pointer File Locations

Settings	Functions

The following string shows an example of the path for the oraInst.loc file:

In UNIX, if you do not want to use the Central Inventory located in the directory specified by the inventory pointer file, you can use the -invPtrLoc option to specify another inventory pointer file. The syntax is as follows:

If the contents of the oraInst.loc file is empty, Oracle Universal Installer prompts you to create a new inventory.

2.4.1.2 Central Inventory

The Central Inventory contains the information relating to all Oracle products installed on a host. It contains the following files and folders:

This file lists all the Oracle homes installed on the node. For each Oracle home, it also lists the Oracle home name, home index, and nodes on which the home is installed. It also mentions if the home is an Oracle Clusterware home or a removed Oracle home. It can only detect removed Oracle homes created using Oracle Universal Installer version 11.2 and later. This file is present in the following location:

The following code shows a sample inventory.xml file:

Oracle recommends that you do not remove or manually edit this file as it could affect installation and patching.

The Central Inventory contains installation logs in the following location:

The logs directory contains the logs corresponding to all installations performed on a particular node. You can also find a copy of the installation log in the $ORACLE_HOME/cfgtoollogs directory.The installation logs for an installation are identified by the timestamp associated with the log files. These files are generally saved in the following format:

For example, consider an attachHome operation performed on 17th, May, 2009 at 6.45AM. The associated log file would be created as follows:

2.4.1.3 Oracle Home Inventory

Oracle home inventory or local inventory is present inside each Oracle home. It only contains information relevant to a particular Oracle home. This file is located in the following location:

It contains the following files and folders:

This file contains the details about third-party applications like Java Runtime Environment (JRE) required by different Java-based Oracle tools and components. In addition, it also contains details of all the components as well as patchsets or interim patches installed in the Oracle home. This file is located here:

For an example of the components file, see Sample Components File in Appendix C, «Sample Files.»

Home Properties File

This file contains the details about the node list, the local node name, and the Oracle Clusterware option for the Oracle home. In a shared Oracle home, the local node information is not present. This file also contains the following information:

GUID — Unique global ID for the Oracle home.

ARU ID — Unique platform ID. The patching and patchset application depends on this ID.

ARU ID DESCRIPTION — Platform description.

The information in oraclehomeproperties.xml overrides the information in inventory.xml . This file is located here:

The following example shows the Oracle home property file:

Table 2-3 lists the ARU_IDs for some platforms:

Table 2-3 ARU_IDs for Platforms

Platform	Default Inventory Pointer Location
Linux Linux.PPC64 AIX
Solaris.SPARC Solaris.X64 HPUX HPIA HP.TRU64 Linux.IA64 Linux.xSeries
Windows Windows.X64 Windows.IA64

Apple Mac OS X (PowerPC)

HP-UX Itanium (32-bit)

HP-UX PA-RISC (32-bit)

HP-UX PA-RISC (64-bit)

IBM AIX on POWER Systems (32-bit)

IBM AIX on POWER Systems (64-bit)

IBM i on POWER Systems

IBM S/390-based Linux (31-bit)

IBM z/OS on System z

IBM: Linux on POWER Systems

IBM: Linux on System z

Microsoft Windows (32-bit)

Microsoft Windows Itanium (64-bit)

Microsoft Windows x64 (64-bit)

Oracle Solaris SPARC (32-bit)

Oracle Solaris SPARC (64-bit)

Oracle Solaris x86 (32-bit)

Oracle Solaris x86-64 (64-bit)

Table 2-4 lists the other folders you can find in the Oracle home inventory:

Table 2-4 Other Folders in the Oracle Home Inventory

Platform	ARU_ID

Contains the scripts used for the cloning operation.

Contains the details of the components and libraries installed.

Contains the template files used for cloning.

Contains the details of the one-off patches applied.

2.4.2 Creating the Central Inventory

Oracle Universal Installer enables you to set up the Central Inventory on a clean host or register an existing Oracle home with the Central Inventory when it is lost or corrupted. If the Central Inventory does not already exist, Oracle Universal Installer creates the Central Inventory in the location specified by the oraInst.loc file.

You can set up the Central Inventory by using the -attachHome option of Oracle Universal Installer. The syntax is as follows:

Or you can use the attachHome.sh (cmd) script with the following syntax:

2.4.2.1 Using Session Variables

You can use the following session variables:

In a cluster installation:

If you do not pass the CLUSTER_NODES session variable, Oracle Universal Installer takes it from the following file:

If you do not pass the LOCAL_NODE session variable, Oracle Universal Installer takes it from the following file:

If it does not find an entry there, it takes it from the Oracle Clusterware stack. If it is not able to find it in the stack, the first node of the CLUSTER_NODES is taken as the LOCAL_NODE .

You can pass the REMOTE_NODES variable if you want to specify the list of remote nodes. If you want to set up the Central Inventory in the local node, you need to pass the -local option, and the REMOTE_NODES variable is empty. The syntax is as follows:

When you use the -local option, it performs the action on the local node irrespective of the cluster nodes specified.

For a non-Oracle Real Application Clusters setup, you do not need to pass the LOCAL_NODE variable, and the CLUSTER_NODES variable is empty. The syntax is as follows:

You can use the -local option to attach the local Oracle home. If you are using a shared Oracle home with the -local option, use the -cfs option. This ensures that the local node information is not populated inside a shared Oracle home.

2.4.2.2 Verifying the Operation

After attaching the Oracle home, you can verify the success of the operation by verifying the contents of the log file present in the /logs directory. You can also view the contents of the inventory.xml file under the /ContentsXML directory to verify if the Oracle home is registered.

Oracle recommends cloning on Windows operating systems to create the Central Inventory.

2.4.3 Detaching Oracle Homes from the Central Inventory

You can detach an Oracle home from the Central Inventory. When you pass this option, it updates the inventory.xml file present in the Central Inventory. The syntax is as follows:

(Optional) If you need to point to a custom inventory, you have the option to use the detachHome.sh (cmd) script with the following syntax:

2.4.3.1 Using the Optional -local Option

You can use the -local option to detach the Oracle home from the inventory of the local node. If you are using a shared Oracle home, use the -cfs option. This ensures that the local node information is not populated inside a shared Oracle home.

2.4.3.2 Removing the Central Inventory

Even after all the Oracle homes on a host are removed, you will find traces of the inventory with certain log files. If you do not want to maintain these files and want to remove the Central Inventory completely, do the following:

For Unix. To remove the Central Inventory for Unix:

Locate the oraInst.loc file and get the Central Inventory location ( inventory_loc parameter) from this file.

For Solaris, this file is located in the /var/opt/oracle folder.

For Linux, this file is located in the /etc folder.

Remove the Central Inventory by executing the following command:

Remove the oraInst.loc file by executing the following command with root privileges:

For Windows. To remove the Central Inventory from Windows platforms:

Locate the registry key:

Get the Central Inventory location from this key.

Delete the Central Inventory directory and all its contents.

Delete the registry key:

2.4.4 Consolidating Multiple Central Inventories

The following procedure explains how to consolidate multiple central inventories into a single central inventory. For Oracle Clusterware and Oracle RAC homes, perform this procedure for each node.

Identify the Central Inventory to use and ensure that it is the same path on all nodes of the cluster.

Go to this Central Inventory directory and run orainstRoot.sh to ensure that the oraInst.loc file points to this inventory.

Identify the other central inventories on the system, then identify the Oracle homes for each Central Inventory.

Do the following for each Oracle home:

Enter the $ORACLE_HOME/oui/bin directory.

Run the following script:

For single instance homes, run the ./attachhome.sh -silent script.

Verify the inventory updates by going to the ORACLE_HOME/OPatch directory and running the opatch lsinventory -detail command.

Verify that the overall inventory is being updated by running the ./launch command and clicking Installed Products. to bring up the contents of the central inventory. Ensure that the inventory shows the new home and the nodes.

2.4.5 Reconstructing a Shared Central Inventory on a Nonshared Location

The following sections provide advisory information about shared Central Inventories, explain the enforced shared inventory check, and provide a procedure for reconstructing the Central Inventory:

2.4.5.1 Oracle Recommendation Regarding Central Inventory Placement

The Oracle Central Inventory is a repository for all Oracle products (software) installed on a system. Since the Central Inventory consists of system-specific information, it is required that the Central Inventory be saved on a local non-shared directory on the system. While software can be shared across nodes, the inventory should be local to each system.

If the Central Inventory is shared across system (nodes), this would reflect the installation information for a group of systems collectively. Such a configuration also mandates that all Oracle homes registered in the inventory are also shared. However, a shared inventory is contrary to Central Inventory design principles.

Consequently, Oracle recommends placing the Central Inventory on a local file system not shared by other systems , because the Central Inventory is a system-specific inventory of the installations on this system. Shared inventories are strongly discouraged.

2.4.5.2 Enforced Shared Inventory Check

Since a shared inventory is a recommended practice, OUI displays a warning if you attempt to specify a shared inventory location under the following circumstances:

Grid Control upgrades from 10.1.x or 10.2.x to 10.2.0.4 or later

10.2.0.4 or later Grid Control patchset applications and 11g Grid Control installations

Exceptions are as follows:

Shared storage prior to 10.2.0.4

If you have already set up your inventory on shared storage prior to Grid Control version 10.2.0.4, you can use the steps in Procedure to Reconstruct the Central Inventory below to reconstruct the central inventory on a non-shared location.

If you do not want to reconstruct the central inventory on a non-shared location, you can pass the -ignoreSharedInventory option to suppress the shared inventory error when invoking runInstaller.

Tru64 is a special operating system where all storage is shared storage (including the operating system installed on shared storage). Therefore, a shared inventory is permissible.

2.4.5.3 Procedure to Reconstruct the Central Inventory

Perform the following steps as a Grid Control installation user, which is the user who owns the inventory.

Identify a non-shared location for the Central Inventory. This location should have sufficient permissions, such as read and write permissions. Make sure that the installation user creates this new location and that the location is part of the installation group.

Obtain the list of Oracle homes from the existing shared Central Inventory registered in oraInventory, use the opatch lsinventory -all command.

Since this is a shared inventory, you may see Oracle homes listed in the Central Inventory from other systems on which the inventory is shared. Identify the Oracle home pertinent to the current system.

Edit the default inventory pointer file indicating the location of the non-shared inventory:

The default inventory pointer file resides in this file:

All other Unix operating systems, such as Solaris and so forth reside in this file:

For each Oracle home in the existing shared inventory, do the following:

Detach the home from the existing inventory.

For a non-RAC home, run:

For a Clusterware, RAC, or clustered Agent home, run the following command on each of the nodes:

Attach a home to the new non-shared inventory.

For a non-RAC home, run:

For a non-shared Clusterware home, run the following command on each of the nodes:

For a shared Clusterware home, run the following command on each of the nodes:

For a non-shared RAC or clustered Agent home, run the following command on each of the nodes:

For a shared RAC or clustered Agent home, run the following command on each of the nodes:

The old inventory becomes obsolete after this migration. You can delete the directory, but this is not mandatory.

2.4.6 Upgrading and Patching the Oracle Home

You can apply patchsets and upgrade an existing Oracle home. You can apply patchsets using Oracle Universal Installer. For more information on upgrading or applying patchsets for an Oracle product, refer to the respective Oracle product installation guide of the product that you want to upgrade.

2.4.7 Cloning Oracle Homes

You can clone an Oracle home using Oracle Universal Installer. For more information on cloning, see Chapter 5, «Cloning Oracle Software.»

2.4.8 Backing up the Central Inventory

You can back up the Oracle home using your preferred method. You can use any method such as zip , tar , and cpio to compress the Oracle home.

It is highly recommended to back up the Oracle home before any upgrade or patch operation. You should also back up the Central Inventory when Oracle home is installed or deinstalled.

Consider a scenario where you have a Database Oracle home called DBHome that is registered with the default Central Inventory in the /product directory. You want to patch this database but decide to back up the database before patching.

Enter the following to back up the database:

If you are using a Win32 system, you could use WinZip to zip up the Oracle home. Do not use the jar command to zip the Oracle home, as this causes the file permissions to become lost.

Suppose you apply the patch and something goes wrong. You decide to delete the Oracle home from the Central Inventory and restore the original Oracle home. To delete the Oracle home from the Central Inventory, use the following command:

On Win32 systems, the command would be:

Delete the Oracle home:

Restore the original Oracle home and update the Central Inventory. Restore the Oracle home to its original location using the following commands:

Attach this Oracle home to the Central Inventory:

On Win32 systems, the command would be:

2.4.9 Recovering from Central Inventory Corruption

The inventory (Central and the Oracle home inventory) is critically important in the Oracle software life-cycle management. The following section explains what you need to do in case of inventory corruption.

2.4.9.1 Diagnosing and Recovering from Central Inventory Corruption

Problem: When you execute the opatch lsinventory -detail command or when you click Installed Products, the Oracle home does not appear.

Cause: This may result because of a missing or corrupted Oracle home inventory.

Action: If the Oracle home inventory is missing or corrupted, restore the Oracle home inventory. If you have not backed up the Oracle home inventory, you may have to install the software on a different node with the same platform and install the same patch levels including interim patches. After that, you can simply copy the inventory directory from the patched Oracle home to the location of the affected Oracle home.

For Oracle Universal Installer version 10.2.0.2.0 and above, you can use the following scripts in Oracle home to recover from Oracle home inventory corruption:

detachHome.bat / detachHome.sh : Use this script if the Oracle home is corrupted or needs to be updated.

attachHome.bat / attachHome.sh : Use this script if the Oracle home needs to be added to the inventory.

For information on recovering from Oracle Real Application Clusters Oracle home inventory corruption, see Diagnosing and Recovering from Central Inventory Corruption.

2.5 Home Selector (Available on Win32 Platforms)

The following sections describe the Home Selector, which is installed as part of Oracle Universal Installer on Windows computers.

To view the Home Selector, click the Environment tab of the Inventory dialog, which appears when you click the Installed Products button on several Oracle Universal Installer screens.

2.5.1 Home Selector Overview

The Home Selector is a part of the installation software. The Home Selector enables you to easily change your primary Oracle home (the one that appears first in the PATH environment variable). If you need to switch the active home or need to perform batch work which requires a «default home» to be active, you can use the Home Selector to change the Windows NT system settings.

When using the Home Selector to make a specific Oracle home the active one, the software installation in question is moved to the front of the PATH variable, making it the first directory to be scanned for executable and library files.

Use the GUI in the Environment tab of the Inventory dialog to establish the order of Oracle homes in your PATH variable.

2.5.2 How Home Selector Works

When you perform an installation on a system, Oracle Universal Installer runs the selectHome.bat file to register the Oracle home you selected. In silent mode, you perform this outside Oracle Universal Installer. The first Oracle home is named the » DEFAULT_HOME » and registers itself in the Windows NT registry under the key:

This is the default Windows NT registry hive which contains all the «generic» Oracle settings. Also, the PATH variable is adjusted, and the BIN directory of the $ORACLE_HOME is added to the environment variable.

Some additional parameters is also written to the key:

With Oracle Universal Installer, you can change the » DEFAULT_HOME » name to something else. Also, it registers all Oracle settings in the » KEY_ » sub-key of the ORACLE key.

When an additional Oracle home is added to the system, the PATH variable is adjusted again to add the new BIN directory of the newly installed Oracle software. The registry variables are written to a key named » KEY_ «.

2.5.3 Oracle Home Directory Structure for Windows Platforms

A typical Oracle home on Windows platforms contains the files and directories shown in Table 2-5.

Table 2-5 Oracle Home Directory for Windows Platforms

Folder Name	Description

Product executable and DLLs

Common message files

PROD1 product files

PROD2 product files

2.5.4 Optimal Flexible Architecture Directory Structure (on Unix)

The Optimal Flexible Architecture (OFA) standard is a set of configuration guidelines for fast, reliable Oracle databases that require little maintenance.

OFA is designed to:

Organize large amounts of complicated software and data on disk to avoid device bottlenecks and poor performance

Facilitate routine administrative tasks such as software and data backup functions, which are often vulnerable to data corruption

Alleviate switching among multiple databases

Adequately manage and administer database growth

Help eliminate fragmentation of free space in the data dictionary, isolate other fragmentation, and minimize resource contention

The OFA directory structure is described in the following sections:

2.5.4.1 ORACLE_BASE Directory

ORACLE_BASE specifies the BASE of the Oracle directory structure for OFA-compliant databases. A typical ORACLE_BASE directory structure is described in Table 2-6. When installing an OFA-compliant database using Oracle Universal Installer, ORACLE_BASE is set to /pm/app/oracle by default.

Table 2-6 Sample ORACLE_BASE Directory Structure and Content

Oracle Home Directory	Contents

Sub-tree for local Oracle software

2.5.4.2 ORACLE_HOME Directory

Table 2-7 shows an example of the Oracle home directory structure and content for an Oracle Server Installation.

If you install an OFA-compliant Oracle Server, the Oracle home directory is /mount_point/app/oracle/product/ release_number . Under Unix, the Oracle home directory might contain the following subdirectories, as well as a subdirectory for each Oracle product selected.

The directory and content information in this table are only samples. The directories that appear in your own Oracle home depend on whether the corresponding products are installed and the version of the Oracle Database you are running.

Table 2-7 Sample Oracle Home Directory Structure and Content

Directory	Content

binaries for all products

interMedia Text cartridge

init sid .ora , lk sid

install related files

Oracle product libraries

Xerox Stemmer (for interMedia Text cartridge)

NLS run-time loadable data

common files for all products

Parallel Server Manager Components

server files and libraries required for the database

2.6 Global Distribution Registry (GDR) Selections

During an installation, prior to the actual installation of files, it may be required to prompt the user to obtain the list of selected features to install. The following sections describe how the selections are defined and how to drive the API which allows modification of these selections:

2.6.1 Feature Set Groups

A feature set group, just like the name says, groups features together. From a feature selection and installation perceptive these groups are virtual constructs which are only used for display purposes. The underlying dependency graph does not consider feature set groups. When a feature selection tree is presented to the user the feature set groups are meant to be the parent tree nodes which help group the features into areas the user might be interested in.

The features set references defined under each feature set group have a Boolean attribute called selected which is true by default. This defines the default selection state of that feature when the graph is initialized to the default install type or when an install type is chosen.

The following is an example of two feature set groups you might see defined within a distribution definition. Here the core.feature and client.feature are selected by default, but the samples.feature is not.

2.6.2 Install Types

The OUI distribution definition gives you the ability to define optional install types. If the distribution definition does not define an install type, then a default one is created internally with the name Typical , which holds the default set of selections which were defined in the feature set group section of the distribution definition. When a distribution definition defines its own install types, the feature set references within each install type override the default selections that were defined in the feature set groups for that specific install type.

Only one of the install types should be set as the default ( default=»true» ). This install type will be used to initialize the selections in the case that no install type is chosen or custom selections changes are made. If a default is not defined or multiple defaults are defined, the first one encountered will be assumed as the default. Whenever a new install type is selected, the selection state of the graph is reset to reflect the selections that the chosen install type defines which will overwrite any custom selections that may have been performed up to that point.

The following is an example of three install types which were defined for the feature set groups in the example above.

The Standard install type does not define any overriding selection values for the feature sets. Since this install set provides no overriding values it simply takes on the selection states which were defined in the feature set groups above. This is also the default install type which means it will be used to initialize the default set of selections after the graph is built and in absence of a install type actually being chosen. This means that the initial selection state (or if this install type was chosen) of the features in the graph would contain the core.feature and client.feature in a selected state and the samples.feature in a non-selected state.

The Standard With Examples install set defines that the samples.feature will be selected if this install type is chosen. All other selection states will be inherited from defaults defined in the feature set group section. This means that if this install type were chosen the core.feature , client.feature , and samples.feature will all be in the selected state.

The Client Only install set defines that the core.feature and the samples.feature will not be selected if this install type is chosen. The selection state of the client.feature is inherited from the feature set groups and will be in the selected state. This means that if this install type were chosen the client.feature would be in a selected state and the core.feature and samples.feature will be in a non-selected state.

2.6.3 Custom Selections

If an installer allows for custom feature selection and the user chooses this option during the installation, the «selection tree» which the user is presented with is always a complete view of all feature set groups and visible features in the distribution. This is to say that all feature set groups defined in the distribution will be presented to the user for selection. The default state of the selections in the tree presented will be determined by the install set which was chosen or the default install set if one was not chosen.

2.6.4 The InstallerConfig API

The API for interacting with the feature selections is the com.oracle.cie.gdr.external.InstallerConfig class. This class lives in the com.oracle.cie.gdr_1.0.0.0.jar module. There are two pieces of data which are required any time you are interacting with this API:

shipHomeDir — This location is the location of the /Disk1/stage directory itself (for example, FROM_LOCATION ).

homeDir — This is the Oracle home directory that was chosen by the user.

The first thing which should be done when interacting with this API is to create a session object. This is done by calling the getInstallerSession (File shipHomeDir , File homeDir ) method. The session object which is obtained by calling this method should be kept and reused for all operations in the API which pertain to the shipHomeDir and homeDir which was chosen. If the user chooses a new Oracle home directory, a new session should be created. When the session object is created installation validation is performed. If there are any incompatibilities between the shiphome being installed and the chosen Oracle home a DependencyException error will be thrown.

Eventually, the API Installer may take this session object or a similar one when it is created, but for now as long as the shipHomeDir and homeDir provided to the API Installer match those used to create this session, the selections made via the InstallerConfig API should be honored.

Once you have the session object you should store a reference to this object and pass it to the other API methods:

Set getInstallTypes(InstallerSession session)

This method gets a Set of the names of the install types which are defined in the distribution. If no install types are defined this will return a Set containing one install type name which is the default and has a name of «Typical». If install types are defined in the distribution definition then this will return that set of names. If the installer wishes to present the user with install type selection, these are the names the user should be presented with. Once the user selects the install type you will call the setInstallType method.

void setInstallType(InstallerSession session, String name) throws DependencyException, GdrException

This method sets the install type which was selected by the user. When the install type is set the selection state of the graph is reset to match the selections which were defined for that install type. If there’s an issue with the dependencies of what was selected in the graph a DependencyException may be thrown. If the install type specified does not exist a GdrException is thrown.

TreeModel getFeatureSelectionTreeModel(InstallerSession session)

This method gets a TreeModel which contains the feature set groups and features to allow for custom selection. All objects in this tree, with the exception of the root, implement the com.oracle.cie.gdr.selection.Selectable interface which provides the method setSelected(boolean) for modifying the selection state of each item. This model can be presented to the user in the UI and any modifications which are made to the selection state of the objects in the tree model will be automatically reflected in the underlying graph. If a selected feature has dependencies on other features these will automatically be selected to enforce the dependencies.

Map > getFeatureSelectionWrappers(InstallerSession session)

This method provides a map of the Selectable objects which are used to create the TreeModel returned from the getFeatureSelectionTreeModel() method. This method is meant to be used only if you wish to populate your own custom TreeModel with the Selectable objects. Any changes to the selection state of these objects will be automatically reflected in the underlying dependency graph.

void setSelectedFeatures(InstallerSession session, Set featureRefs) throws GdrException, DependencyException

This method is meant to be used for programmatic selections of features. This would most likely be used for silent type installations where the user has provided some type of list of features they wish to have installed. The set of feature references provided to this method define the features you wish to have set to a selected state. Only the features in the set and their dependencies will be set as selected, all other features will be unselected.

Reference createReference(String name, String version)

This is a convenience method for creating the Reference objects which are used in the setSelectedFeatures() method. You would pass the name and version of the feature and a resulting Reference is returned.

The following code snippet shows this API being driven:

2.7 Removing or Deinstalling an Oracle Home

To remove or deinstall Oracle homes, you can either use the Deinstall tool included with the Shiphome, or use the Deinstall utility available as part of the Oracle home.

To use the Deinstall tool, do the following to remove the Oracle home:

Change to the DeinstallTool directory.

To use the Deinstall utility, do the following to remove the Oracle home:

Change to the $Oracle_Home/deinstall directory.

Directory	Content