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