11g New Features For Administrators Student Guide-2 PDF

Command Line Syntax
• Silent mode run

– dbua –silent –dbName <Oracle database>
• Backup location
– –backupLocation
• Custom scripts
– -postUpgradeScripts
• Initialization parameters
– –initParam
• Help
– -help
• EM configuration
– –emConfiguration
1 - 37 Copyright © 2007, Oracle. All rights reserved.
Command Line Syntax

When invoked with the -silent command line option, DBUA operates in silent mode. In silent
mode, DBUA does not present a user interface. It also writes any messages (including
information, errors, and warnings) to a log file in
ORACLE_HOME/cfgtoollogs/dbua/SID/upgraden, where n is the number of upgrades that DBUA
has performed as of this upgrade.
For example, the following command upgrades a database named ORCL in silent mode: dbua -
silent -dbName ORCL &
Here is a list of important options you can use:
• -backupLocation directory Specifies a directory to back up your database before the upgrade
starts
• -postUpgradeScripts script [, script ] ... Specifies a comma-delimited list of SQL scripts.
Specify complete path names. The scripts are executed at the end of the upgrade.
• -initParam parameter=value [, parameter=value ] ... Specifies a comma-delimited list of
initialization parameter values of the form name=value
• -emConfiguration {CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE} Specifies
Oracle Enterprise Manager management options.
Note: For more information on these options refer to the Oracle Database Upgrade guide.
Oracle Database 11g: New Features for Administrators 1 - 37

Using DBUA to Upgrade Your Database
Using DBUA to Upgrade Your Database

Complete the following steps to upgrade a database using the DBUA graphical user interface:
On Linux or UNIX platforms, enter the dbua command at a system prompt in the Oracle Database
11g release 1 (11.1) environment. The DBUA Welcome screen appears.
Click Next.
If an Automatic Storage Management (ASM) instance is detected on the system, then the Upgrade
Operations page appears with options to upgrade a database or an ASM instance. If no ASM
instance is detected, then Databases screen appears.
At the Upgrade Operations page, select Upgrade a Database. This operation upgrades a database
to Oracle Database 11g release 1 (11.1).
Oracle recommends that you upgrade the database and ASM in separate DBUA sessions, in
separate Oracle homes.
Click Next.

Choose Database to Upgrade and Diagnostic
Destination
Choose Database to Upgrade and Diagnostic Destination

The Databases screen appears.
Select the database you want to upgrade from the Available Databases table.
You can select only one database at a time. If you do not see the database that you want, then
make sure an entry with the database name exists in the oratab file in the etc directory.
If you are running DBUA from a user account that does not have SYSDBA privileges, then you
must enter the user name and password credentials to enable SYSDBA privileges for the selected
database.
Click Next.
DBUA analyzes the database, performing the following pre-upgrade checks and displaying
warnings as necessary:
• Redo log files whose size is less than 4 MB. If such files are found, then DBUA gives the
option to drop/create new redo log files.
• Obsolete or deprecated initialization parameters.
When DBUA finishes its checks, the Diagnostic Destination screen appears.
Do one of the following:
• Accept the default location for your diagnostic destination
• Enter the full path to a different diagnostic destination in the Diagnostic Destination field.
Click Browse to select a diagnostic destination
Click Next.
Moving Database Files
Moving Database Files

If you are upgrading a single-instance database, then the Move Database Files screen appears. If
you are upgrading an Oracle Real Application Clusters database, then the Move Database Files
screen does not appear.
Select one of the following options:
• Do Not Move Database Files as Part of Upgrade
• Move Database Files during Upgrade
If you choose to move database files, then you must also select one of the following:
• File System: Your database files are stored on the host file system.
• Automatic Storage Management (ASM): Your database files are stored on ASM storage,
which must already exist on your system. If you do not have an ASM instance, you can create
one using DBCA and then restart DBUA.
Click Next.

Database File Locations
Database File Locations

The Database File Locations screen appears.
Select one of the following options:
• Use Common Location for All Database Files. If you choose to have all of your database files
in one location, then you must also do one of the following:
- Accept the default location for your database files
- Enter the full path to a different location in the Database Files Location field
- Click Browse and select a different location for your database files
• Use Oracle-Managed Files. If you choose to use Oracle-Managed Files for your database
files, then you must also do one of the following:
- Accept the default database area
- Enter the full path to a different database area in the Database Area field
- Click Browse and select a different database area
• Use a Mapping File to Specify Location of Database Files. This option enables you to specify
different locations for your database files. A sample mapping file is available in the logging
location. You can edit the property values of the mapping file to specify a different location
for each database file.
Click Next.

Recovery Configuration
Recovery Configuration
The Recovery Configuration screen allows you to designate a Flash Recovery Area for your
database.
If you selected the Move Database Files during Upgrade, or if an Oracle Express Edition database
is being upgraded to Oracle Enterprise Edition, then a Flash recovery Area must be configured. If
a Flash Recovery Area is already configured, then current settings are retained but the screen will
come up to allow you to override these values.
Click Next.

Management Options and Database Credentials
Management Options and Database Credentials

If no other database is already being monitored with Enterprise Manager, then the Management
Options screen appears.
At the Management Options screen, you have the option of setting up your database so it can be
managed with Enterprise Manager.
Before you can register the database with Oracle Enterprise Manager Grid Control, an Oracle
Enterprise Manager Agent must be configured on the host computer.
To set up your database to be managed with Enterprise Manager, select Configure the Database
with Enterprise Manager and then select one of the proposed options.
Click Next.
The Database Credentials screen appears.
Choose one of the proposed options and click Next.

