Performance Archives - Philipp Salvisberg's Blog

Constants vs. Parameterless Functions

Philipp Salvisberg — Fri, 13 Dec 2019 17:24:17 +0000

Do you use parameterless PL/SQL functions in your queries? Did you know that this may cause performance issues? In this blog post, I explain why parameterless functions can be the reason for bad execution plans in any Oracle Database.

I recently had to analyze this problem in a production system and thought it was worth sharing. On the one hand, because we did not find a satisfactory solution and on the other hand because this could change in the future when we start discussing it.

For this blog post, I used an Oracle Database 19c Enterprise Edition, version 19.5.0.0.0 in a Docker environment. However, you can run the scripts in any edition of an Oracle Database 12c Release 1 or later to reproduce the results.

1. Data Setup

We create a user demo with ALTER SESSION and SELECT ANY DICTIONARY privileges as follows:

Create user demo

CREATE USER demo IDENTIFIED BY demo  
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;

GRANT connect, resource TO demo;
GRANT alter session TO demo;
GRANT select any dictionary TO demo;

Then as user demo we create a table t with an index t_ind_idx on column ind

Create table t

CREATE TABLE t (
   id   INTEGER       GENERATED ALWAYS AS IDENTITY CONSTRAINT t_pk PRIMARY KEY,
   ind  INTEGER       NOT NULL CONSTRAINT ind_ck CHECK (ind IN (0, 1)), 
   text VARCHAR2(100) NOT NULL
);
CREATE INDEX t_ind_idx ON t (ind);

and populated table t with the following anonymous PL/SQL block:

Populate table t

BEGIN
   dbms_random.seed(0);
   INSERT INTO t (ind, text)
   SELECT CASE 
             WHEN dbms_random.value(0, 999) < 1 THEN
                1 
             ELSE 
                0
          END AS ind,
          dbms_random.string('p', round(dbms_random.value(5, 100),0)) AS text
     FROM xmltable('1 to 100000');
   COMMIT;
END;
/

The case expression leads to a skewed distribution of column ind. Only around 0.1% of the rows have a value 1 as the following query shows:

Distribution of column ind

SELECT ind, count(*) 
  FROM t 
 GROUP BY ind;

       IND   COUNT(*)
---------- ----------
         1        101
         0      99899

Therefore we are gathering statistics for table t with a histogram for column ind:

Gather statistics

BEGIN
   dbms_stats.gather_table_stats(
      ownname    => user, 
      tabname    => 'T', 
      method_opt => 'FOR ALL COLUMNS SIZE AUTO FOR COLUMNS SIZE 2 IND'
   );
END;
/

Now, we can check the histogram with the following query:

Histogramm of column ind

SELECT endpoint_value, endpoint_number 
  FROM user_histograms
 WHERE table_name = 'T' 
   AND column_name = 'IND';

ENDPOINT_VALUE ENDPOINT_NUMBER
-------------- ---------------
             0           99899
             1          100000

Two rows for the two values of column ind. For value 0 we expect 99899 rows (endpoints) and for value 1 we expect 101 rows (100000 – 99899 endpoints). This is 100 percent accurate.

2. Constant Declaration

In the Trivadis PL/SQL & SQL Guidelines we recommend avoiding the use of literals in PL/SQL code. Every time we see a literal in a PL/SQL code we should consider using a constant instead. Often this makes sense because the name of the constant is more meaningful than the literal, making the code more readable and maintainable.

Hence we create the following PL/SQL package for our representation of boolean values in SQL:

PL/SQL package for boolean values

CREATE OR REPLACE PACKAGE const_boolean AUTHID DEFINER IS
   co_true  CONSTANT INTEGER := 1;
   co_false CONSTANT INTEGER := 0;
END const_boolean;
/

Now we can use these constants in our PL/SQL code as follows:

SQL using a constant (within PL/SQL)

SET SERVEROUTPUT ON
BEGIN
   FOR r IN (
      SELECT count(*) AS open_count
        FROM t 
       WHERE ind = const_boolean.co_true
   ) LOOP
      dbms_output.put_line('open: ' || r.open_count);
   END LOOP;
END;
/

open: 101

PL/SQL procedure successfully completed.

When developing complex SQL statements I often run them standalone in an IDE until I’m satisfied with the result. But when we run this

SQL using a constant (outside of PL/SQL)

