Consultancy

I am an independent consultant specialising in Oracle databases. I am based in England and generally work for clients in the UK and Europe.

I am frequently engaged to perform tasks including Oracle RAC installation, performance tuning, Orace Data Guard configuration, Oracle Streams replication, upgrades and migrations. I provide specialist knowledge of Oracle internals to solve extreme performance issues such as redo generation, latch contention and library cache fragmentation. I also assist customers with strategic planning and architectural advice

I work directly for a number of customers specialising in short term consulting assignments from one day to around two weeks. I am generally available at short notice. I also allocate a limited number of free on-site consultancy days each year for business development purposes. I can be contacted either by e-mail info@juliandyke.com or by telephone +44 (0)7917 360777

Since 2005 I have worked for clients in England, Scotland, Wales, Switerland, France, the Netherlands, Belgium, Germany, Finland and Estonia.

Examples of typical engagements follow:

RAC Implementation

A RAC implementation typically requires between four and five days of consultancy time. Most engagements start with a couple of days planning involving members of DBA, storage, network and operating system teams where appropriate. There is normally a pause in the engagement for one or two weeks while the prerequisites are implemented by the various teams. On the third consultancy day all prerequisite configuration is verified and any outstanding issues are resolved. I normally work with a member of the DBA team to perform the installation and configuration of Grid Infrastructure and RAC software including any relevant patch sets. I usually create a test database to verify that the installation process has been successful. Screenshots are collected throughout the process and I include these in a full report. If sufficient time remains, we will perform further installations on test or standby clusters. Alternatively time is often spent with developers discussing how to modify applications to run efficiently in RAC environments.

Data Guard Configuration

Data Guard configuration typically requires 2 or 3 days of consultancy time. The amount of consultancy time depends on the complexity of the requirements and the size of the database. Common configuration options include physical and logical standbys, RAC and non-RAC environments, Data Guard Broker, Flashback Logging, Snapshot Standby, Fast Start Failover and Active Data Guard. In Oracle 11.1 and standby databases can usually be created without affecting the production database. However, some downtime is inevitable to test switchover and if possible failover operations. A full report describing creation, configuration and operation of the standby database is provided.

Performance Studies

Performance studies typically require between 2 and 5 days of consultancy time depending on the complexity of the environment. The engagement usually starts with a series of meetings to establish the characteristics of the workload and the perceptions of all stakeholders in the system including end-users, DBA teams, storage, network and operation systems administrators. If the Enterprise Management Diagnostics Pack has been licensed I will normally extract key statistics for a typical week from the AWR and use these to focus on a specific day for which I will generate hourly AWR reports for each instance. If available additional data is collected from sar archives and/or the Enterprise Manager repository. If the AWR is not available then I normally use STATSPACK as an alternative, though snapshots are not automatically enabled and therefore it may be necessary to allow workload data to be collected for a few days prior to the visit.

Following investigation of the AWR / STATSPACK data further analysis is often required to identify areas of inefficiency. Frequently performance issues exist in the library cache, buffer cache or cluster interconnect. However issues are also likely to be caused by application design and implementation. Another area of interest is often the storage subsystem where performance is often severely impacted by the distribution of the database across available disks and by other applications sharing the same storage.

All findings are documented in a report. I use Perl scripts to extract data from the repositories and also to generate tables and graphs to describe signifcant data. Perl scripts allow data to be presented more flexibly to highlight issues. For example the data in the chart below shows aggregated logical reads from a single server that supports eleven production databases concurrently.