Failed to pass checking accessibility by :
Login to EM > Setup > Provisioning and Patching > Software Library
Click to highlight the row > Actions(drop-down) > Check Accessibility
Solution
Make sure OMS host preferred credential is setup correctly.
Failed to pass checking accessibility by :
Login to EM > Setup > Provisioning and Patching > Software Library
Click to highlight the row > Actions(drop-down) > Check Accessibility
Make sure OMS host preferred credential is setup correctly.
Short Running Task Worker metric collection status is shown as Down from OMS and Repository monitoring :
From the Management Services and Repository target page, Navigate:
OMS and Repository > Monitoring > All Metrics > select Repository Operations Status
Following query running as sysman shows No Short Running task workers are running, which causes a backlog build up.
SQL> SELECT Decode(task_class_list, 0 , 'Short Running' , 1, 'Long Running ' , 'Unkown') Worker_type,
CASE
WHEN j.job_action IS NULL THEN 'No'
WHEN j.job_action IS NOT NULL THEN 'Yes'
END AS job_submitted,
j.state AS job_state,
w.job_id AS worker_id,
Decode(w.worker_status, 0,'Starting', 1, 'Started', 'Stop Pending') worker_status
FROM dba_scheduler_jobs j, MGMT_collection_workers w
WHERE j.job_action(+) = 'EM_TASK.WORKER(' || w.job_id || ');'
AND w.task_class_list IN ('0','1');
WORKER_TYPE JOB JOB_STATE WORKER_ID WORKER_STATU
------------- --- --------------- ---------- ------------
Long Running Yes SCHEDULED 6 Started
Long Running Yes SCHEDULED 7 Started
SQL> show user
USER is "SYSMAN"
SQL> exec mgmt_collection.set_worker_count(0,4);
PL/SQL procedure successfully completed.
SQL> exec mgmt_collection.start_workers();
PL/SQL procedure successfully completed.
SQL> SELECT Decode(task_class_list, 0 , 'Short Running' , 1, 'Long Running ' , 'Unkown') Worker_type,
CASE
WHEN j.job_action IS NULL THEN 'No'
WHEN j.job_action IS NOT NULL THEN 'Yes'
END AS job_submitted,
j.state AS job_state,
w.job_id AS worker_id,
Decode(w.worker_status, 0,'Starting', 1, 'Started', 'Stop Pending') worker_status
FROM dba_scheduler_jobs j, MGMT_collection_workers w
WHERE j.job_action(+) = 'EM_TASK.WORKER(' || w.job_id || ');'
AND w.task_class_list IN ('0','1');
WORKER_TYPE JOB JOB_STATE WORKER_ID WORKER_STATU
------------- --- --------------- ---------- ------------
Short Running Yes SCHEDULED 2 Started
Short Running Yes SCHEDULED 1 Started
Short Running Yes SCHEDULED 3 Started
Short Running Yes SCHEDULED 4 Started
Long Running Yes SCHEDULED 5 Started
Long Running Yes SCHEDULED 8 Started
6 rows selected.
OEM Scheduled Information Publisher Report failed everyday with the following errors:
"Unexpected error getting the HTTP response stream while generating report: java.net.ConnectException:Connection refused (Connection refused) Connection: https://emslb.domain:7799 URI:/em/onetime/reports/render?printablePage=true&reportID=0120G3D88D567B78E06324D1020A73D0&action=generate&scheduled=true"
Read more of this content when you subscribe today.
we do not have any method to manually move old restore logs to new location via OS commands. Please drop any old restore points & create new restore points so that +FRAOLD gets cleared & new logs start generating in +FRANEW.
For restore point only:
SQL> select GUARANTEE_FLASHBACK_DATABASE,NAME from v$restore_point; Drop Restore Point in primary database On primary database: SQL> drop RESTORE POINT restore_dg; Drop Restore Point in standby database Ensure the standby database is in mount state and drop If Active Data Guard is used, open read only the standby database after dropping the Guaranteed restore point. GUARANTEED RESTORE POINT : SQL> drop restore point restore_dg;
For database flashback on:
When we modify FRA location, we need to flashback off & on the database so that flashback logs start generating in new location. When we flashback off & on, all the previously created restore points get void hence we need to drop them. We need to create a new restore point, this time as we have modified the FRA location, new flashback restore point logs start getting generated in new location.
Modify the flashback destinations -> DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE SQL> alter system set db_recovery_file_dest='/+FRANEW' scope=both; SQL> alter system set db_recovery_file_dest_size=''; Drop restore point SQL> select GUARANTEE_FLASHBACK_DATABASE,NAME from v$restore_point; Drop Restore Point in primary database On primary database: SQL> drop RESTORE POINT restore_dg; Drop Restore Point in standby database Ensure the standby database is in mount state and drop If Active Data Guard is used, open read only the standby database after dropping the Guaranteed restore point. GUARANTEED RESTORE POINT : SQL> drop restore point restore_dg; Turn off and turn on flashback : Since the Oracle DB version is 11g, we can perform the below activity with out downtime. SQL> ALTER DATABASE FLASHBACK OFF; SQL> ALTER DATABASE FLASHBACK ON;
Please do not run any OS command to remove flashback logs from +FRAOLD manually.