SELECT count(*) AS open_count
  FROM t 
 WHERE ind = const_boolean.co_true;

we get the following error message:

Error when using a constant in SQL

Error starting at line : 1 in command -
SELECT count(*) AS open_count
  FROM t 
 WHERE ind = const_boolean.co_true
Error at Command Line : 3 Column : 14
Error report -
SQL Error: ORA-06553: PLS-221: 'CO_TRUE' is not a procedure or is undefined
06553. 00000 -  "PLS-%s: %s"
*Cause:    
*Action:

We have to change the constant const_boolean.co_true to a literal (1), which is cumbersome and error-prone.

3. Parameterless Functions for Constants

As a workaround, we can create a parameterless function for each constant. Like this:

Parameterless function for each constant

CREATE OR REPLACE PACKAGE const_boolean AUTHID DEFINER IS
   co_true  CONSTANT INTEGER := 1;
   co_false CONSTANT INTEGER := 0;
   FUNCTION true# RETURN INTEGER DETERMINISTIC;
   FUNCTION false# RETURN INTEGER DETERMINISTIC;
END const_boolean;
/
CREATE OR REPLACE PACKAGE BODY const_boolean IS
   FUNCTION true# RETURN INTEGER DETERMINISTIC IS
   BEGIN
      RETURN co_true;
   END true#;
   FUNCTION false# RETURN INTEGER DETERMINISTIC IS
   BEGIN
     RETURN co_false;
   END false#;
END const_boolean;
/

Now we can use the function in PL/SQL and SQL like this:

SQL

SELECT count(*) AS open_count
  FROM t 
 WHERE ind = const_boolean.true#;

OPEN_COUNT
----------
       101

So far so good.

4. The Problem

The execution plan of the previous statement looks as follows:

Bad execution plan

SQL_ID  bg67gqa8f48j8, child number 0
-------------------------------------
SELECT count(*) AS open_count  FROM t  WHERE ind = const_boolean.true#
 
Plan hash value: 3395265327
 
-----------------------------------------------------------------------------------
| Id  | Operation             | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |           |       |       |    75 (100)|          |
|   1 |  SORT AGGREGATE       |           |     1 |     3 |            |          |
|*  2 |   INDEX FAST FULL SCAN| T_IND_IDX | 50000 |   146K|    75  (12)| 00:00:01 |
-----------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - filter("IND"="CONST_BOOLEAN"."TRUE#"())

When you look at line 12 you see that the optimizer estimates to process 50000 rows. That’s 50 percent of all rows. This is based on the number of distinct values for column ind and the number of rows in the table t. The optimizer gets this information from here:

Table and column statistics

SELECT num_rows 
  FROM user_tables 
 WHERE table_name = 'T';

  NUM_ROWS
----------
    100000

SELECT num_distinct 
  FROM user_tab_columns
 WHERE table_name = 'T'
   AND column_name = 'IND';

NUM_DISTINCT
------------
           2

Unfortunately, the histogram for the column ind is ignored. Why? Because the Oracle Database has no idea what the value of const_boolean.true# is. Hence, a histogram is not helpful in finding an execution plan.

An optimal plan would look like this:

Good execution plan

SQL_ID  bstdc2tsv1qcw, child number 0
-------------------------------------
SELECT count(*) AS open_count  FROM t  WHERE ind = 1
 
Plan hash value: 3365671116
 
-------------------------------------------------------------------------------
| Id  | Operation         | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |           |       |       |     1 (100)|          |
|   1 |  SORT AGGREGATE   |           |     1 |     3 |            |          |
|*  2 |   INDEX RANGE SCAN| T_IND_IDX |   101 |   303 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - access("IND"=1)

When you look at line 12, you see that

an INDEX RANGE SCAN is used and
the number of rows is estimated correctly.

We get this plan when using a literal 1, a bind variable with the bind value 1 (thanks to bind variable peeking) or a constant with value 1 (which is treated as a bind variable in PL/SQL).

The wrong cardinality is a major problem. Because the cardinality is the most important criterion for choosing an optimal access method, join order and join method. Bad cardinality estimates lead to bad execution plans and bad performance. This cannot be ignored, even if in this demo case the resulting performance is still okay.

The problem occurs only if we are accessing columns with significantly skewed data and if these columns have a histogram.

5. Workarounds

We have basically three options to work around the problem:

