Disabling metric during backups
From: Herring, David <"Herring,>
Date: Tue, 17 Dec 2019 23:36:23 +0000
Message-ID: <CH2PR02MB6664D7D533E97B355D4C95E5D4500_at_CH2PR02MB6664.namprd02.prod.outlook.com>
Anyone run into a situation where they modify a metric threshold dynamically based on when certain jobs run? We're running OEM 13cR3 and have a 4-node RAC (11gR2) on Exadata in a DG configuration. We feel that a transport gap of 3600 is enough to raise a warning but frequently during RMAN backups on the primary that threshold is surpassed, sometimes beyond the critical threshold (7200).
Date: Tue, 17 Dec 2019 23:36:23 +0000
Message-ID: <CH2PR02MB6664D7D533E97B355D4C95E5D4500_at_CH2PR02MB6664.namprd02.prod.outlook.com>
Anyone run into a situation where they modify a metric threshold dynamically based on when certain jobs run? We're running OEM 13cR3 and have a 4-node RAC (11gR2) on Exadata in a DG configuration. We feel that a transport gap of 3600 is enough to raise a warning but frequently during RMAN backups on the primary that threshold is surpassed, sometimes beyond the critical threshold (7200).
I know I could just look for whatever the max transport gap is during backups and reset the thresholds beyond that value but that doesn't seem right. The only other option I've found so far is to have something running regularly on the server housing the OMS and look for any backup jobs that are active. When found, run a "emcli modify_threshold" for transport gap and associated target to be a large value. Also have logic in this step to if the threshold is set at the "high" value and no backup is active, in which case it should be reset to the original value. That seems like a huge hack but I can't figure out any other way to avoid use getting alerts about a transport gap during backups.
Thoughts? Thx.
Regards,
Dave
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Dec 18 2019 - 00:36:23 CET