Automatic
Diagnostic Repository(ADR)
Oracle
Database 11g offers a new automatic diagnostic repository (ADR), which provides
a single directory location for all the diagnostic data needed for diagnosing
and repairing database problems. The ADR uses standard methods to store
diagnostic data for the database as well as other Oracle products. Various automatic
diagnostic tools then use this diagnostic data to quickly diagnose and resolve
problems. The ADR also provides a consolidated location for the collection of
all diagnostic data you want to send to Oracle Support for diagnosing and
resolving problems.
The
ADR contains several subdirectories such as alert and cdump, where the
traditional diagnostic data as well as new types of diagnostic data are stored.
You have two versions of the alert log in Oracle Database 11g, one a regular
text file and the other an XML-formatted file. You can read the alert log using
a normal text editor, the Enterprise Manager, or the new ADRCI tool, which lets
you perform a variety of tasks pertaining to problem diagnosis.
New Database Components
Oracle Application
Express (APEX)-
Oracle’s browser-based rapid application development tool, known earlier as
Oracle HTML DB, now contains prepackaged applications for blogs, storefronts,
and discussion forums, in addition to new reporting capabilities and support
for drag-and-drop forms layout. APEX is now installed with Oracle database 11g as
part of the base Oracle installation CD instead of the companion CD.
Oracle SQL Developer- Oracle’s free
database development productivity tool, SQL Developer, is installed
automatically when you choose a template-based database installation by
selecting an installation option such as General Purpose/Transaction Processing
and Data Warehousing. SQL Developer contains new tuning enhancements such as database
activity reporting and expanded support for version control and visual query
building.
Oracle Real
Application Testing-
This new component, which consists of two new features— Database Replay and SQL
Performance Analyzer—is automatically installed when you select the Enterprise
Edition installation option.
Oracle Configuration
Manager (OCM)-
This is an optional component. The OCM gathers software configuration
information and uploads it to the Oracle configuration repository.
Oracle Warehouse
Builder-
This tool is installed as part of the Oracle Database server software.
Oracle Database
Vault
This tool is now installed with the Oracle Database 11g, butas an optional
component, instead of as a component of the companion CD. The Oracle Database
Vault installation provides a baseline security policy for the database. When
you install the Oracle Database Vault, all security-related initialization
parameters are assigned default values.
Components which are
not in 11G but in 10g
The
following components aren’t part of the Oracle Database 11ginstallation (but
were part of the Oracle Database 10g release 2):
# iSQL*Plus
# Oracle Workflow
# Oracle Enterprise Manager Java Console
# Oracle Data Mining Scoring
Engine
# Raw storage support for datafiles
(installer only)
Role and Privilege
Changes
Oracle
Database 11g seeks to demarcate database administration and ASM administration.
Oracle now recommends that you create an optional operating system level group
for the users who’ll manage automatic storage management (ASM). You can do this
during the installation or later on. Oracle Database 11g introduces the new
operating system OS group named OSASM, exclusively for users who’ll manage ASM.
Oracle recommends that you grant ASM access only to users who are members of
the OSASM group. There is also a new ASM-related system privilege called
SYSASM, which Oracle recommends that you grant to those users who perform ASM
administrative tasks. The OSASM operating system group and the SYSASM system
privilege are purely optional in this release.
New DBCA Options
Oracle
Database 11gcontains quite a few changes in configuring databases through the
DBCA. These include the configuration of the new automatic memory management
feature, secure database configuration by default, and others. They are
Automatic Memory
Management-
The DBCA doesn’t specify values for the memory-related initialization
parameters sga_targetand pga_aggregate_target by default. Instead, it uses the
memory_target parameter, which allows you to configure the new automatic memory
management feature. You select automatic memory management in the Memory
Management page, as you’ll see
later
in the DBCA database creation example.
Automatic Secure
Configuration-
The DBCA will configure a secure database by default in Oracle Database 11g. If
you want, you can even configure this later on, but Oracle recommends that you
opt for automatic secure configuration when you create the database.
Automatic switching
to Grid Control-
In previous releases, it took quite a bit of work to reconfigure a database
from Database Control to Grid Control. In Oracle Database 11g, you can use the
Enterprise Manager plug-in provided by the DBCA to automate the switching of a
database from Database Control to Grid Control.
Configuration of
Oracle Base and Diagnostic Destination- DBCA now uses the values for the Oracle
base directory, stored in the Oracle home inventory, to derive the default
locations for datafiles and the diagnostic_dest initialization parameter, which
is the ADR base directory.
Some
Parameter Default Values
#FAILED_LOGIN_ATTEMPTS - Specifies the
maximum number of times a user can try to log in. The default value for this
parameter is 10, which is the same as in the previous release.
# PASSWORD_GRACE_TIME - Specifies the number of days within which users must change
their password before it expires. The default value for this setting is 7 days,
whereas it was unlimited before.
# PASSWORD_LIFE_TIME- Sets the duration for which
users can use the same
password. This is set to 180 days by default, whereas it was unlimited before.
# PASSWORD_LOCK_TIME
- Sets the number of days for which an account will remain locked after a set
number of failed attempts to log in. The default value is 1, compared to
unlimited in the previous release.
# PASSWORD_REUSE_MAX - Sets
the number of days that must pass before you can reuse a password after it
expires. The default value is set to unlimited, the same value as before.
# PASSWORD_REUSE_TIME - Sets
the number of new passwords
you must use before you are permitted to reuse the current password. By
default, there is no limit on the number of times you can reuse a password.
#
PASSWORD_GRACE_TIME – It is now 7
days by default, instead of being unlimited.
# PASSWORD_LIFE_TIME
- It is set by default to 180
days, instead of being unlimited.
#
PASSWORD_LOCK_TIME – It is 1 day, instead of being set to the value of DEFAULT as in the
Oracle Database 10grelease.
Oracle
11g Upgrade Path
Depending
on your current database release, you may or may not be able to directly
upgrade to the Oracle Database 11gRelease 1 (11.1) version. You can directly
upgrade to Oracle Database Release 1 if your current database is based on an
Oracle 9.2.0.4 or newer release. For Oracle database releases older than Oracle
9.2.0.4, you have to migrate via one or two intermediate releases, as shown by
the following upgrade paths:
#7.3.3 (or lower) => 7.3.4 => 9.2.0.8
=> 11.1
# 8.0.5 (or lower) => 8.0.6 => 9.2.0.8 => 11.1
# 8.1.7 (or lower) => 8.1.7.4 => 9.2.0.8 => 11.1
# 9.0.1.3 (or lower) => 9.0.1.4 => 9.2.0.8
=> 11.1
# 9.2.0.3 (or lower) => 9.2.0.8 => 11.1
Upgrading with the
DBUA-
The DBUA is essentially unchanged from the Oracle Database 10g release. There
are a couple of important changes which you’ll see when we go through a manual
upgrade process. You’ll have an additional screen during the upgrade process,
which asks you to specify a location for the diagnostic directory. The DBA
automatically starts when you choose to upgrade your database during the
installation of the Oracle Database 11gserver software. Note that when you use
the manual upgrade method, you must upgrade an ASM instance separately, Where as
the DBUA lets you perform the ASM upgrade along with the upgrade of the database
instance.
Scripts to Run for
Upgrading a Database- Upgrade
an Oracle Database 10grelease database to the Oracle Database 11grelease using
the Oracle-supplied scripts for upgrading a database. The following are the
steps you use in upgrading a database to the Oracle Database 11g release:
#
utlu111i.sql - The Pre-Upgrade Information tool
#
catupgd.sql - The script that performs the actual upgrade process
# utlu111s.sql - The Post-Upgrade Status tool
# catuppst.sql - The post-upgrade actions script
# utlrp.sql - The script you run at the end of the upgrade process, to
recompile
all objects that were invalidated during the upgrade.
Real
Application Testing
The
Real Application testing feature, which consists of two separate tools,
Database Replay and the SQL Performance Analyzer, is arguably the most
significant new feature in the Oracle Database 11.1 release. The two new
features address significant unmet needs regarding change management.
Organizations often find that upgrading operating system or database server
software or making major application changes is fraught with considerable risk.
There simply is no way to predict how a production system is going to perform
pursuant to major changes. Real Application Testing addresses this need by
letting you quickly and exhaustively test changes using Oracle’s own tools
instead of your having to resort to third-party tools that may not be able to
capture all the required changes.
The
new Oracle-supplied packages DBMS_WORKLOAD_CAPTURE and DBMS_WORKLOAD_REPLAY
provide the APIs for the Database Replay feature. The DBMS_SQLPA package
supports the SQL performance Analyzer feature. The following sections first
look at the Database Replay feature and then the SQL Performance Analyzer.
New System Testing
Tools
As
a DBA, one of the most bedeviling problems that I've regularly faced is to be
able to predict accurately how the next set of changes to the database's
application code, database patch set, or hardware configuration will affect
that database's performance. That usually meant purchasing a relatively
expensive third-party package (e.g., Mercury Interactive's Load Runner) to generate a sample workload
against the database using the next version of the application code, and then
comparing the results against baseline performance for the current application
code version.
Fortunately,
Oracle Database 11g has come to the res-cue with two new utilities that offer monumental
strides forward in system testing-
Database Replay
System
changes such as a database upgrade require substantial testing and validation
before you can actually migrate the changes to a production system. The trick
is to simulate a real production workload on a test system. The Database Replay
feature enables you to perform real-life testing of major changes by letting
you capture the actual database workload on the production system and replay it
on a test system. Thus, you essentially re-create the production workload
effortlessly on a test system. Database Replay performs a sophisticated replay
of the production workload by adhering to the original concurrency and timing
characteristics. Once you complete the testing, you can analyze and review the
reports produced by Database Replay to see if there was a performance
divergence between the two runs and also if there were any errors. Finally, you
can choose to implement the recommendations made by Database Replay to fix any
problems it encountered during the replay of the production workload.
You
can employ Database Replay to test significant system changes such as the
following:
#Operating
system and database upgrades and migrations.
#
Configuration changes such as moving to an oracle
RAC environment.
#
Storage changes.
Database
Replay doesn’t capture the following types of client requests:
# SQL*Loader direct path load of data
# Oracle Streams
# Data Pump Import and
Export
# Advanced replication
streams
# Non–PL/SQL-based Advanced
Queuing (AQ)
# Flashback Database and
Flashback queries
#
Distributed transactions and remote describe/commit operations
# Shared server
# Non–SQL-based object access
The
following data dictionary views help you manage the Database Replay feature:
# DBA_WORKLOAD_CAPTURES - It shows all workload
captures you performed
in a database.
# DBA_WORKLOAD_FILTERS – It shows all workload filters
you defined in a database.
# DBA_WORKLOAD_REPLAYS – It shows all workload
replays you performed in
a database.
# DBA_WORKLOAD_REPLAY_DIVERGENCE – It helps
monitor workload divergence.
# DBA_WORKLOAD_THREAD – It helps monitor the status of external
replay clients.
# DBA_WORKLOAD_CONNECTION_MAP – It shows all
connection strings used
by workload replays.
SQL
Performance Analyzer
SQL
Performance Analyzer, which, along with the Database Replay constitutes the
Total Replay
feature,
lets you test the impact of potential changes such as a server or database
upgrade on SQL workload response time. The SQL Performance Analyzer focuses on
comparing the performance of a specific SQL workload before and after a major
system change. The analyzer does this by building two versions of the SQL
workload performance, which includes both the SQL execution plans as well as
their execution statistics. After analyzing SQL performance both before and
after you make a major
change,
the SQL Performance Analyzer provides suggestions to prevent potential
performance degradation of SQL statements. This is especially handy when you’re
planning an upgrade of your database to a newer release of the Oracle database.
The SQL Performance Analyzer, by enabling you to compare SQL performance on two
systems running on different versions of the Oracle database, lets you know
ahead of the upgrade which of the SQL statements may show a deterioration in
performance. Thus, you can reengineer those statements prior to the actual upgrade.
You
can use the SQL Performance Analyzer to predict performance changes resulting
from the following system changes:
# Database and application upgrades
# Hardware upgrades
# Operating system upgrades
#
Initialization parameter changes
# SQL tuning actions such as the creation of SQL
profiles
# Statistics gathering
# Schema changes
Result Caches
I've
often wished that the Oracle database would pro-vide a method to retain in
memory the result set from a complex query that contains what I like to call
reference information. These are data that hardly ever change, but must still
be read and used across multiple applications. For instance, a list of all
country codes and their corresponding names for lookup when processing addresses
for new international customers, or a list of all the zip codes of North India.
Oracle Database 11g fills this gap with three new structures called result
caches, and each structure has a different purpose:
#
The SQL query result cache is an area of memory in the Shared Global Area (SGA)
that can retain the result sets that a query generates.
#
The PL/SQL function result cache can store the results from a PL/SQL function
call.
#
Finally, the client result cache can retain results from queries or functions
on the application server from which the call originated.
By
retaining result sets in these in-memory caches, the results are immediately
available for reuse by any user session. For user sessions that connect to the
database through an application server, the client cache permits those sessions
to simply share the results that are already cached on the application server
without having to reissue a query directly against the database. These result
caches therefore hold great promise for eliminating unnecessary "round
trips" to the database
server
to collect relatively static reference data that still.
Improved SQL Tuning
If
you've already experienced the advice for SQL performance improvements that
Oracle Database 10g's SQL Tuning Advisor and SQL Access Advisor provide, you'll
be pleasantly surprised with Oracle Database 11g's enhanced SQL tuning
capabilities. Here's a brief sample-
#
SQL statements can now tune themselves via an expansion to the automatic SQL
tuning features that were introduced in Oracle Database 10g.
#
Statistics for the Cost-Based Optimizer (CBO) are now published separately from
being gathered. This means that recomputed statistics for the CBO will not
necessarily cause existing cursors to become invalidated.
#
Multi-column statistics can be collected for two or more columns in a table.
This gives the CBO the ability to more accurately select rows based on common
multi-column conditions or joins.
#
SQL Access Advisor can now make recommendations on how partitioning might be
applied to
existing
tables, indexes, and materialized views to improve an application's
performance.
#
Oracle Database 11g now supports retention of historical execution plans for a
SQL statement. This
means
that the CBO can compare a new execution plan against the original plan and, if
the old plan still offers better performance than the new one, it can decide to
continue to use the original execution plan.
Advisors and Fault
Diagnostics
Oracle
Database 10g introduced an impressive plethora of database performance advisors
like the Segment Advisor, the Undo Advisor, the SQL Access Advisor, the SQL
Tuning Advisor, the MTTR Advisor, and the ultimate expert system for tuning
database performance: the Automatic Database Diagnostic Monitor (ADDM). Oracle
Database 11g expands this advisory framework with several new Database Repair
Advisors. The chief goals of these new Advisors are to locate root causes of a
failure, identify and present options for repairing these root causes, and even
correct the identified problems with self-healing mechanisms. Oracle Database
11g also adds a series of improved fault diagnostics to make it extremely easy
for even an inexperienced DBA to detect and quickly resolve problems with
Oracle Database 11g. Here are the highlights of these new features-
#
Automatic Health Monitoring. When a problem within the database is detected,
the new Health Monitor (HM) utility will automatically perform a series of
integrity checks to determine if the problem
can
be traced to corruption within database blocks, redo log blocks, undo segments,
or dictionary table blocks. HM can also be fired manually to perform checks
against the database's health on a periodic basis.
#
Automatic Diagnostic Repository. The Automatic Diagnostic Repository (ADR) is
at the heart of Oracle Database 11g's new fault diagnostic framework. The ADR
is a central, file-based repository external to the database itself, and it's
composed of the diagnostic data -- alert logs (in XML format), core dumps,
back-ground process dumps, and user trace files -- collect-ed from individual
database components from the first moment that a critical error is detected.
#
Support Workbench. Though it's stored outside of the database itself, the ADR
can be accessed via
either
Enterprise Manager or command-line utilities. Once the ADR has detected and
reported a critical
problem,
the DBA can interrogate the ADR, report on the source of the problem, and in
some cases
even
implement repairs through the Support Workbench, a new facility that's part of
Enterprise Manager.
#
Incident Packaging Service. If the problem can't be solved using these tools,
it may be time to ask for help from Oracle Support. The new Incident Packaging
Service (IPS) facility provides tools for
gathering
and packaging all necessary logs that Oracle Support typically needs to resolve
a Service
Request.
#
Hang Manager. Oracle Database 10g introduced the Hang Analysis tool in
Enterprise Manager, and
Oracle
Database 11g now expands this concept with the Hang Manager. Through a series
of dynamic
views,
it allows the DBA to traverse what's called a hang chain to determine exactly
which processes and sessions are causing bottlenecks because they are blocking
access to needed resources. And since it's activated by default on all
single-instance databases, RAC clustered databases, and ASM instances, it's now
possible to track down the source of a hang from one end of the system to the
other.
Flashback
Enhancements
Oracle
Database 10g dramatically expanded database recoverability with the ability to
perform an incomplete recovery of the database with Flashback Database. Oracle
Database 10g also provided four new logical database recovery features:
Flashback Table, Flashback Drop, Flashback Version Query, and Flashback
Transaction Query. Oracle Database 11g expands this arsenal of recovery tools
with two new. Flashback features-
#
Flashback Transaction. Essentially an extension of the Flashback Transaction
Query functionality introduced in Oracle Database 10g, Flashback Transaction allows
the DBA to back out of the database one or more transactions -- as well as any
corresponding dependent transactions -- by applying the appropriate reciprocal
UNDO statements for the affected transaction(s) to the corresponding affected
rows in the database.
#
Total Recall. This new feature offers the ability to retain the reciprocal UNDO
information for critical data significantly beyond the point in time that it
would be flushed out of the UNDO tablespace. Therefore, it's now possible to
hold onto these reciprocal transactions essentially indefinitely. Once this
feature is enabled, all retained transaction history can be viewed, and this
eliminates the cumbersome task of creating corresponding history tracking
tables for critical transactional tables. And as you might expect, Oracle Database
11g also provides methods to automatically purge data retained in the data
archive once a specified retention period has been exceeded.
Secure Files
Oracle
Database 11g provides a series of brand-new methods for storing large binary
objects (also known as LOBs) inside the database. These new features,
collectively called Secure Files, will allow Oracle Database 11g to store
images, extremely large text objects, and the more advanced data types
introduced in prior Oracle releases (e.g., XML Type, Spatial, and medical imaging
objects that utilize the DICOM [Digital Imaging and Communications In Medicine]
format). Secure Files promises to offer performance that com-pares favorably
with file system storage of these object types, as well as the ability to
transparently compress and "deduplicate" these data. (Deduplication
is yet another brand-new feature in Oracle Database 11g. It can detect
identical LOB data in the same LOB column
that's
referenced in two or more rows, and then stores just one copy of that data,
thus reducing the amount of space required to store these LOBs.) Perhaps most importantly,
Oracle Database 11g will also ensure that these data can be encrypted using
Transparent Data Encryption (TDE) methods - especially important (and welcome)
in the current security-conscious environments we inhabit today as database
administrators.
Improved Database
Security
Oracle
Database 10g Release 2 dramatically improved the options for encrypting
sensitive data both within Oracle database tables and indexes, as well as
outside the database (i.e., RMAN backups and Data Pump export files) with
Transparent Data Encryption (TDE). Oracle Database 11g continues to expand the
use of TDE within the database. For example, it's now possible to encrypt data
at the tablespace level as well as the table and index level. Also, logical
standby data-bases can utilize TDE to protect data that's been transferred from
its corresponding primary standby database site. Moreover, secured storage of
the TDE master encryption key is ensured by allowing it to be stored
externally
from the database server in a separate Hardware Security Module. Secure By
Default. Oracle Database 11g also implements a new set of out-of-the-box
security enhancements that are collectively called Secure By Default. These
security settings can be enabled during data-base creation via the Database
Configuration Assistant (DBCA), or they can be enabled later after the
data-base has been created. Here's a sample of these new security features-
#
Every user account password is now checked automatically to ensure sufficient
password complexity is being used.
#
To further strengthen password security, the DEFAULT user profile now sets
standard values for password grace time, lifetime, and lock time, as well as
for the maximum number of failed login attempts
#
Auditing will be turned on by default for over 20 of the most sensitive DBA
activities (e.g., CREATE ANY PROCEDURE, GRANT ANY PRIVILEGE, DROP USER, and so
forth). Also, the AUDIT_TRAIL parameter is set to DB by default when the
database is created, so this means that a data-base "bounce" will no
longer be required to activate auditing
#
Fine-Grained Access Control (FGAC) is now available for network callouts when
using raw TCP (e.g.,
via
the UTL_TCP package), FGAC will be able to construct Access Control Lists
(ACLs) to provide fine-grained access to external network services for specific
Oracle Database 11g database user accounts.
#
Enterprise Manager now provides interfaces for direct management of the
External Security Module
(ESM),
Fine-Grained Auditing (FGA) policies, and Row-Level Security (RLS) policies.
#
Finally, an RMAN recovery catalog can now be secured via Virtual Private
Catalog to prevent unauthorized users from viewing backups that are registered
within the catalog.
Partitioning
Upgrades
Oracle
Database 10g made a few important improvements to partitioned tables and
indexes (e.g., hash-partitioned global indexes), but Oracle Database 11g
dramatically expands the scope of partitioning
with several new composite partitioning options: Range Within Range, List
Within Range, List Within Hash, and List Within List. And that's not all-
#
Interval Partitioning. One of the more intriguing new partitioning options,
interval partitioning is a special version of range partitioning that requires
the partition key be limited to a single column with a data type of either
NUMBER or DATE. Range partitions of a fixed duration can be specified just like
in a regular range partition table based on this partition key. However, the
table can also be partitioned dynamically based on which date values fall into
a calculated interval (e.g., month, week, quarter, or even year). This enables
Oracle Database 11g to create future new partitions automatically based on the
interval specified without any future DBA intervention.
#
Partitioning On Virtual Columns. The concept of a virtual column - a column
whose value is simply the result of an expression, but which is not stored
physically in the database - is a powerful new construct in Oracle Database
11g. It's now possible to partition a table based on a virtual column value,
and this leads to enormous flexibility when creating a partitioned table. For
example, it's no longer necessary to store the date value that represents the
starting week date for a table that is range-partitioned on week number; the
value of week number can be simply calculated as a virtual column instead.
#
Partitioning By Reference. Another welcome partitioning enhancement is the ability
to partition a table that contains only detail transactions based on those detail
transactions' relationships to entries in another partitioned table that
contains only master transactions. The relationship between a set of invoice
line items (detail entries) that corresponds directly to a single invoice (the
master entry) is a typical business example. Oracle Database 11g will
automatically place the detail table's data into appropriate sub-partitions based on the
foreign key constraint that establishes and enforces the relationship between
master and detail rows in the two tables. This eliminates the need to
explicitly establish different partitions for both tables because the
partitioning in the master table drives the partitioning of the detail table.
#
Transportable Partitions. Finally, Oracle Database 11g makes it possible to
transport a partitioned table's individual partitions between a source and a
target database. This means it's now possible to create a tablespace version of
one or more selected partitions of a partitioned table, thus archiving that
partitioned portion of the table to another database server.
ASM Enhancements
Oracle
Database 10g introduced Automatic Storage Management (ASM) that at its essence
is a file system specifically developed for Oracle database files. Oracle Database
11g expands the reach of ASM with several new features, including-
#
SYSASM Role. A new role, SYSASM, has been created so that ASM instances can be
managed separately from the roles typically granted for traditional Oracle
database instance management.
#
ASM Rolling Upgrades. One of the most popular and sensible uses of ASM is in a
Real Applications
Cluster
(RAC) environment. Oracle Database 10g made it possible to initiate a rolling
patch set upgrade to the software in the Oracle database home on each node in
the cluster. This ensures that
the
clustered database remains accessible at all times because at least one Oracle
database instance is active while the patch set is applied to the other node(s).
The good news is that Oracle Database 11g now extends this concept to ASM
instances in a RAC clustered environment.
#
Fast Mirror Resynchronization. An ASM disk group that's mirrored using ASM
two-way or three-way mirroring could lose an ASM disk due to a transient
failure (e.g., failure of a Host Bus Adapter, SCSI cable, or disk I/O
controller). Should this occur, ASM will now utilize the Fast Mirror
Resynchronization feature to quickly resynchronize only the extents that were affected
by the temporary outage when the disk is repaired, thus reducing the time it
takes to restore the redundancy of the mirrored ASM disk group.
#
Preferred Mirror Read. An ASM disk group that's mirrored using ASM two-way or
three-way mirroring requires the configuration of failure groups. (A failure group
defines the set of disks across which ASM will mirror allocation units; this
ensures that the loss of any disk(s) in the failure group doesn't cause data loss.)
In Oracle Database 11g, it's now possible to inform ASM that it's acceptable to
read from the nearest secondary extent (i.e., the extent that's really supporting
the mirroring of the ASM allocation unit) if that extent is actually closer to
the node that's accessing the extent. This feature is most useful in a Real
Application Clusters (RAC) database environment, especially when the primary
mirrored extent is not local to the node that's attempting to access the extent.
#
Resizable Allocation Unit. Oracle Database 11g now permits an ASM allocation
unit to be sized at
either
2, 4, 8, 16, 32, or 64 MB when an ASM disk group is first created. This means
that larger sequential I/O is now possible for very large tablespaces, and/or
tablespaces with larger block sizes. The extent size is now automatically
increased as necessary and this allows an ASM file to grow up to the maximum of
128 TB as supported by Bigfile Tablespaces (BFTs).
#
Improved ASMCMD Command Set. ASMCMD now includes several new commands that
increase visibility of ASM disk group information, support faster restoration
of damaged blocks, and retain and
restore
complex metadata about disk groups:
#
A system / storage administrator can execute the lsdsk command to view a list
of all ASM disks even if an ASM instance is not currently running.
#
The remap command utilizes the existing backup of a damaged block on an
ASM-mirrored disk group to recover the damaged block to an alternate location elsewhere
in the ASM disk group.
#
Commands md_backup and md_restore allow a DBA to back up and restore,
respectively, the meta-data reflecting the exact structure of an ASM disk group.
These new commands are an immense boon
because
the recreation of extremely large disk groups consisting of several dozen mount
points can be
tedious,
time-consuming, and prone to error.
Data Guard
Enhancements
Last
but most certainly not least, Oracle Database 11g adds plenty of enhancements
to its flagship high-avail-ability solution for site survivability, Data Guard:
#
Snapshot Standby Database. Prior versions of Oracle Database supported two
types of standby
databases:
the physical standby, which is an exact duplicate of the primary database and
is updated via direct application of archived redo logs; and the logical
standby, which contains the same logical information as the primary database,
but whose data is organized and/or structured differently than on the primary
database and which is updated via SQL Apply. Oracle Database 11g adds a third
standby database type, the snapshot standby database, that's created by
converting an existing physical standby database to this format. A snapshot
standby data-base still accepts redo information from its primary, but unlike
the first two standby types, it does not apply the redo to the database
immediately; instead, the redo is only applied when the snapshot standby database
is reconverted back into a physical standby. This means that the DBA could
convert an existing physical standby database to a snapshot standby for testing
purposes, allow developers or QA personnel to make changes to the snapshot
standby, and then roll back those data created during testing and immediately
reapply the valid production redo data, thus reverting the snapshot standby to
a physical standby again.
#
Rolling Database Upgrades Support Physical Standby Databases. Oracle Database
10g introduced
the
ability to utilize SQL Apply to perform rolling upgrades against a primary
database and its logical
standby
database. During a rolling upgrade, the DBA first upgrades the logical standby
database to the latest database version, and then performs a switchover to make
the standby database the primary and vice versa. The original primary database
is then upgraded to the new database version, and a switchover reverses the
roles once again. This ensures that the only interruption to database access is
the time it takes to perform the switchovers. The good news is that Oracle
Database 11g now allows a rolling data-base upgrade to be performed on a
physical standby database by allowing the physical standby to be converted into
a logical standby database before the upgrade begins. After the rolling upgrade
is completed, the upgraded logical standby is simply reconverted back into a
physical standby.
#
Real-Time Query Capability. Active Data Guard will now allow the execution of
real-time queries against a physical standby database, even while the physical standby
continues to receive and apply redo transactions via Redo Apply. (In prior
releases, the physical standby could only be accessed for reporting if it was opened
in read-only mode while the application of redo was suspended.) This means that
a physical standby database can be utilized more flexibly for read-only
reporting purposes; also, the considerable resources needed to create and
maintain the standby environment may now be put to much more effective use.
#
Expanded Data Type and Security Support. Oracle Database 11g now supports XML Type
data stored in CLOB data types on logical standby databases. In addition,
Transparent Data Encryption (TDE) can now support encrypted table data as well
as encrypted tablespaces, and Virtual Private Database (VPD) is supported for
logical standby databases.
#
Heterogeneous Data Guard. Finally, it's now possible to set up the primary
database site using one
operating
system (e.g., Oracle Enterprise Linux 4.4) while using another operating system
(e.g., Windows 2003 Server) for the standby database site.
References
the
MacGraw-Hill ‘s OCP Oracle Database 11g: New Features for Administrator
