1. Session S317113: What do I really need to know when upgrading
Thomas Kyte

2. So … What Does Oracle Database 11g Mean To Me?
Change

3. Small Change – but think about it…
Let’s Go
Green 3

4. Small Change – but think about it…
ops$tkyte%ORA11GR2> create table t
2 as
3 select substr(object_name, 1, 1 ) str, all_objects.*
4 from all_objects
5 order by dbms_random.random;
Table created.
ops$tkyte%ORA11GR2> create index t_idx on t(str,object_name);
Index created.
ops$tkyte%ORA11GR2> begin
dbms_stats.gather_table_stats
( user, 'T',
method_opt => 'for all indexed columns size 254',
estimate_percent=>100 );
6 end;
7 /
PL/SQL procedure successfully completed. 4

5. Small Change – but think about it…
ops$tkyte%ORA11GR2> select count(subobject_name) from t t1 where str = 'T'; …
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | (0)| 00:00:04 |
| 1 | SORT AGGREGATE | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| T | | | (0)| 00:00:04 |
|* 3 | INDEX RANGE SCAN | T_IDX | | | (0)| 00:00:01 | 5

6. Small Change – but think about it…
ops$tkyte%ORA11GR2> insert into t
2 select 'T', all_objects.*
3 from all_objects
4 where rownum <= 1;
1 row created.
ops$tkyte%ORA11GR2> begin
dbms_stats.gather_table_stats
( user, 'T',
method_opt => 'for all indexed columns size 254',
estimate_percent=>100 );
6 end;
7 /
PL/SQL procedure successfully completed. 6

7. Small Change – but think about it…
ops$tkyte%ORA11GR2> select count(subobject_name) from t t2 where str = 'T'; …
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | (1)| 00:00:04 |
| 1 | SORT AGGREGATE | | | | | |
|* 2 | TABLE ACCESS FULL| T | | | (1)| 00:00:04 | 7

8. ““The Law of unintended consequences holds that almost all human actions have at least one unintended consequence. Unintended consequences are a common phenomenon, due to the complexity of the world and human over-confidence.”

9. What do you have from the past…
Online Parameter Changes
Online Major Memory Changes
Online Schema Evolution
Online Index Creates
Quiesce
Rolling Upgrades
Online Disk reconfiguration (ASM)
Online Cross Platform Tablespace Transport
Full Database Transports
And more….

10. The ability to forget and let it go
What do you need to know?
Test To Scale
The ability to forget and let it go
SQL Plan Management
Never
Stopping
Planning Ahead

11. First – what do we need to do?11
© 2010 Oracle Corporation 11

12. Database Upgrade Process: Steps
Planning Ahead
Analyze & gather information about environment
Determine the upgrade path and choose upgrade method
Prepare backup / recovery strategy and clone database to test
Establish performance baseline/metrics before upgrade
Develop a test plan for database, applications, and reports
Test upgraded database with applications and reports
Ensure adequate performance by comparing metrics gathered before and after upgrade
Remediate regressions, e.g, tune queries, update database parameters, call Support, etc.
Go Live!
Forget and let it go
ASH and AWR
Test To Scale
Never Stopping
SQL Plan Management

13. SQL
Plan Management 13
© 2010 Oracle Corporation 13

14. SQL Plan Management Phase 1 - Capture
Run applications to create a baseline
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
SQL MANAGEMENT BASE
Residing in SYSAUX TS.
Will occupy max. 10% of SYSAUX.
Weekly job will delete plans
not used in 53 weeks [default].
Repeated plans will be added to the SQL Plan Baseline during this phase
Plan History
Parse HJ GB
Plan Baseline GB HJ HJ

15. SQL Plan Management Phase 2 - Selection
New Plans are generated (because something changed)
But are not trusted
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE
New plan will be added to the Plan History but it won't be used unless and until it has been verified
Hard Parse NL GB
Plan History
Plan Baseline HJ

16. SQL Plan Management Phase 3 – Evolution
Plans are verified – by testing the performance of the new plan in the background
Automagically or Manually
Plan History
Plan Baseline GB NL
DBA HJ
Equal or better plans can be added to the SQL Plan Baseline
Inefficient plan will
be kept in the
Automatic Job

17. Your 9i application is already in 11g for whatever reason
Upgrade Scenario
Your 9i application is already in 11g for whatever reason
You’d like to have ‘query plan stability’
Coupled with the opportunity to use better plans – do not want to be frozen
The steps would be….