Network Configuration
Network Configuration
If DBUA detects multiple listeners are configured, then the Network Configuration for the
Database screen appears.
The Network Configuration screen has two tabs. The Listeners tab is displayed if you have more
than one listener. The Directory Service tab shows up if you have directory services configured.
On the Listeners tab, select one of the following options:
• Register this database with all the listeners
• Register this database with selected listeners only
If you choose to register selected listeners only, then you must select the listeners you want in the
Available Listeners list and use the arrow buttons to move them to the Selected Listeners list.
If you want to register your database with a directory service, then click the Directory Service tab.
On the Directory Service tab, select one of the following options:
• Yes, register the database: Selecting this option enables client computers to connect to this
database without a local name file (tnsnames.ora) and also enables them to use the Oracle
Enterprise User Security feature.
• No, don't register the database
If you choose to register the database, then you must also provide a user distinguished name (DN)
in the User DN field and a password for that user in the Password field.
An Oracle wallet is created as part of database registration. It contains credentials suitable for
password authentication between this database and the directory service. Enter a password in the
Wallet Password andDatabase
Oracle Confirm Password
11g: Newfields.
Features for Administrators 1 - 44
Click Next.
Recompile Invalid Objects
Recompile Invalid Objects

The Recompile Invalid Objects screen appears.
Select Recompile invalid objects at the end of upgrade if you want DBUA to recompile all invalid
PL/SQL modules after the upgrade is complete. This ensures that you do not experience any
performance issues later, as you begin using your newly upgraded database.
If you have multiple CPUs, then you can reduce the time it takes to perform this task by taking
advantage of parallel processing on your available CPUs. If you have multiple CPUs available,
then DBUA automatically adds an additional section to the Recompile Invalid Objects screen and
automatically determines the number of CPUs you have available.
DBUA also provides a recommended degree of parallelism, which determines how many parallel
processes are used to recompile your invalid PL/SQL modules. Specifically, DBUA sets the
degree of parallelism to one less than the number of CPUs you have available. You can adjust this
default value by selecting a new value from the Degree of Parallelism menu.
Select Turn off Archiving and Flashback logging for the duration of upgrade to reduce the time
required to complete the upgrade.
If the database is in ARCHIVELOG or flashback logging mode, then DBUA gives you the choice
of turning them off for the duration of the upgrade. If you choose this option, Oracle recommends
that you perform an offline backup immediately after the upgrade.
Click Next.

Database Backup and Space Checks
Database Backup and Space Checks

The Backup screen appears.
Select Backup database if you want DBUA to back up your database for you.
Oracle strongly recommends that you back up your database before starting the upgrade. If errors
occur during the upgrade, you might be required to restore the database from the backup.
If you use DBUA to back up your database, then it makes a copy of all your database files in the
directory you specify in the Backup Directory field. DBUA performs this cold backup
automatically after it shuts down the database and before it begins performing the upgrade
procedure. The cold backup does not compress your database files, and the backup directory must
be a valid file system path. You cannot specify a raw device for the cold backup files.
In addition, DBUA creates a batch file in the specified directory. You can use this batch file to
restore the database files:
• On Windows operating systems, the file is called db_name_restore.bat.
• On Linux or UNIX platforms, the file is called db_name_restore.sh.
If you choose not to use DBUA for your backup, then Oracle assumes you have already backed up
your database using your own backup procedures.
Click Next.
Note: If you decide to use DBUA to backup your database, DBUA checks that you have enough
space before the backup is taken.

Database Upgrade Summary
Database Upgrade Summary

The Summary screen appears.
The Summary screen shows the following information about the upgrade before it starts:
• Name, version, and Oracle home of the old and new databases
• Database backup location, available space, and space required
• Warnings ignored
• Database components to be upgraded
• Initialization parameters changes
• Database files location
• Listener registration
Check all of the specifications. Then do one of the following:
• Click Back if anything is incorrect until you reach the screen where you can correct it.
• Click Finish if everything is correct.

Upgrade Progress and Results
Upgrade Progress and Results

The Progress screen appears, and DBUA begins the upgrade.
You might encounter error messages with Ignore and Abort choices. If other errors appear, then
you must address them accordingly. If an error is severe and cannot be handled during the
upgrade, then you have the following choices:
• Click Ignore to ignore the error and proceed with the upgrade. You can fix the problem,
restart DBUA, and complete the skipped steps.
• Click Abort to terminate the upgrade process. If a database backup was taken by DBUA, then
it asks if you want to restore the database. After the database has been restored, you must
correct the cause of the error and restart DBUA to perform the upgrade again. If you do not
want to restore the database, then DBUA leaves the database in its present state so that you
can proceed with a manual upgrade.
After the upgrade has completed, the following message is displayed on the Progress screen:
Upgrade is complete. Click "OK" to see the results of the upgrade. Click OK.
The Upgrade Results screen appears.
The Upgrade Results screen displays a description of the original and upgraded databases and
changes made to the initialization parameters. The screen also shows the directory where various
log files are stored after the upgrade. You can examine these log files to obtain more details about
the upgrade process.
Click Restore Database if you are not satisfied with the upgrade results.

Best Practices - 1
• The three T’s: TEST, TEST, TEST

