VVCALLLOG is growing and not recovering deleted space

[rdeardorff@spi-ind.com]

We are having an issue with the VVCALLLOG file growing. I have the configurations for the logs to keep data for 3 days, and that is all the data that is in there. yesterday I ran a rgzpfm on that file and the size went from 21 GB to 2.4...so there is a lot of unusable space in that file.

this morning it has grown to 8.5 gb...i just ran a rgzpfm again and now the size did not change...

vvcalllog is one of the largest files on my system,...yesterday at 21 gp, it was the 3rd largest overall

suggestions?

[robert.swanson]

The VVCALLLOG file is distributed with REUSEDLT(*YES), but even so there's no guarantee the deleted records will be reused within any certain timeframe, especially on a file like that which has a very high insert rate.

Your first RGZPFM had a big impact because the file had accumulated a large number of deleted rows. The second RGZPFM likely had no impact because new inserts of the current day’s call-log data expanded the file again, so there were few (or zero) deleted rows, hence nothing to reclaim.

It might be advisable to run a periodic RGZPFM on that file if there's a point during the day or week when there is little activity in that instance.

That said, one of the fields in VVCALLLOG incudes the entire back-end response to the front-end, up to the first 32K of data. Multiple records of this can add up quickly, particularly when you have many users executing apps with large grid loads. So one easy way to greatly reduce the size growth of VVCALLLOG is to omit JSON response data going into that file altogether. This is configured in Portal Admin > Log Settings by unchecking the "Log all data sent to browser" box.
?
?