18. SQL Plan Management – Parameterize
STS GB NL
Now: Different plans created
with OFE=11
will be added to
the Plan History
for later verification
OPTIMIZER_FEATURES_ENABLE=11.2.0
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE 
This will cause the optimizer to capture a good approximation of the plans that would be generated in 9.2, but it‘s not a perfect impersonation of the earlier version because it still uses the 11g optimizer code. And, it won‘t capture Rule Based plans. So, it‘s not a perfect solution for people concerned about changing from rule based to cost based optimizer.
Repeatable plans will be added
to the Plan Baseline upon 2nd
execution 18
Plan History
Plan Baseline GB HJ GB NL GB NL
OPTIMIZER_FEATURES_ENABLE=9.2.0
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE

19. Your application is in 9i You’d like to have ‘query plan stability’
Upgrade Scenario
Your application is in 9i
You’d like to have ‘query plan stability’
Coupled with the opportunity to use better plans – do not want to be frozen
You will be changing platforms during the upgrade (not doing a direct upgrade of the database)
The steps would be….

20. SQL Plan Management – Outlines
Exp/imp outlines to
New system
exp imp expdp impdp DB-Link ... 
Query outlines can be captured on production and then exported/imported to a test system. Capturing plans with these outlines in place will preserve the original plans in the baseline. Just make sure to execute each statement twice.
STS SS
Plan History
Plan Baseline GB NL HJ
DBMS_SPM.MIGRATE_STORED_OUTLINE 3  20
Capture query outlines on the production system

21. Same Scenario but your application is in 10g
Upgrade Scenario
Same Scenario but your application is in 10g
You’d like to have ‘query plan stability’
Coupled with the opportunity to use better plans – do not want to be frozen
You will be changing platforms during the upgrade (not doing a direct upgrade of the database)
The steps would be….

22. SQL Plan Management – Tuning Pack
STS 
Staging
Table
exp imp expdp impdp DB-Link ...
STS 
STS = SQL Tuning Set. This is a mechanism we provide to collect a set of statements and their plans. This part of the DBMS_SQLTUNE package, and requires a Diagnostic and Tuning Pack license.
The STS can be put into a staging table, which can then be transported to the new database using one of several mechanisms. We can then unpack the STS and place all the 10.2 plans into the Plan Baseline.
Now, when the database finds plans that it thinks are better, those plans will go into the plan history for later evolution and acceptance by the DBA.
Package DBMS_SQLTUNE (ADD_SQLSET_REFERENCE, CAPTURE_CURSOR_CACHE_SQLSET, CREATE_SQLSET, CREATE_STGTAB_SQLSET, DELETE_SQLSET, DROP_SQLSET, LOAD_SQLSET, PACK_STGTAB_SQLSET, REMOVE_SQLSET_REFERENCE, SELECT_CURSOR_CACHE, SELECT_SQLSET, SELECT_WORKLOAD_REPOSITORY, UNPACK_STGTAB_SQLSET, UPDATE_SQLSET)
Plan History
Plan Baseline GB NL HJ
10.2 plans will become
the SQL Plan Baseline 3 22

23. You would like to deploy from development to production..
Upgrade Scenario
You would like to deploy from development to production..
You would like to deploy at a customer site…
And you want to start with a stable set of plans
Using better plans only after they have been verified
The steps would be….

24. SQL Plan Management - New Application
exp imp expdp impdp 
@Customer
Staging
Table
@Vendor
This requires 11g. If a vendor doesn‘t know for sure how customers will parameterize their database, then the vendor can ship a staging table of query baselines to the destination, and ensure that a default good plan is stored in the customer‘s plan baseline.
DBMS_SPM.CREATE_STGTAB_BASELINE
Staging
Table 24
DBMS_SPM.UNPACK_STGTAB_BASELINE
Plan Baseline GB NL HJ 3
DBMS_SPM.PACK_STGTAB_BASELINE
Plan Baseline GB HJ GB NL GB NL

25. Test to Scale 25
© 2010 Oracle Corporation 25

