The In-Memory Column Store feature that was introduced by Oracle in the database version 12c (188.8.131.52) brings the solution for accelerating performance of database-driven business decision-making to real-time speeds. Since it is an extra-license feature for which Oracle makes you pay around 50% on top of your CPU license (similar to RAC option), you probably ask yourself a few valid questions. Don’t we cache everything already in memory anyway? Is it really required for my application, my company? Will it work for my workload at all? In this post I’ll give you a short guideline and introduction into Oracle database In-Memory feature.
First of all me personally and so probably you do not know any database that works only on disk. Indeed we cache most of our data, code and intermediate results in memory already. Furthermore there are some extra Oracle database performance features that help you to achieve that fairly efficiently, for example:
– KEEP/RECYCLE Pools
– RESULT Cache
– 12c Big Table Caching
– 12c Full Database Caching
The key point of Oracle In-Memory is not “What to cache” but “How”. So the major difference of Oracle In-Memory Column Store is that it enables individual database segments to be loaded into memory in the compressed columnar format. This technique enables segment scans to perform much faster than the traditional on-disk formats, providing performance boost for analytical and reporting workload.
If you are not satisfied with the resolution or response to a critical Service Request (SR) at My Oracle Support (MOS), you can escalate it. SR escalation process (formerly known as the Duty Manager Process) is officially known as Requesting Manager Attention to a Service Request. This procedure will facilitate the assignment of a Support Manager [and potentially another support Engineer] to the SR, creation of an Action Plan and as the result it will usually speed up the resolution of the issue.
See below a Workbook of how to properly escalate MOS SR which is based on the Oracle official procedure, best practices and my own experience (this is a draft document -> it will be adjusted based on your valuable comments and experiences that you can post right below this post).
Before Escalating MOS SR
- Raise SR Severity (do not escalate if you have an ability to raise the severity)
- Work properly with the SR to avoid delays using my MOS SR Tips and Best practices
- In case you decide to escalate SR ensure the following:
- You have a valid reason and business case at your hands.
- Decide who will be the main contact from your side for the escalation process and that contact information is properly documeted in the SR (either as Primary or Alternate SR contact or if other: place it in SR body).
1. Insert the below template into the SR
This step is optional but makes sense to ensure proper communication Read more »