Share the content if you found it is useful (You can share using 300 community websites) click "share" at the end of the post.

You are encouraged to leave a comment.








Showing posts with label 11g. Show all posts
Showing posts with label 11g. Show all posts

Friday, January 02, 2009

Opatch - Central Inventory

The Oracle Universal Installer supports the installation of several active Oracle homes on the same host. An Oracle home is a directory into which all Oracle software is installed. This is pointed to 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

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:

1. Run Oracle Universal Installer.

2. In the Specify Home Details page, enter the Oracle home settings for the installation session.
3. Continue with your installation. Oracle Installation Settings for Specify Home Details page

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.

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


For Windows platforms, you must provide a valid path that is not in the Windows directory. Different homes cannot share the same location.

Note:

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 flag on the command line. The effect of using the -force flag is the same as selecting Yes while installing in interactive mode. You receive a warning message, but the installation continues.

Removing Oracle Homes
To remove an existing Oracle home, invoke Oracle Universal Installer and click Deinstall Products. At the inventory dialog, select the homes you want to delete and click Remove. You can also use the REMOVE_HOMES variable in the command line or in a response file. The syntax is as follows:

$./runInstaller -deinstall -silent ORACLE_HOME= "REMOVE_HOMES={}"


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. If not, the following convention is used for the name:

Ora_

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:·
$ORACLE_BASE/product//_

For example: $ORACLE_BASE/product/11.1.0/Db_1.
· If ORACLE_BASE has not been specified in the environment:· $HOME/product//_

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

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.

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.

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 allows for 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.

Structure of the Oracle Universal Installer Inventory
The Oracle Universal Installer inventory has the following hierarchical structure:
· Central Inventory Pointer Directory
· Central Inventory
· Oracle Home Inventory


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.

The following list shows the location of the inventory pointer file for various platforms:

· Solaris — /var/opt/oracle/oraInst.loc
· Linux — /etc/oraInst.loc
· Windows — The pointer is located in the registry key:· \\HKEY_LOCAL_MACHINE\\Software\Oracle\inst.loc


The following string shows an example of the path for the oraInst.loc file: inventory_loc=/home/oracle_db11g/product/11.1.0/db_1inst_group=oracle

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 flag to specify another inventory pointer file. The syntax is as follows:

./runInstaller -silent -invPtrLoc ORACLE_HOME="" ORACLE_HOME_NAME=""

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


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

Inventory File
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.1 and later. This file is present in the following location:

/ContentsXML/inventory.xml
The following code shows a sample inventory.xml file:




11.1.0.0.0 2.1.0.6.0






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

Logs Directory
The Central Inventory contains installation logs in the following location:

/logs

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:.log

For example, consider an attachHome operation performed on 17th, May, 2007 at 6.45AM. The associated log file would be created as follows:AttachHome2007-05-17_06-45-00AM.log

Note:
The installation logs do not contain any errors or failures.