– Test the upgrade
– Test the application(s)
– Test the recovery strategy
• Functional Testing
– Clone your production database on a machine with
similar resources
– Use DBUA for your upgrade
– Run your application and tools to ensure they work
Best Practices – 1
Perform the planned tests on the current database and on the test database that you upgraded to
Oracle Database 11g release 1 (11.1). Compare the results, noting anomalies. Repeat the test
upgrade as many times as necessary.
Test the newly upgraded test database with existing applications to verify that they operate
properly with a new Oracle database. You also might test enhanced functions by adding available
Oracle Database features. However, first make sure that the applications operate in the same
manner as they did in the current database.
Functional testing is a set of tests in which new and existing features and functions of the system
are tested after the upgrade. Functional testing includes all database, networking, and application
components. The objective of functional testing is to verify that each component of the system
functions as it did before upgrading and to verify that new functions are working properly.
Create a test environment that does not interfere with the current production database.
Practice upgrading the database using the test environment. The best upgrade test, if possible, is
performed on an exact copy of the database to be upgraded, rather than on a downsized copy or
test data.
Do not upgrade the actual production database until after you successfully upgrade a test subset of
this database and test it with applications, as described in the next step.
The ultimate success of your upgrade depends heavily on the design and execution of an
appropriate backup strategy.

Best Practices - 2
• Performance Analysis
– Gather performance metrics prior to upgrade
— Gather AWR or Statspack baselines during various
workloads
– Gather sample performance metrics after upgrade
— Compare metrics before and after upgrade to catch issues
– Upgrade production systems only after performance and
functional goals have been met
• Pre-Upgrade Analysis
– You can run DBUA without clicking finish to get a pre-
upgrade analysis or utlu111i.sql
– Read general and platform specific release notes to catch
special cases
Performance testing of the new Oracle database compares the performance of various SQL
statements in the new Oracle database with the statements' performance in the current database.
Before upgrading, you should understand the performance profile of the application under the
current database. Specifically, you should understand the calls the application makes to the
database server.
For example, if you are using Oracle Real Application Clusters, and you want to measure the
performance gains realized from using cache fusion when you upgrade to Oracle Database 11g
release 1 (11.1), then make sure you record your system's statistics before upgrading.
For that, you can use various V$ views or AWR/Statspack reports.

Best Practices - 3
• Automate your upgrade

– Use DBUA in command line mode for automating your
upgrade
– Useful for upgrading a large number of databases
• Logging
– For manual upgrade, spool upgrade results and check
logs for possible issues
– DBUA can also do this for you
• Automatic conversion from 32 bit to 64 bit database
software
• Check for sufficient space in SYSTEM, UNDO, TEMP and
redo log files
Best Practices - 3
If you are installing 64-bit Oracle Database 11g release 1 (11.1) software but were previously
using a 32-bit Oracle Database installation, then the databases is automatically converted to 64-bit
during a patch release or major release upgrade to Oracle Database 11g release 1 (11.1).
You must increase initialization parameters affecting the system global area, such as sga_target
and shared_pool_size, to support 64-bit operation.

Best Practices - 4
• Use Optimal Flexibility Architecture (OFA)

– Offers best practices for locate your database files,
configuration files and ORACLE_HOME
• Use new features
– Migrate to CBO from RBO
– Automatic management features for SGA, Undo, PGA etc.
– Use AWR/ADDM to diagnose performance issues
– Consider using the SQL tuning advisor
– Change COMPATIBLE and OPTIMIZER_FEATURES_ENABLE
parameters to enable new optimizer features
Oracle recommends the Optimal Flexible Architecture (OFA) standard for your Oracle Database
installations. The OFA standard is a set of configuration guidelines for efficient and reliable
Oracle databases that require little maintenance.
OFA provides the following benefits:
• Organizes large amounts of complicated software and data on disk to avoid device
bottlenecks and poor performance
• Facilitates routine administrative tasks, such as software and data backup functions, which
are often vulnerable to data corruption
• Alleviates switching among multiple Oracle databases
• Adequately manages and administers database growth
• Helps to eliminate fragmentation of free space in the data dictionary, isolates other
fragmentation, and minimizes resource contention.
If you are not currently using the OFA standard, then switching to the OFA standard involves
modifying your directory structure and relocating your database files.

Best Practices - 5
• Use Enterprise Manager Grid Control to manage your

enterprise
– Use EM to setup new features and try them out
– EM provides complete manageability solution for
Databases, Applications, Storage, Security, Networks
• Collect Object and System Statistics to improve plans
generated by CBO
• Check for invalid objects in the database before
upgrading
– SQL> select owner, object_name, object_type,
status
from dba_objects where status<>'INVALID';
When upgrading to Oracle Database 11g release 1 (11.1), 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.
To decrease the amount of downtime incurred when collecting statistics, you can collect statistics
prior to performing the actual database upgrade. As of Oracle Database 10g release 1 (10.1),
Oracle recommends that you also use the DBMS_STATS.GATHER_DICTIONARY_STATS
procedure to gather dictionary statistics in addition to database component statistics like SYS,
SYSMAN, XDB, … using the DBMS_STATS.GATHER_SCHEMA_STATS procedure.

Best Practices- 6
• Avoid upgrading in a crisis

– Keep up with security alerts
– Keep up with critical patches needed for your
applications
– Keep track of de-support schedules
• Always upgrade to latest supported version of the
RDBMS
• Make sure patchset is available for all your platforms
• Data Vault Option needs to be turned off for upgrade
Best Practices- 6
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.

Deprecated Features in 11g Release 1
• Oracle Ultra Search

• Java Development Kit (JDK) 1.4
• CTXXPATH index
Deprecated Features in 11g Release 1

The slide lists Oracle Database features deprecated in Oracle Database 11g release 1 (11.1). They
are supported in this release for backward compatibility. But Oracle recommends that you migrate
away from these deprecated features:
• Oracle Ultra Search
• Java Development Kit (JDK) 1.4: Oracle recommends that you use JDK 5.0; but JDK 1.5 is
also fully supported.
• CTXXPATH index: Oracle recommends that you use XMLIndex instead.

Important Initialization Parameter Changes
• USER_DUMP_DEST
• BACKGROUND_DUMP_DEST DIAGNOSTIC_DEST
• CORE_DUMP_DEST
• UNDO_MANAGEMENT not set implies AUTO mode
• To migrate to automatic undo management:
1. Set UNDO_MANAGEMENT=MANUAL
2. Execute your workload
3. Execute DBMS_UNDO_ADV.RBU_MIGRATION function
4. Create undo tablespace based on previous size result
5. Set UNDO_MANAGEMENT=AUTO
Important Initialization Parameter Changes

The DIAGNOSTIC_DEST initialization parameter replaces the USER_DUMP_DEST,
BACKGROUND_DUMP_DEST, and CORE_DUMP_DEST parameters. Starting with Oracle
Database 11g, the default location for all trace information is defined by DIAGNOSTIC_DEST
which defaults to $ORACLE_BASE/diag.
For more information about diagnostics, refer to the Diagnostics lesson in this course.
A newly installed Oracle Database 11g instance defaults to automatic undo management mode,
and if the database is created with Database Configuration Assistant, an undo tablespace is
automatically created. A null value for the UNDO_MANAGEMENT initialization parameter now
defaults to automatic undo management. It used to default to manual undo management mode in
earlier releases. You must therefore use caution when upgrading a previous release to Oracle
Database 11g.

Important Initialization Parameter Changes (Continued)
To migrate to automatic undo management, perform the following steps:
1. Set UNDO_MANAGEMENT=MANUAL.
2. Start the instance again and run through a standard business cycle to obtain a representative
workload.
3. After the standard business cycle completes, run the following function to collect the undo
tablespace size:
DECLARE
utbsiz_in_MB NUMBER;
BEGIN
utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION;
end;
/
This function runs a PL/SQL procedure that provides information on how to size your new undo
tablespace based on the configuration and usage of the rollback segments in your system. The
function returns the sizing information directly.
4. Create an undo tablespace of the required size and turn on the automatic undo management by
setting UNDO_MANAGEMENT=AUTO or by removing the parameter.
Note: For RAC configurations, repeat these steps on all instances.

Direct NFS Client Overview
Oracle Database 10g Oracle Database 11g

Optional generic
configuration
parameters
Oracle Oracle
RDBMS RDBMS
kernel kernel
Specific
configuration
parameters DBA
Specific Specific
kernel kernel
NFS driver NFS driver
Variations across platforms

Lots of parameters to tune
NAS NAS
Ease of NFS configuration
Storage Much less parameters
Storage
(NFS V3)
Direct NFS Client Overview

Direct NFS is implemented as a Direct Network File System client as a part of Oracle RDBMS
Kernel in Oracle Disk Manager library. NAS-based storage systems use Network File System to
access data. In Oracle Database 10g, NAS storage devices are accessed using the operating system
provided kernel network file system driver, which require specific configuration settings to ensure
its efficient and correct usage with Oracle Database. The following are the major problems that
arise in correctly specifying these configuration parameters:
• NFS clients are very inconsistent across platforms and vary across operating system releases.
• With more than 20 parameters to tune, manageability is impacted.
Oracle Direct Network File System implements NFS version 3 protocol within the Oracle
RDBMS kernel. The following are the main advantages of implementing Oracle Direct NFS:
• It enables a complete control over input-output path to Network File Servers. This results in a
predictable performance and enables simpler configuration management and a superior
diagnosability.
• Its operations avoid the kernel network file system layer bottlenecks and resource limitations.
However, the kernel is still used for network communication modules.
• It provides a common Network File System interface for Oracle for potential use on all host
platforms and supported Network File System servers.
• It enables improved performance through load balancing across multiple connections to
Network File System servers and deep pipelines of asynchronous input-output operations
with improved concurrency.
Direct NFS Configuration
1 Mount all expected mount points using kernel NFS driver
2 optionally create an oranfstab file
cp libodm10.so libodm10.so_stub
3 ln -s libnfsodm10.so libodm10.so
Mount points lookup order

server: MyDataServer1
$ORACLE_HOME/dbs/oranfstab Load balancing path: 132.34.35.12
& path: 132.34.35.13
failover export: /vol/oradata1 mount: /mnt/oradata1
/etc/oranfstab
/etc/mtab
Direct NFS Configuration

By default Direct NFS attempts to serve mount entries found in /etc/mtab. No other configuration
is required. You can optionally use oranfstab to specify additional Oracle specific options to
Direct NFS. For example, you can use oranfstab to specify additional paths for a mount point as
shown on the slide’s example.
When oranfstab is placed in $ORACLE_HOME/dbs its entries are specific to a single database.
However, when oranfstab is placed in /etc then it is global to all Oracle databases, and hence can
contain mount points for all Oracle databases.
Direct NFS looks for the mount point entries in the follwoing order:
ORACLE_HOME/dbs/oranfstab, /etc/oranfstab, and /etc/mtab. It uses the first matched entry as
the mount point.
In all cases, Oracle requires that mount points be mounted by the kernel NFS system even when
being served through Direct NFS. Oracle verifies kernel NFS mounts by cross-checking entries in
oranfstab with operating system NFS mount points. If a mismatch exists, then Direct NFS logs an
informational message, and does not serve the NFS server.
Complete the following procedure to enable Direct NFS:
1. Make sure NFS mount points are mounted by your kernel NFS client. The filesystems to be
used via ODM NFS should be mounted and available over regular NFS mounts in order for Oracle
to retrieve certain bootstrapping information. The mount options used in mounting the filesystems
are not relevant.

