Additional data purging needed; e.g. RHQ_CONFIG_UPDATE
Thomas Segismont
tsegismo at redhat.com
Mon Sep 29 16:26:36 UTC 2014
Hi,
I agree, we need more sub-tasks in the purge job.
In the past, when adding such tasks (operations history purge), we made
them disabled by default with a configurable cut-off date. To me, it
still sounds like the way to go.
Le 23/09/2014 20:11, Elias Ross a écrit :
> Bug 1131726 - Data from RHQ_CONFIG_UPDATE never purged
> https://bugzilla.redhat.com/show_bug.cgi?id=1131726
>
OK
> I saw data from 2012 in here. Not deleting data means more often
> running into issues like this: Bug 1131724 - Full table scan of
> RHQ_CONFIG_UPDATE in delete for RHQ_CONFIG
>
Can you elaborate on the symptoms? A full scan of a table is not a
problem per se. What do you see? Timeouts?
> Also Bug 1145776 - RHQ_PARTITION_EVENT/DETAILS
> https://bugzilla.redhat.com/show_bug.cgi?id=1145776
>
> I have 3 million rows here. Not sure what good the data is.
OK
>
> Also RHQ_RESOURCE_ERROR
> Bug 1145778 - Purge RHQ_RESOURCE_ERROR table as well
> https://bugzilla.redhat.com/show_bug.cgi?id=1145778
>
OK
> Not that many but the data is not deleted by RHQ and more data leads to this:
> Bug 1139433 - Deadlock in deletion of RHQ_RESOURCE_ERROR, possibly in
> resource upgrade
> https://bugzilla.redhat.com/show_bug.cgi?id=1139433
I believe this is the method responsible for the delete statement:
ResourceManagerBean#clearResourceConfigErrorByType
Can you elaborate on the symptoms for this one as well? In the BZ
description you say "there is a possibility of deadlock". Did Oracle
fail any execution of these requests with ORA-00060?
>
> I would add these to core but the problem is I don't really want to do
> the UI work for them because most users don't really need to configure
> each setting individually for 3-4 tables. Can we just use the settings
> for another option?
I'm not sure yet. Maybe a new "Advanced database purge settings" section
would make sense.
Regards,
Thomas
More information about the rhq-devel
mailing list