31. Can you migrate
data in a database on one operating system to 11gR1 or 11gR2 on another
operating system
using DBUA or manual upgrade ?
When using DBUA or when
performing a manual upgrade, you cannot migrate data in a database on one
operating system to a database on another operating system.
For example:
You cannot migrate data in an Oracle9i
database on Solaris to an 11g Release 1 (11.1)
database on Windows 2000 using DBUA.
If you must migrate
Oracle Database software to a different operating system, then the best
practice is to follow these steps:
Use the Oracle Database 11g Release 1 (11.1) cross-platform transportable
tablespace feature or the Oracle Data Pump Export and Import
32. What is the Pre-Upgrade Information Tool (utlu<xxx>i.sql) and
where is it located?
The Pre-Upgrade Information Tool is a SQL script (utlu11ni.sql) that ships
with Oracle Database 11gR1 or 11gR2, and must be copied to and run from the
environment of the database being upgraded.
After you have installed Oracle Database 11g Release 1 (11.1) and any
required patches, you should analyze your database before upgrading it to the
new release. This is done by running the Pre-Upgrade Information Tool. This is a necessary step if you are
upgrading manually. It provides information about the source database and
displays warnings and recommendations about possible upgrade issues with the
database. It also records the timezone
version which is later used by the actual upgrade script. It is also
recommended if you are upgrading with DBUA, so that you can preview the items
that DBUA checks.
The location of the Pre-Upgrade Information Tool is a SQL script
(utlu11ni.sql) which is located in the <ORACLE_HOME>/rdbms/admin
directory.
33. Can you upgrade
Oracle Database Express Edition to 11gR1 or 11gR2?
Yes. In order to upgrade
Oracle Database 10g Express Edition (Oracle Database XE) to Oracle Database
11g, you need to install Oracle Database 11g on the same system as Oracle
Database XE and use the Database Upgrade Assistant to perform the upgrade.
34. What are the
different Component Status Values in the dba_registry view?
Following are the STATUS
of the database components when querying "STATUS" from DBA_REGISTRY .
INVALID
: One or more objects for this component are invalid
VALID
: All objects for this component are valid
LOADING
: Load script for this component is executing
LOADED
: Load script for this component reached the end
UPGRADING
: Upgrade script for this component is executing
UPGRADED
: Upgrade script for this component reached the end
DOWNGRADING
: Downgrade script for this component is executing
DOWNGRADED
: Downgrade script for this component reached the end
REMOVING
: Components is in the process of being removed
OPTIONOFF
: This component was installed, but is not currently enabled
NOSCRIPT
: This component is enabled, but there is no upgrade/downgrade script for this
component
35. What are the
STATUS of the database components ?
Component Status Values
Description
NO
SCRIPT The component upgrade script was not found in
ORACLE_HOME. Check the install logs, install the component software, and then
rerun catupgrd.sql.
OPTION
OFF The server option required for the component was not
installed or was not linked with the server. Check the V$OPTION view as well as the install logs. Install the component or
relink the server with the required option, and then rerun catupgrd.sql
REMOVED
The component was not upgraded because it was removed from the database.
INVALID
Some objects for the component were invalid at the completion of the upgrade.
If there were no errors during the component upgrade, then running utlrp.sql might change the status to
VALID without rerunning the entire upgrade. Check the DBA_REGISTRY view after
running utlrp.sql.
UPGRADING
The component upgrade did not complete. Resolve the problem and rerun catupgrd.sql
36. Do you need to
disable Oracle Database Vault before upgrade to 11gR1 or 11gR2?
Yes, if you have enabled
Oracle Database Vault, then you must disable it before upgrading the database,
and enable it again when the upgrade is finished.If Database Vault is enabled,
then DBUA will return an error asking you to disable Database Vault prior to
upgrade
37. Do you need to
upgrade the timezone files before upgrade?
If you are upgrading to
11gR1:
The time zone files that
are supplied with Oracle Database 11g Release 1 (11.1) are version 4, to
reflect changes in transition rules for some time zone regions
If you have not already
updated your existing databases to time zone file version 4, you must do so
prior to upgrading to Oracle Database 11g Release 1 (11.1).
If your existing
databases are already using a time zone file version greater than 4, then after
installing Oracle Database 11g Release 1 (11.1), you must patch the ORACLE_HOME
with the appropriate 11g patch for the time zone file version in use with the
databases you will be upgrading.
If the time zone file
version used by the Oracle Database 11g Release 1 (11.1) server does not match
the time zone file version that was used with the existing database being
upgraded, then the upgrade script will terminate without upgrading the
database.
If you are upgrading to
11gR2:
The timezone files
supplied are TZ version 11 or 14 depending on patch level.
If your source timezone
is less then the installed version for 11gR2, you will upgrade the timezone
post upgrading using thdbms_dst package
If your source timezone
is greater then the installed version for 11gR2, you must patch the 11gR2
version to the same level.
38. During the upgrade you receive ORA-165x errors. How can you avoid
these errors?
To avoid these errors, set AUTOEXTEND ON MAXSIZE UNLIMITED for the
SYSTEM and SYSAUX tablespaces.
39. During the
upgrade you receive an ORA-1562 error. How can you avoid this error? OR
ORA-01562: failed to
extend rollback segment number string
Typically you get an
ora-1562 error if your rollback segment size is insufficient. If you are using
rollback segments, then you must have a single large (100 MB) PUBLIC rollback
segment online while the upgrade scripts are being run. Smaller public rollback
segments should be taken offline during the upgrade.
If you are using an undo
tablespace, then be sure it is at least 400 MB.
40. What is a
database upgrade?
Database upgrade is the
process of changing the data dictionary contents of a database to reflect a
particular release of the server. This process transforms an existing Oracle
Database system (including associated applications) into different releases of
the Oracle Database Server.
41. What type of
upgrades are there?
There are two general
types of upgrade:
1. Major or Maintenance
upgrade
2. Patch set upgrade (
within a release )
In a Major or
Maintenance upgrade you are upgrading from one major or maintenance release to another.
When you do a Major or Maintenance upgrade, the first and/or second digit of
the Oracle release number will be changed to the new database release number.
Example :
Upgrading from 10.2.0 to
11.2.0 is a major release upgrade
Upgrading from 11.1.0 to
11.2.0 is a maintenance release upgrade
In a patch set upgrade,
you are upgrading the database within the same major and maintenance release by
applying a patch set. When you do a patch set upgrade, the fourth digit of the
Oracle release number will be changed.
Example : Upgrading from
11.2.0.2 to 11.2.0.3 is a patch set upgrade.
42. Is upgrade time
dependent on the size of the database ?
NO .the upgrade time is
independent of the size of the database .
43. What is direct
and indirect upgrade ?
Direct upgrade means you
can directly upgrade your source database release/version to the target
databaserelease/version.
Example : If the source
database is 9.2.0.8 or higher, then you can upgrade directly to database
11.2.x.
9.2.0.8 or higher
---> 11.2.x
Indirect upgrade means
you cannot directly upgrade the source database release/version to the target
database release/version. You first have to upgrade the database to a supported
release/version as an interim step, and then you can directly upgrade the database
to the target database release/version .
Example : If the source
database is 8.1.7.0.0, the upgrade path to 11.2.x requires three upgrades as
follows
8.1.7.0.0 --> 8.1.7.4
--> 10.2.0.4--> 11.2.x.
44. Can we estimate
the time to upgrade the database ?
Predicting the time of
an upgrade is a common question but, unfortunately, there is no simple answer
to this question due to the differences in environments, platforms, processors,
memory, disk storage, options, and many other factors.
Running a test upgrade
is the only useful method to approximate the time needed.
45. Does the presence
of various database components affect the time to upgrade a database?
YES, the presence of
various database components affects the time to upgrade the database. If you
have ONLY "Oracle Database Server" component installed then it will
take less time compared to other databases in which more components are
installed, like 'Oracle Spatial' , 'Oracle XLM database' and 'Oracle
Intermedia" etc. The upgrade process has to upgrade all the installed
components.
46. Which view can be
used to see the current/latest status of the database components ?
You can always use the
DBA_REGISTRY view to check the current/latest status of the database components
.
47. What setting is recommended
for the COMPATIBLE database parameter while doing the upgrade?
Oracle recommends you
keep the COMPATIBLE parameter to the minimum required to upgrade the database.
Once you are done with the complete testing of the upgraded database, then you
can set the COMPATIBLE initialization parameter to match the release number of
the new release. Doing so enables you to use all of the features of the new
release, but prevents you from downgrading.
Oracle recommends
increasing the COMPATIBLE parameter only after complete testing of the upgraded
database has been performed. After the upgrade is complete, you can increase
the setting of the COMPATIBLE initialization parameter to the maximum level for
the new Oracle Database release. However, after you increase the COMPATIBLE
parameter, the database cannot subsequently be downgraded.
48. Which schema
should the AUD$ table exist in while doing the upgrade ?
AUD$ table should exist
in SYS schema while doing the upgrade.
49. Can we use DBUA
to upgrade a database across servers?
NO, you cannot use DBUA
to upgrade the database across servers. DBUA can ONLY be used to upgrade the
database on the same server.
50. Can we invoke the
DBUA silently?
YES, DBUA can be invoked
silently. DBUA supports several command line options. You can specify all valid
options from the command line using the following syntax:
dbua [ -silent ] [ -sid SID ]
[-oracleHomehome_name] [-oracleBasebase_name]
[-diagnosticDestdiagnostic_destination]
[-sysDBAUserNameSYSDBA_user]
[-sysDBAPasswordSYSDBA_pwd]
[-upgradeASM] [-autoextendFiles]
[-newGlobalDbNamedb_name] [-newSidnew_SID]
[-generateMapFile] [-useASM]
[-commonFileLocationcommon_files]
[-omfLocationomf_area]
[-databaseMapFilemap_file_name]
[-newRecoveryArearecover_area]
[-newRecoveryAreaSizerecover_size]
[-apexAdminPasswordapex_pwd]
[-disableUpgradeScriptLogging ]
[-backupLocation directory]
[-sysauxTablespace -datafileName name
-datafileSize size
-datafileSizeNext size -datafileSizeMax size]
[-postUpgradeScripts script [, script ] ... ]
[-initParam parameter=value [, parameter=value
] ... ]
[-disableArchiveLogMode]
[-recompile_invalid_objects true | false]
[-degree_of_parallelismcpu_number]
[-emConfiguration {CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE}
-dbsnmpPassword password -sysmanPassword password
-asmPassword password
-hostUserName hostname -hostUserPassword
password -backupSchedulehh:mm
[-smtpServerserver_name -emailAddress address]
[-centralAgent location] [-localRacSid SID]]
[-recoveryAreaDestination directory]
[-h|-help]
51. Where does DBUA
get the information of the databases available for upgrade?
DBUA gets the
information of the databases available for upgrade from the /etc/oratab file, and other locations
in the oraInventory.
52. What is the
location of the DBUA logs?
For oracle 10g or higher
$ORACLE_HOME/cfgtoollogs/dbua/<SID>
For Oracle 9i
$ORACLE_HOME/assistants/dbma/<SID>
53. Can DBUA be
invoked multiple times after a failed DBUA upgrade?
NO, DBUA cannot be
invoked multiple times after a failed DBUA upgrade.
54. Is it required to
run pre-upgrade steps before starting DBUA?
DBUA executes
pre-upgrade script checks, so it is not required to execute pre-upgrade
scripts, but it is best practice to check whether DB is ready for upgrade prior
to invoking DBUA.
55. What is manual upgrade
?
A manual upgrade
consists of running SQL scripts and utilities from a command line to upgrade a
database to a new release. A manual upgrade gives you finer control over the
upgrade process, and is generally easier to debug if there is a problem during
the upgrade. It is more susceptible to problems if any of the upgrade or
pre-upgrade steps are either not followed or are performed out of order.
56. Can catupgrd.sql
be run multiple times while doing a manual upgrade?
YES, the catupgrd.sql
script can be run multiple times while doing a manual upgrade.
57. Can a database be
upgraded with OFFLINE NORMAL and READONLY user created tablespacesin
the source database?
YES, you can upgrade the
database with OFFLINE NORMAL and READONLY user created tablespaces in the
source database to minimize downtime during upgrade.
58. What is the
location of the catpugrd.sql log when using manual upgrade?
You have to set the
system to spool results to a log file for later verification after the upgrade
is completed. Unless you specify a directory path, the spool file will be
created in the current directory.
You can use following
command to spool the output of the catupgrd.sql to the current directory:
SQL> set echo on
SQL> SPOOL upgrade.log
SQL> @catupgrd.sql
SQL> spool off
59. What is the
Post-Upgrade Information Tool (utlu<xxx>s.sql)?
The Post-Upgrade
Information Tool (utlu<xxx>s.sql) is a SQL script 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, as well as the total database upgrade time.
Any errors that occur during the upgrade are listed with each component and
must be addressed. Please note that the output from this script will never
change unless the upgrade script is run again, as this script only shows the
status immediately after the upgrade script was run, which is not necessarily
the current status.
60. What is the
location of the Pre-Upgrade and Post-Upgrade Information scripts?
Pre-Upgrade Information
Tool or script location :
$ORACLE_HOME/rdbms/admin/utlu<xxx>i.sql
Post-Upgrade Information
Tool or script location :
$ORACLE_HOME/rdbms/admin/utlu<xxx>s.sql
61. Is it recommended
to implement all the recommendations suggested by Pre-Upgrade Information
Tool?
YES, it is recommended
to implement all the recommendations suggested by the Pre-Upgrade Information
tool. After making the recommended corrections, run the Pre-Upgrade script
again to verify.
62. Is it recommended
to apply the latest available patch set and PSU/CPU on the target database
before upgrading the
source database?
YES, it is recommended
to apply the latest available patch set and PSU/CPU on the target ORACLE_HOME
before upgrading the database. It will reduce the database downtime.
63. Is it recommended
to remove "hidden" parameters before upgrading?
Hidden parameters are
not carried to the target database by DBUA. This is expected behavior. Oracle
recommends removing all hidden parameters prior to upgrading. Changes will need
to be made in the pfile or spfile if you are manually upgrading the database.
If you are using DBUA, then it is taken care of by DBUA automatically.
64. Is it recommended
to purge the recycle bin objects prior to upgrade?
YES, it is recommended
to purge the recycle bin objects prior to upgrade .
65. Is it recommended
to remove the Obsolete/Deprecated Parameters prior to upgrade?
YES, you should remove
all of the Obsolete/Deprecated Parameters prior to upgrade.
66. Is it recommended
to gather statistics on the source database prior to upgrade?
Gathering statistics is
highly recommended on the source database prior to upgrading to decrease the
downtime and increase the upgrade performance.
67. What is the
requirement for the timezone file for successful upgrade?
For Oracle 9i,10gR1,
10gR2, and 11gR1 :
The source home and the
target home should have the same timezone version.
If the source timezone
version is lower than the default target timezone version then apply the patch
on the sourcehome to match the timezone version same as the target .
If the source timezone
version is higher than the default target timezone version then apply the patch
on the targethome to match the timezone version same as the source.
For 11gR2 and higher :
If the timezone version
of the source is lower than the target then you can upgrade the timezone
version to the defaultversion shipped with the target using the DBMS_DST
package AFTER the upgrade.
If the timezone version
of the source is higher than the target then apply the patch on the target home
to match thetimezone version same as the source.
68. Applying [PSU]
patch takes very long time (hours) after "verifying the update"
opatch
or "opatch auto" takes
hours to finish after the following message is printed:
[Feb 7, 2013 9:27:18 PM]
verifying 1009 copy files.
<<no more display
after this, it could stop here for hours, eventually complete
This is due to bug
13963741 which at the time of this writing is still being worked by Development,
the workaround is to unset environment variable "JAVA_COMPILER=NONE",
refer to note 1541186.1 for more details.
69. opatch auto
Reports: The path "<GRID_HOME>/bin/acfsdriverstate" does not
exist
"opatch auto"
reports the following message:
The path "/ocw/grid/bin/acfsdriverstate"
does not exist
The message can be
ignored
70. Common causes of
"patch <patch-loc> apply failed for home <ORACLE_HOME>"
dbconsole is not down -
it needs to be stopped prior to patching, as database home owner, execute
" <ORACLE_HOME>/bin/emctl stop
dbconsole" to stop it
OUI-67124:Copy failed from
'/ocw/grid/.patch_storage/13540563_Jan_16_2012_03_31_27/files/bin/crsctl.bin'
to
'/ocw/grid/bin/crsctl.bin'...
OUI-67124:ApplySession failed in system modification phase... 'Copy
failed from
'/ocw/grid/.patch_storage/13540563_Jan_16_2012_03_31_27/files/bin/crsctl.bin'
to '/ocw/grid/bin/crsctl.bin'...
OUI-67124:NApply restored the home. Please check your ORACLE_HOME to
make sure: dbconsole is not down
opatch bug 12732495,
refer to note 1472242.1 for more details.
opatch bug 14308442
which is closed as duplicate of bug 14358407, affects AIX only, refer to note
1518022.1
for more details.
other opatch bug - use
latest opatch to avoid known issues.
For other potential
causes, review opatch logfile. The OPatch log file can be found in
$ORACLE_HOME/cfgtoollogs/opatch.
No comments:
Post a Comment