Direct NFS Configuration (Continued)
2. Optionally create an oranfstab file with the following attributes for each NFS server to be
accessed using Direct NFS:
• Server: The NFS server name.
• Path: Up to four network paths to the NFS server, specified either by IP address, or by name,
as displayed using the ifconfig command. The Direct NFS client performs load balancing
across all specified paths. If a specified path fails, then Direct NFS reissues I/Os over any
remaining paths.
• Export: The exported path from the NFS server.
Mount: The local mount point for the NFS server.
3. Oracle Database uses the ODM library libnfsodm10.so to enable Direct NFS. To replace this
standard ODM library with the ODM NFS library, complete the following steps:
• Change directory to $ORACLE_HOME/lib.
• Enter the following commands:
cp libodm10.so libodm10.so_stub
ln -s libnfsodm10.so libodm10.so
Use one of the following methods to disable the Direct NFS client:
• Remove the oranfstab file.
• Restore the stub libodm10.so file by reversing the process you completed in step 3.
• Remove the specific NFS server or export paths in the oranfstab file.
Note:
• If you remove an NFS path that Oracle Database is using, then you must restart the database
for the change to be effective.
• If Oracle Database is unable to open an NFS server using Direct NFS, then Oracle Database
uses the platform operating system kernel NFS client. In this case, the kernel NFS mount
options must be set up correctly. Additionally, an informational message will be logged into
the Oracle alert and trace files indicating that Direct NFS could not be established.
• With the current ODM architecture, at any given time, there can only be one active ODM
implementation per instance: Using NFS ODM in an instance precludes any other ODM
implementation.
• The Oracle files resident on the NFS server that are served by the Direct NFS Client are also
accessible through the operating system kernel NFS client. The usual considerations for
maintaining integrity of the Oracle files apply in this situation.

Monitoring Direct NFS
V$DNFS_FILES
V$DNFS_SERVERS Process V$DNFS_STATS
V$DNFS_CHANNELS
Monitoring Direct NFS

Use the following views for Direct NFS management:
• V$DNFS_SERVERS: Shows a table of servers accessed using Direct NFS.
• V$DNFS_FILES: Shows a table of files currently open using Direct NFS.
• V$DNFS_CHANNELS: Shows a table of open network paths (or channels) to servers for
which Direct NFS is providing files.
• V$DNFS_STATS: Shows a table of performance statistics for Direct NFS.

Online Patching Overview
Online Patching provides the ability to:

• install
• enable
• disable
a bug fix or diagnostic patch on a running Oracle instance.
Online Patching Overview

Online Patching provides the ability to install, enable, and disable a bug fix or diagnostic patch on
a live, running Oracle instance.

Installing an Online Patch
• Applying an online patch does not require instance

shutdown, relink of the oracle binary, or instance
restart.
• OPatch can be used to install or uninstall an online
patch.
• OPatch detects conflicts between two online patches,
as well as between an online patch and a conventional
patch.
Installing an Online Patch

Unlike with traditional patching mechanisms, applying an online patch does not require instance
shutdown or restart.
Similar to traditional patching, you can use OPatch to install an online patch.
You can determine if a patch is an online patch using the following command:
opatch query -is_online_patch <patch location> or
opatch query <patch location> -all
Note: The patched code is shipped as a dynamic/shared library, which is then mapped into
memory by each oracle process.

Online Patching Benefits
• No downtime and no interruption of business.

• Incredibly fast install/uninstall time.
• Integrated with OPatch:
– conflict detection
– listed in patch inventory
– work in RAC environment.
• Even though the on-disk oracle binary is
unchanged, online patches persist across instance
shutdown and startup.
Online Patching Benefits

You do not have to shutdown your database instance while you apply the online patch.
Unlike conventional patching, online patching is incredibly fast to install and uninstall.
Because online patching uses OPatch, you basically get all the benefits you already have with
conventional patching that uses OPatch.
It does not matter how long or how many times you shutdown your database, an online patch will
always persist across instance shutdown and startup.

Conventional Patching and Online Patching
Conventional Patches Online Patches

Require downtime to apply or Do not require downtime
remove
Installed/uninstalled via OPatch Installed/uninstalled via OPatch
Persist across instance startup & Persist across instance startup &
shutdown shutdown
Takes several minutes to Takes only a few seconds
install/uninstall
Conventional Patching and Online Patching

Conventional patching basically requires a shutdown of your database instance.
Online patching does not require any downtime. Applications can keep on running while you
install or uninstalling an online patch.

Online Patching Considerations
• Online patches may not be available on all platforms.

Currently available on:
– Linux x86
– Linux x86-64
– Solaris SPARC64.
• Some extra memory is consumed. Exact amount
depends on:
– Size of the patch
– Number of concurrently running oracle processes.
– The minimum amount of memory is approximately 1 OS
page per running oracle process.

One Operating System (OS) page is typically 4KB on Linux x86 and 8KB on Solaris SPARC64.
Counting an average of a thousand oracle processes running at the same time, that would
represents around 4MB of extra memory for a small online patch.

• There may be a small delay (a few seconds) before

every oracle process installs/uninstalls an online patch.
• Not all bug fixes and diagnostic patches are available
as an online patch.
• Use online patches in situations when downtime is not
feasible
• When downtime is possible, you should install any
relevant bug fixes as conventional patches.

The vast majority of diagnostic patches are available as online patches. For bug fixes, it really
depends of their nature.

Using Online Patching
• Shops where downtime is extremely inconvenient or

