TimesTen In-Memory Database
for Extreme Performance

How to create heat maps using R for Oracle TimesTen Velocity Scale

Doug Hood
TimesTen Cloud Product Manager

This article was created by Jason Feldhaus, Consulting Member of Technical Staff at Oracle.

In data science, the open source R language is popular for statistical analysis and graphics. The combination of R and the RStudio IDE creates a powerful and productive environment for analysis, visualization and reporting.

R, R Studio and ROracle

Oracle created the ROracle package which is an open source SQL interface enabling optimized access to data in Oracle Database. As the ROracle package uses OCI drivers it can also work unchanged with Oracle TimesTen Velocity Scale In-Memory Database. Velocity Scale is primarily an OLTP RDBMS, but it also has advanced analytic features and benefits from parallel processing due to its scale out, shared nothing architecture.

This article shows how easy it is to create heat maps using ROracle with TimesTen Velocity Scale. Instead of using application data for the heat map, we will use run time performance metrics from the Oracle TimesTen Velocity Scale Database.

Velocity Scale with 8 nodes

The network diagram above was created by using ROracle to query the runtime topology of a TimesTen Velocity Scale database.  In this case, the database consists of eight machines (four nodes each with a copy for high availability, blue/yellow/red/green) which have some database connections (the pink circles).

How that this chart was created using ROracle, will be covered in another article, but this eight node database is used to provide the runtime metrics for the following heat map:

Heat map for some TimesTen Velocity Scale performance mertics

Heat maps display a color encoded summary of numeric data. This display also includes a dendogram. Dendograms are tree structures representing a hierarchy of clusters among row or column values based on a dissimilarity calculation.

Each column in this heat map represents performance metric values from a particular element (node) in the Velocity Scale grid. And each row represents all of the values for a particular metric. The color of each cell in a given row is scaled so that the largest value in the row is the darkest and the smallest value is the lightest. When a metric’s value is identical across all elements in the grid the cells are not colored.

If you compare the heat map with the grid network diagram above the similarities and differences between elements start to make sense.

  • There is a general pattern where elements that are copies of each other are also similar. The element pairs 5-6, 3-4, 7-8 and 1-2 are copies (replica sets) and this sequence is close to the order of the columns in the heat map.
  • Element 1 disrupts this pattern with distinctive differences compared to the others. This is likely due to three unique application connections (GridTxnMain, RTerm, GlobalDB_den00asr) that are not present on other elements.
  • Element 5 also stands out. This element does not have any direct application connections but it seems to be working harder (with more lock contention). After some investigation the extra work was associated with a global sequence object used by the workload applications. The sequence object batch size was increased to resolve the lock contention.

The following four chunks of R code were used to create the heat map:


Disclaimer: these are my personal thoughts and do not represent Oracle's official viewpoint in any way, shape, or form.


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.