The Database Paramedics

Early in my career at Oracle, I worked as what you might call a “paramedic” for Oracle databases.  Our team was originally called Field Support, but was later renamed Advanced Customer Services (ACS).  Most of us worked on full-time contracts, but we also worked short duration emergency jobs that we called “Fly & Fix” engagements.

During a Fly & Fix engagement, you could encounter just about any problem imaginable with Oracle databases.  We worked on database performance issues, crashing databases, corrupted databases, and corrupted databases with failing recovery.  By far, the most challenging engagement was the failing recovery situation. 

Consider the situation where a database is corrupted and the backup is either corrupted, doesn’t exist, or the backup isn’t usable for some reason.  Most importantly, think about the business impact in these situations as well as the human impact to the people involved.  These are very stressful situations.  People’s lives are disrupted and careers are impacted. Backup/recovery is a critical part of any IT operation, and it normally works unless mistakes were made. Like I said, it’s a very stressful situation.  Making such serious mistakes can be career limiting. 

120 Stories

In this blog, I will tell a sampling of stories from my years doing Fly & Fix work, with a focus on the events that taught important lessons to everyone involved. I will also tell how the failure started and some of the human and business impact it caused.  I went on a Fly & Fix engagement about once per month for 11 years, so I have about 120 stories to draw from.

Some of these stories are known to the industry and business press, but most of them went unreported. All of these cases are highly confidential, so I won’t divulge names of companies or people involved. I hope this blog will serve as a warning to IT professionals so you can avoid these sorts of issues in your own operations.  All of these stories will be told from my perspective and I will tell you the lessons I learned through the process. Others involved might have taken different lessons.  I hope you enjoy the re-telling.

Home

Introducing Total Session History

Attribution of time in database application determines potential benefits of Exadata

Exadata is a technology that delivers superior database performance, so it attacks the portion of time an application spends INSIDE the database.  Exadata will not make the network faster, and will not make application tiers faster.  Oracle database applications will have some transactions and/or batch jobs that show small increases in performance and transactions or jobs that show large performance increases.  It’s all a matter of where  the time is being spent.

Every Oracle database application includes portions that will show a LARGE benefit from Exadata, while other portions of that same application will show SMALL performance benefits.  To determine which portions of an application will show more or less performance benefit from a faster database, there are built-in features of the Oracle database that enable such analysis.

The Oracle Automated Workload Repository (AWR)

Oracle’s Automated Workload Repository (AWR) feature enables performance analysis of Oracle databases at the system level.  AWR reports show performance statistics for the system as a whole, including the SQL statements that consume the most resources on the system.  AWR is a great tool for doing analysis of system-wide performance issues.

The Oracle Active Session History (ASH)

Active Session History (ASH) facilitates performance tuning of SQL statements that consume the most resources in the system.  ASH provides a historical repository, making it possible to go back in time and find high resource consuming SQL statements.  This is a truly revolutionary capability for performance tuning because it allows the DBA to go back in time to see what performance problems existed when users were having troubles.

Total Session History (TSH) Utility

While AWR and ASH are great tools, they don’t facilitate analysis of the complete application from a session perspective.  The Total Session History (TSH) utility allows database administrators to analyze what factors account for time consumed by sessions in the database.  TSH gives a better picture of where time is being spent and how Exadata might help performance as viewed from the perspective of an end-user or within a batch job.

The TSH utility relies on built-in features of the database engine to track performance statistics and facilitate analysis of those statistics for all active sessions in the database.  Unlike the Active Session History (ASH) feature of Oracle, TSH captures the TOTAL session history.  This includes the full duration of each session as well as ALL sessions in the database regardless of whether they are active or not.