5 Replies Latest reply on Dec 5, 2013 8:12 PM by TSharma-Oracle

    OEM 10g - Corrective Action for directory size


      Hi, we currently have an rman job to backup archivelogs tied to the "Archive Area Used (%)" metric. However, this metric checks the entire disk's usage. We have some databases that all share the same disk for archive logs; however, they have different sub-directories. Using this metric, if the disk reaches the threshold, the corrective action rman job kicks off for all of the databases at the same time, creating a performance hit. Is it possible to set up a metric that would compare the size of a single directory (for one database) to the capacity of the disk, and if the ratio hits a certain threshold, then rman kicks off for just that one database?

        • 1. Re: OEM 10g - Corrective Action for directory size

          Are you using Monitoring templates? I believe if you set the metric setting just for that database, your RMAN will be kicked just for that particular database. We have the same scenario but it never kicks for all the databases. Make sure you are setting the metric for that particular database.


          OR you can write a shell or batch script in which you are connecting to particular instance and kicking the RMAN job for that particular instance. You can use this script in your corrective actions. I hope it make sense.


          like in shell script,

          rman user@instance

          backup; <whatever you want to do>


          • 2. Re: OEM 10g - Corrective Action for directory size
            Courtney Llamas-Oracle

            In 10g this would probably be best accomplished by monitoring the host filesystem metric, you can specify each directory as an individual object and I think associate a CA with each of them (though it's been a while since i've been on 10g so I'm not certain!)  Another option would be to build a throttle into your script... so check to see if it's running and if there's more than 2 executions, sleep for X minutes, etc...

            • 3. Re: OEM 10g - Corrective Action for directory size

              We have the metric set for each database. Here is our current setup (using fake names/directories/sizes):



              Mount point:   /abc/archive/


              Directories for 4 databases on that mount point:






              As any of those 4 directories fill up, /abc/archive fills up.

              In OEM, we set the "Archive Area Used (%)" metric to kick off rman when the archive area reaches some threshold (we'll say 65% for example).


              So if DB1 fills up its archive area to 65%, that means /abc/archive is at 65%. Since DB2/DB3/DB4 have their directories on that same disk, they will mistakenly kick off rman too since OEM will see their archive areas as being at 65% too since it's all one mount point.



              So what I would like to do is find some way where OEM can detect that /abc/archive/DB1 is at 130GB full, and /abc/archive has a capacity of 200GB, so /abc/archive/DB1 is responsible for filling 65% of the disk on its own, so only DB1 kicks off rman, and DB2/3/4 do not.

              • 4. Re: OEM 10g - Corrective Action for directory size

                I'm looking to do the equivalent of a unix du command divided by the output of a df command, and run rman based on which directory's du output is the one that broke the threshold.

                • 5. Re: OEM 10g - Corrective Action for directory size

                  I see what you are saying now. i can give you an idea


                  Login to Grid

                  Go to Targets -> Hosts

                  Click on "User defined Metrics" in the related links

                  Hit "Create"

                  You can write a command for a particular directory or create a shell script like du -skh /directory ( you do nto have to do any calculations here eg du/df). Just simply get the output of du -skh /directory


                  Now you know the total size of your mount point, you can now set the threshold for this user defined metric.


                  and Now you can back to corrective actions of this metric and run RMAN once it reaches threshold.