Vice Admiral
Vice Admiral
747 views

probe db increases its size 2018.11 due to posgres_db table 'ddm_discovery_results'

Jump to solution

Hi there

We face an issue with increasing disk size of probe since upgrade from 10.33 to 2018.11.

The posgres-db grows very fast in size. After some days it required additonal 50GB of disk storage.

The main problem seems to be in table 'ddm_discovery_results' and in the logs we have entries with job_id tha si null... The problem occures on all 4 environments at the customer (DEV,TEST,UAT,PROD) which seems to be a bug in the product.

Support seems not know of anything.. Has anyone else had similar issues?
My current workaround is to "stop service, clearProbe.bat, start service" but this is not acceptable in production..

Hope you have any idea! Many thanks for your replies in advance!

Thomas

0 Likes
1 Solution

Accepted Solutions
Commander Commander
Commander

@ThomasLanz 

I suspect the table is actually the ddm_discovery_touch_results_queue table. This is a known issue after the upgrade and changing the table to allow null jobid. Since there was a change to allow nulls in the jobid column the old process to clean out this table has the wrong syntax (postgresql.log) for postgresql. My case on this issue is SD02438129 and a hotfix was provided by QCCR1H126095 which I've tested and installed in production.

If this is left unpatched the table could grow to a size that starts causing the touch process to fail from that probe. That is actually how we were alerted to this issue. Our table had grown to over 335 million rows and was taking up over 49gb of storage. It seems to be on certain integrations as we didn't see this null jobids on most other probes.

As a quick, temporary, fix you could delete the rows on the probe database:   
delete from ddm_discovery_touch_results_queue where jobid IS NULL

Virgil

 

View solution in original post

4 Replies
Micro Focus Expert
Micro Focus Expert

Hello Thomas,

 

do you have an antivirus which scans the pgsql directory?

Did you try to run the autovacuum procedure for the probe DB.

Both are documented.



Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success
0 Likes
Commander Commander
Commander

@ThomasLanz 

I suspect the table is actually the ddm_discovery_touch_results_queue table. This is a known issue after the upgrade and changing the table to allow null jobid. Since there was a change to allow nulls in the jobid column the old process to clean out this table has the wrong syntax (postgresql.log) for postgresql. My case on this issue is SD02438129 and a hotfix was provided by QCCR1H126095 which I've tested and installed in production.

If this is left unpatched the table could grow to a size that starts causing the touch process to fail from that probe. That is actually how we were alerted to this issue. Our table had grown to over 335 million rows and was taking up over 49gb of storage. It seems to be on certain integrations as we didn't see this null jobids on most other probes.

As a quick, temporary, fix you could delete the rows on the probe database:   
delete from ddm_discovery_touch_results_queue where jobid IS NULL

Virgil

 

View solution in original post

Micro Focus Expert
Micro Focus Expert

Virgil is right.

You can open a Support case and ask for the patch QCCR1H126095 or manually clean the DB tables when jobID is null as Virgil explained. The second option will be faster.



Kind regards,
Bogdan Mureșan
EMEA CMS Technical Success
Vice Admiral
Vice Admiral

Thanks guys. I will let my support_engineer know of that hotfix. Anyway, I need to know with which official release version the issue will be fixed..

Best regards,

Thomas

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.