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.There are well documented methodologies and tools available to diagnose and resolve Oracle performance problems. What we don’t see much of are the high-level steps an IT Manager can take to identify causes of poor Oracle performance and usable solutions to resolve Oracle performance problems.
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 220.127.116.11. 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.
Oracle RMAN Backup Transport Tablespace Limitations
Oracle RMAN backup of transportable tablespace has a number of limitations for Oracle 10g. Oracle Transportable Tablespace allow for the efficient movement of large volumes of data between Oracle databases. On the whole this works well and once setup is far more efficient data than processing through database links.
What probably is not widely known is that Oracle RMAN in Oracle Database 10gR2 seems to have some difficulty with backup of a plugged in read only tablespace (the default state for a tablespace that is plugged in using transport tablespace).
There are two issues with using Oracle RMAN for backup on 10g when you have plugged in read only tablespace’s that have not been set to read write:
RMAN will not backup the datafile’s for the plugged in tablespace.
RMAN will not report the datafile’s as part of the ‘report need backup’ or ‘restore database preview check read only’ commands either.
Session Control with Oracle Database Resource Manager
The Oracle Database Resource Manager (DBRM) provides a wealth of functionality to control what user workloads are able to consume server and database resources. I have recently used the DBRM to provide the following functionality to the application:
Provide the ability to limit the duration of reports that are run through the DBMS_SCHEDULER.
Provide the ability to cancel and/or limit the duration a query submitted from the application user interface can run.
I spend a lot of time working on issues of performance and scalability for clients systems. The bulk of this work is around database and application transaction processing as these areas typically have the greatest business visibility. An area that does not seem to have the same level of visibility is how operationally efficient these same environments are – not through neglect however, but as a result of operational support requirements not being included as a part of the core requirements during a design phase.