For PL/SQL code we can use a constant instead of a parameterless function
(e.g. ind = const_boolean.co_true)
For PL/SQL code or plain SQL like in views, we can use a literal with a comment instead of a parameterless function
(e.g. ind = 1 -- const_boolean.co_true)
For PL/SQL code or plain SQL like in views, we can query the parameterless function in a subquery and force the optimizer to execute it during parse time [added on 2019-12-14]
(e.g. ind IN (SELECT /*+ precompute_subquery */ const_boolean.true# FROM DUAL))

The first option has the drawback, that you have to change the SQL to make it runnable outside of PL/SQL. The second option may lead to inconsistencies due to wrong literal/comment combinations or when changing constant values. The third option requires an IN condition that could be accidentally changed to an equal comparison condition due to the scalar subquery, which would make the undocumented precompute_subquery hint ineffective. [added on 2019-12-14]

Of course, you can continue to use parameterless functions in SQL and PL/SQL and switch to one of the options if there is a problem or if you know that a histogram exists for a certain column. But this is difficult to apply consistently. In fact, it makes maintenance more complicated with a certain performance risk or penalty.

6. Considered Alternatives

I had a look at Associate Statistics (Extensible Optimizer Interface). This does not help, because there is no way to access the related table columns to calculate the impact on the selectivity. The feature is useful if a function gets some parameters to calculate the impact on the selectivity, but without parameters, this is not possible.

I had considered list partitioned tables based on skewed columns instead of using indexes. This works and can make sense to reduce the overhead of an index (especially indexing non-selective values). But the issues regarding parameterless functions are 100 percent the same.

7. Summary

Parameterless functions are a way to use constants in SQL outside of PL/SQL, for example in views. However, they rob the optimizer of the capability to use histograms and therefore find an optimal execution plan.

Actually, we can only work around the problem. The Oracle Database has to provide the solution. Either by allowing to access package global constants in SQL (outside of PL/SQL) or by implementing some kind of peeking for parameterless, deterministic functions.

If you think I missed something important, especially if you think there is a better workaround or even a solution, then please do not hesitate to leave a comment or contact me directly. Thank you.

Updated on 2019-12-14, added a third option under “5. Workarounds” based on a tweet by Jonathan Lewis. Thanks a lot.

The post Constants vs. Parameterless Functions appeared first on Philipp Salvisberg's Blog.

MemOptimized RowStore in Oracle Database 19c

Philipp Salvisberg — Sun, 17 Feb 2019 20:15:42 +0000

Since February 13 2019 Oracle Database 19c has been available. I blogged about this feature here and here. Time for an update. So, what’s new in 19c regarding the MemOptimized Rowstore?

Fast Lookup Works with JDBC Thin Driver

I listed 16 prerequisites for the MemOptimized Rowstore in this blog post. The last one – “The query must not be executed from a JDBC thin driver connection. You have to use OCI, otherwise the performance will be really bad.” does not apply anymore. This “bug” is fixed in 19c. Here are the JDBC thin driver results of the test program listed in this blog post:

Console output of run.sh (excerpt) with comments

# t1 - heap table
run #1: read 100000 rows from t1 in 18.602 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #2: read 100000 rows from t1 in 17.723 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #3: read 100000 rows from t1 in 18.834 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #4: read 100000 rows from t1 in 18.039 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #5: read 100000 rows from t1 in 18.711 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.

# t4 - memoptimized heap-table
run #1: read 100000 rows from t4 in 16.696 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #2: read 100000 rows from t4 in 16.671 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #3: read 100000 rows from t4 in 16.952 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #4: read 100000 rows from t4 in 16.805 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #5: read 100000 rows from t4 in 17.627 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.

See, the runs for t4 are the fastest because they used memopt r lookups instead of consistent gets. BTW, the absolute runtime values of these tests are not important or representative, they vary a lot depending on the Docker environment that I use. However, I consider the relative difference between the t1 and t4 as relevant and conclusive. The next graph visualizes the results. I also added the results for the PL/SQL runs to this graph. It clearly shows that if you can do it within the database, you should do it.

I also run this test for 18.5.0.0.0. It looks like this bug has not been fixed in 18c yet.

Fast Ingest

This new 19c feature consists of two parts. The usage is best described in the Database Performance Tuning Guide.

First, the table must be enabled for memoptimized write using the memoptimize_write_clause. You can do that in the create table or the alter table statement. Here’s an example:

Example of memoptimize_write_clause

CREATE TABLE t5 (
   key    INTEGER            NOT NULL,
   value  VARCHAR2(30 CHAR)  NOT NULL,
   CONSTRAINT t5_pk PRIMARY KEY (key)
) 
SEGMENT CREATION IMMEDIATE
MEMOPTIMIZE FOR WRITE;

One way to trigger fast ingest is to use an insert hint. Here’s an example:

Fast ingest (autocommit)

BEGIN
   FOR r IN (SELECT * FROM t4 WHERE key between 10001 and 20000) LOOP
      INSERT /*+ memoptimize_write */ INTO t5 VALUES r;
   END LOOP;
END;
/

There is no commit in this anonymous PL/SQL block. In this case an additional commit statement would just slow down the processing. The insert statements are treated like asynchronous transactions. This mechanism is called „delayed inserts“. The rows to be inserted are collected in the large pool and processed asynchronously in batches using direct path inserts. That will happen eventually. However, you can call dbms_memoptimize_admin.writes_flush to force the rows in the large pool to be written to disk.

Fast ingest is much more efficient than a series of conventional single transactions. But, there are some disadvantages to consider.

Data loss in case of a crash of the database instance
Delayed visibility of inserted data
Delayed visibility of errors

The first two are simply the price to optimize the insert performance of multiple clients. However, the last one is interesting. Where are errors reported in this case and how do we deal with them?

Here’s an example.

Fast ingest with a duplicate row

SELECT * FROM t5 WHERE key IN (10001, 20001);

       KEY VALUE                         
---------- ------------------------------
     10001 PAST7NL2N2W8K9ESS7BZWSI   

BEGIN
   FOR r IN (SELECT * FROM t4 WHERE key IN (10001, 20001)) LOOP
      INSERT /*+ memoptimize_write */ INTO t5 VALUES r;
   END LOOP;
   dbms_memoptimize_admin.writes_flush;
END;
/

PL/SQL procedure successfully completed.

SELECT * FROM t5 WHERE key IN (10001, 20001);

       KEY VALUE                         
---------- ------------------------------
     10001 PAST7NL2N2W8K9ESS7BZWSI       
     20001 4IMKI9RLBTV7

Fast ingest persisted the non-existing row with the key 20001. But the row with the existing key 10001 was ignored. Somewhere an ORA-00001: unique constraint violated must have been thrown. But right now I do not know If it was just swallowed or stored somewhere (I have not found the trace file mentioned in Database Concepts). If ignoring is the right way to deal with such errors, then we are all set. Otherwise, we have to think a bit more about it.

The post MemOptimized RowStore in Oracle Database 19c appeared first on Philipp Salvisberg's Blog.

MemOptimized RowStore in Oracle Database 18c with OCI

Philipp Salvisberg — Tue, 19 Jun 2018 19:34:51 +0000

On June 10 2018 I blogged about the MemOptimized RowStore in Oracle Database 18c. If you haven’t read this post, it is a good idea to catch up now. I showed that accessing a memoptimized table t4 via the MemOptimized RowStore was around 60% slower than accessing a heap-organized table t1. I suspected that this disappointing result was related to my unsupported Docker environment. But I was wrong.

The next day, Chris Antognini contacted me, since he planned to talk about this feature at the AOUG Anwenderkonferenz 2018. We exchanged our thoughts and shared our findings. Chris did his tests in the Oracle cloud and could also reproduce my test results. That’s interesting. Even more interesting is, that Chris translated my Java program to C and proved that the MemOptimized RowStore can be fast. That’s cool. But why didn’t it work in Java? It’s the same after all, right? No. The Java program used the JDBC thin driver and the C program OCI.

In this blog post, I will show that OCI is a prerequisite for getting good performance out of the MemOptimized RowStore.

The Program

I use the Java program from my previous post. I only added 3 parameters. The JDBC URL, the username and the password. Here’s the program.

J.java – 100,000 queries

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import oracle.jdbc.driver.OracleDriver;
public class J {
   private static boolean isRunningInDatabase() {
      return System.getProperty("oracle.jserver.version") != null;
   }
   public static void m(String tableName, String url, String userName, String password) throws SQLException {
      Connection conn;
      if (isRunningInDatabase()) {
         conn = new OracleDriver().defaultConnection();
      } else {
         conn = DriverManager.getConnection(
           url, userName, password);
      }
      conn.setAutoCommit(false);
      long start = System.currentTimeMillis();
      String query = "SELECT value FROM " + tableName + " WHERE key = ?";      
      PreparedStatement ps = conn.prepareStatement(query);
      for (long i = 1; i <= 100000; i++) {
         ps.setLong(1, i);
         ResultSet rs = ps.executeQuery();
         while (rs.next()) {
            rs.getString("value");
         }
         rs.close();
      }
      ps.close();
      if (!isRunningInDatabase()) {
         conn.close();
      }
      long end = System.currentTimeMillis();
      System.out.println("read 100000 rows from " + tableName + " in " +
         String.valueOf((double) (end-start)/1000) + " seconds via " + url + ".");      
   }
   public static void main(String[] args) throws SQLException {
      m(args[0], args[1], args[2], args[3]);
   }
}

I copied this program to my Docker container into the directory $ORACLE_HOME/jdbc/lib and compiled it with the following script:

compile.sh

export rt CLASSPATH=.:./ojdbc8.jar
javac J.java

The Test Script

I’ve run the tests for my previous post from the Eclipse IDE because it was convenient for me to set a break point on line 20 to identify the Oracle process for perf. Now, I do not need to produce flame graphs. Running the test script on the server directly will also reduce the network overhead, especially when running without Oracle Net.

Here’s the test script:

run.sh

#/bin/bash

run(){
    TABLE=${1}
    URL=${2}
    for ((i=1;i<=5;i++));
    do
        echo -n "run #${i}: "
        java J ${TABLE} ${URL} ${USERNAME} ${PASSWORD}
    done
    echo ""
} 

export CLASSPATH=.:./ojdbc8.jar
export USERNAME=tvdca
export PASSWORD=tvdca

# Thin driver
run t1 "jdbc:oracle:thin:@//localhost:1521/odb.docker"
run t2 "jdbc:oracle:thin:@//localhost:1521/odb.docker"
run t3 "jdbc:oracle:thin:@//localhost:1521/odb.docker"
run t4 "jdbc:oracle:thin:@//localhost:1521/odb.docker"

# OCI driver with Oracle*Net
run t1 "jdbc:oracle:oci:@odb"
run t2 "jdbc:oracle:oci:@odb"
run t3 "jdbc:oracle:oci:@odb"
run t4 "jdbc:oracle:oci:@odb"

# OCI driver without Oracle*Net
run t1 "jdbc:oracle:oci:@"
run t2 "jdbc:oracle:oci:@"
run t3 "jdbc:oracle:oci:@"
run t4 "jdbc:oracle:oci:@"

The Result

Here’s the output of the run.sh call:

Console output of run.sh

[oracle@odb180 lib]$ ./run.sh
run #1: read 100000 rows from t1 in 11.918 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #2: read 100000 rows from t1 in 11.625 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #3: read 100000 rows from t1 in 11.662 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #4: read 100000 rows from t1 in 11.574 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #5: read 100000 rows from t1 in 11.729 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.

run #1: read 100000 rows from t2 in 11.786 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #2: read 100000 rows from t2 in 12.071 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #3: read 100000 rows from t2 in 12.621 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #4: read 100000 rows from t2 in 11.913 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #5: read 100000 rows from t2 in 11.972 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.

run #1: read 100000 rows from t3 in 11.397 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #2: read 100000 rows from t3 in 11.429 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #3: read 100000 rows from t3 in 11.308 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #4: read 100000 rows from t3 in 11.793 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #5: read 100000 rows from t3 in 11.903 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.

run #1: read 100000 rows from t4 in 19.789 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #2: read 100000 rows from t4 in 19.461 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #3: read 100000 rows from t4 in 19.181 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #4: read 100000 rows from t4 in 19.211 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.
run #5: read 100000 rows from t4 in 19.242 seconds via jdbc:oracle:thin:@//localhost:1521/odb.docker.

run #1: read 100000 rows from t1 in 13.145 seconds via jdbc:oracle:oci:@odb.
run #2: read 100000 rows from t1 in 12.698 seconds via jdbc:oracle:oci:@odb.
run #3: read 100000 rows from t1 in 13.14 seconds via jdbc:oracle:oci:@odb.
run #4: read 100000 rows from t1 in 12.842 seconds via jdbc:oracle:oci:@odb.
run #5: read 100000 rows from t1 in 12.978 seconds via jdbc:oracle:oci:@odb.

run #1: read 100000 rows from t2 in 13.049 seconds via jdbc:oracle:oci:@odb.
run #2: read 100000 rows from t2 in 12.581 seconds via jdbc:oracle:oci:@odb.
run #3: read 100000 rows from t2 in 12.44 seconds via jdbc:oracle:oci:@odb.
run #4: read 100000 rows from t2 in 12.787 seconds via jdbc:oracle:oci:@odb.
run #5: read 100000 rows from t2 in 12.727 seconds via jdbc:oracle:oci:@odb.

run #1: read 100000 rows from t3 in 12.402 seconds via jdbc:oracle:oci:@odb.
run #2: read 100000 rows from t3 in 12.479 seconds via jdbc:oracle:oci:@odb.
run #3: read 100000 rows from t3 in 12.483 seconds via jdbc:oracle:oci:@odb.
run #4: read 100000 rows from t3 in 12.346 seconds via jdbc:oracle:oci:@odb.
run #5: read 100000 rows from t3 in 12.528 seconds via jdbc:oracle:oci:@odb.

run #1: read 100000 rows from t4 in 11.452 seconds via jdbc:oracle:oci:@odb.
run #2: read 100000 rows from t4 in 10.945 seconds via jdbc:oracle:oci:@odb.
run #3: read 100000 rows from t4 in 11.597 seconds via jdbc:oracle:oci:@odb.
run #4: read 100000 rows from t4 in 11.295 seconds via jdbc:oracle:oci:@odb.
run #5: read 100000 rows from t4 in 11.746 seconds via jdbc:oracle:oci:@odb.

run #1: read 100000 rows from t1 in 10.508 seconds via jdbc:oracle:oci:@.
run #2: read 100000 rows from t1 in 10.662 seconds via jdbc:oracle:oci:@.
run #3: read 100000 rows from t1 in 10.105 seconds via jdbc:oracle:oci:@.
run #4: read 100000 rows from t1 in 10.44 seconds via jdbc:oracle:oci:@.
run #5: read 100000 rows from t1 in 10.415 seconds via jdbc:oracle:oci:@.

run #1: read 100000 rows from t2 in 10.29 seconds via jdbc:oracle:oci:@.
run #2: read 100000 rows from t2 in 10.15 seconds via jdbc:oracle:oci:@.
run #3: read 100000 rows from t2 in 10.266 seconds via jdbc:oracle:oci:@.
run #4: read 100000 rows from t2 in 10.351 seconds via jdbc:oracle:oci:@.
run #5: read 100000 rows from t2 in 10.259 seconds via jdbc:oracle:oci:@.

run #1: read 100000 rows from t3 in 9.95 seconds via jdbc:oracle:oci:@.
run #2: read 100000 rows from t3 in 9.756 seconds via jdbc:oracle:oci:@.
run #3: read 100000 rows from t3 in 10.325 seconds via jdbc:oracle:oci:@.
run #4: read 100000 rows from t3 in 9.517 seconds via jdbc:oracle:oci:@.
run #5: read 100000 rows from t3 in 9.951 seconds via jdbc:oracle:oci:@.

run #1: read 100000 rows from t4 in 9.182 seconds via jdbc:oracle:oci:@.
run #2: read 100000 rows from t4 in 8.996 seconds via jdbc:oracle:oci:@.
run #3: read 100000 rows from t4 in 8.977 seconds via jdbc:oracle:oci:@.
run #4: read 100000 rows from t4 in 9.024 seconds via jdbc:oracle:oci:@.
run #5: read 100000 rows from t4 in 9.082 seconds via jdbc:oracle:oci:@.

As in my previous post, I ignore the slowest and fastest run and take the average of the remaining three results per test variant to produce a chart.

We see that using the JDBC OCI driver delivers the fastest results when skipping Oracle Net. Furthermore, the MemOptimized RowStore delivers the fastest results via OCI. Accessing the MemOptimized RowStore via the JDBC thin driver leads by to a bad performance. This looks like a bug.

Conclusion

To get benefit from the MemOptimized RowStore you have to access the database via OCI.

The post MemOptimized RowStore in Oracle Database 18c with OCI appeared first on Philipp Salvisberg's Blog.