Re: How to purge metric values from dropped metric extension in EM13c?

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Mon, 29 Oct 2018 10:52:31 -0500
Message-ID: <CAP79kiQaQQMduiiOahUCRJcOOB9VOPegyz073nwnzaOuh7NP_Q_at_mail.gmail.com>



Well, depending on the version of the repository db, I guess you could delete the 27m and then run a shrink space on the table?

Of course, searching for that table in Metalink returns 0 rows so no maintenance notes available :/

Chris

On Mon, Oct 29, 2018 at 10:35 AM Rich J <rjoralist3_at_society.servebeer.com> wrote:

> On 2018/10/29 09:43, Chris Taylor wrote:
>
> Have you looked at the SYSMAN MGMT_METRICS tables.
>
> There's a METRIC_GUID (but perhaps it got removed as well?). I would
> think you'd be able to manually do either:
>
> 1. Delete the mgmt collected metrics from the SYSMAN schema in the
> repository
> 2. Save the metrics you want to keep to a temp table, truncate the metrics
> table(s) and reinsert the saved values
>
> OEM would need to be down while you did that though. Purging data
> manually from the SYSMAN tables is pretty straight forward once you have
> the METRIC_GUID and find all the child tables that also have that GUID.
>
>
> Hey Chris,
>
> I have looked and it's gone, which is exactly what I would expect from
> dropping the ME. However, in troubleshooting performance in getting these
> metric values out of EM, I do have the ME's Metric Group ID. I can grab
> all 27M+ of the metric values using:
>
> SELECT
> k.*
> FROM
> sysman.em_metric_items_e i,
> sysman.em_metric_string_latest_e v,
> sysman.em_metric_keys_e k
> WHERE
> i.metric_item_id = v.metric_item_id
> AND i.metric_key_id = k.metric_key_id
> AND i.metric_group_id = 7541;
>
> While I'm sure I could come up with a fun way to drop all of those
> manually via SQL, I'd much prefer a supported method. There's a lot to
> consider, like after deleting the ~27M rows (1M less than I thought before)
> from EM_METRIC_STRING_LATEST_E, there'll be only 5K rows left. And around
> 8K rows left from EM_METRIC_ITEMS_E. If this was any "normal" data system,
> I'd be rebuilding those tables instead of deleting the rows. And since I
> don't have a comprehensive list of what tables would need to be rebuilt,
> I'm much less comfortable doing that.
>
> Thanks!
> Rich
>

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Oct 29 2018 - 16:52:31 CET

Original text of this message