ORA-19815: WARNING: db_recovery_file_dest_size of 42949672960 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Errors in file /u00/app/oracle/diag/rdbms/sid/SID/trace/SID_ora_20214.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 1063256064 bytes disk space from 42949672960 limit
ARCH: Error 19809 Creating archive log file to ‘+FRA’
Thursday, 29 December 2011
Monday, 26 December 2011
Finding the 10 largest objects in an Oracle database
col owner format a15
col segment_name format a30
col segment_type format a15
col mb format 999,999,999
select owner
, segment_name
, segment_type
, mb
from (
select owner
, segment_name
, segment_type
, bytes / 1024 / 1024 "MB"
from dba_segments
order by bytes desc
)
where rownum < 11
/
col segment_name format a30
col segment_type format a15
col mb format 999,999,999
select owner
, segment_name
, segment_type
, mb
from (
select owner
, segment_name
, segment_type
, bytes / 1024 / 1024 "MB"
from dba_segments
order by bytes desc
)
where rownum < 11
/
HOME ABOUT ORACLE SITES RSS Backing up your CRONTAB
If you are running a lot of scripts through CRON you may want to have a current backup. Since your CRON is simply a text schedule I prefer a daily email backup. It’s simple and does what I need. I add this line to my CRON:
00 0 * * * crontab -l > crontablist.txt;
mail -s "DW CRON - Quality Control" nitish@domain.com < crontablist.txt
Everyday at midnight I get an email with the contents of my CRON.
00 0 * * * crontab -l > crontablist.txt;
mail -s "DW CRON - Quality Control" nitish@domain.com < crontablist.txt
Everyday at midnight I get an email with the contents of my CRON.
Dynamically Delete Old Partitions
Are you looking to delete older partitions in an Oracle database? Here is a basic SQL query that will give you what you need.
select ‘ALTER TABLE ‘||table_owner||’.'||table_name
||’ DROP PARTITION ‘
||partition_name||’ UPDATE INDEXES;’
from dba_tab_partitions
where table_owner = ‘AVCO’
and table_name = ‘LOAN_DETAIL’
order by PARTITION_POSITION;
Modify to your specific needs.
select ‘ALTER TABLE ‘||table_owner||’.'||table_name
||’ DROP PARTITION ‘
||partition_name||’ UPDATE INDEXES;’
from dba_tab_partitions
where table_owner = ‘AVCO’
and table_name = ‘LOAN_DETAIL’
order by PARTITION_POSITION;
Modify to your specific needs.
Change a table’s default tablespace
Do you need to change a table’s default tablespace? It’s pretty simple:
ALTER TABLE {OWNER}.{TABLE NAME}
MODIFY DEFAULT ATTRIBUTES TABLESPACE {NEW TABLESPACE NAME};
This does not move the table it only changes the attribute for the default tablespace. This is helpful if you are adding partitions, but not specifying the tablespace.
ALTER TABLE {OWNER}.{TABLE NAME}
MODIFY DEFAULT ATTRIBUTES TABLESPACE {NEW TABLESPACE NAME};
This does not move the table it only changes the attribute for the default tablespace. This is helpful if you are adding partitions, but not specifying the tablespace.
Remove non-ASCII characters from a column
Do you need to remove special (non-ASCII) characters from a VarChar2 column in Oracle? Create this function:
CREATE OR REPLACE FUNCTION O1DW.RECTIFY_NON_ASCII(INPUT_STR IN VARCHAR2)
RETURN VARCHAR2
IS
str VARCHAR2(2000);
act number :=0;
cnt number :=0;
askey number :=0;
OUTPUT_STR VARCHAR2(2000);
begin
str:=’^'||TO_CHAR(INPUT_STR)||’^';
cnt:=length(str);
for i in 1 .. cnt loop
askey :=0;
select ascii(substr(str,i,1)) into askey
from dual;
if askey < 32 or askey >=127 then
str :=’^'||REPLACE(str, CHR(askey),”);
end if;
end loop;
OUTPUT_STR := trim(ltrim(rtrim(trim(str),’^'),’^'));
RETURN (OUTPUT_STR);
end;
/
CREATE OR REPLACE FUNCTION O1DW.RECTIFY_NON_ASCII(INPUT_STR IN VARCHAR2)
RETURN VARCHAR2
IS
str VARCHAR2(2000);
act number :=0;
cnt number :=0;
askey number :=0;
OUTPUT_STR VARCHAR2(2000);
begin
str:=’^'||TO_CHAR(INPUT_STR)||’^';
cnt:=length(str);
for i in 1 .. cnt loop
askey :=0;
select ascii(substr(str,i,1)) into askey
from dual;
if askey < 32 or askey >=127 then
str :=’^'||REPLACE(str, CHR(askey),”);
end if;
end loop;
OUTPUT_STR := trim(ltrim(rtrim(trim(str),’^'),’^'));
RETURN (OUTPUT_STR);
end;
/
Move and partitioned index to a new tablespace
To dynamically move a partitioned index to a new tablespace run the following SQL
select ‘Alter index ‘||INDEX_OWNER||’.'||INDEX_NAME||’
rebuild partition ‘||PARTITION_NAME||’ tablespace ABC_DETAIL_INDEX1;’
from dba_ind_partitions where TABLESPACE_NAME = ‘DW_ABC_DETAIL’;
select ‘Alter index ‘||INDEX_OWNER||’.'||INDEX_NAME||’
rebuild partition ‘||PARTITION_NAME||’ tablespace ABC_DETAIL_INDEX1;’
from dba_ind_partitions where TABLESPACE_NAME = ‘DW_ABC_DETAIL’;
Wednesday, 21 December 2011
How to resolve “Unable to create Patch Object” error?
FTU % opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./12419278
Invoking OPatch 11.1.0.6.0
Oracle Interim Patch Installer version 11.1.0.6.0 Copyright (c) 2007, Oracle Corporation. All rights reserved.
PREREQ session
Oracle Home : /u02/app/oracle/product/11.2.0.1/FTU
Central Inventory : /u01/app/oracle/oraInventory
from : /etc/oraInst.loc
OPatch version : 11.1.0.6.0
OUI version : 11.2.0.1.0
OUI location : /u02/app/oracle/product/11.2.0.1/FTU/oui Log file location : /u02/app/oracle/product/11.2.0.1/FTU/cfgtoollogs/opatch/opatch2011-11-05_01-50-34AM.log
Invoking prereq “checkconflictagainstohwithdetail”
The location “./12419278/README.html” is not a directory or a valid patch zip file.
Prereq “checkConflictAgainstOHWithDetail” not executed
PrereqSession failed: Unable to create Patch Object.
Exception occured : Patch ID is null.
OPatch failed with error code 73
We have two solutions for this problem
SOLUTION # 1
——————-
Move the text files like readme.html, readme.txt etc from the patch directory to some other location and try checking conflicts and it will be successful
But the problem is, this is not a permanent solution and just a workaround
SOLUTION # 2
——————–
This is the permanent solution for this problem. Cause for this error is we don’t have latest opatch version. As you can see in the output above my database version is 11.2.0.1, but my opatch version is 11.1.0.6. So, download latest opatch version from My Oracle Support with the help of patch # 6880880 and install it
Steps to install new opatch
1. copy the downloaded zip file for patch # 6880880 to $ORACLE_HOME
2. change location to ORACLE_HOME and rename the old OPatch directory
example : FTU% cd $ORACLE_HOME
FTU% mv OPatch OPatch.old
3. unzip the zip file which will create new OPatch directory
4. run below command to check if version is changed
FTU% $ORACLE_HOME/OPatch/opatch version
The above steps are also available in README file of the patch
Invoking OPatch 11.1.0.6.0
Oracle Interim Patch Installer version 11.1.0.6.0 Copyright (c) 2007, Oracle Corporation. All rights reserved.
PREREQ session
Oracle Home : /u02/app/oracle/product/11.2.0.1/FTU
Central Inventory : /u01/app/oracle/oraInventory
from : /etc/oraInst.loc
OPatch version : 11.1.0.6.0
OUI version : 11.2.0.1.0
OUI location : /u02/app/oracle/product/11.2.0.1/FTU/oui Log file location : /u02/app/oracle/product/11.2.0.1/FTU/cfgtoollogs/opatch/opatch2011-11-05_01-50-34AM.log
Invoking prereq “checkconflictagainstohwithdetail”
The location “./12419278/README.html” is not a directory or a valid patch zip file.
Prereq “checkConflictAgainstOHWithDetail” not executed
PrereqSession failed: Unable to create Patch Object.
Exception occured : Patch ID is null.
OPatch failed with error code 73
We have two solutions for this problem
SOLUTION # 1
——————-
Move the text files like readme.html, readme.txt etc from the patch directory to some other location and try checking conflicts and it will be successful
But the problem is, this is not a permanent solution and just a workaround
SOLUTION # 2
——————–
This is the permanent solution for this problem. Cause for this error is we don’t have latest opatch version. As you can see in the output above my database version is 11.2.0.1, but my opatch version is 11.1.0.6. So, download latest opatch version from My Oracle Support with the help of patch # 6880880 and install it
Steps to install new opatch
1. copy the downloaded zip file for patch # 6880880 to $ORACLE_HOME
2. change location to ORACLE_HOME and rename the old OPatch directory
example : FTU% cd $ORACLE_HOME
FTU% mv OPatch OPatch.old
3. unzip the zip file which will create new OPatch directory
4. run below command to check if version is changed
FTU% $ORACLE_HOME/OPatch/opatch version
The above steps are also available in README file of the patch
how to define RMAN retention policy time?
Many a times, I heard DBA’s complaining about RMAN retention policy through which they face some problems during restore or recovery.
For example a friend posted that his retention policy is set to recovery window of 90 days, but when tried to restore the database to 30 days back date, RMAN saying recovery till that time is not possible. he wondered why this cannot be done if he has retention of 90 days.
Here is the answer for the same….
we all know that RMAN will store backup metadata in control file’s reusable location if recovery catalog is not configured. Generally this information will be stored for 7 days and can be changed by modifying CONTROLFILE_RECORD_KEEP_TIME parameter.
whenever we define retention policy of RMAN either to recovery window or redundancy to some X value, we need to remember that RMAN still follow the value defined for CONTROLFILE_RECOD_KEEP_TIME. That means, if recovery window is set to 30 days, but the above parameter is set to 7 days (default), you cannot recover beyond 7 days… which is very unfortunate…
Right ! so lets see what can be done for this?
we need to define CONTROLFILE_RECORD_KEEP_TIME always a higher value than what we set for retention policy. As per the formula, it should be
CONTROLFILE_RECORD_KEEP_TIME=retention policy value+ level 0 backup interval+ 1
let me throw some example for easy understanding…
If suppose your retention time is set to recovery window of 90 days and a weekly full level 0 backup is scheduled, then CONTROLFILE_RECORD_KEEP_TIME = 90 (retention policy) + 7 (level 0 backup interval) + 1 = 98
Note: In worst case, atleast you should set that same (equal to) as retention policy value
What happens if I don’t set to higher value?
In such case, RMAN will overwrite the content of backup metadata prior to obsolete them by RMAN and even though physically backup pieces are existing, you cannot use them
For example a friend posted that his retention policy is set to recovery window of 90 days, but when tried to restore the database to 30 days back date, RMAN saying recovery till that time is not possible. he wondered why this cannot be done if he has retention of 90 days.
Here is the answer for the same….
we all know that RMAN will store backup metadata in control file’s reusable location if recovery catalog is not configured. Generally this information will be stored for 7 days and can be changed by modifying CONTROLFILE_RECORD_KEEP_TIME parameter.
whenever we define retention policy of RMAN either to recovery window or redundancy to some X value, we need to remember that RMAN still follow the value defined for CONTROLFILE_RECOD_KEEP_TIME. That means, if recovery window is set to 30 days, but the above parameter is set to 7 days (default), you cannot recover beyond 7 days… which is very unfortunate…
Right ! so lets see what can be done for this?
we need to define CONTROLFILE_RECORD_KEEP_TIME always a higher value than what we set for retention policy. As per the formula, it should be
CONTROLFILE_RECORD_KEEP_TIME=retention policy value+ level 0 backup interval+ 1
let me throw some example for easy understanding…
If suppose your retention time is set to recovery window of 90 days and a weekly full level 0 backup is scheduled, then CONTROLFILE_RECORD_KEEP_TIME = 90 (retention policy) + 7 (level 0 backup interval) + 1 = 98
Note: In worst case, atleast you should set that same (equal to) as retention policy value
What happens if I don’t set to higher value?
In such case, RMAN will overwrite the content of backup metadata prior to obsolete them by RMAN and even though physically backup pieces are existing, you cannot use them
Tuesday, 20 December 2011
Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2
Applies to:
Oracle Server - Enterprise Edition - Version: 11.2.0.2 and later [Release: 11.2 and later ]
Oracle Server - Standard Edition - Version: 11.2.0.2 and later [Release: 11.2 and later]
Oracle Server - Personal Edition - Version: 11.2.0.2 and later [Release: 11.2 and later]
Information in this document applies to any platform.
What is being announced?
Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2
What has changed?
Packaging: Starting with the first patch set for Oracle Database 11g Release 2 (11.2.0.2), Oracle Database patch sets are full installations of the Oracle Database software. In past releases, Oracle Database patch sets consisted of a set of files that replaced files in an existing Oracle home. Beginning with Oracle Database 11g Release 2, patch sets are full installations that replace existing installations.
Because Oracle Database 11g Release 2 and later patch sets are a full installation, Oracle patch sets are now released as several installation bundles, just as are the base releases:
Oracle Database Server
Oracle Grid Infrastructure
Oracle Database Client
Companion/examples
Oracle Gateways
Simplified new installation: Because the release 11.2.0.2 patch set is a full installation package, if you are installing Oracle Database on a system without an existing Oracle Database installation, then you can simply install the release 11.2.0.2 patch set. You are no longer required to install the base release, and then apply the patch set.
Upgrade process: Beginning with the release 11.2.0.2 patch set, you have two ways to apply a patch set:
Out-of-place upgrade – This is Oracle's recommended way to apply a patch set. You install the patch set into a new, separate Oracle home location. After you install the patch upgrade, you then migrate the Oracle Database from the older Oracle home. The patch set upgrade is now the same process to upgrade from one version to another. Oracle recommends that you perform an out-of-place patch set upgrade, because this patch set application option requires much less downtime, and is safer because it does not require patching an ORACLE_HOME that is already being used in production. However, you must ensure that you have sufficient free disk space to accommodate two Oracle home directories at the same time.
In-place upgrade – You install the patch set into an existing Oracle home location. Oracle recommends that you select this option only if you do not have sufficient free disk space to perform an out-of-place upgrade, as the upgrade removes the existing Oracle installation. This patch option requires less disk space, but requires more time, and is riskier, because if you encounter an installation failure, then you must recover the entire existing Oracle home from a backup. If you choose this more risky option, then before you begin the patch installation, complete the following tasks:
Make a complete backup of your existing Oracle home
Read through the entire Upgrade Guide section dealing with in-place upgrades
Note: All Oracle Grid Infrastructure patch set upgrades must be out-of-place upgrades, in which you install the patch set into a new Grid home. In-place patch set upgrades are not supported.
Direct upgrade from previous releases: You can upgrade from a previous Oracle Database release directly to the latest patch set, without having to install the base release. For example, if you want to upgrade from Oracle Database 10g Release 2, or Oracle Database 11g Release 1, then you can upgrade directly to Oracle Database 11g Release 2, patch set 2 (11.2.0.2) using an out-of-place upgrade. Oracle now supports direct upgrades to the release 11.2.0.2 patch set from any release where direct upgrade to the base release (11.2.0.1) is supported, as well as direct upgrades from 11.2.0.1 to 11.2.0.2.
New Features Available in Patch Sets
In addition to the usual set of fixes, the release 11.2.0.2 patch set contains a small number of features that complete the Database 11g Release 2 feature set. The new features fall into the following five categories:
General improvements
Oracle Automatic Storage Management Cluster File System (ACFS) improvements
Quality of Service Management
Database Replay
Management
How to Obtain the Patch Set
As with all previous patch sets, the release 11.2.0.2 patch set is available for download from the Patches tab on My Oracle Support.
Important Changes to Note:
Disk space requirement: Because the out-of-place upgrade requires the installation of a new Oracle home, you must have enough free disk space to accommodate the new Oracle home, as well as disk space needed for temporary files during installation.
ORACLE_HOME location change: When using the out-of-place upgrade path, the location of your Oracle home is different after you complete the upgrade. You must change any direct references to the old location of your Oracle home (such as in /etc/oratab or in tnsnames.ora) to the new location, and update user environment variables for the Oracle home.
In-place upgrade process differs from previous patch set installation processes: Even though it seems similar, the in-place upgrade process for the release 11.2.0.2 patch set differs from previous patch set installation procedures. It is very important to read the entire in-place upgrade process before you begin to install the release 11.2.0.2 patch set, because the preinstallation steps are different.
Frequently Asked Questions
Q. Is this really a patch set?
A. Yes – This patch set still consists primarily of incremental bug fixes to the base release (11.2.0.1) but with different packaging. While new features are included in 11.2.0.2, the number of new features is very small, and is included to complete the 11.2 feature set.
Q. Why did Oracle make this change?
A. In response to customer feedback, Oracle is making this change for several reasons:
Out-of-place upgrade has been a best practice of many customers for patch set application for years. Out-of-place upgrades reduce downtime, because you can complete the initial installation and configuration of the upgrade before you take down the existing installation. Out-of-place patch upgrades are easier, safer, and provide faster fallback if needed: If you encounter issues with the new installation, then simply point clients back to the original Oracle Database installation Oracle home, and restart the database.
Out-of-place upgrades allow customers running multiple instances out of one Oracle home to upgrade each instance individually rather than having to upgrade all instances sharing an Oracle home at the same time (and incur downtime on them all simultaneously).
Full installations provide a better customer experience during the upgrade. By creating a full installation package that uses the same installation process as a base release (as opposed to a differential install of the changes objects), Oracle is able to use the same tools to build and test the patch set installation as Oracle uses with the base release. Improved testing enables a smoother, more trouble-free upgrade process that uses significantly less down time.
Full installations provide an easier upgrade for customers moving to release 11.2.0.2 from releases earlier than Oracle Database 11g release 2. Instead of having to install the base release, and then applying a patch release, you can now upgrade to the latest release in one step.
Q. Is this new packaging unique to the 11.2.0.2 patch set, or will Oracle follow this model for future patch sets?
A. This will be the new model going forward. Oracle will release patch set release 11.2.0.3 and later patch sets as full installation packages. Direct out-of-place upgrade is the Oracle best practices recommendation for patch set upgrades.
Q. There are many new features in 11.2.0.2. Are patch sets not just for bug fixes?
A. Oracle intends to maintain the focus of patch sets as a fix delivery vehicle. Oracle has included a very small number of new features in past patch sets. In this case, after the release of Oracle Database 11g release 2 (11.2.0.1), Oracle completed development of a small number of features that are closely related to the 11.2 release, and Oracle is including these features so that you can use them now, rather than wait for their inclusion in next major release.
Reference Note: Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2 [ID 1189783.1]
Oracle Server - Enterprise Edition - Version: 11.2.0.2 and later [Release: 11.2 and later ]
Oracle Server - Standard Edition - Version: 11.2.0.2 and later [Release: 11.2 and later]
Oracle Server - Personal Edition - Version: 11.2.0.2 and later [Release: 11.2 and later]
Information in this document applies to any platform.
What is being announced?
Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2
What has changed?
Packaging: Starting with the first patch set for Oracle Database 11g Release 2 (11.2.0.2), Oracle Database patch sets are full installations of the Oracle Database software. In past releases, Oracle Database patch sets consisted of a set of files that replaced files in an existing Oracle home. Beginning with Oracle Database 11g Release 2, patch sets are full installations that replace existing installations.
Because Oracle Database 11g Release 2 and later patch sets are a full installation, Oracle patch sets are now released as several installation bundles, just as are the base releases:
Oracle Database Server
Oracle Grid Infrastructure
Oracle Database Client
Companion/examples
Oracle Gateways
Simplified new installation: Because the release 11.2.0.2 patch set is a full installation package, if you are installing Oracle Database on a system without an existing Oracle Database installation, then you can simply install the release 11.2.0.2 patch set. You are no longer required to install the base release, and then apply the patch set.
Upgrade process: Beginning with the release 11.2.0.2 patch set, you have two ways to apply a patch set:
Out-of-place upgrade – This is Oracle's recommended way to apply a patch set. You install the patch set into a new, separate Oracle home location. After you install the patch upgrade, you then migrate the Oracle Database from the older Oracle home. The patch set upgrade is now the same process to upgrade from one version to another. Oracle recommends that you perform an out-of-place patch set upgrade, because this patch set application option requires much less downtime, and is safer because it does not require patching an ORACLE_HOME that is already being used in production. However, you must ensure that you have sufficient free disk space to accommodate two Oracle home directories at the same time.
In-place upgrade – You install the patch set into an existing Oracle home location. Oracle recommends that you select this option only if you do not have sufficient free disk space to perform an out-of-place upgrade, as the upgrade removes the existing Oracle installation. This patch option requires less disk space, but requires more time, and is riskier, because if you encounter an installation failure, then you must recover the entire existing Oracle home from a backup. If you choose this more risky option, then before you begin the patch installation, complete the following tasks:
Make a complete backup of your existing Oracle home
Read through the entire Upgrade Guide section dealing with in-place upgrades
Note: All Oracle Grid Infrastructure patch set upgrades must be out-of-place upgrades, in which you install the patch set into a new Grid home. In-place patch set upgrades are not supported.
Direct upgrade from previous releases: You can upgrade from a previous Oracle Database release directly to the latest patch set, without having to install the base release. For example, if you want to upgrade from Oracle Database 10g Release 2, or Oracle Database 11g Release 1, then you can upgrade directly to Oracle Database 11g Release 2, patch set 2 (11.2.0.2) using an out-of-place upgrade. Oracle now supports direct upgrades to the release 11.2.0.2 patch set from any release where direct upgrade to the base release (11.2.0.1) is supported, as well as direct upgrades from 11.2.0.1 to 11.2.0.2.
New Features Available in Patch Sets
In addition to the usual set of fixes, the release 11.2.0.2 patch set contains a small number of features that complete the Database 11g Release 2 feature set. The new features fall into the following five categories:
General improvements
Oracle Automatic Storage Management Cluster File System (ACFS) improvements
Quality of Service Management
Database Replay
Management
How to Obtain the Patch Set
As with all previous patch sets, the release 11.2.0.2 patch set is available for download from the Patches tab on My Oracle Support.
Important Changes to Note:
Disk space requirement: Because the out-of-place upgrade requires the installation of a new Oracle home, you must have enough free disk space to accommodate the new Oracle home, as well as disk space needed for temporary files during installation.
ORACLE_HOME location change: When using the out-of-place upgrade path, the location of your Oracle home is different after you complete the upgrade. You must change any direct references to the old location of your Oracle home (such as in /etc/oratab or in tnsnames.ora) to the new location, and update user environment variables for the Oracle home.
In-place upgrade process differs from previous patch set installation processes: Even though it seems similar, the in-place upgrade process for the release 11.2.0.2 patch set differs from previous patch set installation procedures. It is very important to read the entire in-place upgrade process before you begin to install the release 11.2.0.2 patch set, because the preinstallation steps are different.
Frequently Asked Questions
Q. Is this really a patch set?
A. Yes – This patch set still consists primarily of incremental bug fixes to the base release (11.2.0.1) but with different packaging. While new features are included in 11.2.0.2, the number of new features is very small, and is included to complete the 11.2 feature set.
Q. Why did Oracle make this change?
A. In response to customer feedback, Oracle is making this change for several reasons:
Out-of-place upgrade has been a best practice of many customers for patch set application for years. Out-of-place upgrades reduce downtime, because you can complete the initial installation and configuration of the upgrade before you take down the existing installation. Out-of-place patch upgrades are easier, safer, and provide faster fallback if needed: If you encounter issues with the new installation, then simply point clients back to the original Oracle Database installation Oracle home, and restart the database.
Out-of-place upgrades allow customers running multiple instances out of one Oracle home to upgrade each instance individually rather than having to upgrade all instances sharing an Oracle home at the same time (and incur downtime on them all simultaneously).
Full installations provide a better customer experience during the upgrade. By creating a full installation package that uses the same installation process as a base release (as opposed to a differential install of the changes objects), Oracle is able to use the same tools to build and test the patch set installation as Oracle uses with the base release. Improved testing enables a smoother, more trouble-free upgrade process that uses significantly less down time.
Full installations provide an easier upgrade for customers moving to release 11.2.0.2 from releases earlier than Oracle Database 11g release 2. Instead of having to install the base release, and then applying a patch release, you can now upgrade to the latest release in one step.
Q. Is this new packaging unique to the 11.2.0.2 patch set, or will Oracle follow this model for future patch sets?
A. This will be the new model going forward. Oracle will release patch set release 11.2.0.3 and later patch sets as full installation packages. Direct out-of-place upgrade is the Oracle best practices recommendation for patch set upgrades.
Q. There are many new features in 11.2.0.2. Are patch sets not just for bug fixes?
A. Oracle intends to maintain the focus of patch sets as a fix delivery vehicle. Oracle has included a very small number of new features in past patch sets. In this case, after the release of Oracle Database 11g release 2 (11.2.0.1), Oracle completed development of a small number of features that are closely related to the 11.2 release, and Oracle is including these features so that you can use them now, rather than wait for their inclusion in next major release.
Reference Note: Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2 [ID 1189783.1]
Step By Step Manual Database Upgrade to 11.2.0.2
Compatibility Matrix
Minimum Version of the database that can be directly upgraded to Oracle 11g Release 2
Source Database Target Database
9.2.0.8 or higher 11.2.x
10.1.0.5 or higher 11.2.x
10.2.0.2 or higher 11.2.x
11.1.0.6 or higher 11.2.x
The following database version will require an indirect upgrade path.
Source Database ---> Upgrade Path for Target Database--->Target Database
7.3.3 (or lower)-----> 7.3.4 ---> 9.2.0.8 ---->11.2.x
8.0.5 (or lower)----> 8.0.6 ---> 9.2.0.8 ---->11.2.x
8.1.7 (or lower)----> 8.1.7.4---> 10.2.0.4---->11.2.x
9.0.1.3 (or lower)----> 9.0.1.4-- ->10.2.0.4---->11.2.x
9.2.0.7(or lower)---->9.2.0.8---->11.2.x
Here I am upgrading my Oracle 10.2.0.4 database to Oracle 11.2.0.2
1. Copy Pre upgrade Information gathering Script:
Log in to the system as the owner of the Oracle Database 11g Release 2 (11.2) Oracle home directory.
Copy the Pre-Upgrade Information Tool (utlu112i.sql) and utltzuv2.sql from the Oracle Database 11g Release 2 (11.2) ORACLE_HOME/rdbms/admin directory to a directory outside of the Oracle home, such as the temporary directory on your system.
$ORACLE_HOME/rdbms/admin/utlu112i.sql
2. Execute Pre Upgrade Script:
Should be change to the directory where utlu112i.sql had been copied in the previous step.
Start SQL*Plus and connect to the database instance as a user with SYSDBA privileges. Then run and spool the utlu112i.sql file. Please note that the database should be started using the Source Oracle Home.
$ sqlplus '/ as sysdba'
SQL> spool upgrade_info.log
SQL> @utlu112i.sql
SQL> spool off
SQL>
Check the spool file and examine the output of the upgrade information tool.
3. Check for the integrity of the source database:
Check for the integrity of the source database prior to starting the upgrade by downloading and running dbupgdiag.sql script from below My Oracle Support article
Note 556610.1 Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql) (Avoid this step if don’t have support access)
If the dbupgdiag.sql script reports any invalid objects, run $ORACLE_HOME/rdbms/admin/utlrp.sql (multiple times) to validate the invalid objects in the database, until there is no change in the number of invalid objects.
$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus "/ as sysdba"
SQL> @utlrp.sql
After validating the invalid objects, re-run dbupgdiag.sql in the database once again and make sure that everything is fine.
4. Check that National Characterset:
Check that National Characterset (NLS_NCHAR_CHARACTERSET) is UTF8 and AL16UTF16.
select value from NLS_DATABASE_PARAMETERS where parameter = 'NLS_NCHAR_CHARACTERSET';
If this is UTF8 or AL16UTF16 then no action is needed.
If is not UTF8 or AL16UTF16 then refer the following article
Note 276914.1 The National Character Set in Oracle 9i and 10g.
5. Optimizer Statistics:
When upgrading to Oracle Database 11g Release 2 (11.2), optimizer statistics are collected for dictionary tables that lack statistics. This statistics collection can be time consuming for databases with a large number of dictionary tables, but statistics gathering only occurs for those tables that lack statistics or are significantly changed during the upgrade
$ sqlplus "/as sysdba"
SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
6. Ensure that no files need media recovery:
Sql> SELECT * FROM v$recover_file;
7. Stop the listener for the database:
Make pfile from spfile;
$ lsnrctl stop
8. Suhtdown the Database:
Shutdown the database.
$ sqlplus "/as sysdba"
SQL> shutdown immediate;
9. Back Up the Database:
1- Perform Cold Backup
(or)
2- Take a backup using RMAN
Connect to RMAN:
rman "target / nocatalog"
RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT '%U' TAG before_upgrade;
BACKUP CURRENT CONTROLFILE TO '';
}
10 Backup and change pfile:
Make a backup of the init.ora file.
Comment out obsolete parameters
* The DIAGNOSTIC_DEST initialization parameter replaces the USER_DUMP_DEST, BACKGROUND_DUMP_DEST.
Note: Once the Parameter file is modified as per your requirement, copy the file to $ORACLE_HOME/dbs (11g Oracle Home )
11 Set Environment Variables:
If your operating system is UNIX then complete this step, else skip to next Step.
1. Make sure the following environment variables point to the Oracle 11g Release directories:
- ORACLE_BASE
- ORACLE_HOME
- PATH
$ export ORACLE_HOME=
$ export PATH=$ORACLE_HOME/bin:$PATH
$ export ORACLE_BASE=
Note : If ORACLE_BASE is not known, after setting Path towards 11g Oracle Home, execute 'orabase', which will point the location of base.
$ orabase
/uo1/app/oracle
2. Update the oratab entry, to set the new ORACLE_HOME pointing towards ORCL and disable automatic startup
Sample /etc/oratab
#orcl:/opt/oracle/product/10.2/db_1:N
orcl:/opt/oracle/product/11.2/db_1:N
Note : After /etc/oratab is updated to have sid and Oracle Home (11.2), you can execute oraenv (/usr/local/bin/oraenv) and set the environment. The input has to be the sid which is entered in /etc/oratab against 11g home.
for Instance,
[oracle@localhost ~]$ . oraenv
ORACLE_SID = [orcl] ? orcl
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2/db_1 is /u01/app/oracle
[oracle@localhost ~]$
12 Upgrade Database:
At the operating system prompt, change to the $ORACLE_HOME/rdbms/admin directory of 11gR2 Oracle Home.
$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus "/ as sysdba"
SQL> startup UPGRADE
Set the system to spool results to a log file for later verification after the upgrade is completed and start the upgrade script.
SQL> set echo on
SQL> SPOOL upgrade.log
SQL> @catupgrd.sql
SQL> spool off
These measures are an important final step to ensure the integrity and consistency of the newly upgraded Oracle Database software. Also, if you encountered a message listing obsolete initialization parameters when you started the database for upgrade, then remove the obsolete initialization parameters from the parameter file before restarting. If necessary, convert the SPFILE to a PFILE so you can edit the file to delete parameters.
Post Upgrade Steps
13 Post Upgrade:
Start the database and run the Post-Upgrade Status Tool $ORACLE_HOME/rdbms/admin/utlu112s.sql which provides a summary of the upgrade at the end of the spool log. It displays the status of the database components in the upgraded database and the time required to complete each component upgrade. Any errors that occur during the upgrade are listed with each component and must be addressed
$ sqlplus "/as sysdba"
SQL> STARTUP
SQL> @utlu112s.sql
14 Recompile Invalid Objects:
This script can be run concurrently with utlrp.sql. Run utlrp.sql to recompile any remaining stored PL/SQL and Java code in another session.
SQL> @utlrp.sql
15 Check for the integrity of the source database:
Check for the integrity of the upgraded database by running dbupgdiag.sql script from below Metalink article
Note 556610.1 Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)
If the dbupgdiag.sql script reports any invalid objects, run $ORACLE_HOME/rdbms/admin/utlrp.sql (multiple times) to validate the invalid objects in the database, until there is no change in the number of invalid objects.
After validating the invalid objects, re-run dbupgdiag.sql in the upgraded database once again and make sure that everything is fine.
16 Configure & Start Listener.ora :
Modify the listener.ora file:
For the upgraded instance(s) modify the ORACLE_HOME parameter to point to the new ORACLE_HOME. Start the listener :
lsnrctl start
17 Crosscheck Environment Variables:
Set Environment Variables
1. Make sure the following environment variables point to the Oracle 11g Release directories:
- ORACLE_BASE
- ORACLE_HOME
- PATH
Also check that your oratab file and any client scripts that set the value of ORACLE_HOME point to the Oracle Database 11g Release 2 (11.2) home.
Note : If you are upgrading a cluster database, then perform these checks on all nodes in which this cluster database has instances configured.
2. Modify /etc/oratab entry to use automatic startup
SID:ORACLE_HOME:Y
For Instance,
orcl:/opt/oracle/product/11.2/db_1:Y
18 Spfile from Pfile:
Edit init.ora:
- If you changed the CLUSTER_DATABASE parameter prior the upgrade set it back to TRUE
- Migrate your initialization parameter file to a server parameter file.
Create a server parameter file with a initialization parameter file
SQL> create spfile from pfile;
This will create a spfile as a copy of the init.ora file located in $ORACLE_HOME/dbs (UNIX) & %ORACLE_HOME%\database (Windows).
19 Start the Database with spfile:
Shutdown the database:
Sql> shutdown immediate
Now start the database it will user spfile
Sql> startup
Check the Alert log file for any Error.
Database is ready to use now.
Minimum Version of the database that can be directly upgraded to Oracle 11g Release 2
Source Database Target Database
9.2.0.8 or higher 11.2.x
10.1.0.5 or higher 11.2.x
10.2.0.2 or higher 11.2.x
11.1.0.6 or higher 11.2.x
The following database version will require an indirect upgrade path.
Source Database ---> Upgrade Path for Target Database--->Target Database
7.3.3 (or lower)-----> 7.3.4 ---> 9.2.0.8 ---->11.2.x
8.0.5 (or lower)----> 8.0.6 ---> 9.2.0.8 ---->11.2.x
8.1.7 (or lower)----> 8.1.7.4---> 10.2.0.4---->11.2.x
9.0.1.3 (or lower)----> 9.0.1.4-- ->10.2.0.4---->11.2.x
9.2.0.7(or lower)---->9.2.0.8---->11.2.x
Here I am upgrading my Oracle 10.2.0.4 database to Oracle 11.2.0.2
1. Copy Pre upgrade Information gathering Script:
Log in to the system as the owner of the Oracle Database 11g Release 2 (11.2) Oracle home directory.
Copy the Pre-Upgrade Information Tool (utlu112i.sql) and utltzuv2.sql from the Oracle Database 11g Release 2 (11.2) ORACLE_HOME/rdbms/admin directory to a directory outside of the Oracle home, such as the temporary directory on your system.
$ORACLE_HOME/rdbms/admin/utlu112i.sql
2. Execute Pre Upgrade Script:
Should be change to the directory where utlu112i.sql had been copied in the previous step.
Start SQL*Plus and connect to the database instance as a user with SYSDBA privileges. Then run and spool the utlu112i.sql file. Please note that the database should be started using the Source Oracle Home.
$ sqlplus '/ as sysdba'
SQL> spool upgrade_info.log
SQL> @utlu112i.sql
SQL> spool off
SQL>
Check the spool file and examine the output of the upgrade information tool.
3. Check for the integrity of the source database:
Check for the integrity of the source database prior to starting the upgrade by downloading and running dbupgdiag.sql script from below My Oracle Support article
Note 556610.1 Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql) (Avoid this step if don’t have support access)
If the dbupgdiag.sql script reports any invalid objects, run $ORACLE_HOME/rdbms/admin/utlrp.sql (multiple times) to validate the invalid objects in the database, until there is no change in the number of invalid objects.
$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus "/ as sysdba"
SQL> @utlrp.sql
After validating the invalid objects, re-run dbupgdiag.sql in the database once again and make sure that everything is fine.
4. Check that National Characterset:
Check that National Characterset (NLS_NCHAR_CHARACTERSET) is UTF8 and AL16UTF16.
select value from NLS_DATABASE_PARAMETERS where parameter = 'NLS_NCHAR_CHARACTERSET';
If this is UTF8 or AL16UTF16 then no action is needed.
If is not UTF8 or AL16UTF16 then refer the following article
Note 276914.1 The National Character Set in Oracle 9i and 10g.
5. Optimizer Statistics:
When upgrading to Oracle Database 11g Release 2 (11.2), optimizer statistics are collected for dictionary tables that lack statistics. This statistics collection can be time consuming for databases with a large number of dictionary tables, but statistics gathering only occurs for those tables that lack statistics or are significantly changed during the upgrade
$ sqlplus "/as sysdba"
SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
6. Ensure that no files need media recovery:
Sql> SELECT * FROM v$recover_file;
7. Stop the listener for the database:
Make pfile from spfile;
$ lsnrctl stop
8. Suhtdown the Database:
Shutdown the database.
$ sqlplus "/as sysdba"
SQL> shutdown immediate;
9. Back Up the Database:
1- Perform Cold Backup
(or)
2- Take a backup using RMAN
Connect to RMAN:
rman "target / nocatalog"
RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT '%U' TAG before_upgrade;
BACKUP CURRENT CONTROLFILE TO '';
}
10 Backup and change pfile:
Make a backup of the init.ora file.
Comment out obsolete parameters
* The DIAGNOSTIC_DEST initialization parameter replaces the USER_DUMP_DEST, BACKGROUND_DUMP_DEST.
Note: Once the Parameter file is modified as per your requirement, copy the file to $ORACLE_HOME/dbs (11g Oracle Home )
11 Set Environment Variables:
If your operating system is UNIX then complete this step, else skip to next Step.
1. Make sure the following environment variables point to the Oracle 11g Release directories:
- ORACLE_BASE
- ORACLE_HOME
- PATH
$ export ORACLE_HOME=
$ export PATH=$ORACLE_HOME/bin:$PATH
$ export ORACLE_BASE=
Note : If ORACLE_BASE is not known, after setting Path towards 11g Oracle Home, execute 'orabase', which will point the location of base.
$ orabase
/uo1/app/oracle
2. Update the oratab entry, to set the new ORACLE_HOME pointing towards ORCL and disable automatic startup
Sample /etc/oratab
#orcl:/opt/oracle/product/10.2/db_1:N
orcl:/opt/oracle/product/11.2/db_1:N
Note : After /etc/oratab is updated to have sid and Oracle Home (11.2), you can execute oraenv (/usr/local/bin/oraenv) and set the environment. The input has to be the sid which is entered in /etc/oratab against 11g home.
for Instance,
[oracle@localhost ~]$ . oraenv
ORACLE_SID = [orcl] ? orcl
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2/db_1 is /u01/app/oracle
[oracle@localhost ~]$
12 Upgrade Database:
At the operating system prompt, change to the $ORACLE_HOME/rdbms/admin directory of 11gR2 Oracle Home.
$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus "/ as sysdba"
SQL> startup UPGRADE
Set the system to spool results to a log file for later verification after the upgrade is completed and start the upgrade script.
SQL> set echo on
SQL> SPOOL upgrade.log
SQL> @catupgrd.sql
SQL> spool off
These measures are an important final step to ensure the integrity and consistency of the newly upgraded Oracle Database software. Also, if you encountered a message listing obsolete initialization parameters when you started the database for upgrade, then remove the obsolete initialization parameters from the parameter file before restarting. If necessary, convert the SPFILE to a PFILE so you can edit the file to delete parameters.
Post Upgrade Steps
13 Post Upgrade:
Start the database and run the Post-Upgrade Status Tool $ORACLE_HOME/rdbms/admin/utlu112s.sql which provides a summary of the upgrade at the end of the spool log. It displays the status of the database components in the upgraded database and the time required to complete each component upgrade. Any errors that occur during the upgrade are listed with each component and must be addressed
$ sqlplus "/as sysdba"
SQL> STARTUP
SQL> @utlu112s.sql
14 Recompile Invalid Objects:
This script can be run concurrently with utlrp.sql. Run utlrp.sql to recompile any remaining stored PL/SQL and Java code in another session.
SQL> @utlrp.sql
15 Check for the integrity of the source database:
Check for the integrity of the upgraded database by running dbupgdiag.sql script from below Metalink article
Note 556610.1 Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)
If the dbupgdiag.sql script reports any invalid objects, run $ORACLE_HOME/rdbms/admin/utlrp.sql (multiple times) to validate the invalid objects in the database, until there is no change in the number of invalid objects.
After validating the invalid objects, re-run dbupgdiag.sql in the upgraded database once again and make sure that everything is fine.
16 Configure & Start Listener.ora :
Modify the listener.ora file:
For the upgraded instance(s) modify the ORACLE_HOME parameter to point to the new ORACLE_HOME. Start the listener :
lsnrctl start
17 Crosscheck Environment Variables:
Set Environment Variables
1. Make sure the following environment variables point to the Oracle 11g Release directories:
- ORACLE_BASE
- ORACLE_HOME
- PATH
Also check that your oratab file and any client scripts that set the value of ORACLE_HOME point to the Oracle Database 11g Release 2 (11.2) home.
Note : If you are upgrading a cluster database, then perform these checks on all nodes in which this cluster database has instances configured.
2. Modify /etc/oratab entry to use automatic startup
SID:ORACLE_HOME:Y
For Instance,
orcl:/opt/oracle/product/11.2/db_1:Y
18 Spfile from Pfile:
Edit init.ora:
- If you changed the CLUSTER_DATABASE parameter prior the upgrade set it back to TRUE
- Migrate your initialization parameter file to a server parameter file.
Create a server parameter file with a initialization parameter file
SQL> create spfile from pfile;
This will create a spfile as a copy of the init.ora file located in $ORACLE_HOME/dbs (UNIX) & %ORACLE_HOME%\database (Windows).
19 Start the Database with spfile:
Shutdown the database:
Sql> shutdown immediate
Now start the database it will user spfile
Sql> startup
Check the Alert log file for any Error.
Database is ready to use now.
How to see free space on unix system.
[oracle@itc-799 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 100G 72G 24G 76% /
/dev/sda2 341G 205G 119G 64% /data
/dev/sda1 92M 12M 76M 14% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
df -h is command to check space usage on unix system, type this command on unix prompt and the out will be like above detail. In the above example, we have two mount points “/” and “/data” which we can use. In local environment usually we have two or one mount point.
Let’s talk about these mount points one by one.
/dev/sda3 100G 72G 24G 76% /
This mount point is known as root mount point and has total 100G of space out of which 72G is used and 24G is available.
/dev/sda2 341G 205G 119G 64% /data
This mount point is known as data mount point as given name and have 341G of space out of which 205G is used and 119G is free and the used percentage is 64%.
Some systems may have more mount points like
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 100G 72G 24G 76% /
/dev/sda2 341G 205G 119G 64% /data
/dev/sda4 341G 205G 119G 64% /data1
/dev/sda1 92M 12M 76M 14% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
This system has there mount points “/” , “/data” and “/data1”.
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 100G 72G 24G 76% /
/dev/sda2 341G 205G 119G 64% /data
/dev/sda1 92M 12M 76M 14% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
df -h is command to check space usage on unix system, type this command on unix prompt and the out will be like above detail. In the above example, we have two mount points “/” and “/data” which we can use. In local environment usually we have two or one mount point.
Let’s talk about these mount points one by one.
/dev/sda3 100G 72G 24G 76% /
This mount point is known as root mount point and has total 100G of space out of which 72G is used and 24G is available.
/dev/sda2 341G 205G 119G 64% /data
This mount point is known as data mount point as given name and have 341G of space out of which 205G is used and 119G is free and the used percentage is 64%.
Some systems may have more mount points like
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 100G 72G 24G 76% /
/dev/sda2 341G 205G 119G 64% /data
/dev/sda4 341G 205G 119G 64% /data1
/dev/sda1 92M 12M 76M 14% /boot
tmpfs 2.0G 0 2.0G 0% /dev/shm
This system has there mount points “/” , “/data” and “/data1”.
Moving between two Oracle Homes
I have two Oracle versions installed on my system. Oracle 11.2.0.1 and Oracle 11.2.0.2.
Here are the steps how to switch between them.
Make Oracle 11.2.0.1 as Oracle Home
oracle@suse32:~> cd /opt/oracle/product/11.2/db_1/bin/
oracle@suse32:/opt/oracle/product/11.2/db_1/bin> export ORACLE_HOME=/opt/oracle/product/11.2/db_1 product/11.2/db_1
oracle@suse32:/opt/oracle/product/11.2/db_1/bin> ./sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Mon Nov 7 23:47:37 2011
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> exit;
oracle@suse32:/opt/oracle/product> ls
11.2 11.2.0.2
Make Oracle 11.2.0.2 as Oracle Home
oracle@suse32:/opt/oracle/product> cd 11.2.0.2/
oracle@suse32:/opt/oracle/product/11.2.0.2> cd db_1/bin/
oracle@suse32:/opt/oracle/product/11.2.0.2/db_1/bin> export ORACLE_HOME=/opt/oracle/product/11.2.0.2/db_1
oracle@suse32:/opt/oracle/product/11.2.0.2/db_1/bin> ./sqlplus /nolog
SQL*Plus: Release 11.2.0.2.0 Production on Mon Nov 7 23:58:40 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
SQL>
Here are the steps how to switch between them.
Make Oracle 11.2.0.1 as Oracle Home
oracle@suse32:~> cd /opt/oracle/product/11.2/db_1/bin/
oracle@suse32:/opt/oracle/product/11.2/db_1/bin> export ORACLE_HOME=/opt/oracle/product/11.2/db_1 product/11.2/db_1
oracle@suse32:/opt/oracle/product/11.2/db_1/bin> ./sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Mon Nov 7 23:47:37 2011
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> exit;
oracle@suse32:/opt/oracle/product> ls
11.2 11.2.0.2
Make Oracle 11.2.0.2 as Oracle Home
oracle@suse32:/opt/oracle/product> cd 11.2.0.2/
oracle@suse32:/opt/oracle/product/11.2.0.2> cd db_1/bin/
oracle@suse32:/opt/oracle/product/11.2.0.2/db_1/bin> export ORACLE_HOME=/opt/oracle/product/11.2.0.2/db_1
oracle@suse32:/opt/oracle/product/11.2.0.2/db_1/bin> ./sqlplus /nolog
SQL*Plus: Release 11.2.0.2.0 Production on Mon Nov 7 23:58:40 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
SQL>
Subscribe to:
Posts (Atom)