impossible (24x7)
• Bugs with an unknown cause, and require a series of
one or more diagnostic patches
Using Online Patching

A very nice use case for online patching is when you hit a bug with an unknown cause. Oracle
Support provides one or more diagnostic patches that can be installed quickly to narrow down the
cause of the problem.

Summary
In this lesson, you should have learned how to:

• Install Oracle Database 11g
• Upgrade your database to Oracle Database 11g
• Use online patching

Practice 1: Overview
This practice covers the following topics:

• Install Oracle Database 10g Software
• Configure ASM using Oracle Database 10g software
• Install Oracle Database 11g Software
• Upgrade ASM to Oracle Database 11g
• Create a Database

Storage Enhancements
Copyright © 2007, Oracle. All rights reserved.

Objectives
After completing this lesson, you should be able to:

• Setup ASM fast mirror resynch
• Use ASM preferred mirror read
• Understand scalability and performance enhancements
• Setup ASM disk group attributes
• Use SYSASM role
• Use various new manageability options for CHECK, MOUNT,
and DROP commands
• Use the mb_backup, md_restore, and repair ASMCMD
extensions
2-2 Copyright © 2007, Oracle. All rights reserved.

Without ASM Fast Mirror Resync
1 ASM redundancy is used 2 Disk access failure
Secondary
Primary
extent
extent
Oracle Database 10g&11g
4 Disk added back: 3 Disk automatically dropped:

Extents rebalanced All dropped extents recreated
Without ASM Fast Mirror Resync

ASM offlines a disk whenever it is unable to complete a write to an extent allocated to the disk,
while writing at least one mirror copy of the same extent on another disk if ASM redundancy is
used by the corresponding disk group.
With Oracle Database 10g, ASM assumes that an offline disk contains only stale data and
therefore it does not read from such disks anymore. Shortly after a disk is put offline, ASM drops
it from the disk group by recreating the extents allocated to the disk on the remaining disks in the
disk group using redundant extent copies. This process is a relatively costly operation, and may
take hours to complete.
If the disk failure is only a transient failure, such as failures of cables, host bus adapters, or
controllers, or disk power supply interruptions, you have to add the disk back again once the
transient failure is fixed. However, adding the dropped disk back to the disk group incurs an
additional cost of migrating extents back onto the disk.

ASM Fast Mirror Resync Overview
1 ASM redundancy is used 2 Disk access failure
Secondary
Primary
extent
extent
Oracle Database 11g
4 Disk again accessible:

3 Failure time < DISK_REPAIR_TIME
Only need to resync modified extents
ASM Fast Mirror Resync Overview

ASM fast mirror resync significantly reduces the time required to resynchronize a transient failure
of a disk. When a disk goes offline following a transient failure, ASM tracks the extents that are
modified during the outage. When the transient failure is repaired, ASM can quickly
resynchronize only the ASM disk extents that have been affected during the outage.
This feature assumes that the content of the affected ASM disks has not been damaged or
modified.
When an ASM disk path fails, the ASM disk is taken offline but not dropped if you have set the
DISK_REPAIR_TIME attribute for the corresponding disk group. The setting for this attribute
determines the duration of a disk outage that ASM tolerates while still being able to resynchronize
after you complete the repair.
Note: The tracking mechanism uses one bit for each modified allocation unit. This ensures that
the tracking mechanism very efficient.

Using EM to Perform Fast Mirror Resync

In Enterprise Manager (EM), when you offline an ASM disk, you are asked to confirm the
operation. On the Confirmation page, you can override the default Disk Repair Time. Similarly,
you can View by failure group and choose a particular failure group to offline.


Similarly, you can online disks using Enterprise Manager.

Setting Up ASM Fast Mirror Resync
ALTER DISKGROUP dgroupA SET ATTRIBUTE 'DISK_REPAIR_TIME'='3H';
ALTER DISKGROUP dgroupA

OFFLINE DISKS IN FALUREGROUP controller2 DROP AFTER 5H;
ALTER DISKGROUP dgroupA

ONLINE DISKS IN FALUREGROUP controller2 POWER 2 WAIT;
ALTER DISKGROUP dgroupA DROP DISKS IN FALUREGROUP controller2 FORCE;
Setting Up ASM Fast Mirror Resync

You setup this feature on a per disk group basis. You can do so after disk group creation using the
ALTER DISKGROUP command. Use the following commands to enable ASM fast mirror
resync:
ALTER DISKGROUP SET ATTRIBUTE DISK_REPAIR_TIME="2D4H30M"
After you repair the disk, run the SQL statement ALTER DISK GROUP DISK ONLINE. This
statement brings a repaired disk group back online to enable writes so that no new writes are
missed. This statement also starts a procedure to copy of all of the extents that are marked as stale
on their redundant copies. You cannot apply the ONLINE statement to already dropped disks.
You can view the current attribute values by querying the V$ASM_ATTRIBUTE view.
You can determine the time left before ASM drops an offlined disk by querying the
REPAIR_TIMER column of either V$ASM_DISK or V$ASM_DISK_IOSTAT. In addition a row
corresponding to a disk resync operation will appear in V$ASM_OPERATION with the
OPERATION column set to SYNC.

Setting Up ASM Fast Mirror Resync (Continued)
You can also use the ALTER DISK GROUP DISK OFFLINE SQL statement to manually bring
ASM disks offline for preventative maintenance. With this command, you can specify a timer to
override the one defined at the disk group level. After you complete maintenance, use the ALTER
DISK GROUP DISK ONLINE statement to bring the disk online.
If you cannot repair a failure group that is in the offline state, you can use the ALTER
DISKGROUP DROP DISKS IN FAILUREGROUP command with the force option. This ensures
that data originally stored on these disks is reconstructed from redundant copies of the data and
stored on other disk in the same disk group.
Note: The time elapses only when the disk group is mounted. Also changing the value of
DISK_REPAIR_TIME does not affect disks previously offlined. The default setting of 3.6 hours
for DISK_REPAIR_TIME should be adequate for most environments.

