This content has been marked as final. Show 5 replies
5th bug I've found this week. Archive metrics don't work if LOG_ARCHIVE_DEST_n set to USE_DB_RECOVERY_FILE_DEST (FRA). Bug has been around for over 6 years and oracle appears unable to resolve.
Can you please mention the bug number?
The Archive Area metric isn't applicable if an FRA is in use. Instead use the Recovery Area Free Space (%) metric. This is a server-generated alert (i.e. the database monitors the condition and raises an alert).
You can refer to the doc for more details:
Here's the description for Recovery Area Free Space (%) from the doc:
"This is a database-level metric that is evaluated by the server every 15 minutes or during a file creation, whichever occurs first. The metric is also printed in the alert log. For cluster databases, this metric is monitored at the cluster database target level and not by member instances. The Critical Threshold is set for < 3% and the Warning Threshold is set for < 15%. You cannot customize these thresholds. An alert is returned the first time the alert occurs, and the alert is not cleared until the available space rises above 15%"
Hi Ana - I was actually aware of the FRA monitor already but wanted to use my own thresholds, seems ridiculous that this is not configurable which is why I was exploring the archive area metric (which is configurable, but doesn't work well). For FRA in production we want to be very conservative, warning occurs at 70%, critical at 85%, as we cannot afford having an errant process generate a mass of archive logs and bring down the system. I ended up going with metric extensions which, surprisingly, actually work well.
The bug in question is 5962743 - basically the archive metric skips archive areas that are set with USE_DB_RECOVERY_FILE_DEST - option is to explicitly specify the archive path which we are not interested in doing, and as oracle nominally supports USE_DB_RECOVERY_FILE_DEST it is obviously a problem with the software if the metric ignores this location. Note taht the bug was registered in 2007. Fairly confident that Oracle will fix it within the next decade, keeping my fingers crossed.
As noted, located the bug involved - developed custom metric to handle this situation