How long does it take to encrypt a database?

A request came from a customer to estimate how long it would take to encrypt a database with cvencrypt utility.

This question is a little bit like how long is a piece of string — it depends. But its an interesting question. The answer primarily depends on the performance of CPU and storage on the target platform the customer is using, so the answer is more about coming up with a simple methodology that can be used to benchmark the CPU and storage while running cvencrypt.


  1. Copy a large and representative CACHE.DAT file to target storage
  2. Create a keyfile via System Management Portal (includes a key)
  3. Run the cvencrypt over your sample CACHE.DAT file (as below)

The following shows the process once the test file is in place:

# ccontrol all
Instance Name     Version ID        Port   Directory
----------------  ----------------  -----  --------------------------------
up >H20162            2016.2.1.803.0    56772  /hs/h20162

# ls -l
total 54967296
-rw-r--r-- 1 root root 56286511104 Oct 27 10:31 CACHE.DAT

# date; /hs/h20162/bin/cvencrypt -dbfile CACHE.DAT -outkeyfile /hs/h20162/mgr/syd_enc_key -outuser xxx -outpass xxx; date


Fri Oct 27 10:36:53 AEDT 2017

Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2016.2.1 (Build 803) Wed Oct 26 2016 12:30:49 EDT
Stand-alone encryption utility for Cache databases and journal files

Database has 6870912 blocks.
6870912 blocks (done!)
Fri Oct 27 10:43:25 AEDT 2017

So we can see from above that:

Bytes/sec =
56,286,511,104 bytes /392 seconds = 156,351,420 bytes/sec = 156 MB/sec

This test is on our lab system in Sydney. But remember; your milage will vary and you will have to test on your own systems. I have included details of the set up I used at the end of the post.

Running multiple encryptions in parallel

During a conversion downtime must be kept to a minimum, so I was interested whether running multiple cvencrypt processes in parallel was scalable. It is. Up to the IO limits of the storage and CPU you can run multiple cvencrypt processes in parallel. So with careful planning you should be able to play Tetris and encrypt multiple databases in the shortest time.

The following chart shows a nice scaling (not quite linear) as multiple processes are running in parallel.

Script to test in parallel

This is how I ran the parallel tests. Set up multiple CACHE.DAT files in subdirectories — I used copies of the same file, but you will want to test on a copy of your database.

For the test I laid the files out in a simple tree:

# ls -l *
-rw-r--r-- 1 root root 56286511104 Oct 26 21:57 CACHE.DAT
-rwxr-xr-x 1 root root         189 Oct 26 22:29
-rw-r--r-- 1 root root         241 Oct 26 19:56 syd_enc_key

total 54967296
-rw-r--r-- 1 root root 56286511104 Oct 26 22:33 CACHE.DAT

total 54967296
-rw-r--r-- 1 root root 56286511104 Oct 26 22:46 CACHE.DAT

total 54967296
-rw-r--r-- 1 root root 56286511104 Oct 26 22:54 CACHE.DAT

The simple script runs the cvencrypt:

# cat ./

echo "Start " ${1} " "  `date`
/hs/h20162/bin/cvencrypt -dbfile ./db${1}/CACHE.DAT -outkeyfile ./syd_enc_key -outuser xxx -outpass xxx
echo "End " ${1} " " `date`

Iterate over the subdirectories:

# for i in 1 2 3; do ( ./ $i & ) ; done

Test system configuration

Red Hat 7.4, using xfs disk on LVM2. On VMWare 6.5.

Dell PowerEdge R730 Servers
- 2 x Intel Xeon E5-2680 v3 2.5GHz,30M Cache,9.60GT/s QPI,Turbo,HT,12C/24T (120W)

Dell PowerVault MD3420 Storage
- 24 x 960GB Solid State Drive SAS Read Intensive MLC 12Gbps 2.5in Hot-plug Drives
- Dual 8GB Cache Controller (Each controller contains 8GB of cache for a total of 16GB of cache which is mirrored with the other controller’s cache for high availability. )
- One 24-disk RAID6 disk group.