Discussions
Categories
- 382.3K All Categories
- 2.1K Data
- 209 Big Data Appliance
- 1.9K Data Science
- 447.9K Databases
- 220.9K General Database Discussions
- 3.7K Java and JavaScript in the Database
- 25 Multilingual Engine
- 520 MySQL Community Space
- 465 NoSQL Database
- 7.8K Oracle Database Express Edition (XE)
- 2.9K ORDS, SODA & JSON in the Database
- 492 SQLcl
- 3.9K SQL Developer Data Modeler
- 186.1K SQL & PL/SQL
- 21K SQL Developer
- 293.3K Development
- 7 Developer Projects
- 128 Programming Languages
- 290K Development Tools
- 95 DevOps
- 3K QA/Testing
- 645.5K Java
- 24 Java Learning Subscription
- 36.9K Database Connectivity
- 149 Java Community Process
- 104 Java 25
- 22.1K Java APIs
- 137.9K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 16 Java Essentials
- 144 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 198 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 265 LiveLabs
- 36 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.8K Other Languages
- 2.3K Chinese
- 166 Deutsche Oracle Community
- 1.2K Español
- 1.9K Japanese
- 229 Portuguese
Avoiding DB Performance degradation during upgrade
Hi everyone,
in short we are planning to upgrade our 11g instances to 12c. We are exporting and then importing in a new environment so not an in-place upgrade.
Some of the team are suggesting that we just have to accept that performance will tank when we switch to the new environment as the DB will need time to 'warm up'. By this they are are referring to execution plans etc.
If schema statistics are being copied over as part of the export is this predicted performance apocalypse still to be reasonably expected?
Is there anything else we can do to make the transition more smooth?
I really can't see our users accepting the line 'the db needs time to warm up!'.
Any insight, articles or personal experience appreciated.
Answers
-
Well, 99% or more of your tasks will be faster or at the same speed, for some statements you might need to tune the database a bit, but his is normal.
For the warm up - every START of a database instance means there is an empty buffer and library cache, this all needs to "warm up" and you can't really speed that up. Just use the application. Typically the first minutes are a little bit slower because there is physical I/O involved.
Which Version of 12c you want to use? 12c is a lot faster itself as 11g. If 12.2 it's fine, if 12.1 you may struggle a little bit about adaptive query optimization, then you must reconfigure that.
-
We are going from 11.2.0.4 to 12.2.0.1
Thank you for taking the time to reply @Joerg.Sobottka What you describe above is in line with what I understood and was expecting. The rumblings are about days and even weeks of warm up. As long as the database is in use, I don't believe this is a realistic expectation.
-
12.2.0.1 isn't problematic at all. I have a lot of databases that where migrated from 11.2 to 12.1 and later on to 12.2 and there wasn't any performance degredation by weeks (not even by days) . Caches need to warm up to have a hit rate better 95%, but this is normal behavior since release 6 or 7... There is nothing where 12.2 makes things worser, except for maybe some exceptional statements, But this are things that can happen at EVERY change of a release as there are some small changes in statistics or optimizer behavior...
So stay relaxed in total and work on a solution of the 1 to 5 exceptional statements if you may need to tune them...
