Sunday, August 03, 2014

Oracle Database 12c: In-Memory Option

Starting with Oracle Database 12cR1 (12.1.0.2), a new static pool in the SGA is designed to store data in the columnar format and is called In-Memory Column Store (IMCS). Each table column is stored as a separate structure in IMCS. The In-Memory column store does not replace the buffer cache, rather supplements by storing data in columnar format.

Following the levels at which IMCS can be enabled at:
  • Column
  • Partition / sub-partition
  • Table
  • Materialized view
  • Tablespace
The IMCS is populated by a set of background processes. Objects are populated into the IMCS either in a prioritized list soon after database start-up or after they are queried for the first time.

Like other Oracle Database Options, you make NO changes in your application to start benefiting from the In-Memory Option. It is completely transparent to the applications. Also, Oracle Optimizer is fully aware of the column format and automatically utilizing IMCS when required.

I plan to test and blog more on the In-Memory option. Following are few of the topics that I plan to post a blog entry on:

  • Enable and disable In-Memory Option
  • In-Memory Option at various levels
  • In-Memory Space pressure
  • In-Memory background processes
  • In-Memory with compression levels
  • In-Memory statistics
  • In-Memory and Data Pump Export
  • In-Memory with Multi-tenant Option



Thursday, July 24, 2014

AWR Warehouse

AWR Warehouse is a central repository configured for long term AWR data retention. It stores AWR snapshots from multiple database sources. Increasing AWR retention in the production systems would typically increase overhead and cost of mission critical databases. Hence, offloading the AWR snapshots to a central repository is a better idea. Unlike AWR retention period of default 8 days, the AWR Warehouse default retention period is "forever". However, it is configurable for weeks, months, or years. 

For more information on AWR Warehouse click on the following link for a video tutorial. 

http://www.youtube.com/watch?v=StydMitHtuI&feature=youtu.be

Monday, July 07, 2014

Benefits of Single Tenant Deployments

While presenting at a database event, I had a question from one of the attendees on benefits of running Oracle databases in Single Tenant Configuration.  I thought this would be a nice if I post it on my blog as it would benefit others too.

From Oracle documentation, “The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB) that includes zero, one, or many customer-created pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and non-schema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c were non-CDBs”.

Following are the benefits of running databases in Single Tenant Configuration:
  1. Alignment with Oracle’s new multi-tenant architecture
  2. Cost saving. You save on license fee as single tenant deployments do not attract Multi-tenant option license fee. License is applicable should you have two or more PDBs.
  3. Upgrade/patch your single PDB from 12.1.0.1 to 12.x easily with reduced downtime
  4. Secure separation of duties (between CDBA & DBA)
  5. Easier PDB cloning

I would recommend running all your production and non-production databases in single-tenant configuration (if you are not planning for consolidation using multi-tenant option) once you upgrade them to Oracle Database 12c. I expect to see single tenant deployments become the default deployment model for the customers.