Presentation is loading. Please wait.

Presentation is loading. Please wait.

Session S317113: What do I really need to know when upgrading

Similar presentations

Presentation on theme: "Session S317113: What do I really need to know when upgrading"— Presentation transcript:

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

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

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 visibility
43 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 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


Download ppt "Session S317113: What do I really need to know when upgrading"

Similar presentations

Ads by Google