In many instances of Oracle system optimisation, businesses consider a capacity increase as the first course of action. That is often a mistake. In my experience, 8 out of 10 times, an expansion isn’t needed to solve a problem, and just ends up an unnecessary and untimely cost.
Here are some surprising statistics we’ve seen from working in this space for the last 20 years.
80% of the fixes we’ve provided have not required any additional infrastructure or capacity spending.
Upgrading your Oracle database platform is one of the most strategic IT projects an organisation will undertake.
Whilst this upgrade is a relatively straightforward process, it will typically be linked to an infrastructure platform migration, or can be tied to a major application upgrade.
We will discuss the main performance related features in Oracle 12.2 that will directly benefit your organisation – enabling your systems to run faster or reducing the effort required to maintain and operate your critical Oracle database platforms.
When planning on an Oracle database upgrade, to maintain software currency or utilise new features, there are a number of things that can be done to minimise the risk of poor Oracle database performance after the upgrade.
Despite significant advances in the Oracle database optimiser and the supporting platform infrastructure, we as IT Managers still see poor Oracle database performance across a diverse range of workloads.
Recently I have been involved in a number of cases where the topic of virtualising the Oracle eBS R12 applications tier has been on the agenda. In all cases the target deployment has been on x86_64 infrastructure (combination of blades and stand alone servers) so the virtualisation platform considered has been either VMware or Oracle VM.
Beyond the obvious known benefits of deploying the applications tier – and where relevant the database tier – on virtual infrastructure one additional benefit that does not seem to receive attention is the ability to provision specific applications components to specific servers.
Recently I have been optimising the Oracle analytic SQL sort operations for a number of queries that make use of the ROLLUP analytic function. The test system was Oracle Database 126.96.36.199. Reviewing the extended SQL trace files to understand exactly where the time for the query was being spent we observed the same type of problem documented in Analytic Agony.
Tracing the sort operations performed by the analytic SQL we noticed the following:
Many small sort operations that were completing in memory using less than 80mb sort_area_size.
A few very large sort operations that were writing out to temporary tablespace of approximately 8GB in size.