26. Database Replay Overview
Replay actual production database workload in test environment
Identify, analyze and fix potential instabilities before making changes to production
Capture Workload in Production
Capture full production workload with real load, timing & concurrency characteristics (9i, 10g, 11g)
Move the captured workload to test system (11g)
Replay Workload in Test
Make the desired changes in test system
Replay workload with full production characteristics
Honor commit ordering
Analyze & Report
Errors
Data divergence
Performance divergence
Oracle Database 11g provides two specific solutions to these aforementioned challenges.
Database Replay allows you to test the impact of a system change by replaying real-world workload on the test system before it is exposed to a production system. The production workload (including transaction concurrency and dependency) of the database server is recorded over an illustrative period of time (for example a peak period). This recorded data is used to replay the workload on a test system that has been appropriately configured. You gain a high degree of confidence in the overall success of the database change by subjecting the database server in a test system to a workload that is practically indistinguishable from a production workload.
Analysis & Reporting

27. Recording of External Client Requests
Supported Changes
Client …
Changes Unsupported
(there are other tools for that)
Database Replay focuses on recording and replaying of the workload that is directed to the RDBMS. Therefore recording of the workload is done at the point indicated in the above diagram. Recording at the RDBMS within the software stack makes it possible to exchange anything below this level and test the new setup using the record and replay functionality.
While replaying the workload, the RDBMS performs the actions observed during recording. In other words, during the replay phase the RDBMS code is exercised in a very similar way as it was exercised during the recording phase. This is achieved by recreating all external client requests to the RDBMS. External client requests include all the requests by all possible external clients of the RDBMS.
Middle Tier
Changes Supported
Recording of External Client Requests
Database Upgrades, Patches
Schema, Parameters
RAC nodes, Interconnect
OS Platforms, OS Upgrades
CPU, Memory
Storage
Etc.
Storage

28. Step 1: Workload Capture
Production System
All external client requests captured in binary files
System background and internal activity excluded
Minimal overhead
Avoids function call when possible
Buffered I/O
Independent of client protocol
Can capture on 9i, 10g, and 11g and replay on 11g
Capture load for interesting time period, e.g., peak workload, month-end processing, etc.
Here you see an illustration of a system that is being recorded. You should always record a workload that spans an “interesting” period in a production system. Typically, the replay of the recording is used to determine whether it is safe to upgrade to a new version of the RDBMS server. During recording, special recording infrastructure built into the RDBMS records data about all external client requests, while the production workload is running on the system. External requests are any SQL queries, PLSQL blocks, PLSQL remote procedure calls, DML statements, DDL statements, Object Navigation requests and OCI calls. Background jobs and in general all internal clients continue their work during recording, without being recorded. The end product is the workload recording contains all necessary information for replaying the workload as seen by the RDBMS in the form of external requests.
The recording infrastructure imposes minimal performance overhead (extra CPU, memory and I/O) on the recording system. You should however plan to accommodate the additional disk space needed for the actual workload recording.
RAC Note: Instances in a RAC environment have access to the common database files. However, they do not need to share a common general-purpose file system. In such an environment, the workload recording is written on each instance’s file system during recording. For processing and replay all the parts of the workload recording need to be manually copied into a single directory.
Overhead
Performance Overhead for TPCC is 4.5%
Memory Overhead : 64k/session
Client …
File System
Middle Tier
File 1
File 2 …
File n
Storage

29. Step 2: Process Workload Files
Setup test system
Application data should be same as production system as of capture start time
Use RMAN, Snapshot Standby, imp/exp, Data Pump, etc. to create test system
Make change: upgrade db and/or OS, change storage, migrate platforms, etc.
Processing transforms captured data into replayable format
Once processed, workload can be replayed many times
For RAC copy all capture files to single location for processing or use shared file system
Test System
File 1
File 2
File n …
Capture Files
File 1
File 2 …
File n
Metadata
Replay Files

30. Step 3: Replay Workload Test System …
Replays workload preserving timing, concurrency and dependencies of the capture system
Replay Client is a special program that consumes processed workload and sends requests to the replay system
Clients interpret captured calls into sequence of OCI calls and submit to database
For high concurrency workloads, it may be necessary to start multiple clients
Replay Clients
The workload recording is consumed by a special application called the replay driver, which sends requests to the RDBMS on which the workload is replayed. The RDBMS on which the workload is replayed is usually a test system. It is assumed that the database of the replay system is suitable for the replay of the workload that was recorded. The internal RDBMS clients are not replayed. The replay driver is a special client that consumes the Workload Recording and sends appropriate requests to the test system to make it behave as if the external requests were sent by the clients used during the recording of the workload (see previous example). The use of a special driver that acts as the sole external client to the RDBMS allows for the record and replay infrastructure to be client agnostic.
The replay driver consists of one or more clients that connect to the replay system and sends requests based on the workload capture. The replay driver equally distributes the workload capture streams among all the replay clients based on network bandwidth, CPU and memory capability.
Why OCI?
Powerful and Flexible
Supports a superset of most protocols
File 1
File 2 …
File n
Metadata
Replay Files