Oracle Home Inventory (Local 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:$ORACLE_HOME/inventory
It contains the following files and folders:
· Components File
· Home Properties File
· Other Folders

Components File
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:ORACLE_HOME/inventory/ContentsXML/comps.xml
For an example of the components file,

Home Properties File
This file contains the details about the node list, the local node name, and the CRS flag 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:$ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml
The following example shows the Oracle home property
file:
893051798#.356758136

46 ARU_ID_DESCRIPTION>Linux x86



NAME="stacg34"/>

Below is the list of the ARU_IDs for some platforms:

ARU_IDs for Platforms Platform ARU_ID
HPUX 64-bit 59
IBM 5L 212
Linux 32-bit 46
Solaris 32-bit 453
Solaris 64-bit 23
Windows XP 912

Other Folders
list of the other folders you can find in the Oracle home inventory:
Other Folders in the Oracle Home Inventory
Folder Name Description
Scripts Contains the scripts used for the cloning operation.
ContentsXML Contains the details of the components and libraries installed.
Templates Contains the template files used for cloning.
oneoffs Contains the details of the one-off patches applied.

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 flag of Oracle Universal Installer. The syntax is as follows:

./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME="""CLUSTER_NODES={}" LOCAL_NODE=""

Using the Session Variables
You can use the following session variables:
· ORACLE_HOME
· ORACLE_HOME_NAME
· CLUSTER_NODES
· REMOTE_NODES
· LOCAL_NODE

In a cluster installation:
· If you do not pass the CLUSTER_NODES session variable, Oracle Universal Installer takes it from the $ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml file.
· If you do not pass the LOCAL_NODE session variable, Oracle Universal Installer takes it from the $ORACLE_HOME/inventory /ContentsXML/oraclehomeproperties.xml 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 flag, and the REMOTE_NODES variable is empty.

The syntax is as follows:

./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME="""REMOTE_NODES={}" -local

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

For a non-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:

./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME="""CLUSTER_NODES={}"

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

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.

Note:
Oracle recommends cloning on Windows operating systems to create the Central Inventory.
Detaching Oracle Homes from the Central Inventory. You can detach an Oracle home from the Central Inventory. When you pass this flag, it updates the inventory.xml file present in the Central Inventory.

The syntax is as follows:

./runInstaller -silent -detachHome -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME=""

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

./runInstaller -silent -local -cfs -detachHome -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME=""

./runInstaller -silent -detachHome -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME=""

You can completely clean the Oracle home and remove the home directory by using the -removeallfiles flag.

The syntax is as follows:

./runInstaller -silent -deinstall -removeallfiles -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME=""

If you want to disable the warning message that appears when you use the -removeallfiles flag, use the -nowarningonremovefiles flag.

The syntax is as follows:

./runInstaller -silent -deinstall -nowarningonremovefiles -invPtrLoc ./oraInst.loc ORACLE_HOME="" ORACLE_HOME_NAME=""

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, do the following:

Removing the Central Inventory on UNIX Platforms

You can remove the Central Inventory on UNIX by performing the following steps:
1. 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 /va/opt/oracle folder.
For Linux, this file is located in the /etc folder.

2. Remove the Central Inventory by executing the following command:

3. rm -rf

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

Solaris:rm /va/opt/oracle/oraInst.loc
Linux:rm /etc/oraInst.loc

Removing the Central Inventory on Windows Platforms
You can remove the Central Inventory on Windows by performing the following steps:
1. Locate the registry key:
\\HKEY_LOCAL_MACHINE\Software\Oracle\inst_loc
2. Get the Central Inventory location from this key.
3. Delete the Central Inventory directory and all its contents.
4. Delete the registry key:
\\HKEY_LOCAL_MACHINE\Software\Oracle\inst_loc

Consolidating Multiple Central Inventories
The following procedure explains how to consolidate multiple central inventories into a single central inventory. For CRS and RAC homes, perform this procedure for each node.
1. Identify the central inventory to use and ensure that it is the same path on all nodes of the cluster.
2. Go to this central inventory directory and run orainstRoot.sh to ensure that the oraInst.loc file points to this inventory.
3. Identify the other central inventories on the system, then identify the Oracle homes for each central inventory.
4. Do the following for each Oracle home:
a. Enter cd $ORACLE_HOME/oui/bin.
b. Run ./attachhome.sh -silent -local "CLUSTER_NODES={}" LOCAL_NODE=
For single instance homes, run ./attachhome.sh -silent.
c. Verify the inventory updates by going to the ORACLE_HOME/OPatch directory and running opatch lsinventory -detail.
d. Verify that the overall inventory is being updated by running ./runInstaller and clicking on 'Installed Products...' to bring up the contents of the central inventory. Ensure that the inventory shows the new home and the nodes.


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.

Cloning Oracle Homes
You can clone an Oracle home using Oracle Universal Installer.

Backing up the 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.

Example:
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.

1. Enter the following to back up the database:

2. cd /product/DBHome

3. tar cf - * gzip > /product/archive/DBHome.tar.gz

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

5. 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:

./runInstaller -silent -detachHome ORACLE_HOME="/product/DBHome"7. ORACLE_HOME_NAME="DBHome"

On Win32 systems, the command would be:setup.exe -silent -detachHome ORACLE_HOME="C:\product\DBHome"ORACLE_HOME_NAME="DBHome"

7. Delete the Oracle home:

cd /product10. rm -rf /product/DBHome


Restore the original Oracle home and update the Central Inventory.

Restore the Oracle home to its original location using the following commands:

mkdir -p /product/DBHome

gunzip < /product/archive/DBHome.tar.gz tar xf -
Attach this Oracle home to the Central Inventory:

./runInstaller -silent -attachHome ORACLE_HOME="/product/DBHome"16. ORACLE_HOME_NAME="DBHome"

On Win32 systems, the command would be:
setup.exe -silent -attachHome ORACLE_HOME="C:\product\DBHome"ORACLE_HOME_NAME="DBHome"
Recovering from 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.

Diagnosing and Recovering from Central Inventory Corruption
When you execute opatch lsinventory -detail or when you click Installed Products, the Oracle home does not appear.

Cause: The Oracle home may be missing from the Central Inventory, or the Central Inventory could be missing or corrupted.


Action:
Do the following:
· If the Oracle home is missing from the Central Inventory, perform an attach home operation on the missing Oracle home. The Central Inventory will be restored.
· If the Central Inventory is missing or corrupted, restore the Central Inventory. If you have not backed up the Central Inventory, perform an attach home operation.

If multiple entries are in the inventory.xml file for a given Oracle home, Inventory Collection from the Grid Control perspective would have issues. In this event, you should remove these duplicate entries manually.

Here are some examples of the kind of incorrect entries that could be there:


In the above example, the first and third entries are duplicates. The Oracle home name and Oracle home location are identical. In this example, remove the third line.

Note that all duplicate inventory issues are caused by manual updates to the inventory.xml file. Use the OUI APIs to change the inventory.

Diagnosing and Recovering from Oracle Home Inventory Corruption
When you execute opatch lsinventory -detail or when you click Installed Products, the Oracle home appears, but the products and components within the Oracle home are not listed.

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.

Note:
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.

Real Application Clusters
In a Real Application Clusters environment, the inventory also contains a list of nodes associated with an Oracle home. It is important that during upgrade and patching, the inventory is correctly populated with the list of nodes.

Updating the Nodes of a Cluster
When you use the -updateNodeList flag with the Oracle Universal Installer, it retrieves the list of nodes and updates the inventory.xml file. If the CRS tag is set to TRUE, the Oraclehomeproperties.xml file is updated with the Oracle Clusterware home information. For shared Oracle homes, you need to use this with the -cfs flag. The syntax is as follows:

./runInstaller -updateNodeList "CLUSTER_NODES={Node1,Node2}" ORACLE_HOME="" ORACLE_HOME_NAME="" LOCAL_NODE="Node_Name"

Note:
You update the nodes of a cluster only under exceptional circumstances. Oracle recommends that you perform this operation with the help of Oracle support.

Diagnosing and Recovering from RAC Oracle Home Inventory Corruption

When you execute opatch lsinventory -detail or when you click Installed Products, the Oracle home appears, but the products and components within the Oracle home are not listed.

Cause: This may result because of a missing or corrupted Oracle home inventory.
Action: Do the following:
1. Back up the Central and Local inventories of both CRS and RDBMS for all nodes.
2. Rename or remove the Central Inventory on all nodes.
3. Copy the Local Inventory from the node that is not corrupted to the node that is corrupted.
4. Recreate the Central Inventory with the attachhome option as in MetaLink note 413939.1, Steps to Recreate the Central Inventory in Real Application Clusters.
5. Verify that opatch lsinventory functions correctly in both the CRS and RDBMS homes.
Note:

Copying the Local Inventory is supported only when patch sets and one-off patches applied are the same across all nodes.

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

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

:HKEY_LOCAL_MACHINESoftwareOracle

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:

HKEY_LOCAL_MACHINESoftwareOracleKEY_

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_".

Oracle Home Directory Structure for Windows Platforms
A typical Oracle home on Windows platforms contains the files and directories shown

Oracle Home Directory for Windows Platforms
Oracle Home Directory Contents
\BIN Product executable and DLLs
\LIB DLL files
\JLIB All JAR files
\DBS Common message files
\PROD1 PROD1 product files
\PROD2 PROD2 product files

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 Oracle 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.
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 below.

When installing an OFA-compliant database using Oracle Universal Installer, ORACLE_BASE is set to /pm/app/oracle by default.
Sample ORACLE_BASE Directory Structure and Content

Directory Content
admin Administrative files
doc online documentation
local Sub-tree for local Oracle software
product Oracle software

ORACLE_HOME Directory
Below table 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.

Note:
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.

Sample Oracle Home Directory Structure and Content

Directory Content
assistants configuration Assistants
bin binaries for all products
ctx interMedia Text cartridge
dbs initsid.ora, lksid
install install related files
lib Oracle product libraries
jlib Java classes
md Spatial cartridge
mlx Xerox Stemmer (for interMedia Text cartridge)
network Net8
nlsrtl NLS run-time loadable data
ocommon common files for all products
odg data gatherer
opsm Parallel Server Manager Components
oracore core libraries
ord data cartridges
otrace Oracle TRACE
plsql PL/SQL
precomp precompilers
rdbms server files and libraries required for the database
slax SLAX parser
sqlplus SQL*Plus

Friday, December 26, 2008

Dataguard: Physical Standby Database

In this post I described in detail the way in which we can configure a Dataguard for Oracle Databases. Here the instance is of 11g.

Oracle Database 11g RMAN introduces the FROM ACTIVE DATABASE capability to the DUPLICATE FOR STANDBY command. This alleviates the previous need for interim storage on both the Primary and Standby systems, and the limitation of single stream network traffic.

Now when taking the backup of the Primary database you can simultaneously create and restore the standby database over the network in parallel streams. Apart from some simple Oracle Net setup, and creating a couple of directories and an interim password file, the whole standby creation can be done in one RMAN script.

RMAN will automatically copy the server parameter file to the standby host, start the auxiliary instance with the server parameter file, restore a backup control file, and copy all necessary database files and archived redo logs over the network to the standby host.

Prerequisites

1.

Perform an Oracle Database 11g installation (software and db installed) for a single server environment OR Oracle Database 11g installation (software and db installed) on 1 server and Oracle Database 11g software only on 2nd server for a dual server environment.



Please Save the following script as we need to run during this process.

1. Script for RMAN:

run {
allocate channel prmy1 type disk;

allocate channel prmy2 type disk;

allocate channel prmy3 type disk;

allocate channel prmy4 type disk;

allocate auxiliary channel stby type disk;


duplicate target database for standby from active database

spfile

parameter_value_convert 'orcl','orclsby1'

set db_unique_name='orclsby1'

set db_file_name_convert='/orcl/','/orclsby1/'

set log_file_name_convert='/orcl/','/orclsby1/'

set control_files='/u01/app/oracle/oradata/orclsby1.ctl'

set log_archive_max_processes='5'

set fal_client='orclsby1'

set fal_server='orcl'

set standby_file_management='AUTO'

set log_archive_config='dg_config=(orcl,orclsby1)'

set log_archive_dest_1='service=orcl ASYNC
valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=orcl'

;

2. Create Standby logfile (cr_sby_redologs.sql)

alter database add standby logfile
('/u01/app/oracle/oradata/orcl/srl01.log',
'/u01/app/oracle/oradata/orcl/srl02.log',
'/u01/app/oracle/oradata/orcl/srl03.log',
'/u01/app/oracle/oradata/orcl/srl04.log')
size 52428800

/

3. Query for Archived Logs (query_archived_log.sql)

SELECT sequence#, first_time, next_time

FROM v$archived_log
ORDER BY sequence#
/


Preparing the Primary Database for Standby Database Creation

You verify that the primary database is configured correctly to support a physical standby database.

You only need to perform these preparatory tasks once. After you complete these steps, the database is prepared to serve as the primary database for one or more standby databases. You should perform the following steps:

1.

Determine if FORCE LOGGING is enabled. If it is not enabled, enable FORCE LOGGING mode. This statement may take some time to complete, because it waits for all unlogged direct write I/O to finish. You use the following commands:

Select FORCE_LOGGING from V$DATABASE;

ALTER DATABASE FORCE LOGGING;

2.

Configure redo transport authentication.

Data Guard uses Oracle Net sessions to transport redo data and control messages between the members of a Data Guard configuration. These redo transport sessions are authenticated using either the Secure Sockets Layer (SSL) protocol or a remote login password file.

In this blog, we will be using a remote login password file which will be created in a subsequent step.

3.

Configure the primary database to receive redo data, by adding the standby logfiles to the primary. You can use the cr_sby_redologs.sql script, after validating the directory paths reflect your environment.

It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. The files must be the same size or larger than the primary database’s online redo logs.

SQL> alter database add standby logfile
2 '/u01/app/oracle/oradata/orcl/srl01.log' size 52428800
3 /
Database altered.
SQL> alter database add standby logfile
2 '/u01/app/oracle/oradata/orcl/srl02.log' size 52428800
3 /
Database altered.
SQL> alter database add standby logfile
2 '/u01/app/oracle/oradata/orcl/srl03.log' size 52428800
3 /
Database altered.
SQL> alter database add standby logfile
2 '/u01/app/oracle/oradata/orcl/srl04.log' size 52428800
3 /
Database altered.
 

4.

Set primary database initialization parameters

On the primary database, you define initialization parameters that control redo transport services while the database is in the primary role. You use SQL commands similar to the following to verify these settings:

Ensure the following parameters are set to reflect the Data Guard configuration.

DB_NAME Specifies the database name. Must be orcl.
DB_UNIQUE_NAME Specify a unique name for each database. Does not change even if DG roles change. Must be orcl.
CONTROL_FILES Specifies the local path name for the control files on the primary database.
LOG_ARCHIVE_CONFIG Uses the DG_CONFIG attribute to list the DB_UNIQUE_NAME of the primary and standby databases.
LOG_ARCHIVE_DEST_1 Defaults to archive destination for the local archived redo log files.
LOG_ARCHIVE_DEST_2 Valid only for the primary role, this destination transmits redo data to the remote physical standby destination orclsby1.
REMOTE_LOGIN_PASSWORDFILE Must be EXCLUSIVE or SHARED if a remote login password file is used (default = EXCLUSIVE)
LOG_ARCHIVE_DEST_STATE_n Must be ENABLE (default)

Use the following commands to set the LOG_ARCHIVE_CONFIG and LOG_ARCHIVE_DEST_2 indicating the primary and standby databases.


5.

Issue the following statements to determine your database's archival state, and then put the primary database in ARCHIVELOG mode to enable automatic archiving.


In this practice, you configure the network environment and create a physical standby database.

NOTE: In this blog, you configure the network for a single server environment. If you are configuring an environment on two different servers, you would need to configure Net Manager on both servers accordingly.


A. Use Oracle Net Manager to create an Oracle Net service name for your physical standby database.

1.

Launch Net Manager.

2.

Expand Local. Select Service Naming and click the green plus sign

3.

Enter your (i.e. orclsby1) in the Net Service Name field and click Next

4.

Select TCP/IP (Internet Protocol) and click Next

5.

Enter your fully qualified and click Next.


6.

Enter your in the Service Name field and click Next


7.

Click Finish.

8.

Click File -> Save Network Configuration to save the information to the tnsnames.ora file.


B. Use Oracle Net Manager to configure an entry for your standby database in the listener.ora file.

1.

Expand Listeners

2.

Select LISTENER.

3.

Select Database Services in the drop-down list.

4.

Click Add Database.

5.

Enter your in the Global Database Name field. Enter your and your in the SID field.


6.

Select File -> Save Network Configuration.

7.

Select File -> Exit.


C. Creating the standby database over the network

1.

Reload the listener.



$lsnrctl reload


2.

Navigate to ORACLE_HOME/dbs folder to perform this steps.

Copy the remote login password file (orapworcl) from the primary database system to the standby database system, renaming it to orapworclsby1.

The password file must be re-copied each time the SYSDBA or SYSOPER privilege is granted or revoked and whenever the login password of a user with these privileges is changed. You may need FTP, or some other remote file transfer mechanism, if you are using differenet servers.



3.

In the ORACLE_HOME/dbs folder, for the standby system, create an initialization parameter file named initorclsby1.ora containing a single parameter: DB_NAME=




4.

For the standby system, change to the /u01/app/oracle/admin directory. Create your (i.e. orclsby1) directory. Change to your (i.e. orclsby1) directory and create the adump directory.




5.

For the standby system, create your (i.e. orclsby1) directory in $ORACLE_BASE/oradata for the data files.

NOTE: Depending on how you installed Oracle Database 11g, you may need to also add the following directory paths: $ORACLE_BASE/flash_recovery_area and $ORACLE_BASE/oradata

6.

On the standby system, set the ORACLE_SID environment variable to your (i.e. orclsby1) and start the instance in NOMOUNT mode with the text initialization parameter file.



7.

On the primary system, ensure the ORACLE_SID environment variable is set to your primary DB (i.e. orcl).




8.

On the primary system, invoke RMAN and connect as SYSDBA to the target database. Connect to the auxiliary database.



9.

Execute the script no.1 from prerequisite of this blog for RMAN on the primary system. When this script finishes you will have a new standby database that was created over the network without any interim storage.










 
10.

Perform a log switch on the primary database and redo will start being sent to the standby.


11.

On the standby system, ensure the ORACLE_SID environment variable is set to your (i.e. orclsby1) and start the MRP process.




Verify that the Physical Standby Database is Performing Correctly

Once you create the physical standby database and set up redo transport services, you may want to verify database modifications are being successfully transmitted from the primary database to the standby database. To see that redo data is being received on the standby database, you should first identify the existing archived redo log files on the standby database, force a log switch and archive a few online redo log files on the primary database, and then check the standby database again. The following steps show how to perform these tasks.

1.

On the standby database, identify the existing archived redo log files by querying the V$ARCHIVED_LOG view.

You can use the query_archived_log.sql file.


2.
On the primary database, issue the ALTER SYSTEM SWITCH LOGFILE statement to force a log switch and archive the current
online redo log file group.

3.

On the standby database, re-query the V$ARCHIVED_LOG view to verify the redo data was received and archived on the standby database:


4.

On the standby database, query the V$ARCHIVED_LOG view to verify the archived redo log files were actually applied. Please requery until you see a YES in the APPLIED column.

At the completion of this step, the physical standby database is running and provides the maximum performance level of data protection.

Wednesday, December 17, 2008

Step -by-Step Replication (MASTER_MASTER) Asynchromous Replication

Why I am using Asynchronous?

In our scenario, The availability of network is uncertain in a given time. Synchronous uses two side commit. If one site is not available at a time, then the update is not possible. It will raise error.

But in Asynchronous,
Using change queues and materialized queues snapshot logs to store changes and therefore even if single side is not available during some period of time the remained side may be used. Moreover, after detached side will be available again, data will be synchronized [last statement depends on purge period, the purge period constraint defends active master database via to be filled by not propagated changes.]

The first thing to know prior to start with advanced replication is that you should have primary key (or at least the alternative) for all tables you would like to replicate. For instance, you have two instances test1 and test2. On both instances you have created user REPTEST00 with default tablespace pool_data and temporary tablespace temp.


The following statement describes database names and tnsnames aliases of the involved instances:
TEST1 = Global Database name of the Master Definition Site
TEST2 = Global Database name of secondary Master Site

test1 = Net alias to the Master Definition Site
test2 = Net alias to the secondary Master Site
You may check your global database name by running:

select * from global_name
Net alias is an alias from $ORACLE_HOME/network/admin/tnsnames.ora

*Note:
Even all oracle documentation that describes advanced replication features, explicitly suggesting that you are using oracle domains eg.test1.world. However it is not really required. So if you have well designed set of database names, you do not need this feature.
During this session we will avoid to use oracle domains and our Net aliases will be named just test1 and test2 respectively.
In order to work with the oracle advanced replication we should add GLOBAL_NAMES = true to our pfile (or spfile).

Test1 creates user repadmin in both instances with appropriate permissions


CONNECT system/manager@test1
CREATE USER repadmin IDENTIFIED BY repadmin;
ALTER USER repadmin DEFAULT TABLESPACE POOL_DATA;
ALTER USER repadmin TEMPORARY TABLESPACE TEMP;
GRANT connect, resource TO repadmin;
EXECUTE dbms_repcat_admin.grant_admin_any_schema('repadmin');
GRANT comment any table TO repadmin;
GRANT lock any table TO repadmin;
EXECUTE dbms_defer_sys.register_propagator('repadmin');
GRANT execute any procedure TO repadmin;
CREATE PUBLIC DATABASE LINK TEST2 USING 'test2';
CONNECT repadmin/repadmin@test1
CREATE DATABASE LINK TEST2 CONNECT TO repadmin IDENTIFIED BY repadmin;

Test2.
CONNECT system/manager@test2
CREATE USER repadmin IDENTIFIED BY repadmin;
ALTER USER repadmin DEFAULT TABLESPACE POOL_DATA;
ALTER USER repadmin TEMPORARY TABLESPACE TEMP;
GRANT connect, resource TO repadmin;
EXECUTE dbms_repcat_admin.grant_admin_any_schema('repadmin');
GRANT comment any table TO repadmin;
GRANT lock any table TO repadmin;
EXECUTE dbms_defer_sys.register_propagator('repadmin');
GRANT execute any procedure TO repadmin;
CREATE PUBLIC DATABASE LINK TEST1 USING 'test1';
CONNECT repadmin/repadmin@test2
CREATE DATABASE LINK TEST1 CONNECT TO repadmin IDENTIFIED BY repadmin;

Test1 uses ASYNCHRONOUS replication. It tries pushing changes every 10 second, purge changes that not succeed to be propagated during 3 days

BEGIN
dbms_defer_sys.schedule_push(
destination => 'test2',
interval => '/*10:Sec*/ sysdate + 10 / (3600*24)',
next_date => sysdate,
stop_on_error => FALSE,
delay_seconds => 0,
parallelism => 1);
END;
/
BEGIN
dbms_defer_sys.schedule_purge(
next_date => sysdate,
interval => '/*3 : days*/ sysdate + 3',
delay_seconds => 0,
rollback_segment => '');
END;
/
Test2 uses ASYNCHRONOUS replication.

It tries pushing changes each 10 second, purge changes that not succeed to be propagated during 3 days

BEGIN
dbms_defer_sys.schedule_push(
destination => 'test1',
interval => '/*10:Sec*/ sysdate + 10 / (3600*24)',
next_date => sysdate,
stop_on_error => FALSE,
delay_seconds => 0,
parallelism => 1);
END;
/
BEGIN
dbms_defer_sys.schedule_purge(
next_date => sysdate,
interval => '/*3 : days*/ sysdate + 3',
delay_seconds => 0,
rollback_segment => '');
END;
/

Create master replication group on test1 which is primary master:

CONNECT repadmin/repadmin@test1
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPGROUP(
gname => '"REPTEST"',
qualifier => '',
group_comment => '');
END;
/

Add secondary master and suspend master activity. If this replication needed to be SYNCHRONOUS, then just change propagation_mode from ASYNCHRONOUS to SYNCHRONOUS but be aware that SYNCHRONOUS configuration may not be used for High Availability
BEGIN
DBMS_REPCAT.ADD_MASTER_DATABASE(
gname => '"REPTEST"',
master => 'TEST2',
use_existing_objects => TRUE,
copy_rows => TRUE,
propagation_mode => 'ASYNCHRONOUS');
END;
/
BEGIN
DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY(
gname => '"REPTEST"');
END;
/

Let's assume you have tables XXXX with primary key XXXX_PK YYYY without primary key but with unique constraint YYYY_UX contains two columns YYYY_UX_COL1, YYYY_UX_COL2 and additional index YYYY_IX. Also assume there is a trigger on table XXXX namely XXXX_TRIGGER that will be replicated as well.
On test1 which is primary master, create master replication objects:
CONNECT repadmin/repadmin@test1
Now creating master replication object for all tables
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT(
gname => '"REPTEST"',
type => 'TABLE',
oname => '"XXXX"',
sname => '"REPTEST00"',
copy_rows => TRUE,
use_existing_object => TRUE);
END;
/
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT(
gname => '"REPTEST"',
type => 'TABLE',
oname => '"YYYY"',
sname => '"REPTEST00"',
copy_rows => TRUE,
use_existing_object => TRUE);
END;
/
Create master replication object for trigger:
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT(
gname => '"REPTEST"',
type => 'TRIGGER',
oname => '"XXXX_TRIGGER"',
sname => '"REPTEST00"',
copy_rows => TRUE,
use_existing_object => TRUE);
END;
/
Create master replication object for all indexes:
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT(
gname => '"REPTEST"',
type => 'INDEX',
oname => '"YYYY_IX"',
sname => '"REPTEST00"',
copy_rows => TRUE,
use_existing_object => TRUE);
END;
/
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT(
gname => '"REPTEST"',
type => 'INDEX',
oname => '"YYYY_UX"',
sname => '"REPTEST00"',
copy_rows => TRUE,
use_existing_object => TRUE);
END;
/
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT(
gname => '"REPTEST"',
type => 'INDEX',
oname => '"XXXX_PK"',
sname => '"REPTEST00"',
copy_rows => TRUE,
use_existing_object => TRUE);
END;
/


Define alternative key for table that have no primary key:
BEGIN
DBMS_REPCAT.SET_COLUMNS(
sname => '"REPTEST00"',
oname => '"YYYY"',
column_list => '"YYYY_UX_COL1, YYYY_UX_COL2"');
END;
/

Generate replication support for all the tables to be replicated:
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT(
sname => '"REPTEST00"',
oname => '"XXXX"',
type => 'TABLE',
min_communication => TRUE,
generate_80_compatible => FALSE);
END;
/
BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT(
sname => '"REPTEST00"',
oname => '"YYYY"',
type => 'TABLE',
min_communication => TRUE,
generate_80_compatible => FALSE);
END;
/
Now wait until all objects from primary master will be copied to secondary master. Afterwards replication can be started by issuing running following statement:
BEGIN
DBMS_REPCAT.RESUME_MASTER_ACTIVITY(gname => '"REPTEST"');
END;
/

Warning!
Oracle Advanced replication is not resistant to schema changes sincevery likely that schema change replication will fail with ORA-23474 afterwards.
This is one of the worst possible cases. Replication may not continue to work until you drop all non-primary masters and recreate all replication support from the scratch.
23474, 0000, "definition of \"%s\".\"%s\" has changed since generation of replication support"
*Cause: The current columns in the specified table and their column types do not match the columns and column types when replication support was last generated.
*Action: Regenerate replication support for the affected table.
All flavors that include the specified table should be checked
for validity. Types for any UDT columns should also be checked
for validity.
You can try to resolving ORA-23474 by regenerating replication support for invalidated objects on primary master:


CONNECT repadmin/repadmin@test1
BEGIN
DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY(
gname => '"REPTEST"');
END;
/

Next is regenerate replication support for all affected objects, for instance:
BEGIN
DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT(
sname => '"REPTEST00"',
oname => '"YYYY"',
type => 'TABLE',
min_communication => TRUE,
generate_80_compatible => FALSE);
END;
/
Then you may resume replication by issuing the following statement:
BEGIN
DBMS_REPCAT.RESUME_MASTER_ACTIVITY(
gname => '"REPTEST"');
END;
/
The right way to change schema would be using DBMS_REPCAT.EXECUTE_DDL. Example:
BEGIN
DBMS_REPCAT.EXECUTE_DDL (
gname => 'REPTEST',
master_list => 'test1, test2',
DDL_TEXT => 'alter table REPTEST00.XXXX add (add_test
number(8,0))');
END;
/
If one of the master databases to be removed:
BEGIN
DBMS_REPCAT.REMOVE_MASTER_DATABASES (
gname => '"REPTEST"',
master_list => 'test2');
END;
/
If one of master objects to be removed:
BEGIN
DBMS_REPCAT.SUSPEND_MASTER_ACTIVITY(
gname => '"REPTEST"');
END;
/
BEGIN
DBMS_REPCAT.DROP_MASTER_REPOBJECT (
sname => '"REPTEST00"',
oname => '"YYYY"',
type => 'TABLE',
drop_objects => FALSE);
END;
/
BEGIN
DBMS_REPCAT.RESUME_MASTER_ACTIVITY(
gname => '"REPTEST"');
END;
/

Monitoring and troubleshooting of Oracle advanced replication.
Oracle advanced replication uses tables with names such as def$_xxxx in the schema “system”. User schema “sys” holds several useful views on those tables named defxxxx respectively.
For example, if one of the alternative keys that you set was not unique, then you may receive ORA-01422 error.
All errors received during advanced replication activity and not yet purged can be identified from DEFERROR view.
You may use the following script:
set linesize 132
col DESTINATION for a10
col ERROR_MSG for a45
col START_TIME for a21
col DEFERRED_TRAN_ID for a15
col CALLNO for 9999
SELECT deferred_tran_id, callno, SUBSTR (destination, 1, 10) destination,
TO_CHAR (start_time, 'HH24:MI:SS DD/MM/YYYY') start_time,
SUBSTR (error_msg, 1, 45) error_msg
FROM deferror;
Example of inappropriate surrogate key usage result:
DEFERRED_TRAN_I CALLNO DESTINATIO START_TIME ERROR_MSG
--------------- ------ ---------- --------------------- ---------------------------------------------
9.3.865 0 TEST1 08:10:09 14/03/2004 ORA-01422: exact fetch returns more than requ
2.27.874 0 TEST1 08:10:10 14/03/2004 ORA-01422: exact fetch returns more than requ
9.33.864 0 TEST1 08:10:16 14/03/2004 ORA-01422: exact fetch returns more than requ
9.39.1073 0 TEST1 22:02:36 18/03/2004 ORA-01422: exact fetch returns more than requ
1.15.1107 0 TEST1 22:02:48 18/03/2004 ORA-01422: exact fetch returns more than requ
5.36.1089 0 TEST1 22:02:51 18/03/2004 ORA-01422: exact fetch returns more than requ
9.30.1074 0 TEST1 22:10:58 18/03/2004 ORA-01422: exact fetch returns more than requ

The other useful view of this kind is DEFTRAN.
Via this view you may see the currently queued transaction. Please note, transaction that are not propagated due to the error such as in the previous example will remain in this queue forever or until purged.
select DEFERRED_TRAN_ID, DELIVERY_ORDER, DESTINATION_LIST, START_TIME from DEFTRAN;
DEFERRED_TRAN_I DELIVERY_ORDER D START_TIME
--------------- -------------- - ---------------------
9.3.865 4183230 D 14-MAR-04
2.27.874 4183237 D 14-MAR-04
9.33.864 4183406 D 14-MAR-04
9.39.1073 5196085 D 18-MAR-04
1.15.1107 5196094 D 18-MAR-04
5.36.1089 5196100 D 18-MAR-04
9.30.1074 5198042 D 18-MAR-04
Related Posts Plugin for WordPress, Blogger...

Let us be Friends...

Share |

Popular Posts

Recent Comments