Little Grid Control Issues
Dec 3, 2008 / By Marcelo Lopes
Sometimes you find yourself facing some little problem. You don’t believe it’s a bug or software deficiency, and you spend some time trying to find out what is the silly thing you’ve missed. Here are a handful of issues in Grid Control that cause this sort of little problem.
The overall status of a multi-task job is shown as succeeded even though some of the steps within the job have failed.
This is expected behavior. The various tasks (such as T1, T2, T3) of the multi-task job are part of a serial step-set. The status of a serial step-set is considered to have succeeded if the last step has succeeded. This happens if the “Condition” and “Depends On” are not used while creating the task.
To avoid this default behavior use “Condition” and “Depends On” while creating the task.
When a Task’s name has more than 30 characters, editing a multi-task job fails with the following error:
This is due to unpublished bug 5620581 MULTITASK JOB: ERROR WHEN TASK NAME IS MORE THAN 30 CHARACTERS.
The workaround is to create multi-task jobs with task names no longer than 30 characters, or use Grid control 10.2.0.4.0, which allows tasks names of more that 30 characters.
It is NOT possible to create a multi-task job with a task name containing a quote mark. For example, task name “test’Task1″ will fail with the error message:
ORA-06550: line 65, column 60: PLS-00103: nbsp;Encountered the symbol "TEST" when expecting one of the following: . ( * @ % & = - + ; at in is mod remainder not rem or != or ~= >= <= and or like between || member SUBMULTISET_
This is due to unpublished bug 5682051 EMGC10203TC11:FAIL TO CREATE MULTI-TASK JOB IF THE TASK NAME CONTAIN QUOTE MARKS
The workaround is to not use quote marks while giving the task name.
Consider a multi-task job that has three tasks and an error handler, such as follows:
Task1 : OSCommand on target 1
Task2 : on success Of Task1 on target 2
Task3 : on success Of Task1 on target 3
ER : Errorhandler task on target 4
So this job involves four targets. For a job run, the job activity page shows the number of targets as 3. On visiting the job run page for that completed execution, it mentions that the execution ran on 4 targets.
This is due to internal Bug 6495091 Abstract: TARGET COUNT DIFFERS BETW JOB ACTIVITY AND JOB RUN PAGES FOR MULTI-TASK JOB
If you get this behavior, open an SR with Oracle Support to get the fix. As a workaround, the number of targets should be checked from the job execution page.
When checking the nested/multi-step jobs from the tasks page in job results, sub-steps are not shown in sorted order.
All the steps are shown, but some of the steps within a step-set may be out of order. This occurs intermittently, and only if the repository database is in RAC.
This is due to unpublished bug 4637789 EXECUTION DETAILS PAGE DOES NOT ALWAYS SHOW STEPS SORTED BY TIME.
This issue occurs in the 10.2.0.4.0 release. The bug will be fixed in the 11G version of Grid Control. It affects only the task page; steps can be correctly viewed from the executions page.
For this one, the patch’s name speaks for itself:
6528787 REPEATING DAILY JOB NOT RE-SCHEDULED AT THE APPROPRIATE TIME to the OMS
For this, you need to apply patch 6528787. Go to metalink-> Patches & Updates; option -> simple search and add this patch number. Download it and apply following the readme file instructions.
Leave a Reply