31. Analysis & Reporting
Error Divergence: For each call error divergence is reported
New: Error encountered during replay not seen during capture
Not Found: Error encountered during capture not seen during replay
Mutated: Different error produced in replay than during capture
Data Divergence
Replay: Number of rows returned by each call are compared and divergences reported
User: Application level validation scripts
Performance Reporting
Capture and Replay Report: Provides high-level performance information
ADDM Report: Provides in-depth performance analysis
AWR, ASH Report: Facilitates comparative or skew analysis
There may be some divergence of the replay relative to what was recorded. For example when replaying on a newer version of the RDBMS a new algorithm may cause specific requests to be faster, and so divergence appears as a faster execution. This is considered a desirable divergence. Another example of a divergence is when a SQL statement returns fewer rows during replay-time than those returned during record-time. This is clearly non-desirable and its root cause may be some new index look-up algorithm. The replay will identify this fact.
For data divergence the result of an action can be considered as:
The result set of SQL query.
An update to persistent database state.
A return code or an error code
Performance divergence is useful to determine how new algorithms introduced in the replay system may affect overall performance. There are numerous factors that can cause replay divergence. While some of them cannot be controlled, others can be mitigated. It is the task of the DBA to understand the workload runtime operations and take the necessary actions to reduce the level of record and replay divergence.
The two types of divergence reporting are listed above. Online divergence should aid the decision to stop a replay that has diverged significantly. The results of the replay before the divergence may still be useful, but further replay would not produce reliable conclusions. Offline divergence reporting is used to determine how successful the replay was after the replay has finished.

32. SQL Performance Analyzer: Overview Make Changes / Tuning Regressions
Production
Test …
Client
Middle Tier
Re-execute SQL … …
Capture SQL
Transport SQL
Oracle DB
Storage
Make Changes / Tuning Regressions
If adequate spare cycles available, optionally execute SQL here
* No middle & application tier setup required

33. SQL Performance Analyzer: Workflow
Production
Test
Mughees:
Similar to database replay, SQL Performance Analyzer is another key capability of Real Application Testing but it focused on SQL execution plan regressions. One of the biggest concerns DBA’s have when making any change is its impact on SQL statement performance. SQL Performance Analyzer provides the ability to capture the entire SQL workload from the production environment, replay it in the test environment and then provide a report identifying all SQL statements that improved, those that got worse, and those that remained unchanged. It then optionally allows you to automatically tune the regressed SQL statements using Oracle Database 11g capabilities like SQL Tuning Advisor and SQL Plan Baselines.
The end result is that all negative outcomes of a change are quickly identified and addressed using SQL Performance Analyzer so that businesses can continue to embrace change while minimizing risk.
Moe: Mughees, What are the unique capabilities of SQL Performance analyzer?
Mughees: SQL Performance analyzer offers three unique capabilities not available from other solutions in the market. 1) Low overhead, 2) test with production context and 3)automatic transfer of resolutions to production.
Moe: Lets talk about the effort involved here. How much could customers reduce testing effort when using RAT?
Make Change
Steps (1) (2) (3) (4) (5)
Capture
SQL (STS)
Transport
STS
Execute SQL
Pre-change
Execute SQL
Post-change
Compare
Perf.
(6) Reiterate
Done? No
(7)
Yes
Tuned System
Production Change / Tuning Deployment
(7)

34. SQL Performance Analyzer: Key Differentiators
From:
To:
Automated SQL capture, Negligible overhead
Manual SQL capture, High overhead
Non-production SQL context
Production SQL context
Partial SQL workload
Complete SQL workload
Automated analysis in minutes
Months of manual analysis
Automatic regression tuning
Manual regression tuning
Low risk, Low cost
High risk, High cost

