- August 29, 2017 at 5:04 pm #10995ggoodrichKeymaster
Disk space in the $HVR_CONFIG directory is used for several purposes
On the hub-machine:
- Storage of hvr logfiles (growing, but managed by hvrmaint)
- Temporary storage of transaction files.
- The capture job reads all the changes, compresses them and sends them to the hub-machine
- These files are immediately picked up by the integrate job and deleted when the changes are applied to the target database.
So normally there is 0 or 1 files (per channel). However when the integrate job is stopped (crashed or suspended), these files are starting to pile up. The growth of disk-space can be estimated: as the amount of Ingres journal / Oracle archive files that are generated (in a day) times the HVR compression ratio (typically 90 % or higher, but use 80 % to be safe). After a couple of days you will decide to use HVR Load / Refresh to reinitialize the channel, instead of using the transaction files to process all the changes. So storage for a couple of days would suffice.
On the capture / integrate machine:
Spilling of big transactions that can not be held in memory, e.g. used with long data types (CLOB etc) or a single transaction that updates 1 million rows.
Estimated: size of the/your biggest transaction * HVR compression ratio
During row-wise refresh / compare: for sorting tables.
Estimated: 3 * (size of largest table) * (parallelism in compare or refresh)
Since HVR 4.6.2, temp files for cases 1, 3, 4 & 5 are compressed unless $HVR_TMP_COMPRESS_LEVEL=0 is set. Before HVR 4.6.2 files for case 2 (sorting during row-wise) are only compressed if HVR_SORT_COMPRESS=1 is set. Since 4.6.2 files for case 2 are compressed unless $HVR_SORT_COMPRESS_LEVEL=0 is set. So for versions more recent than HVR 4.6.2 the estimate should
Estimated: 3 * (size of largest table) * (parallelism in compare or refresh) * (HVR compression ratio)
- The forum ‘Expert Notes’ is closed to new topics and replies.