ASM Preferred Mirror Read Overview
Site A Site B
P S
Site A Site B
P S
ASM Preferred Mirror Read Overview

When you configure ASM failure groups, ASM in Oracle Database 10g always reads the primary
copy of a mirrored extent. It may be more efficient for a node to read from a failure group extent
that is closest to the node, even if it is a secondary extent. This is especially true in extended
cluster configurations where reading from a local copy of an extent provides improved
performance.
With Oracle Database 11g, you can do this by configuring preferred mirror read using the new
initialization parameter, ASM_PREFERRED_READ_FAILURE_GROUPS, to specify a list of
preferred mirror read names. The disks in those failure groups become the preferred read disks.
Thus, every node can read from its local disks. This results in higher efficiency and performance
and reduced network traffic. The setting for this parameter is instance-specific.

ASM Preferred Mirror Read Setup
Setup
On first instance
ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEA
On second instance
ASM_PREFERRED_READ_FAILURE_GROUPS=DATA.SITEB
Monitor
SELECT preferred_read FROM v$asm_disk;
SELECT * FROM v$asm_disk_iostat;
ASM Preferred Mirror Read Setup

To configure this feature, set the new ASM_PREFERRED_READ_FAILURE_GROUPS
initialization parameter. This parameter is a multi-valued parameter and should contain a string
with a list of failure group names separated by a comma. The failure group name specified should
be prefixed with its disk group name and a ‘.’ character. This parameter is dynamic and can be
modified using the ALTER SYSTEM command at any time. An example is shown on the slide.
This initialization parameter is only valid for ASM instances. In a stretch cluster, the failure
groups specified in this parameter should only contain the disks that are local to the corresponding
instance.
The new column PREFERRED_READ has been added to the V$ASM_DISK view. Its format is a
single character. If the disk group that the disk is in pertains to a preferred read failure group, the
value of this column is Y.
To identify specific performance issues with ASM preferred read failure groups, use the
V$ASM_DISK_IOSTAT view. This view displays disk I/O statistics for each ASM client. If this
view is queried from a database instance, only the rows for this instance are shown.

Enterprise Manager ASM Configuration Page
Enterprise Manager ASM Configuration Page

You can specify a set of disks as preferred disks for each ASM instance using Enterprise
Manager. The preferred read attributes are instance specific. In Oracle Database 11g the Preferred
Read Failure Groups field (asm_preferred_read_failure_group) is added to the
configuration page.
This parameter only takes effect before the diskgroup is mounted or when the diskgroup is
created. It only applies to newly opened files or a newly loaded extend map for a file.

ASM Preferred Mirror Read - Best Practice
Two sites / Normal redundancy Two sites / High redundancy
P S P S S S S P
Only two failure groups: one for each instance Max four failure groups: two for each instance
Three sites / High redundancy
P S S
Only three failure groups: one for each instance
ASM Preferred Mirror Read - Best Practice

In practice, there are only a limited number of good disk group configurations in a stretch cluster.
A good configuration takes into account both performance and availability of a disk group in a
stretch cluster. Here are some possible examples:
For a two-site stretch cluster, a normal redundancy disk group should only have two failure
groups and all disks local to one site should belong to the same failure group. Also, at most one
failure group should be specified as a preferred read failure group by each instance. If there are
more than two failure groups, ASM may not mirror a virtual extent across both sites. Furthermore,
if the site with more than two failure groups were to go down, it would take the disk group down
as well. If the disk group to be created is a high redundancy disk group, at most two failure groups
should be created on each site with its local disks, having both local failure groups specified as
preferred read failure groups for the local instance.
For a three-site stretch cluster, a high redundancy disk group with three failure groups should be
used. This is for ASM to guarantee that each virtual extent has a mirror copy local to each site and
the disk group is protected against a catastrophic disaster on any of the three sites.

ASM Scalability and Performance Enhancements
• Extent size grow automatically according to file size

• ASM support variable extents size to:
– Raise maximum possible file size
– Reduce memory utilization in shared pool
• No administration needs apart manual rebalance in
case of important fragmentation
ASM Scalability and Performance Enhancements

ASM Variable Size Extents is an automated feature that enables ASM to support larger file size
extents while improving memory usage efficiency.
In Oracle Database 11g, ASM supports variable sizes for extents of 1, 4, 16, and 64 MB. ASM
uses a predetermined number of extents of each size. As soon as a file cross a certain threshold,
the next extent size is used. An ASM file can begin with 1 MB extents and as the file's size
increases, the extent size also increases to 4, 16, or 64 MB based on predefined file size
thresholds.
With this feature, fewer extent pointers are needed to describe the file and less memory is required
to manage the extent maps in the shared pool, which would have been prohibitive in large file
configurations. Extent size can vary both across files and within files.
Variable Size Extents also enable you to deploy Oracle databases using ASM that are several
hundred TB even several PB in size.
The management of variable size extents is completely automated and does not require manual
administration.

ASM Scalability and Performance Enhancements (Continued)
However, external fragmentation may occur when a large number of non-contiguous small data
extents have been allocated and freed, and no additional contiguous large extents are available. A
defragmentation operation is integrated as part of the any rebalance operation. So, as a DBA, you
always have the possibility to defragment your disk group by executing a rebalance operation.
Nevertheless, this should only happen very rarely because ASM also automatically perform
defragmentation during extents allocation if the desired size is unavailable. This can potentially
render some allocation operations longer.
Note: This feature also enables much faster file opens because of the significant reduction in the
amount of memory that is required to store file extents.