35. Real Application Testing: Tools of the Trade
SQL Performance Analyzer
Database Replay
What is it?
Predicts SQL performance deviations before end-users can be impacted, helps assess impact of change on SQL response time
Replays real database workload on test system, helps assess impact of change on workload throughput
How it works?
Executes each SQL, stored in SQL Tuning Set, in isolation using production context and then compares before and after execution plans and run-time statistics
Captures workloads and replays it with production characteristics including concurrency, synchronization & dependencies
When to use?
Unit testing of SQL with the goal to identify the set of SQL statements with improved/regressed performance
Comprehensive testing of all sub-systems of the database server using real production workload
SQL
Concurrency
SQL
Dependency
Speed up/down

36. More information… Hands on Lab: S318966
Database and Application Testing HOL
Wed: pm
Marriott Golden Gate
SPA / Database Replay Demo grounds
Moscone West: 038/039 36

37. The Ability to forget
And let it go 37
© 2010 Oracle Corporation 37

38. Flashback for Rapid Recovery from Human Error
Flashback Data Archive:
Automatically stores all changes to selected tables
Archive cannot be modified
View table as of any time
Uses:
Change Tracking
ILM
Long term history - years
Auditing
Compliance
Flashback Query
Flashback Tables
Flashback Database
Flashback Data Archive and Transaction

39. Restore Points Restore point – specifies a jump label
Named Restore Point
Similar to a bookmark
"Can be" - but no guarantee
Will be recorded to the control file
Guaranteed Restore Point
Similar to storage snapshots
Overrides the FLASHBACK_RETENTION_TARGET
Attention: A guarantee restore point can stop the whole database
The guaranteed restore point is useful in upgrades as a fallback scenario (if you‘re coming from 10g). Remember, it was also part of the transient logical standby migration strategy.
If you use the guaranteed restore point for a fallback strategy and the upgrade succeeds, you may want to clear that guaranteed restore point to make sure your disk doesn’t fill up and stop the database.
SQL> CREATE RESTORE POINT rpt;
SQL> FLASHBACK DATABASE TO RESTORE POINT rpt; 39
SQL> CREATE RESTORE POINT grpt GUARANTEE FLASHBACK DATABASE;
SQL> FLASHBACK DATABASE TO RESTORE POINT grpt;

40. Never Stopping 40
© 2010 Oracle Corporation 40

41. Rolling Database Upgrades
Major
Release
Upgrades
Patch Set
Cluster Software & Hardware Upgrades
Redo
Clients
Logs
Queue
Version X
Version X X
X+1 1 2
Initial SQL Apply Config
Upgrade node B to X+1 41 A B A B
Redo
Redo
Upgrade
X+1
X+1 X
X+1 4
Switchover to B, upgrade A 3
Run in mixed mode to test

42. Online Application Upgrade Edition-based redefinition
Code changes are installed in the privacy of a new edition
Data changes are made safely by writing only to new columns or new tables not seen by the old edition
An editioning view exposes a different projection of a table into each edition to allow each to see just its own columns
A crossedition trigger propagates data changes made by the old edition into the new edition’s columns, or (in hot-rollover) vice-versa 42

43. Editions & object visibility43
Object_2
Object_1
Pre-upgrade edition

44. Editions & object visibility
(inherited)
Object_3
Object_3
(inherited) 44
Object_2
Object_2
(inherited)
Object_1
Object_1
(inherited)
Pre-upgrade edition
Post-upgrade edition
is child of

45. Editions & object visibility
(actual)
An editioned object is visible in a child of the edition where it was created.
When you “create or replace” it, you get a new actual occurrence that hides the occurrence that was inherited from the parent.
The old occurrence is still visible in the parent.
Drop and rename work as expected.
An editioned object has a new attribute: the name of the edition where it was created. You can see this in the new DBA_Objects.Edition_Name column.
The DBA_Objects catalog view family, and all the pre-existing ones, show you what is visible in the current edition – and only that. Just the DBA_Objects family (and a couple of others) has the Edition_Name. This tells you whether a particular object is actual or inherited.
There is a new DBA_Objects_AE family that tells you about everything in all editions (hence the suffix). There are a few other _AE view families.
Object_3
Object_3*
(actual) 45
Object_2
Object_2
(inherited)
Object_1
Object_1
(inherited)
Pre-upgrade edition
Post-upgrade edition
is child of

46. Planning Ahead
Upgrade Planner 46
© 2010 Oracle Corporation 46

47. The following is intended to outline our general product direction
The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

