EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
hi
Can i stop this package from running.If so does it any way affect the database ?
Josh
I remember asking something similar once;
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
What does "EXECUTE_EM_DBMS_JOB_PROCS" do??(10g)
Re: What does "EXECUTE_EM_DBMS_JOB_PROCS" do??(10g)
Adith
Similar Messages
-
Enable DBMS JOB EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS for DB Control
Hi all,
I'm getting the below warning message in enterprise manager home at one of the nodes of RAC.
The Availability calculations for the cluster database target are disabled. Please enable the DBMS JOB EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS for Database Control.*
What does this mean ? Any idea ?
Thanks in advance.
Dhaval.Hi there,
The reason I found for this warning was that EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS() was broken.
I fixed it by executing DBMS exec DBMS_JOB.RUN(<<job number>>);
where job number can be obtained from select job,broken,what,log_user,schema_user from dba_jobs;
Thanks for all your efforts.
Regards,
Dhaval. -
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); has broken.
Hi,
im getting below error in my database .. can you any one tell me tips or provide me usefull link ..
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); has broken.
Database :10.2.0 .4
OS :sunHi,
The EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS job performs all the necessary maintenance tasks for the database control repository. It seems that you need to recompile it by doing:
exec emd_maintenance.recompile_invalid_objects;
regards -
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); job status is failed
Hi all,
after I import dump fully database , the EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); job status is failed,
what is the reason and how could I start it successfully.
appreciate your help.user2075318 wrote:
Osama , thx for the updates,
but unfortunatly I don't have access to oracle support site,
it's grate if you can give me the 444033.1 document please.you need to have valid license to get oracle.support.com , otherwise i can't post anything here it will be illegal to do that -
Problem with EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS [ID 444033.1]
I would like to kill/remove this job because it uses up 100% of my cpu and I do not want OEM [Database control]
First problem is, after altering system job_queue_processes=0 then selecting from dba_jobs_running, it never stops running.
START SNIP ========================
SQL> conn sys/JjE8hM7P as sysdba;
Connected.
SQL> show parameter job_queue_processes
NAME TYPE VALUE
job_queue_processes integer 0
SQL> alter system set job_queue_processes=0;
System altered.
SQL> select * from dba_jobs_running;
SID JOB FAILURES LAST_DATE LAST_SEC
THIS_DATE THIS_SEC INSTANCE
18 1 0 13-AUG-10 23:59:54
14-AUG-10 00:00:55 0
17 3 0 13-AUG-10 23:59:54
14-AUG-10 00:00:55 0
END SNIP ========================
So I can call "select * from dba_jobs_running; " and it never appears to stop... so out of morbid curiosity I move onto the next step of the instructions:
SQL> exec emd_maintenance.remove_em_dbms_jobs;
BEGIN emd_maintenance.remove_em_dbms_jobs; END;
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'EMD_MAINTENANCE.REMOVE_EM_DBMS_JOBS' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
Frankly.. no idea what that even means :) If I try to load <ORACLE_HOME>\sysman\admin\emdrep\sql\core\latest\admin\
admin_remove_dbms_jobs.sql; I get even more errors. So I'll stop here for now.
Ideas?hi,
Add "sysman." before like
SQL> conn /as sysdba
Connected.
SQL> EXEC sysman.emd_maintenance.remove_em_dbms_jobs;
PL/SQL procedure successfully completed.thanks,
baskar.l -
Active session Spike on Oracle RAC 11G R2 on HP UX
Dear Experts,
We need urgent help please, as we are facing very low performance in production database.
We are having oracle 11G RAC on HP Unix environment. Following is the ADDM report. Kindly check and please help me to figure it out the issue and resolve it at earliest.
---------Instance 1---------------
ADDM Report for Task 'TASK_36650'
Analysis Period
AWR snapshot range from 11634 to 11636.
Time period starts at 21-JUL-13 07.00.03 PM
Time period ends at 21-JUL-13 09.00.49 PM
Analysis Target
Database 'MCMSDRAC' with DB ID 2894940361.
Database version 11.2.0.1.0.
ADDM performed an analysis of instance mcmsdrac1, numbered 1 and hosted at
mcmsdbl1.
Activity During the Analysis Period
Total database time was 38466 seconds.
The average number of active sessions was 5.31.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 CPU Usage 1.44 | 27.08 1
2 Interconnect Latency .07 | 1.33 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
Finding 1: CPU Usage
Impact is 1.44 active sessions, 27.08% of total activity.
Host CPU was a bottleneck and the instance was consuming 99% of the host CPU.
All wait times will be inflated by wait for CPU.
Host CPU consumption was 99%.
Recommendation 1: Host Configuration
Estimated benefit is 1.44 active sessions, 27.08% of total activity.
Action
Consider adding more CPUs to the host or adding instances serving the
database on other hosts.
Action
Session CPU consumption was throttled by the Oracle Resource Manager.
Consider revising the resource plan that was active during the analysis
period.
Finding 2: Interconnect Latency
Impact is .07 active sessions, 1.33% of total activity.
Higher than expected latency of the cluster interconnect was responsible for
significant database time on this instance.
The instance was consuming 110 kilo bits per second of interconnect bandwidth.
20% of this interconnect bandwidth was used for global cache messaging, 21%
for parallel query messaging and 7% for database lock management.
The average latency for 8K interconnect messages was 42153 microseconds.
The instance is using the private interconnect device "lan2" with IP address
172.16.200.71 and source "Oracle Cluster Repository".
The device "lan2" was used for 100% of interconnect traffic and experienced 0
send or receive errors during the analysis period.
Recommendation 1: Host Configuration
Estimated benefit is .07 active sessions, 1.33% of total activity.
Action
Investigate cause of high network interconnect latency between database
instances. Oracle's recommended solution is to use a high speed
dedicated network.
Action
Check the configuration of the cluster interconnect. Check OS setup like
adapter setting, firmware and driver release. Check that the OS's socket
receive buffers are large enough to store an entire multiblock read. The
value of parameter "db_file_multiblock_read_count" may be decreased as a
workaround.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional Information
Miscellaneous Information
Wait class "Application" was not consuming significant database time.
Wait class "Cluster" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Concurrency" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Wait class "User I/O" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
Hard parsing of SQL statements was not consuming significant database time.
The database's maintenance windows were active during 100% of the analysis
period.
----------------Instance 2 --------------------
ADDM Report for Task 'TASK_36652'
Analysis Period
AWR snapshot range from 11634 to 11636.
Time period starts at 21-JUL-13 07.00.03 PM
Time period ends at 21-JUL-13 09.00.49 PM
Analysis Target
Database 'MCMSDRAC' with DB ID 2894940361.
Database version 11.2.0.1.0.
ADDM performed an analysis of instance mcmsdrac2, numbered 2 and hosted at
mcmsdbl2.
Activity During the Analysis Period
Total database time was 2898 seconds.
The average number of active sessions was .4.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 Top SQL Statements .11 | 27.65 5
2 Interconnect Latency .1 | 24.15 1
3 Shared Pool Latches .09 | 22.42 1
4 PL/SQL Execution .06 | 14.39 2
5 Unusual "Other" Wait Event .03 | 8.73 4
6 Unusual "Other" Wait Event .03 | 6.42 3
7 Unusual "Other" Wait Event .03 | 6.29 6
8 Hard Parse .02 | 5.5 0
9 Soft Parse .02 | 3.86 2
10 Unusual "Other" Wait Event .01 | 3.75 4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
Finding 1: Top SQL Statements
Impact is .11 active sessions, 27.65% of total activity.
SQL statements consuming significant database time were found. These
statements offer a good opportunity for performance improvement.
Recommendation 1: SQL Tuning
Estimated benefit is .05 active sessions, 12.88% of total activity.
Action
Investigate the PL/SQL statement with SQL_ID "d1s02myktu19h" for
possible performance improvements. You can supplement the information
given here with an ASH report for this SQL_ID.
Related Object
SQL statement with SQL_ID d1s02myktu19h.
begin dbms_utility.validate(:1,:2,:3,:4); end;
Rationale
The SQL Tuning Advisor cannot operate on PL/SQL statements.
Rationale
Database time for this SQL was divided as follows: 13% for SQL
execution, 2% for parsing, 85% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "d1s02myktu19h" was executed 48 times and had
an average elapsed time of 7 seconds.
Rationale
Waiting for event "library cache pin" in wait class "Concurrency"
accounted for 70% of the database time spent in processing the SQL
statement with SQL_ID "d1s02myktu19h".
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"63wt8yna5umd6" are responsible for 100% of the database time spent on
the PL/SQL statement with SQL_ID "d1s02myktu19h".
Related Object
SQL statement with SQL_ID 63wt8yna5umd6.
begin DBMS_UTILITY.COMPILE_SCHEMA( 'TPAUSER', FALSE ); end;
Recommendation 2: SQL Tuning
Estimated benefit is .02 active sessions, 4.55% of total activity.
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"fk3bh3t41101x".
Related Object
SQL statement with SQL_ID fk3bh3t41101x.
SELECT MEM.MEMBER_CODE ,MEM.E_NAME,Pol.Policy_no
,pol.date_from,pol.date_to,POL.E_NAME,MEM.SEX,(SYSDATE-MEM.BIRTH_DATE
) AGE,POL.SCHEME_NO FROM TPAUSER.MEMBERS MEM,TPAUSER.POLICY POL WHERE
POL.QUOTATION_NO=MEM.QUOTATION_NO AND POL.BRANCH_CODE=MEM.BRANCH_CODE
and endt_no=(select max(endt_no) from tpauser.members mm where
mm.member_code=mem.member_code AND mm.QUOTATION_NO=MEM.QUOTATION_NO)
and member_code like '%' || nvl(:1,null) ||'%' ORDER BY MEMBER_CODE
Rationale
The SQL spent 92% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "fk3bh3t41101x" was executed 14 times and had
an average elapsed time of 4.9 seconds.
Rationale
At least one execution of the statement ran in parallel.
Recommendation 3: SQL Tuning
Estimated benefit is .02 active sessions, 3.79% of total activity.
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"7mhjbjg9ntqf5".
Related Object
SQL statement with SQL_ID 7mhjbjg9ntqf5.
SELECT SUM(CNT) FROM (SELECT COUNT(PROC_CODE) CNT FROM
TPAUSER.TORBINY_PROCEDURE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
:B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND PR_EFFECTIVE_DATE<=
:B2 AND PROC_CODE = :B1 UNION SELECT COUNT(MED_CODE) CNT FROM
TPAUSER.TORBINY_MEDICINE WHERE BRANCH_CODE = :B6 AND QUOTATION_NO =
:B5 AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND M_EFFECTIVE_DATE<= :B2
AND MED_CODE = :B1 UNION SELECT COUNT(LAB_CODE) CNT FROM
TPAUSER.TORBINY_LAB WHERE BRANCH_CODE = :B6 AND QUOTATION_NO = :B5
AND CLASS_NO = :B4 AND OPTION_NO = :B3 AND L_EFFECTIVE_DATE<= :B2 AND
LAB_CODE = :B1 )
Rationale
The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 0% for SQL execution,
0% for parsing, 100% for PL/SQL execution and 0% for Java execution.
Rationale
SQL statement with SQL_ID "7mhjbjg9ntqf5" was executed 31 times and had
an average elapsed time of 3.4 seconds.
Rationale
Top level calls to execute the SELECT statement with SQL_ID
"a11nzdnd91gsg" are responsible for 100% of the database time spent on
the SELECT statement with SQL_ID "7mhjbjg9ntqf5".
Related Object
SQL statement with SQL_ID a11nzdnd91gsg.
SELECT POLICY_NO,SCHEME_NO FROM TPAUSER.POLICY WHERE QUOTATION_NO
=:B1
Recommendation 4: SQL Tuning
Estimated benefit is .01 active sessions, 3.03% of total activity.
Action
Investigate the SELECT statement with SQL_ID "4uqs4jt7aca5s" for
possible performance improvements. You can supplement the information
given here with an ASH report for this SQL_ID.
Related Object
SQL statement with SQL_ID 4uqs4jt7aca5s.
SELECT DISTINCT USER_ID FROM GV$SESSION, USERS WHERE UPPER (USERNAME)
= UPPER (USER_ID) AND USERS.APPROVAL_CLAIM='VC' AND USER_ID=:B1
Rationale
The SQL spent only 0% of its database time on CPU, I/O and Cluster
waits. Therefore, the SQL Tuning Advisor is not applicable in this case.
Look at performance data for the SQL to find potential improvements.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "4uqs4jt7aca5s" was executed 261 times and had
an average elapsed time of 0.35 seconds.
Rationale
At least one execution of the statement ran in parallel.
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"91vt043t78460" are responsible for 100% of the database time spent on
the SELECT statement with SQL_ID "4uqs4jt7aca5s".
Related Object
SQL statement with SQL_ID 91vt043t78460.
begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
4); end;
Recommendation 5: SQL Tuning
Estimated benefit is .01 active sessions, 3.03% of total activity.
Action
Run SQL Tuning Advisor on the SELECT statement with SQL_ID
"7kt28fkc0yn5f".
Related Object
SQL statement with SQL_ID 7kt28fkc0yn5f.
SELECT COUNT(*) FROM TPAUSER.APPROVAL_MASTER WHERE APPROVAL_STATUS IS
NULL AND (UPPER(CODED) = UPPER(:B1 ) OR UPPER(PROCESSED_BY) =
UPPER(:B1 ))
Rationale
The SQL spent 100% of its database time on CPU, I/O and Cluster waits.
This part of database time may be improved by the SQL Tuning Advisor.
Rationale
Database time for this SQL was divided as follows: 100% for SQL
execution, 0% for parsing, 0% for PL/SQL execution and 0% for Java
execution.
Rationale
SQL statement with SQL_ID "7kt28fkc0yn5f" was executed 1034 times and
had an average elapsed time of 0.063 seconds.
Rationale
Top level calls to execute the PL/SQL statement with SQL_ID
"91vt043t78460" are responsible for 100% of the database time spent on
the SELECT statement with SQL_ID "7kt28fkc0yn5f".
Related Object
SQL statement with SQL_ID 91vt043t78460.
begin TPAUSER.RECEIVE_NEW_FAX_APRROVAL(:V00001,:V00002,:V00003,:V0000
4); end;
Finding 2: Interconnect Latency
Impact is .1 active sessions, 24.15% of total activity.
Higher than expected latency of the cluster interconnect was responsible for
significant database time on this instance.
The instance was consuming 128 kilo bits per second of interconnect bandwidth.
17% of this interconnect bandwidth was used for global cache messaging, 6% for
parallel query messaging and 8% for database lock management.
The average latency for 8K interconnect messages was 41863 microseconds.
The instance is using the private interconnect device "lan2" with IP address
172.16.200.72 and source "Oracle Cluster Repository".
The device "lan2" was used for 100% of interconnect traffic and experienced 0
send or receive errors during the analysis period.
Recommendation 1: Host Configuration
Estimated benefit is .1 active sessions, 24.15% of total activity.
Action
Investigate cause of high network interconnect latency between database
instances. Oracle's recommended solution is to use a high speed
dedicated network.
Action
Check the configuration of the cluster interconnect. Check OS setup like
adapter setting, firmware and driver release. Check that the OS's socket
receive buffers are large enough to store an entire multiblock read. The
value of parameter "db_file_multiblock_read_count" may be decreased as a
workaround.
Symptoms That Led to the Finding:
Inter-instance messaging was consuming significant database time on this
instance.
Impact is .06 active sessions, 14.23% of total activity.
Wait class "Cluster" was consuming significant database time.
Impact is .06 active sessions, 14.23% of total activity.
Finding 3: Shared Pool Latches
Impact is .09 active sessions, 22.42% of total activity.
Contention for latches related to the shared pool was consuming significant
database time.
Waits for "library cache lock" amounted to 5% of database time.
Waits for "library cache pin" amounted to 17% of database time.
Recommendation 1: Application Analysis
Estimated benefit is .09 active sessions, 22.42% of total activity.
Action
Investigate the cause for latch contention using the given blocking
sessions or modules.
Rationale
The session with ID 17 and serial number 15595 in instance number 1 was
the blocking session responsible for 34% of this recommendation's
benefit.
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is .1 active sessions, 24.96% of total activity.
Finding 4: PL/SQL Execution
Impact is .06 active sessions, 14.39% of total activity.
PL/SQL execution consumed significant database time.
Recommendation 1: SQL Tuning
Estimated benefit is .05 active sessions, 12.5% of total activity.
Action
Tune the entry point PL/SQL "SYS.DBMS_UTILITY.COMPILE_SCHEMA" of type
"PACKAGE" and ID 6019. Refer to the PL/SQL documentation for addition
information.
Rationale
318 seconds spent in executing PL/SQL "SYS.DBMS_UTILITY.VALIDATE#2" of
type "PACKAGE" and ID 6019.
Recommendation 2: SQL Tuning
Estimated benefit is .01 active sessions, 1.89% of total activity.
Action
Tune the entry point PL/SQL
"SYSMAN.EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS" of type "PACKAGE" and
ID 68654. Refer to the PL/SQL documentation for addition information.
Finding 5: Unusual "Other" Wait Event
Impact is .03 active sessions, 8.73% of total activity.
Wait event "DFS lock handle" in wait class "Other" was consuming significant
database time.
Recommendation 1: Application Analysis
Estimated benefit is .03 active sessions, 8.73% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits. Refer to
Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .03 active sessions, 8.27% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits in Service
"mcmsdrac".
Recommendation 3: Application Analysis
Estimated benefit is .02 active sessions, 5.05% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits in Module "TOAD
9.7.2.5".
Recommendation 4: Application Analysis
Estimated benefit is .01 active sessions, 3.21% of total activity.
Action
Investigate the cause for high "DFS lock handle" waits in Module
"toad.exe".
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
Finding 6: Unusual "Other" Wait Event
Impact is .03 active sessions, 6.42% of total activity.
Wait event "reliable message" in wait class "Other" was consuming significant
database time.
Recommendation 1: Application Analysis
Estimated benefit is .03 active sessions, 6.42% of total activity.
Action
Investigate the cause for high "reliable message" waits. Refer to
Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .03 active sessions, 6.42% of total activity.
Action
Investigate the cause for high "reliable message" waits in Service
"mcmsdrac".
Recommendation 3: Application Analysis
Estimated benefit is .02 active sessions, 4.13% of total activity.
Action
Investigate the cause for high "reliable message" waits in Module "TOAD
9.7.2.5".
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
Finding 7: Unusual "Other" Wait Event
Impact is .03 active sessions, 6.29% of total activity.
Wait event "enq: PS - contention" in wait class "Other" was consuming
significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .03 active sessions, 6.29% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits. Refer to
Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .02 active sessions, 6.02% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits in Service
"mcmsdrac".
Recommendation 3: Application Analysis
Estimated benefit is .02 active sessions, 4.93% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits with
P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
"3599" respectively.
Recommendation 4: Application Analysis
Estimated benefit is .01 active sessions, 2.74% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits in Module
"Inbox Reader_92.exe".
Recommendation 5: Application Analysis
Estimated benefit is .01 active sessions, 2.74% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits in Module
"TOAD 9.7.2.5".
Recommendation 6: Application Analysis
Estimated benefit is .01 active sessions, 1.37% of total activity.
Action
Investigate the cause for high "enq: PS - contention" waits with
P1,P2,P3 ("name|mode, instance, slave ID") values "1347616774", "1" and
"3598" respectively.
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
Finding 8: Hard Parse
Impact is .02 active sessions, 5.5% of total activity.
Hard parsing of SQL statements was consuming significant database time.
Hard parses due to cursor environment mismatch were not consuming significant
database time.
Hard parsing SQL statements that encountered parse errors was not consuming
significant database time.
Hard parses due to literal usage and cursor invalidation were not consuming
significant database time.
The Oracle instance memory (SGA and PGA) was adequately sized.
No recommendations are available.
Symptoms That Led to the Finding:
Contention for latches related to the shared pool was consuming
significant database time.
Impact is .09 active sessions, 22.42% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is .1 active sessions, 24.96% of total activity.
Finding 9: Soft Parse
Impact is .02 active sessions, 3.86% of total activity.
Soft parsing of SQL statements was consuming significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .02 active sessions, 3.86% of total activity.
Action
Investigate application logic to keep open the frequently used cursors.
Note that cursors are closed by both cursor close calls and session
disconnects.
Recommendation 2: Database Configuration
Estimated benefit is .02 active sessions, 3.86% of total activity.
Action
Consider increasing the session cursor cache size by increasing the
value of parameter "session_cached_cursors".
Rationale
The value of parameter "session_cached_cursors" was "100" during the
analysis period.
Symptoms That Led to the Finding:
Contention for latches related to the shared pool was consuming
significant database time.
Impact is .09 active sessions, 22.42% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is .1 active sessions, 24.96% of total activity.
Finding 10: Unusual "Other" Wait Event
Impact is .01 active sessions, 3.75% of total activity.
Wait event "IPC send completion sync" in wait class "Other" was consuming
significant database time.
Recommendation 1: Application Analysis
Estimated benefit is .01 active sessions, 3.75% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits. Refer
to Oracle's "Database Reference" for the description of this wait event.
Recommendation 2: Application Analysis
Estimated benefit is .01 active sessions, 3.75% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits with P1
("send count") value "1".
Recommendation 3: Application Analysis
Estimated benefit is .01 active sessions, 2.59% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits in
Service "mcmsdrac".
Recommendation 4: Application Analysis
Estimated benefit is .01 active sessions, 1.73% of total activity.
Action
Investigate the cause for high "IPC send completion sync" waits in
Module "TOAD 9.7.2.5".
Symptoms That Led to the Finding:
Wait class "Other" was consuming significant database time.
Impact is .15 active sessions, 38.29% of total activity.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additional Information
Miscellaneous Information
Wait class "Application" was not consuming significant database time.
Wait class "Commit" was not consuming significant database time.
Wait class "Configuration" was not consuming significant database time.
CPU was not a bottleneck for the instance.
Wait class "Network" was not consuming significant database time.
Wait class "User I/O" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 100% of the analysis
period.
Please help.Hello experts...
Please do the needful... It's really very urgent.
Thanks,
Syed -
Please, do not read this thread. This is a test.
1. X$KGLLK, X$KGLPN --> definition
2. EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); job log--> where??
① You might see this Problem: Perf: Emd_maintenance.Execute_em_dbms_job_procs() Job Using All Cpu Doc ID: Note:308291.1.
② Oracle Metalink Doc ID 4636497 EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS() JOB DOES NOT STOP.
Extracts of the Document,
DBConsole is stopped the EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS() continues running each minute. This job must be stopped too because Agent is not collecting information because is down.
③ You can remove this as indicated in the Metalink Document that I have referenced in my first post. After that you can create this job manually by viewing How to create job EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS manually
Doc ID Note: 44033.1. You can then see if the problem persists.
Additionally you should perform these tasks at test sites and please read the documents carefully.
3. DBSNMP/SYSMAN user
4. dbconsole, emagent --> difference
5. sysaux tablespace segment --> organize
6. kill J001 on a test db and see what will happen
7. emagent.trc のログ
8. lock 関連テーブル整理
- dba_ddl_locks or dba_lock_internal
- v$lock and v$locked_object only shows enqueue locks, not library cache locks.
9. 10g default procedureのtruncate command
- enterprise manager のdefault procedureが、truncateを実行している。--> どれ？？
10. how about enabling trace event 10046 to see where your kernals are waiting?
--> 10046 trace event for node2 444 session
11. library cache invalidated object monitoring, reload monitoring
12. v$latch (and v$latch_children)
- v$libraryache latch get/pin
13. AWR report
- library cache 関連
- parsing 関連
- what is cpu time in Top 5 Timed Events
--> I'd take a guess that you have a problem with excessive CPU usage causing a library cache problem as a side effect.
-There are many notes in metalink, which will help you to identify root cause of "libary cache lock".
14. parameter
cursor_space_for_time=true,
●● その他
If the problem still, persists, I suggest you to run hunganlyze ' DIAGNOSING DATABASE HANGING ISSUES' see metalink.1. X$KGLLK, X$KGLPN --> definition
2. EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); job log--> where??
① You might see this Problem: Perf: Emd_maintenance.Execute_em_dbms_job_procs() Job Using All Cpu Doc ID: Note:308291.1.
② Oracle Metalink Doc ID 4636497 EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS() JOB DOES NOT STOP.
Extracts of the Document,
DBConsole is stopped the EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS() continues running each minute. This job must be stopped too because Agent is not collecting information because is down.
③ You can remove this as indicated in the Metalink Document that I have referenced in my first post. After that you can create this job manually by viewing How to create job EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS manually
Doc ID Note: 44033.1. You can then see if the problem persists.
Additionally you should perform these tasks at test sites and please read the documents carefully.
3. DBSNMP/SYSMAN user
4. dbconsole, emagent --> difference
5. sysaux tablespace segment --> organize
6. kill J001 on a test db and see what will happen
7. emagent.trc のログ
8. lock 関連テーブル整理
- dba_ddl_locks or dba_lock_internal
- v$lock and v$locked_object only shows enqueue locks, not library cache locks.
9. 10g default procedureのtruncate command
- enterprise manager のdefault procedureが、truncateを実行している。--> どれ？？
10. how about enabling trace event 10046 to see where your kernals are waiting?
--> 10046 trace event for node2 444 session
11. library cache invalidated object monitoring, reload monitoring
12. v$latch (and v$latch_children)
- v$libraryache latch get/pin
13. AWR report
- library cache 関連
- parsing 関連
- what is cpu time in Top 5 Timed Events
--> I'd take a guess that you have a problem with excessive CPU usage causing a library cache problem as a side effect.
-There are many notes in metalink, which will help you to identify root cause of "libary cache lock".
14. parameter
cursor_space_for_time=true,
●● その他
If the problem still, persists, I suggest you to run hunganlyze ' DIAGNOSING DATABASE HANGING ISSUES' see metalink. -
Hello, I have an Oracle RAC 10gR2 with 2 nodes on Suse Linux Enterprise Server 10. When I enter on the enterprise manager database control (no grid control). I see the follow message:
"Availability calculations for the cluster database target are disabled. Please enable the DBMS JOB EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS for Database Control."
What is it? How can I clean it?
Thanks in advance.Check out MOS note :
What is EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS dbms_job and how to Remove / Re-create it [ID 444033.1]
Regards
Rajesh -
SQL> conn / as sysdba
Connected.
SQL> exec DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB');
BEGIN DBMS_SCHEDULER.DISABLE('GATHER_STATS_JOB'); END;
ERROR at line 1:
ORA-27476: "SYS.GATHER_STATS_JOB" does not exist
ORA-06512: at "SYS.DBMS_ISCHED", line 3429
ORA-06512: at "SYS.DBMS_SCHEDULER", line 2395
ORA-06512: at line 1
SQL> select * from v$version;
BANNER
Oracle Database 11g Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - ProductionSQL> col LOG_USER format a10
SQL> col WHAT format a50
SQL> select JOB,LOG_USER,LAST_DATE,BROKEN,FAILURES,WHAT,NEXT_DATE from dba_jobs;
JOB LOG_USER LAST_DATE B FAILURES
WHAT NEXT_DATE
27 SYS 15-FEB-10 N 0
wksys.wk_job.invoke(22,44); 22-FEB-10
26 SYS 18-FEB-10 N 0
wksys.wk_job.invoke(22,24); 18-FEB-10
1 SYSMAN 18-FEB-10 N 0
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); 18-FEB-10
JOB LOG_USER LAST_DATE B FAILURES
WHAT NEXT_DATE
4001 SYS 18-FEB-10 N 0
wwv_flow_cache.purge_sessions(p_purge_sess_older_t 18-FEB-10
hen_hrs => 24);
4002 SYS 18-FEB-10 N 0
wwv_flow_mail.push_queue(wwv_flow_platform.get_pre 18-FEB-10
ference('SMTP_HOST_ADDRESS'),wwv_flow_platform.get
_preference('SMTP_HOST_PORT'));
JOB LOG_USER LAST_DATE B FAILURES
WHAT NEXT_DATE
46 SYSMAN 18-FEB-10 N 0
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); 18-FEB-10 -
Oracle internal queries taking more CPU time
Hi,
Following are queries taking more CPU time. I got this from awr report. Can anyone tell me why these queries are running? Is it a oracle enterprise manager query? should I use
emctl stop dbconsole to stop this?
DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate; broken BOOLEAN := FALSE; BEGIN EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF; END;
SELECT COUNT(*) FROM MGMT_METRIC_DEPENDENCY_DETAILS DEP, MGMT_SEVERITY SEV WHERE DEP.TARGET_GUID = :B5 AND DEP.METRIC_GUID = :B4 AND DEP.KEY_VALUE = :B3 AND DEP.EDEP_TARGET_GUID = SEV.TARGET_GUID AND DEP.EDEP_METRIC_GUID = SEV.METRIC_GUID AND DEP.DEP_KEY_VALUE = SEV.KEY_VALUE AND SEV.COLLECTION_TIMESTAMP BETWEEN :B2 AND :B1
SELECT CURRENT_STATUS FROM MGMT_CURRENT_AVAILABILITY WHERE TARGET_GUID = :B1
Thanks in advance
With Regards
boobathi.PHi,
maybe this document will help if you are using 10g:
SQL run by SYSMAN consuming a lot of resources on OMS with 800+ targets [ID 330383.1]
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=PROBLEM&id=330383.1
there you'll find Cause and Solution too:
SYSMAN Job and Queries are Taking Up High CPU (DB Console) [ID 1288301.1]
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=PROBLEM&id=1288301.1
For databases above version 11.1 there are paches available.
Best,
Michael T. Z. -
Thread 1 cannot allocate new log -- from alert log
in my alert log file, I have noticed occasionally that this message was showing out during the business hour (8 am ~ 8 pm). Not often , maybe 3 or 4 times, but there are more during the midnight when system run some administration process such as KGL object name :SELECT /*+rule*/ SYS_XMLGEN(VALUE(KU$), XMLFORMAT.createFormat2('VIEW_T', '7')), KU$.OBJ_NUM ,K
U$.SCHEMA_OBJ.NAME ,KU$.SCHEMA_OBJ.NAME ,'VIEW' ,KU$.SCHEMA_OBJ.OWNER_NAME FROM SYS.KU$_VIEW_VIEW KU$ WHERE KU$
.OBJ_NUM IN (SELECT * FROM TABLE(DBMS_METADATA.FETCH_OBJNUMS(200001)))
. My question is : Do I have to add another redo log file to system? and how much is proper?
I also noticed there where message of "Memory Notification: Library Cache Object loaded into SGA
Heap size 2829K exceeds notification threshold (2048K)" during that hours. Appreciate any advice. my system is 10g r2 on AIX 5.3 L.The "Thread cannot allocate new log" occurs more often off the regular hours due to system run process. It seems more regular occurring at evry 20 minutes. By OEM, I noticed thate there some system processes run at 2 am, 8 am, 2 pm, 8pm. for examples
1) EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
2) MGMT_ADMIN_DATA.EVALUATE_MGMT_METRICS;
3) SELECT /*+ USE_HASH(f a) */ SUM(NVL(F.BYTES - NVL(A.BYTES, 0), 0)/1024/1024), SUM(NVL(F.BYTES, 0)/1024/1024) FROM (SELECT DISTINCT TABLESPACE_NAME FROM USER_TABLES) U, (SELECT TABLESPACE_NAME, SUM(BYTES) BYTES FROM DBA_DATA_FILES GROUP BY TABLESPACE_NAME) F, (SELECT TABLESPACE_NAME, SUM(BYTES) BYTES FROM DBA_FREE_SPACE GROUP BY TABLESPACE_NAME) A WHERE A.TABLESPACE_NAME = U.TABLESPACE_NAME AND F.T...
I wonder why they are necessary? or I have to ad one more redo log. -
Hi Experts
we are using Oracle 10g Database Release 2 on Server 2000 ,
Since a Month Jobs are not Running,
I Created the Jobs from Toad,
for the last one and Half years the Jobs were Running Fine
what could be the Cause for this Behaviour,
my Jobs Status is in online Status only but not Getting Executed
There is no Error i am finding ,
i need to Run the Job Manually Executing Every time
please Suggest
many thanksJobs are Runnig Prporperly running Manually,
please Find the out put for the Below Query
SQL>select job, schema_user, last_date, last_sec, next_date, last_date,last_sec, next_sec, total_time, broken, failures, what from dba_jobs
JOB SCHEMA_USER LAST_DATE LAST_SEC NEXT_DATE LAST_DATE LAST_SEC NEXT_SEC TOTAL_TIME B FAILURES WHAT
1 SYSMAN 07-JUNE-09 12:14:47 07-JUNE-09 07-JUNE-09 12:14:47 12:15:47 45084 N 0 EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
4001 FLOWS_030100 07-JUNE-09 04:53:44 07-JUNE-09 07-JUNE-09 04:53:44 12:53:44 706 N 0 wwv_flow_cache.purge_sessions(p_purge_sess_older_then_hrs => 24);
4002 FLOWS_030100 07-JUNE-09 12:13:42 07-JUNE-09 07-JUNE-09 12:13:42 12:23:42 1661 N 0 wwv_flow_mail.push_queue(wwv_flow_platform.get_preference('SMTP_HOST_ADDRESS'),wwv_flow_platform.get_preference('SMTP_HOST_PORT'));
121 user_dml 06-JUNE-09 16:07:42 07-JUNE-09 06-JUNE-09 16:07:42 16:07:42 111 N 0 doclib.do_alert_todos;
122 user_dml 07-JUNE-09 12:12:42 07-JUNE-09 07-JUNE-09 12:12:42 12:27:42 1029 N 0 ctx_ddl.sync_index('doclib_docs_idx2', '2M');
184 user_dml 07-JUNE-09 00:00:04 08-JUNE-09 07-JUNE-09 00:00:04 00:00:00 19852 N 0 user_dml.CREATE_STC_CIRCUIT_PATH_DAILY;
201 user_dml 07-JUNE-09 00:00:04 08-JUNE-09 07-JUNE-09 00:00:04 00:00:00 92 N 0 user_dml.CREATE_STC_HELD_TX_REQUEST_DLY;
521 FLOWS_030100 04-MAR-09 15:30:30 0 N wwv_flow_mail.push_queue;
641 FLOWS_030100 13-JUN-09 12:21:35 0 N wwv_flow_mail.push_queue;
681 FLOWS_030100 15-JUL-09 12:32:49 0 N wwv_flow_mail.push_queue;
Thanks a lot -
Unusual Scripts running on Database
Hello All,
I see that every Sunday some of my procedures are getting invalid and if I see the code an extra / is placed @ the end of the code. To my surprise this is happening on Sunday when no one is in office. Its not that always the same procedures get invalid but few procedures do get invalid. The pattern is the same a "/" @ the end of the code.
I am not a DBA and hence want to know what are possible reasons why this can happen. Is it because of backup or recover?
Regards,
Kapil UppalIs it possible that Cron Jobs or OS Jobs Scheduled will not have the information in DBA_Jobs or some other view? actually the ones I see in DBA_Jobs are
Job1 : EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); done by Sysman after each minute.
Job2 : declare errbuf varchar2(4000); retcode varchar2(4000); begin WF_BES_CLEANUP.CLEANUP_SUBSCRIBERS(errbuf, retcode); end; done by OWB schema each day
Job3 : FND_SVC_COMPONENT.EXECUTE_REQUEST (p_component_request_id => 1); Done by OWB Schema each day
The above mentioned jobs cannot do anything to harm the system only on Sunday specifically.
Cannot see the Cron Jobs or OS Jobs right now as I do not have root password of the system.
Is it possible for me to still any view with sys account to see where this extra "/" is coming from in some procedures. As said earlier the procedures which have the extra "/" are different each week.
Thanks and Regards,
Kapil Uppal -
How to understand Oracle tables (as opposed to DB2)
I am a beginner and need to ask a question.
I determine that the number of records within dba_jobs is 1.
Then I describe the table and find there are about
18 columns within the table.
Then I perform a SELECT * on the table.
When I do the select, it looks like it is printing out about 8 different records.
With only the MISC ENV field being populated.
How should I interpret this
The following are the commands I entered:
SQL> select count(*) from dba_jobs;
COUNT(*)
1
SQL> describe dba_jobs;
Name Null? Type
JOB NOT NULL NUMBER
LOG_USER NOT NULL VARCHAR2(30)
PRIV_USER NOT NULL VARCHAR2(30)
SCHEMA_USER NOT NULL VARCHAR2(30)
LAST_DATE DATE
LAST_SEC VARCHAR2(8)
THIS_DATE DATE
THIS_SEC VARCHAR2(8)
NEXT_DATE NOT NULL DATE
NEXT_SEC VARCHAR2(8)
TOTAL_TIME NUMBER
BROKEN VARCHAR2(1)
INTERVAL NOT NULL VARCHAR2(200)
FAILURES NUMBER
WHAT VARCHAR2(4000)
NLS_ENV VARCHAR2(4000)
MISC_ENV RAW(32)
INSTANCE NUMBER
SQL> select * from dba_jobs;
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
1 SYSMAN SYSMAN
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
SYSMAN 20-APR-09 22:29:55 20-APR-09
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
22:30:55 17989 N
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
sysdate + 1 / (24 * 60)
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
0
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
NLS_LANGUAGE='AMERICAN' NLS_TERRITORY='AMERICA' NLS_CURRENCY='$' NLS_ISO_CURRENC
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
Y='AMERICA' NLS_NUMERIC_CHARACTERS='.,' NLS_DATE_FORMAT='DD-MON-RR' NLS_DATE_LAN
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
GUAGE='AMERICAN' NLS_SORT='BINARY'
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
0102000000000000 0
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
---------------------------------------------------------------- ----------...and then how to post with tags: http://forums.oracle.com/forums/help.jspa
-
I am new to Oracle and need to ask a question.
Some oracle tables appear to act different than in DB2.
I determine that the number of records within dba_jobs is 1.
Then I describe the table and find there are about
18 columns within the table.
Then I perform a SELECT * on the table.
When I do the select, it looks like it is printing out about 8 different records.
With only the MISC ENV field being populated.
How should I interpret this
The following are the commands I entered:
SQL> select count(*) from dba_jobs;
COUNT(*)
1
SQL> describe dba_jobs;
Name Null? Type
JOB NOT NULL NUMBER
LOG_USER NOT NULL VARCHAR2(30)
PRIV_USER NOT NULL VARCHAR2(30)
SCHEMA_USER NOT NULL VARCHAR2(30)
LAST_DATE DATE
LAST_SEC VARCHAR2(8)
THIS_DATE DATE
THIS_SEC VARCHAR2(8)
NEXT_DATE NOT NULL DATE
NEXT_SEC VARCHAR2(8)
TOTAL_TIME NUMBER
BROKEN VARCHAR2(1)
INTERVAL NOT NULL VARCHAR2(200)
FAILURES NUMBER
WHAT VARCHAR2(4000)
NLS_ENV VARCHAR2(4000)
MISC_ENV RAW(32)
INSTANCE NUMBER
SQL> select * from dba_jobs;
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
1 SYSMAN SYSMAN
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
SYSMAN 20-APR-09 22:29:55 20-APR-09
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
22:30:55 17989 N
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
sysdate + 1 / (24 * 60)
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
0
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS();
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
NLS_LANGUAGE='AMERICAN' NLS_TERRITORY='AMERICA' NLS_CURRENCY='$' NLS_ISO_CURRENC
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
Y='AMERICA' NLS_NUMERIC_CHARACTERS='.,' NLS_DATE_FORMAT='DD-MON-RR' NLS_DATE_LAN
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
GUAGE='AMERICAN' NLS_SORT='BINARY'
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
0102000000000000 0
JOB LOG_USER PRIV_USER
SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE
NEXT_SEC TOTAL_TIME B
INTERVAL
FAILURES
WHAT
NLS_ENV
MISC_ENV INSTANCE
---------------------------------------------------------------- ----------Thanks,
Edited by: user10747262 on Apr 21, 2009 11:56 AMHello,
Can you edit your post and enclose your code and output between \ tag to preseve formatting? Also list out all the questions before your output so it will be easier for any volunteer to help you out faster.
\Your code or output goes here.
\Regards
Maybe you are looking for
-
Find Number of Active Calendar Client Sessions?
What is the "ps" command to find the number of active Calendar clients at any given time? We are using 10.1.2 in an OCS installation on Linux SuSe servers. Also, is there a way to see the individual usernames associated with each active session?
-
Re:Customer Outstanding report
Dear friends, I would like to know how to find out a customer outstanding and current balance as of date. Is there any cuncurent for that, or we can see in the front end. Advacned Thanks & Regards, Shruthi
-
i use data table ,but the data from oracle can not display normally,because it is chinese the code is : i want the value of outputText3 encoding, how do? <h:column binding="#{Page1.column2}" id="column2"> <h:outputText bin
-
I have 2 problems that I need help with please?
I had an iPhone 4 1 year ago and I ended up swapping it for an iPhone 4S.. I made a new apple ID. But I can't remember if I synced my notes with iCloud on my old apple ID, so I signed in with my old apple ID which was connected with my iPhone 4 that
-
I have a project originally created in version 4. Opened it in version 5 and there are several slides with short cut keys that do not work. The keys are Ctrl+X and Ctrl+V. These slides are showing how to move cell contents in an excel spreadsheet.