Overhead of SQLNet encryption on RMAN duplicate

Introduction

The table below shows the measured elapsed times in seconds when duplicating a 1GB data file with various encryption algorithms on Oracle 12.1 and 11.2 databases:

Although depending on the CPU, IO and network speed you might get different results on your system the following general conclusions can be made by looking at the durations above:

• The AES algorithm is much more efficient than DES.
• The efficiency of the AES algorithm has been significantly improved in 12c.
• Curiously, no difference in performance was observed between AES128 and AES256 in 12c.

Who does the work (12c)?

I sampled v$session on both auxiliary and target database to get the initial insight into the mechanics of rman duplicate. It became obvious that the session doing the work on the auxiliary instance is created as soon as the auxiliary channel gets allocated and remains connected until the duplicate is completed. The process ID of this session can easily be identifed by the means of v$session.client_info which contains the name of the auxiliary channel:

select p.spid from v$session s,v$process p 
  where s.paddr=p.addr and s.username='SYSBACKUP' 
    and s.client_info='rman channel=ORA_AUX_DISK​_1' ;
P.SPID
22052

In contrast, a separate session is created on the target database for each database file. The sessions log out when the file restore on the auxiliary instance completes. It was not immediately obvious which process connects to the target database. Therefore, I queried the v$session.port for the newly created session and correlated it with the output of the netstat -un -P tcp command on the auxiliary server which shows the open TCP connections for all the processes (I edited out the irrelevant columns and rows in the outputs below):

Local Address  Remote Address User   Pid   Command  State
-------------- -------------- -----  ----  -------- ------- 
x.x.x.x.59066  y.y.y.y.1527   oracle 22052 oracle   ESTABLISHED

Note: 1527 is the port of the listener on the target database.

On the target database:

select sid,port from v$session where username='SYSBACKUP' ;
SID PORT
231 59066

Using the information above it can be deduced that the dedicated process of the rman auxiliary channel session is the one which makes connections to the target database. The following graphic visualizes these findings:

Hence, the dedicated process on the auxiliary database has two roles. One is the dedicated process for the working session on the auxiliary database. The other is the client process of the dedicated process of the working session on the target database.

There hasn’t been any CPU activity instrumented on either the auxiliary or the target database for the working sessions (the “CPU used by this session statistics” from v$sesstat was only 1 during all measurements). Therefore, I wrote a small dtrace script which collects the time spent on the CPU for all dedicated processes of the non-local sessions (the non-local sessions are filtered by setting the predicate execname==”tnslsnr”):

proc:::start
/execname == "tnslsnr"/
{
  self->start = vtimestamp;
}

proc:::exit
/self->start/
{
  printf("Process %d spent %d seconds on CPU\n",pid,(vtimestamp - self->start)/1000000000 );
  self->start = 0;
}

After obtaining the CPU time for all the remote sessions on the server, I correlated v$process.spid with the OS pid in the output of the dtrace script to get the cpu times for the dedicated processes involved in the duplicate processing. No surprise there – it turned out that the whole overhead of encryption can be attributed to the cpu time of the dedicated processes on both the auxiliary and the target database.

The following wait events has fully matched the CPU time on the opposite side:

• target database: SQL*Net more data to client
• auxiliary database: remote db file read

11g

As I explained in the last section, in 12c the dedicated process on the auxiliary database connects to the target database to pull the datafiles. Applying the same testing methodology on 11g, I found out that the 11g databases behave differently: the dedicated process of the session which is created when the channel is allocated on the target database connects to the auxiliary database and pushes the files. The following picture shows the rman duplicate from active mechanics on a 11g database:

As a consequence, you might observe different elapsed times after upgrading the database if the sqlnet encryption is configured differently for the target and auxiliary database. In 12c namely, the configuration of the target database decides which algorithm will be used, in 11g is the other way around – the encryption is defined by the configuration of the auxiliary database.