Saturday, November 28, 2015

ORA-31634: job already exists | Datapump Master Table exists

ORA-31634: job already exists
Datapump Master Table exists


Error

Export Datapump job experience below error during export

Export: Release 11.2.0.1.0 - Production on Fri Nov 21 16:09:37 2015

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORA-31634: job already exists
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "SYS.KUPV$FT", line 1016
ORA-31637: cannot create job EXPDP_BACKUP for user ORACLE



Check the running jobs

SQL> set lines 200 pages 200 numwidth 10
col program for a40
col username for a14
col spid for a10
select to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') "DATE", s.program, s.sid,
s.status, s.username, d.job_name, p.spid, s.serial#, p.pid
from v$session s, v$process p, dba_datapump_sessions d
where p.addr=s.paddr and s.saddr=d.saddr;

no rows selected




SQL> COL OPERATION FOR A14
SQL> COL JOB_MODE FOR A14
SQL> COL OWNER_NAME FOR A14
SQL> COL STATE FOR A15
SQL> SET LIN200 PAGES 200
SQL> SELECT owner_name, job_name, operation, job_mode,
state, attached_sessions
FROM dba_datapump_jobs;


OWNER_NAME     JOB_NAME                       OPERATION      JOB_MODE       STATE           ATTACHED_SESSIONS
-------------- ------------------------------ -------------- -------------- --------------- -----------------
ORACLE         BIN$JWB+GHK0NnLgUKeTGxwsxA==$0 EXPORT         FULL           NOT RUNNING                     0
ORACLE         BIN$JOCfGMFgf4XgUKeTGxwcEA==$0 EXPORT         FULL           NOT RUNNING                     0
ORACLE         EXPDP_BACKUP                   EXPORT         FULL           NOT RUNNING                     0
ORACLE         BIN$JYNqus85nL3gUKeTGxwpmQ==$0 EXPORT         FULL           NOT RUNNING                     0
ORACLE         BIN$JNMboNajQ6DgUKeTGxxb8g==$0 EXPORT         FULL           NOT RUNNING                     0
ORACLE         BIN$JSAQ5vj9TtngUKeTGxw+jg==$0 EXPORT         FULL           NOT RUNNING                     0

6 rows selected.


Checking Orphaned jobs

SQL> SELECT o.status, o.object_id, o.object_type,
o.owner||'.'||object_name "OWNER.OBJECT",o.created,j.state
FROM dba_objects o, dba_datapump_jobs j
WHERE o.owner=j.owner_name AND o.object_name=j.job_name
and j.state='NOT RUNNING' ORDER BY 4,2;


SQL> COL OWNER.OBJECT FOR A20
SQL> /


STATUS  OBJECT_ID OBJECT_TYPE         OWNER.OBJECT         CREATED            STATE
------- --------- ------------------- -------------------- ------------------ ---------------
VALID     1842419 TABLE               ORACLE.EXPDP_BACKUP  21-NOV-15 10.44.50 NOT RUNNING



Clear the master tables created by orphaned jobs

SQL> DROP TABLE ORACLE.EXPDP_BACKUP ;

Table dropped.


Now you can start the export.


Friday, November 20, 2015

ORA-600 [729] Space Leak Errors

Understanding and Diagnosing
ORA-600 [729] Space Leak Errors

References Support DOC: 403584.1

ORA-00600: internal error code, arguments: [729], [560], [space leak], [], [], [], [], []
ORA-10387: parallel query server interrupt (normal)
OPIRIP: Uncaught error 600.  Error Stack:

Effected Versions

Oracle Database - Personal Edition - Version 7.1.4.0 to 11.2.0.3 [Release 7.1.4 to 11.2]
Oracle Database - Enterprise Edition - Version 7.0.16.0 to 11.2.0.3 [Release 7.0 to 11.2]
Oracle Database - Standard Edition - Version 7.0.16.0 to 11.2.0.3 [Release 7.0 to 11.2]
Information in this document applies to any platform.

ORA-600 [729] UGA Space Leak errors.
What is a space (memory) leak?
Memory leak problems generally occur when Oracle is trying to free memory allocated to a process. The memory leak dump is generally discovered during session logoff, when Oracle frees the heaps that are allocated for the user process.

When a user connects to Oracle, a user process is created and at that time the heap is allocated. Every process will have its own memory heap.
The memory is organized in to heaps and every heap consists of one or more extents. Each extent contains a series of contiguous memory chunks, and these chunks can be either FREE or ALLOCATED. The Generic Heap Manager takes care of allocating and deallocating the memory chunks, with the help of FREE LISTS and LRU LISTS.

Chunk types are as follows:
1. FREE
2. FREEABLE
3. RECREATABLE
4. PERMANENT
5. FREEABLE WITH MARK

It is not mandatory that each extent only contains one type of chunk. Extents can contain various types of chunks. When processes require memory chunks, they are allocated as needed. Oracle keeps track of the amount of memory allocated for the process internally.
When the process terminates, all of the memory that has been allocated for the process is automatically released. When the memory is released the allocated heaps are freed. Generally, when the heap is freed the only chunks that the process should identify as allocated are the PERMANENT chunks and FREE chunks on the freelist. If the process finds there are still FREEABLE or RECREATABLE chunks remaining, then the process has not properly deallocated the memory. This situation is considered a space leak.

Oracle generally performs space leak checks for the SGA Heap, UGA Heap, Large Pool Heap and PGA Heap. A space leak error will result in a trace file in the BACKGROUND_DUMP_DESTINATION or USER_DUMP_DESTINATION.
A space leak problem will generally capture the trace information and the heap dump.
In the alert.log, the error will be reported as:
Errors in file d:\oracle\admin\testdb\bdump\yourfilenamehere.trc:
ORA-00600: internal error code, arguments: [729], [560], [space leak], [], [], [], [], []
After the operating system and Oracle process header information you will see the following in the trace file:
*** 2006-10-03 18:43:11.598
*** SESSION ID:(34.50354) 2006-10-03 18:43:11.597
******** ERROR: UGA memory leak detected 560 ********
The above lines tells us that this memory leak is from the UGA and the number of bytes leaked is 560.

******************************************************
HEAP DUMP heap name="session heap" desc=0xaef81d0
extent sz=0xffb8 alt=32767 het=32767 rec=0 flg=3 opc=3
parent=0xaeb63e0 owner=0x7a4b7078 nex=(nil) xsz=0xffb8

The above few lines describe this dump as SESSION HEAP with the descriptor 0xaef81d0.

In the dump below, you can see the chunk not released is Chunk 4085a350. This is a recreatable chunk and the size is 560 bytes, which is exactly the number of bytes reported as leaked in the error ORA-00600 [729], [560], [space_leak].

When analyzing memory leak issues, identify the FREEABLE and RECREATABLE chunks. Ideally, they should equal the sum of the total amount of the memory bytes leaked in the error reported.

If you look at the memory dump below, you see the total size of freeable and recreatable chunks equals 560, which is the amount of the memory bytes leaked.

EXTENT 0 addr=0x407cf048
Chunk 407cf050 sz= 65456 free " "
EXTENT 1 addr=0x408a0048
Chunk 408a0050 sz= 65456 free " "
EXTENT 2 addr=0x40890048
Chunk 40890050 sz= 65456 free " "
EXTENT 3 addr=0x40850048
Chunk 40850050 sz= 41728 free " "
Chunk 4085a350 sz= 560 recreate "bind var heap " latch=(nil)
EXTENT 4 addr=0x407df048
Chunk 407df050 sz= 65456 free " "
EXTENT 5 addr=0x40f91048
Chunk 40f91050 sz= 65456 free " "
EXTENT 6 addr=0x40880048
Chunk 40880050 sz= 65456 free " "
EXTENT 7 addr=0x40870048
Chunk 40870050 sz= 65456 free " "
 
How do I handle a space leak?
Step 1. Review the alert.log to verify the error and obtain the trace file information.

The alert.log will report an error similar to the following:
Sat Dec 02 21:52:17 2006
Errors in file d:\oracle\admin\testdb\udump\testdb_ora_5928.trc:
ORA-00600: internal error code, arguments: [729], [152], [space leak], [], [], [], [], []


a. the first bracketed number [729] is the common argument for space leak problems.
b. the second number [152] is the number of bytes leaked by the error.
c. the third argument is always [space leak].

Step 2. Open the associated trace file.
Below the operating system and Oracle process header information, you will see the following:
*** 2006-12-13 02:01:13.859
*** SESSION ID:(54.11635) 2006-12-13 02:01:13.859
******** ERROR: UGA memory leak detected 152 ********
****************************************************** 


The above error states:

a. the memory was leaked from the UGA area
b. the amount leaked is reported again in the text (152 bytes).
Step 3. Verify the leak was during session logoff.
a. Search the trace file for "Call Stack Trace". If "opilof" is referenced in the stack, the error is happening at session logoff. The section will look similar to the following:

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+184 ? ksedst() 800000010000B938 ?
ksfdmp()+32 ? ksedmp() 800003FFBFFF6418 ?
kgeriv()+152 ? ksfdmp() 20000000B168 ?
kgesiv()+132 ? kgeriv() 40000000000002D9 ?
ksesic2()+124 ? kgesiv() 000000000 ?
ksmuhe()+1040 ? ksesic2() 000000000 ?
ksmugf()+400 ? ksmuhe() 000000000 ?
ksuxds()+2692 ? ksmugf() 800003FFBFFF4020 ?
ksudel()+104 ? ksuxds() 8000000100131B38 ?
opilof()+876 ? ksudel() 800003FFBFFF5808 ?
opiodr()+2416 ? opilof() 0650AB9D8 ?
ttcpip()+1320 ? opiodr() 8000000100004790 ?
opitsk()+1260 ? ttcpip() 000000100 ?
opiino()+1484 ? opitsk() 8000000100138268 ?
opiodr()+2416 ? opiino() 000001560 ?
opidrv()+752 ? opiodr() 800003FFBFFF0870 ?
sou2o()+40 ? opidrv() 000000000 ?
main()+228 ? sou2o() 000000000 ?

b. The session state object has following information in flags that shows that the session has been deleted:
SO: 7000000abdd9290, type: 4, owner: 7000000ab97a2b8, flag: INIT/-/-/0x00
(session) sid: 617 trans: 0, creator: 7000000ab97a2b8, flag: (100041) USR/- BSY/-/-/DEL/-/-
DID: 0000-0000-00000000, short-term DID: 0000-0000-00000000
4. Are you using Dedicated Server or Multi Threaded Server?
a. If you are using Dedicated Server the impact of this error will end when the process exits. The result of this error is minimal and presents no real problem. The leak will be in the UGA.

b. If you are using Multi Threaded Servers(MTS) and/or an XA transaction process manager/monitor, the leaked memory is in the SGA. It is important to review the alert.log for other errors such as ORA-4030 or ORA-4031 to ensure the SGA is not experiencing additional resource related problems.

WORK AROUND AND SOLUTIONS

Can I ignore the leak?
a. Are there any other errors? If there are no other errors reported at the same time, this may be a case where the error was a rare occurrence and can be safely ignored. As a rule of thumb, leaks less than 90,000 bytes in size are considered to be of low significance. The solution in this case is to set event 10262 (see below).

b. Is the leak in the SGA? The alert.log should be reviewed for additional errors such as ORA-4030 and ORA-4031 to ensure there are no additional problems with the shared pool or operating system memory.

c. Does the error reproduce with a given task? If so, this is a case that should be investigated further because the leak could be a known bug.
See 
ORA-600 [729] UGA Space Leak   Click Here...

for a list of known bugs and fixes.
Setting EVENT 10262:
After the amount of bytes leaked has been determined to be minimal, and no other errors have been noted, you can choose to safely ignore the errors. Leaks up to 90,000 bytes in size are considered to be within the allowable range.
In cases where the amount of bytes leaked is allowable and you do not want the errors to be reported in the alert.log file, set event 10262. This will stop reporting of the ORA-600 [729] error in the alert log file up to the specified number of bytes.
a. Set the following event in init.ora parameter file. This example disables reporting for space leaks less than 90000 bytes:
event = "10262 trace name context forever, level 90000"
b. Stop and restart the database.
If the level is set to 1, space leak checking is disabled. This is not advised because large memory leaks will be missed.
If the event is set to a value greater than 1, any space leak up to the number specified in the event is ignored.


Are you encountering a bug?

There are a number of bugs which can cause this issue. These are the most prevalent at this time:

1. Search your incident trace file for the following:
 'XDB' and kgbt'
If you find them, this bug is likely:
Bug 7499301 - Memory leak in XDB / ORA-600 [729] Note 7499301.8
This issue is fixed in
    12.1.0.1 (Base Release)
    11.2.0.2 (Server Patch Set)


2. Search your incident trace file for the following:
kllcqgf:kllsltb

This bug is likely:
Bug 14385220 - Private memory leak of "kllcqgf:kllsltb" memory (ORA-600 [729] / ORA-600 [723]
note 14385220.8

This is not likely to be a large leak. If the errors are small, you can mask them by setting event 10262
as indicated above.
This issue is fixed in
    12.2 (Future Release)


3. Search your incident trace file for the following:
"kxs-role"

This bug is likely:
Bug 9474750 - ORA-600 [729] space leak of "kxs-krole" memory Note 9474750.8
This issue is fixed in  

    12.1.0.1 (Base Release)
    11.2.0.2 (Server Patch Set)


4. Search your incident trace file for the following:
'hssh'
'horkmal'
'ncoxdc'

If you find any or all of these this bug is possible:
Bug 9365381 - ORA-600 [729] having called an external procedure followed by PMON dump Note 9365381.8

This issue is fixed in
    12.1.0.1 (Base Release)
    11.2.0.3 (Server Patch Set)

5. For a complete list of known fixed bugs, please see the following note:
Note 31056.1
 ORA-600 [729] "UGA Space Leak"

6. Please note that, from 11.2.0.4 onwards, ORA-600 [729] is replaced by the external error 'ORA-10260: limit size (<nnnnn>) of the PGA heap set by event 10261 exceeded'

https://support.oracle.com/epmos/adf/images/t.gif


ORA-600 [729] "UGA Space Leak"

ORA-600 [729] "UGA Space Leak"

REFERENCE :

Oracle Support Doc ID 31056.1)

ERROR:             

  Format: ORA-600 [729] [a] [b]

Effected Versions:  
       
  versions 11.2.0.3 ( and below)  MEMORY COMPONENT


PROBLEM DESCRIPTION:       

A space leak has been detected in the User Global Area (UGA).   There is NO data corruption as a result of this error.  It is an internal memory housekeeping problem.


IMPACT:   
         
PROCESS FAILURE - But only during logoff of dedicated process so impact is minimal.
NON CORRUPTIVE - No underlying data corruption.



SOLUTIONS:       

Event 10262 can be set to safely ignore small memory leaks.

Set the following in init.ora for example to disable space leaks less than 4000 bytes:

  event = "10262 trace name context forever, level 4000"

then stop and restart the database.

Repeated errors or large memory leaks can be diagnosed further by Sending the alert.log and trace files to Oracle support.