Performance issue when using Vormetric agent for encryption of database files (Doc ID 2098275.1)

Last updated on JUNE 21, 2017

Applies to:

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
Information in this document applies to any platform.
Specifically when using Vormetric agent for encryption of database files.

Symptoms

Oracle Database under heavy transaction load is unable to write log files quickly enough, and as a result performance suffers noticeably. Symptoms present in either or both of the following ways.

1) Most common symptom: Increasing wait times for redo log switches and archive process writes. This is visible both through an increase in "Log file switch (archiving needed) (%)" wait times…

Note:
The "Log file switch (archiving needed) (%)" wait event indicates that the system is waiting for a log switch because the log being switched into has not been archived yet. In other words, the archiver cannot archive the logs in a timely fashion. It could be due to the following:

…and in the alert log as a hanging archive process that, in extreme cases, causes instance failure:

Incomplete read from log member '+REDO/ORAC_Redo1_.log'. Trying next member.
ARCH: All Archive destinations made inactive due to error 333
ARCH: Closing local archive destination LOG_ARCHIVE_DEST_1: '+ARCH/archiveORCL_ARCH_3478987.dbf' (error 333) (ORCL)
Committing creation of archivelog '+ARCH/1_3541_854889367.dbf' (error 333)
Errors in file /oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_23498.trc:
ORA-16038: log 1 sequence# 3541 cannot be archived
ORA-00333: redo log read error block count
ORA-00312: online log 1 thread 1: '+REDO/ORCL_Redo1_.log'
USER (ospid: 27798): terminating the instance due to error 16038

2) Also commonly seen, but typically masked by high "Log file switch (archiving needed) (%)" wait events, is increasing memory consumption. In cases where the number of archive processes is very high, so that there is significant throughput capability for the archive processes, the symptoms will present as steadily increasing memory consumption by archive processes. This can be seen by checking the memory used by the archivers:

For example:
> ps aux | awk '{print $2, $4, $11}' | sort -k2r | head -n 10
PID %MEM COMMAND
17367 4.2 ora_arc0_orclh2
17390 4.1 ora_arc3_orclh2
17384 4.0 ora_arc2_orclh2

## And a little while later, you will see the memory consumption increase
> ps aux | awk '{print $2, $4, $11}' | sort -k2r | head -n 10
PID %MEM COMMAND
17390 8.2 ora_arc3_orclh2
17384 10.0 ora_arc2_orclh2
17367 10.0 ora_arc0_orclh2

## And a little while after that, you will see the memory consumption increase further
> ps aux | awk '{print $2, $4, $11}' | sort -k2r | head -n 10
PID %MEM COMMAND
17390 12.3 ora_arc3_orclh2
17384 14.6 ora_arc2_orclh2
17367 13.9 ora_arc0_orclh2

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms