Compression and Performance

Compression of archive, archive index, and extract files trades performance for storage savings. If you have enough storage space, consider turning off compression for higher performance.

Compression is turned on by default. Optim provides two types of compression models:
Inline Compression
Data is compressed as it is extracted and before it is written to the file. Inline compression has lower I/O, when compared with post compression, but uses database resources for the duration of the extract service. Inline Compression requires less storage resources during the extract process when compared to post compression.
Post Compression
Data is extracted and written to an uncompressed file. In a second step, Optim™ reads the uncompressed file, and writes a compressed version of the file. The benefit of post compression is that database connections are closed earlier with post compression than with inline compression. However, with post compression the total elapsed time is increased because the uncompressed file must be closed, read, and then a new compressed version created. Sites having concerns about database resource contention may find post compression useful as it shortens the time database resources are needed. However, post compression increases the elapsed time and storage requirements for processing the extract service. Although increased storage is necessary during the compression operation, the temporary storage required is released when the compression is completed.

Compression is set in the archive request or the extract request.

If you have enough storage space, use post compression or turn off compression. If you must use compression, ensure that you have multiple processors on the machine where Optim is running. The use of compression decreases performance. will degrade the performance and if you have a limited batch window, you should establish baselines for archive/extract jobs



Feedback