Part 1 was introducing an Oracle In-Memory Option example; in Part 2 I’ll introduce a few queries that show meta data and statistics in context of the Oracle In-Memory Option.
One interesting set of metadata is the table’s in-memory status as well as the compression and loading priority. A table with enabled in-memory option is called “in-memory table” in the following for short. The following query retrieves these metadata for the in-memory table “IM_PLAYERS”:
SELECT table_name, inmemory, inmemory_compression, inmemory_priority FROM dba_tables WHERE table_name = 'IM_PLAYERS';
Loading of in-memory tables takes some time on initial load and their load status is important. Only when loaded the full capability of the in-memory functionality is available. The following query shows the load status by retrieving the number of bytes not populated into the in-memory area yet:
SELECT v.segment_name name, v.populate_status populate_status, v.bytes_not_populated bytes_not_populated FROM v$im_segments v ORDER BY 1;
The size of an in-memory table is important in order to determine if the memory allocation for the in-memory option is sufficient. The following query fetches various sizes:
SELECT v.owner, v.segment_name, v.populate_status, ROUND(v.bytes / 1000 / 1000, 2) AS size_in_mb, ROUND(v.inmemory_size / 1000 / 1000, 2) AS inmemory_size_in_mb, ROUND(v.inmemory_size / v.bytes, 2) * 100 AS im_size_percent FROM v$im_segments v;
When running queries against in-memory tables the in-memory option might or might not be triggered and used depending on the query optimizer’s decisions. The following two statements executed together show if the in-memory option was used:
EXEC dbms_feature_usage_internal. exec_db_usage_sampling(SYSDATE);
SELECT ul.name, ul.detected_usages FROM dba_feature_usage_statistics ul WHERE ul.version = (SELECT MAX(u2.version) FROM dba_feature_usage_statistics u2 WHERE u2.name = ul.name AND ul.name LIKE 'In-%');
A query to an in-memory table advances the value of detected_usages if the in-memory representation of that table was in fact accessed.
If a query triggers the use of the columnar representation managed by the in-memory option it is important to understand the specific statistics to see how much optimization took place. The following query retrieves some of all available statistics:
SELECT t.display_name, s.value, s.sid, t.statistic# FROM v$statname t, v$mystat s WHERE t.display_name IN ('IM scan CUs columns accessed', 'IM scan segments minmax eligible', 'IM scan CUs pruned') AND s.statistic# = t.statistic# ORDER BY s.sid DESC;
Being able to retrieve the statistics allows now to see the statistics before and after query execution. In the next section a selective as well as aggregate query is run and the statistics examined before and afterwards.
The first example is a selective query that retrieves all columns of two players (rows).
SELECT * FROM cb.im_players WHERE player_id = 10 OR player_id = 20;
First, the statistics is shown before the query is executed and then the statistics after the query is executed.
The second example is a non-selective query that aggregates over all rows.
SELECT player_name, COUNT(*), MIN(player_score), MAX(player_score), AVG(player_score), SUM(player_score) FROM cb.im_players GROUP BY player_name;
Again, first the statistics before and after the query execution is shown.
This blog introduced a series of queries that allow to retrieve metadata as well as statistics on query execution in context of the Oracle In-Memory Option. The nice part is that these are regular SQL queries that can be run manually, but also as part of development or operations tools. It is therefore possible to examine the use of the in-memory tables and their behavior in a running application.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.