ASM Scalability In Oracle Database 11g
ASM imposes the following limits:

• 63 disk groups
• 10,000 ASM disks
• 4 petabyte per ASM disk
• 40 exabyte of storage
• 1 million files per disk group
• Maximum file size:
– External redundancy: 140 PB
– Normal redundancy: 42 PB
– High redundancy: 15 PB
ASM imposes the following limits:

• 63 disk groups in a storage system
• 10,000 ASM disks in a storage system
• 4 petabyte maximum storage for each ASM disk
• 40 exabyte maximum storage for each storage system
• 1 million files for each disk group
• Maximum files sizes depending on the redundancy type of the disk groups used: 140 PB for
external redundancy (value currently greater than possible database file size), 42 PB for
normal redundancy, and 15 PB for high redundancy.
Note: In Oracle Database 10g, maximum ASM file size for external redundancy was 35 TB.

SYSASM Overview
• SYSASM role to manage ASM instances avoid overlap

between DBAs and storage administrators
SQL> CONNECT / AS SYSASM
SQL> CREATE USER ossysasmusername IDENTIFIED by passwd;
SQL> GRANT SYSASM TO ossysasmusername;
SQL> CONNECT ossysasmusername / passwd AS SYSASM;
SQL> DROP USER ossysasmusername;
• SYSDBA will be deprecated:

– Oracle Database 11g Release 1 behaves as in 10g
– In future releases SYSDBA privileges restricted in ASM
instances
SYSASM Overview
This feature introduces a new SYSASM role that is specifically intended for performing ASM
administration tasks. Using the SYSASM role instead of the SYSDBA role improves security by
separating ASM administration from database administration.
As of Oracle Database 11g Release 1, the OS group for SYSASM and SYSDBA is the same, and
the default installation group for SYSASM is dba. In a future release, separate groups will have to
be created, and SYSDBA users will be restricted in ASM instances.
Currently, as a member of the dba group you can connect to an ASM instance using the first
statement above.
You also have the possibility to use the combination of CREATE USER and GRANT SYSMAN
SQL statements from an ASM instance to create a new SYSASM user. This is possible as long as
the name of the user is an existing OS user name. These commands update the password file of
each ASM instance, and do not need instance to be up and running. Similarly, you can revoke the
SYSMAN role from a user using the REVOKE command, and you can drop a user from the
password file using the DROP USER command.
Note: With Oracle Database 11g Release 1, if you log in to an ASM instance as SYSDBA,
warnings are written in the corresponding alert.log file.

11g New Features For Administrators Student Guide-2 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11g New Features For Administrators Student Guide-2 PDF

Uploaded by

Copyright:

Available Formats

Command Line Syntax

• Silent mode run

1 - 37 Copyright © 2007, Oracle. All rights reserved.

Command Line Syntax

Oracle Database 11g: New Features for Administrators 1 - 37

1 - 38 Copyright © 2007, Oracle. All rights reserved.

Using DBUA to Upgrade Your Database

Oracle Database 11g: New Features for Administrators 1 - 38

1 - 39 Copyright © 2007, Oracle. All rights reserved.

Choose Database to Upgrade and Diagnostic Destination

1 - 40 Copyright © 2007, Oracle. All rights reserved.

Moving Database Files

Oracle Database 11g: New Features for Administrators 1 - 40

1 - 41 Copyright © 2007, Oracle. All rights reserved.

Database File Locations

Oracle Database 11g: New Features for Administrators 1 - 41

1 - 42 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 42

1 - 43 Copyright © 2007, Oracle. All rights reserved.

Management Options and Database Credentials

Oracle Database 11g: New Features for Administrators 1 - 43

1 - 44 Copyright © 2007, Oracle. All rights reserved.

1 - 45 Copyright © 2007, Oracle. All rights reserved.

Recompile Invalid Objects

Oracle Database 11g: New Features for Administrators 1 - 45

1 - 46 Copyright © 2007, Oracle. All rights reserved.

Database Backup and Space Checks

Oracle Database 11g: New Features for Administrators 1 - 46

1 - 47 Copyright © 2007, Oracle. All rights reserved.

Database Upgrade Summary

Oracle Database 11g: New Features for Administrators 1 - 47

1 - 48 Copyright © 2007, Oracle. All rights reserved.

Upgrade Progress and Results

Oracle Database 11g: New Features for Administrators 1 - 48

• The three T’s: TEST, TEST, TEST

1 - 49 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 49

1 - 50 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 50

• Automate your upgrade

1 - 51 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 51

• Use Optimal Flexibility Architecture (OFA)

1 - 52 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 52

• Use Enterprise Manager Grid Control to manage your

1 - 53 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 53

• Avoid upgrading in a crisis

1 - 54 Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: New Features for Administrators 1 - 54

• Oracle Ultra Search

1 - 55 Copyright © 2007, Oracle. All rights reserved.

Deprecated Features in 11g Release 1

Oracle Database 11g: New Features for Administrators 1 - 55

1 - 56 Copyright © 2007, Oracle. All rights reserved.

Important Initialization Parameter Changes

Oracle Database 11g: New Features for Administrators 1 - 56

Oracle Database 11g: New Features for Administrators 1 - 57

Oracle Database 10g Oracle Database 11g

Variations across platforms

1 - 58 Copyright © 2007, Oracle. All rights reserved.

Direct NFS Client Overview