48. Performance Management Provisioning & Patching
MOS-EM: Unified View, Integrated Information Between My Oracle Support and Enterprise Manager
My Oracle Support
Knowledge
Management
Problem/SR
Management
Configuration
Management
Oracle
Knowledge
Management
Problem/SR
Management
Configuration
Management
Performance Management
Problem Diagnosis
Provisioning & Patching
Enterprise Manager
Customer
Operating Systems
Databases
Middleware
Applications
© 2010 Oracle Corporation 48

49. My Oracle Support – Upgrade Planner What Are We Announcing?
New Feature in My Oracle Support
Assist customers in planning the an Upgrade of Oracle technology
Benefits
Reduced time to create, manage and execute Upgrade plan
Streamlined process to request merge patches
Greater Reliability due to Software Currency
Latest SW, Patch, and Certification information
Accuracy of recommendations based on config data (not manual)
Lower Risk
Automated analysis for missing patches and conflict checking 49
© 2010 Oracle Corporation 49

50. My Oracle Support: Upgrade Planner
Challenges
Capabilities
Value
Upgrade from to 11.2
Where do I get the software
What are the valid SW upgrade paths ?
What is the certification/EOL status of the SW ?
What recommended patches do I apply post-upgrade?
How do I know if my fixes will be on my 11.2 upgrade?
Are there patch conflicts?
Upgrade path SW recommendations w/
Certification /EOL checks
Recommended Patches
Replacement/Merge Patch
Conflict Analysis for Patches
Research and Add Patches
Review Patch Feedback
Links to latest Support
Best Practices and knowledge
Reduced Time in research, analysis and management of Upgrade Plan
Reduced Risk due to increased accuracy (automated analysis)
Improved quality of plan due to latest Oracle Advice, Best Practices
Reduced Risk in performing Upgrade
Automated advisories based on configuration information
Automated conflict checking of patches and upgrades
Ability to validate Certified platforms and SW
Automated deployment using EM GC
Reduced Downtime by implementing proactive recommendations, - SW Currency
Managed systems can be kept current (up to date)
Latest recommended patches, Upgrade Plans, Certification and EOL Healthchecks
Reduced Time to perform change-
Less manual/tedious research time required
Uploaded configurations used to automatically analyse and recommend changes
Automated conflict analysis
Proactive alerts based on config data 50
© 2010 Oracle Corporation 50

51. ‘End-to-End’ Upgrade Lifecycle
Preparation
Upgrade
Post-Upgrade
Phase
Upgrade Plan
Upgrade Testing
Rehearsal
Production Upgrade
Monitor & Maintain
Sub-Phase
My Oracle Support Upgrade Plan*
Real Application Testing
Provisioning
Monitoring
Enterprise Manager – Grid Control
My Oracle Support ó EM Grid Control Integrated solution can be leveraged throughout full lifecycle
*Will be integrated in upcoming release 51

52. <Insert Picture Here>
How to get there

53. Size of Upgrade guides:
Upgrade is easier!
The upgrade to Oracle Database 11g is much easier than any upgrades to earlier Oracle releases
Size of Upgrade guides:
pages
pages – 111 steps for an RDBMS with 9 components
pages
pages
pages
pages
pages
When you have your system all set and patches is time to consider the upgrade process.
Upgrade is a lot easier than it used to be.
Just by looking at how the number of steps to upgrade has dramastically decreased is a good example of one way
The upgrade process has been simplified. 53
© 2010 Oracle Corporation

54. Documentation Note:785351.1 Upgrade Companion 11g Release 2 54
Companion 11.2: Note:
The upgrade companions are in the top 5 downloads from MetaLink. We produced the 10gR2 companion first back in 2007, because customers were experiencing many problems with upgrades and these problems were getting escalated to the executive level.
We have an initiative across development, support, consulting, ...many parts of the company...to improve the upgrade process. Every Friday we meet to discuss upgrade issues, improve the Companions, and tackle other upgrade topics.
As a result of this initiative, one of the new things we have done as part of the upgrade program is the Upgrade Companion.
The Upgrade Companion is a great place to start – if you are just looking at an upgrade – look at one of these.
Notes in My Oracle Support. It provides best practices and other considerations to take before you upgrade.
Since the Upgrade Companion was released we have found that customers who follow these best practices do not have upgrade problems. The very few escalations we have seen were from customers who skipped significant preparation steps.
Note:   Upgrade Companion 11g Release 2 54

55. What are my upgrade paths? Predictable performance post-upgrade 55 
11.2
SQL Plan Management
Automated SQL tuning
Real Application Testing 