'oracle'에 해당되는 글 31건

  1. 2013.01.21 Oracle Data Record별 Text File 내보내는 방법 1
  2. 2012.07.26 Compound Triggers in Oracle 11g
  3. 2012.05.15 ORA-20023: Missing start and end values for time model stat
  4. 2011.08.11 Bug 5969934: EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK 4
  5. 2011.08.11 DataPump Export (EXPDP) Client Gets UDE-8 ORA-31626 ORA-39086 [ID 549781.1] 3
  6. 2011.08.11 Oracle 10gR2이상에서 Automatic Tuning of Undo_retention Causes Space Problems 1
  7. 2011.08.11 EXPDP for a large table fails with ORA-1555
  8. 2011.02.22 [Oracle Dictionary] PL/SQL과 Table간의 Dependency 정보 확인
  9. 2011.02.18 Oracle REF CURSOR
  10. 2011.02.18 [Oracle9i] Update구문의 Returning Clause

Oracle Data Record별 Text File 내보내는 방법

Oracle 2013. 1. 21. 17:47

Oracle DB에서 특정 Table의 Data를 Record별로 Text File을 생성하여 내보내고 싶을 때 어떻게 할까?

 

UTL_FILE 패키지를 이용하여 PL/SQL에서 파일의 입력 or 출력을 할 수 있다.

 

이는 PL/SQL에서 Log를 File별로 생성하고 싶을 때도 사용이 가능하다.

 

먼저, Oracle Directory를 생성해주어야 한다.

 

▣ Create Directory

 

    DBA 계정으로 oracle에 로그인을 한 후, Directory를 생성하고, 이를 사용하고자 하는 계정에 부여하면 된다.

 

   1. Create Directory exp_text as 'c:\temp';     --Temp Folder를 Directory로 설정하고, 이를 exp_text로 이름을 부여함

 

   2. grant read, write on directory exp_text to scott;    -- Scott 계정에 exp_text Directory에 대한 읽고, 쓰기 권한을 부여함.

 

 

 

위와 같이 Directory 생성 및 권한 부여가 되었다면, Scott 계정에서 아래와 같이 간단하게 PL/SQL을 이용하여 Text File로 Data를

 

추출할 수 있다.

 

▣ Export to Text File

 

create or replace
procedure Export2Text
IS
    vHandle    UTL_FILE.FILE_TYPE;
    vDirectory  varchar2(100);
    vFile   varchar2(256);
    vOutput    varchar2(32767);
 
    cursor c_cur is
    select empno, ename, hiredate, sal from emp;

begin
    vDirectory  := 'exp_text';
   
     for r_cur in c_cur
     loop  
          if r_cur.empno > 0 then  
               vFile := r_cur.empno || '.txt';
               vHandle := UTL_FILE.FOPEN(vDirectory ,vFile,'W', 32767);
               vOutput := r_cur.ename || ', ' || r_cur.hiredate || ', ' || r_cur.sal;
               UTL_FILE.PUT_LINE(vHandle, vOutput);
               UTL_FILE.FCLOSE(vHandle);     
          end if;
    end loop;

exception
    when others then
        UTL_FILE.FCLOSE_ALL;
        raise;
end;
/

 

 아래는 Directory내에 존재하는 file을 읽어오고자 할 때, 사용할 수 있는 PL/SQL이다.

 

▣ Import to Text File

 

create or replace
procedure Import2Text
is
     vHandle   UTL_FILE.FILE_TYPE;
     vDirectory  varchar2(100);
      vFile   varchar2(256);
     vInput    varchar2(32767);
begin
     vDirectory := 'exp_text';
     vFile := 'test.txt';                        
     vHandle   := UTL_FILE.FOPEN(vDirectory ,vFile,'R', 32767);
 
     begin
         loop
               UTL_FILE.GET_LINE(vHandle, vInput,32767);
               DBMS_OUTPUT.PUT_LINE(vInput);
         end loop;
     exception
        when NO_DATA_FOUND then
              dbms_output.put_line('last line of file');
     end;
 
     UTL_FILE.FCLOSE(vHandle);
exception
    when others then
        UTL_FILE.FCLOSE_ALL;
        raise;
end;
/

 

:     

TISTORY에 Login하려면 여기를 누르세요.


Compound Triggers in Oracle 11g

Oracle 2012. 7. 26. 13:19

Oracle 11g에서는 Compound Triggers 기능이 생겨서 각 Event별로 Trigger를 만들 필요가 없어졌네요.

 

In earlier versions of Oracle, triggers were the database objects whose ability to collide with the current database state of an object and session state maintenance, kept the database developers alert while designing triggers.  Oracle11g offers considerable improvements in database triggers. These additions have not only enhanced the language usability but also promise a better performance in a real application environment. 

Oracle 11g fixes major issues by the enhancements as listed below.

  • Trigger firing sequence can be set in Oracle 11g using FOLLOWS keyword
  • Compound Triggers to encapsulate multiple triggering timings in one body
  • Triggers can be created in ENABLED/DISABLED mode
  • The DML triggers in 11g are 25% faster than their earlier versions in terms of compilation, execution and firing

In the tutorial, you will learn how Compound Triggers works and its benefits to the users.

1. Compound Triggers: Introduction

Compound triggers are the database DML triggers which ‘compounds’ or combines all the triggering timings under one trigger body. The triggering timings available for database triggers are BEFORE STATEMENT, AFTER STATEMENT, BEFORE EACH ROW, and AFTER EACH ROW. Trigger level variables can be defined which would be visible and accessible in all the timing blocks.

Compound trigger body does not contain any exception section but recommends each block to contain its own exception handler under exception section.

2. Compound Triggers: Reaping the Benefits

Compound trigger resolves few big issues, which have been the nightmare for the developers in the past.

  1. Mutating table error ORA-04091
  2. Multithread behavior maintains persistent state of session variables till the statement execution finishes. These are defined in the declaration section of the compound trigger.
  3. Enhanced performance in bulk operations
  4. Supports encapsulation of multiple program units; thus enhances code interactivity

3. Compound Triggers: Usage Guidelines

As a new induction to the database family, there are some introductory guidelines which must be followed while working with compound triggers

  • Compound trigger are meant only for DML operations. No support still for DDL and system operations.
  • Exception handling process has to be done for each timing block.
  • Compound trigger remains passive, if the DML does not changes any rows
  • :OLD and :NEW variable identifiers can exist only in ROW level blocks, where :NEW values can only be modified in BEFORE EACH ROW block
  • No support for WHEN clause. Earlier, WHEN clause could be utilized to impose condition on the trigger action.
  • No support for PRAGMA_AUTONOMOUS_TRANSACTION

There are many debates over the above guidelines, which many identify as compound trigger restrictions. But from developer’s perspective, the benefits from compound triggers are much heavier than these restrictions. The assumptions and restrictions can be melted into code practice and as ‘usage guidelines’.

4. Compound Triggers: Syntax

The syntax shows the four timing blocks in a set order.

Example Syntax [1a]: For DML Triggers

Sample Code
  1. CREATE OR REPLACE TRIGGER [TRIGGER NAME]
  2. FOR [DML] ON [TABLE NAME]
  3. COMPOUND TRIGGER
  4. -- Initial section 
  5. -- Declarations 
  6. -- Subprograms
  7. Optional section
  8. BEFORE STATEMENT IS
  9. …;
  10. Optional section
  11. AFTER STATEMENT IS
  12. …;
  13. Optional section
  14. BEFORE EACH ROW IS
  15. …;
  16. Optional section
  17. AFTER EACH ROW IS
  18. …;
  19. END; 
Copyright exforsys.com


In the syntax, note that the compound trigger offers only the declaration section, which are again locally available in the timing blocks.

Example Syntax [1b]: For database views

INSTEAD OF EACH ROW IS 
...; 
END;

Note that none of the timing blocks should be duplicated. Oracle server raises exception PLS-00676 if duplicate timing blocks is found in the compound trigger definition.

5. Compound Triggers: Additional Notes

5.1. USER_TRIGGERS dictionary view structure has been restructured to include the metadata for compound triggers. The new columns specify whether a timing block is available in the compound trigger body.

5.2. The new triggering event has been introduced for compound trigger as ‘COMPOUND’. The figure below shows the TRIGGER_TYPE, TRIGGERING_EVENT and TABLE_NAME of the trigger TRG_COMP_DEMO.

5.3. The columns BEFORE_STATEMENT, BEFORE_ROW, AFTER_ROW, and AFTER_STATEMENT are set as YES/NO based on the timing blocks available in the compound trigger. For example, the trigger TRG_COMP_DEMO contains all the timing blocks in the trigger body, the columns can be queried as below.

6. Applications of Compound Triggers

A compound trigger is best suited to achieve two objectives.

  • Yield better performance while loading a table simultaneous to a running transaction and using its values.
  • Resolve mutating table error (ORA-04091)

I will  illustrate both the accomplishments in below steps

6.1. Demonstrating performance gains during simultaneous loading

1. Two tables were created

Sample Code
  1. SQL> CREATE TABLE ORDERS (ORD_ID NUMBER, 
  2. ITEM_CODE VARCHAR2(100), 
  3. ORD_QTY NUMBER, 
  4. ORD_DATE DATE); 
  5. TABLE created. 
  6. SQL> CREATE TABLE ORDER_ARCHIVE(ORD_ID NUMBER, 
  7. ORD_CODE VARCHAR2(100));
  8.  
  9. TABLE created. 
Copyright exforsys.com


2. To demonstrate the performance difference between the versions, I create a normal FOR EACH ROW trigger on ORDERS table to insert data into ORDER_ARCHIVE table.

Sample Code
  1. SQL> CREATE OR REPLACE TRIGGER TRG_ORDERS
  2. BEFORE INSERT ON ORDERS
  3. FOR EACH ROW 
  4. BEGIN
  5. DBMS_OUTPUT.PUT_LINE('Insert order‘||:NEW.ORD_ID||’ into ORDER_ARCHIVE');
  6. INSERT INTO ORDER_ARCHIVE VALUES (:NEW.ORD_ID,:NEW.ITEM_CODE);
  7. END;
  8. / 
  9. TRIGGER created. 
Copyright exforsys.com


3. Now, I will insert the test data into the ORDERS table using SELECT statement

Sample Code
  1. SQL> INSERT INTO orders(ord_id, item_code, ord_date)
  2. 2 SELECT (rownum+1)*100, 'ITEM_'||rownum, sysdate-rownum
  3. 3 FROM DUAL
  4. 4* CONNECT BY ROWNUM < 15; 
  5. INSERT ORDER 1 INTO ORER_ARCHIVE
  6. INSERT ORDER 2 INTO ORER_ARCHIVE
  7. INSERT ORDER 3 INTO ORER_ARCHIVE
  8. INSERT ORDER 4 INTO ORER_ARCHIVE
  9. INSERT ORDER 5 INTO ORER_ARCHIVE
  10. INSERT ORDER 6 INTO ORER_ARCHIVE
  11. INSERT ORDER 7 INTO ORER_ARCHIVE
  12. INSERT ORDER 8 INTO ORER_ARCHIVE
  13. INSERT ORDER 9 INTO ORER_ARCHIVE
  14. INSERT ORDER 10 INTO ORER_ARCHIVE
  15. INSERT ORDER 11 INTO ORER_ARCHIVE
  16. INSERT ORDER 12 INTO ORER_ARCHIVE
  17. INSERT ORDER 13 INTO ORER_ARCHIVE
  18. INSERT ORDER 14 INTO ORER_ARCHIVE 
  19. 14 rows created. 
Copyright exforsys.com


Note the output of the above INSERT process. For each of the 14 records inserted into the ORDERS table through the trigger, Oracle server makes simultaneous inserts into the ORDER_ARCHIVE table.

4. Compound triggers in Oracle 11g have the ability to perform simultaneous bulk insert process into the table. I will create the compound trigger TRG_COMP_ORDERS to implement the bulk loading process. Note the use of associative arrays, which hold the data to be inserted. It flushes off once the data is replicated into the ORDER_ARCHIVE table when the index count reaches 20 or the statement execution completes.

Sample Code
  1. SQL> CREATE OR REPLACE TRIGGER TRG_COMP_SAL
  2. FOR INSERT ON ORDERS
  3. COMPOUND TRIGGER
  4. TYPE ORDER_T IS TABLE OF ORDER_ARCHIVE%ROWTYPE 
  5. INDEX BY PLS_INTEGER;
  6. L_ORDERS ORDER_T;
  7. I NUMBER := 0;
  8. AFTER EACH ROW IS
  9. BEGIN
  10. I := I+1;
  11. L_ORDERS(I).ORD_ID := :NEW.ORD_ID;
  12. L_ORDERS(I).ORD_CODE := :NEW.ITEM_CODE;
  13. IF I >= 20 THEN
  14. DBMS_OUTPUT.PUT_LINE('Bulk Load for 20 orders'); 
  15. FOR J IN 1..I
  16. LOOP
  17. INSERT INTO ORDER_ARCHIVE VALUES L_ORDERS(J);
  18. END LOOP;
  19. L_ORDERS.DELETE;
  20. I := 0;
  21. END IF;
  22. END AFTER EACH ROW;
  23. AFTER STATEMENT IS
  24. BEGIN
  25. DBMS_OUTPUT.PUT_LINE('Statement level loading');
  26. FORALL J IN 1..L_ORDERS.COUNT
  27. INSERT INTO ORDER_ARCHIVE VALUES L_ORDERS(J);
  28. L_ORDERS.DELETE;
  29. I := 0;
  30. END AFTER STATEMENT;
  31. END;
  32. /
  33.  
  34. TRIGGER created. 
Copyright exforsys.com


5. I will insert 64 rows (instead of just 14) into ORDERS table using SELECT query. The simultaneous inserts into ORDER_ARCHIVE table are achieved only in 3 bulk insert process.

Sample Code
  1. SQL> INSERT INTO orders(ord_id, item_code, ord_date)
  2. 2 SELECT (rownum+1)*100, 'ITEM_'||rownum, sysdate-rownum
  3. 3 FROM DUAL
  4. 4 connect BY rownum < 65
  5. 5 / 
  6. Bulk LOAD FOR 20 orders
  7. Bulk LOAD FOR 20 orders
  8. Bulk LOAD FOR 20 orders
  9. Statement level loading 
  10. 64 rows created. 
Copyright exforsys.com


Above results clearly differentiate the compound trigger from the conventional triggers in terms of performance while simultaneous data loading.

6.2. Demonstration of Mutating table solution using Compound triggers

Now, let us learn about the most accomplished achievement of Compound Triggers, i.e. their ability to tackle with Mutating table error (ORA-04091).

Mutating table occurs when a table is referenced when it is in floating state. A table is in flux or floating state when it is the participant of a running transaction. Earlier, it used to be taken as a precaution during coding or its effects were diluted using workaround solutions. Few of the efficient workarounds are as below.

  • Change in logic implementation and code design
  • Using PRAGMA_AUTONOMOUS_TRANSACTION
  • Conversion of row level trigger to statement level
  • Defining package to hold variables at session level; these variables would hold the values and later would be inserted once the statement execution finishes.

How compound trigger fixes the problem?

Compound trigger contains the timing blocks and variables, which are persistent till the statement completes and are visible in all the timing blocks of the trigger. These variables are of collection type which holds the table data, before it enters the flux mode. Table gets locked once it moves to flux mode, but the backup data in the collection variables remains persistent and can be used for reference within the trigger.

Therefore, the logic used is same as earlier, but being a single compiled unit, it is more convenient and easily maintained.

In the example code below, the compound trigger fires on update of ORDERS table. It queries the ORDERS table to fetch and display the old quantity. For a conventional DML trigger, the situation is the best candidate for ORA-04091 Mutating table error.

A user updates the order quantity for order id 600. Now before the UPDATE statement executes, the BEFORE STATEMENT block fetches the old ‘order quantity’ value (90) and stores in a collection type variable. Now when the statement executes, it updates the ‘order quantity’ to 150. AFTER STATEMENT block in the trigger displays the ‘old quantity’ value.

Sample Code
  1. CREATE OR REPLACE TRIGGER TRG_ORDERS
  2. FOR UPDATE ON ORDERS
  3. COMPOUND TRIGGER
  4. TYPE ORD_QTY_T IS TABLE OF ORDERS.ORD_QTY%TYPE;
  5. L_ORD_QTY ORD_QTY_T; 
  6. BEFORE STATEMENT IS
  7. BEGIN 
  8. SELECT ORD_QTY 
  9. BULK COLLECT INTO L_ORD_QTY 
  10. FROM ORDERS WHERE ORD_ID=600; 
  11. END BEFORE STATEMENT; 
  12. AFTER EACH ROW IS
  13. BEGIN
  14. DBMS_OUTPUT.PUT_LINE('Old Quantity Value:'||L_ORD_QTY(L_ORD_QTY.FIRST));
  15. END AFTER EACH ROW; 
  16. END;
  17. / 
  18. SQL> UPDATE ORDERS
  19. 2 SET ORD_QTY = 150
  20. 3 WHERE ORD_ID = 600;
  21. Old Quantity Value:90 
  22. 1 row updated. 
Copyright exforsys.com


7. Conclusion

Compound trigger combines the properties of both statement and row level triggers. The logic which was earlier maintained at row and statement level can now be placed into one single body, with state and persistency in data across the timings.

 

출처 : http://www.exforsys.com/tutorials/oracle-11g/compound-triggers-in-oracle-11g.html

:     

TISTORY에 Login하려면 여기를 누르세요.


ORA-20023: Missing start and end values for time model stat

Oracle 2012. 5. 15. 11:01

"ORA-20023: Missing start and end values for time model stat"

 

이는 Oracle11g License의 정책으로 인해서 생성된 Parameter설정과 연관되어 있는 Error 입니다.

 

하여 CONTROL_MANAGEMENT_PACK_ACCESS Parameter의 값을 확인 해보셔야 합니다.

 

11g에서는 기본값이 DIAGNOSTIC+TUNING 으로 되어 있는데,

 

이를, NONE으로 설정 시, Snapshot에 대한 조회 권한이 없어집니다.

  

해당 Parameter 값을 변경하기 위해서는 아래와 같이 해주시면 됩니다.

 

 

alter system set CONTROL_MANAGEMENT_PACK_ACCESS="DIAGNOSTIC+TUNING" scope=both;


 

Snapshot 정보는 계속 자동으로 생성되더라도, 위와 같이 설정이 되어 있지 않다면 이를 이용하여 분석할 수 없습니다.

 

보다 자세한 정보는 아래 Link에서 확인해보시기 바랍니다.

 


http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams037.htm

 

:     

TISTORY에 Login하려면 여기를 누르세요.


Bug 5969934: EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK

Oracle 2011. 8. 11. 15:24

 버그 속성


유형 B - Defect 제품 버전에서 수정됨 - (수정된 버전 없음)
중요도 2 - Severe Loss of Service 제품 버전 10.2.0.2
상태 44 - Not Feasible to fix, to Filer 플랫폼 46 - Linux x86
생성 날짜 02-Apr-2007 플랫폼 버전 LINUX AS4.0
업데이트 날짜 06-Aug-2008 기본 버그 -
데이터베이스 버전 10.2.0.2
영향을 받는 플랫폼 Generic
제품 소스 Oracle

관련 제품 표시 관련 제품


라인 Oracle Database Products 제품군 Oracle Database
영역 Oracle Database 제품 5 - Oracle Server - Enterprise Edition

Hdr: 5969934 10.2.0.2 RDBMS 10.2.0.2 DATA PUMP EXP PRODID-5 PORTID-46
Abstract: EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK

*** 04/02/07 10:22 pm ***
TAR:
----

PROBLEM:
--------
1. Clear description of the problem encountered:

    EXPDP client gets UDE-00008 and ORA-31626 while the server side export is
OK.
    The export log from the server side looks OK.

    // client console log
    ------------------------------
    UDE-00008: operation generated ORACLE error 31626
    ORA-31626: job does not exist
    ORA-39086: cannot retrieve job information
    ORA-6512: at "SYS.DBMS_DATAPUMP", line 2745
    ORA-6512: at "SYS.DBMS_DATAPUMP", line 3712
    ORA-6512: at line 1
    ------------------------------

2. Pertinent configuration information (MTS/OPS/distributed/etc)

    2-node RAC

3. Indication of the frequency and predictability of the problem 

    100% reproducible at the customer's site.

4. Sequence of events leading to the problem 

    Please see attached trace files.


DIAGNOSTIC ANALYSIS:
--------------------
No error in alert log on both nodes.

The following is the output of expdp with trace=EB0300.
Deleting queue from the master table fails, same as BUG 5663241.

// expdep command line
expdp \'sys/XXX as sysdba\' trace=EB0300
DUMPFILE=work_app_dmp:20070330_expdp_err_test.dmp
FULL=y LOGFILE=work_app_dmp:20070330_expdp_err_test.log

// trace of Master Control Process
------------------------------
KUPM: 17:54:40.520: Closing job....
KUPM: 17:54:40.520: Final state in Close_job is:  COMPLETED
KUPM: 17:54:40.520: dropping master since job never started
KUPM: 17:54:40.520: keep_master_flag = FALSE
KUPM: 17:54:40.520: Delete files = FALSE
KUPM: 17:54:40.520: File subsystem shutdown
KUPM: 17:54:40.520: In set_longops
KUPM: 17:54:40.521: Work so far is: 66.80495548248291015625
KUPM: 17:54:40.521: Master delete flag is: TRUE
KUPV: 17:54:40.521: Delete request for job: SYS.SYS_EXPORT_FULL_01
KUPV: 17:54:40.535: Deleting FT job entry
KUPV: 17:54:40.535: Deleting queues
KUPC: 17:54:40.966: Deleted queue SYS.KUPC$C_1_20070330174720.
KUPC: 17:54:40.968: Error Code: -24018
KUPC: 17:54:40.968: Error Text: deleteQueue: ORA-24018: STOP_QUEUE on
SYS.KUPC$S_1_20070330174720 failed, outstanding transactions found
KUPV: 17:54:40.968: Delete request for MT: SYS.SYS_EXPORT_FULL_01
*** 17:54:51.426
KUPM: 17:54:51.426: Fixed views cleaned up
KUPM: 17:54:51.427: Log file is closed.
KUPV: 17:54:51.427: Detach request
KUPV: 17:54:51.434: Deleting FT att entry
------------------------------


Importing a table (TABLES=test_tbl_2) with the dump file
(20070330_expdp_err_test.dmp)
is successfully done, which means that the export is OK regarding the table
(test_tbl_2).

// impdp command line
impdp \'sys/XXX as sysdba\' DUMPFILE=work_app_dmp:20070330_expdp_err_test.dmp

TABLES=test_tbl_2 LOGFILE=work_app_dmp:20070330_impdp_test.log


WORKAROUND:
-----------
None.

RELATED BUGS:
-------------
BUG 5416274
BUG 5663241 (duplicate bug of BUG 5416274)

REPRODUCIBILITY:
----------------
reproduced twice at customer's site.
CT says every time expdp was done, this phenomenon occured.

TEST CASE:
----------

STACK TRACE:
------------

SUPPORTING INFORMATION:
-----------------------
I will be loading the following files:
dbram01_dm00_19485.trc
dbram01_dw01_19569.trc
expdp.txt
imp.txt

24 HOUR CONTACT INFORMATION FOR P1 BUGS:
----------------------------------------

DIAL-IN INFORMATION:
--------------------

IMPACT DATE:
------------

*** 04/02/07 10:26 pm ***
*** 04/02/07 10:44 pm ***
*** 04/02/07 10:45 pm ***
*** 04/10/07 01:09 am ***
*** 04/10/07 01:09 am ***
*** 04/10/07 01:20 am ***
*** 04/10/07 01:20 am *** (CHG: Sta->11)
*** 04/10/07 01:20 am ***
*** 04/10/07 01:20 am ***
*** 05/06/07 10:57 pm ***
*** 05/22/07 05:02 pm ***
*** 05/31/07 11:52 pm ***
*** 06/13/07 06:39 pm ***
*** 06/18/07 02:38 am ***
*** 06/18/07 02:38 am ***
*** 06/18/07 02:38 am ***
*** 06/20/07 03:41 am ***
*** 06/20/07 03:50 am ***
*** 07/16/07 06:48 pm ***
*** 07/24/07 06:48 pm ***
*** 08/02/07 09:40 pm ***
*** 08/21/07 06:45 pm ***
*** 09/25/07 07:46 pm ***
*** 10/15/07 06:39 pm ***
*** 11/02/07 05:06 pm ***
*** 11/15/07 01:48 am ***
*** 03/06/08 09:52 pm ***
*** 03/20/08 08:17 am ***
*** 03/20/08 08:17 am ***
*** 05/13/08 11:26 am ***
*** 07/08/08 06:35 am ***
*** 08/06/08 08:35 am ***
*** 08/06/08 09:21 am *** (CHG: Sta->44)
*** 08/06/08 09:21 am ***
In the 10.2.0.2 release, there were a number of problems that caused the
expdp and impdp clients to exit prematurely, interpreting a nonfatal error as
a fatal one, giving the appearance that the job had failed when it hadn't. In
fact, inspection of the log file, if one was specified for the job, showed
that the job ran successfully to completion. Often a trace file written by
one of the Data Pump processes would provide more detail on the error that
had been misinterpreted as a fatal one. Many of these errors involved the
queues used for communication between the Data Pump processes, but there were
other issues as well.

With each subsequent release, these problems have been addressed, and the
client has become more robust and rarely, if ever, runs into situations like
this. However, this is the result of dozens of bug fixes in subsequent
releases, some in Data Pump and some in supporting layers. It's impossible to
know, at this point, what combination of bug fixes would address this
specific failure, and even if that was possible, it wouldn't address other
possible failures that look very similar on the client side.

Relying on information in the log file is one way to verify that the job
actually completed successfully. Problems like this one became much more
intermittent by the 10.2.0.4 and 10.2.0.5 releases and are rarely, if ever,
seen in 11.1 or later.



출처 : Oracle Support


:     

TISTORY에 Login하려면 여기를 누르세요.


DataPump Export (EXPDP) Client Gets UDE-8 ORA-31626 ORA-39086 [ID 549781.1]

Oracle 2011. 8. 11. 15:19

수정 날짜 29-APR-2010     유형 PROBLEM     상태 PUBLISHED  


Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.2 to 11.1.0.7 - Release: 10.2 to 11.1
Information in this document applies to any platform.

Symptoms

Datapump export from the client side completes with errors. Example:

expdp system/password full=y dumpfile=full_exp.dmp logfile=full_explog

...
. . exported "CALYPSO"."KICKOFF_CFG" 0 KB 0 rows 
. . exported "CALYPSO"."LE_AGR_CHILD" 0 KB 0 rows 
. . exported "CALYPSO"."LE_ATTR_CODE" 0 KB 0 rows 

UDE-00008: operation generated ORACLE error 31626 
ORA-31626: job does not exist 
ORA-39086: cannot retrieve job information 
ORA-06512: at "SYS.DBMS_DATAPUMP", line 2745 
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3712 
ORA-06512: at line 1

However, reviewing the logfile shows that the "job successfully completed"

Cause

This issue has been discussed in Bug 5969934 EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK

Solution

The expdp client makes calls to DBMS_DATAPUMP package to start and monitor export job. Once the export job is underway, the client just monitors the job status by issuing DBMS_DATAPUMP.GET_STAUS.
Therefore, if the export logfile says "job successfully completed", the dump file generated by the job should be fine.


You can simply ignore the errors, since the dump file is still valid for an import.

In the 10.2.0.2 release, there were a number of problems that caused the expdp and impdp clients to exit prematurely, interpreting a nonfatal error as a fatal one, giving the appearance that the job had failed when it hadn't. In fact, inspection of the log file, if one was specified for the job, showed that the job ran successfully to completion. Often a trace file written by one of the Data Pump processes would provide more detail on the error that had been misinterpreted as a fatal one. Many of these errors involved the queues used for communication between the Data Pump processes, but there were other issues as well. 
.
With each subsequent release, these problems have been addressed, and the client has become more robust and rarely, if ever, runs into situations like this. However, this is the result of many bug fixes in subsequent releases, some in Data Pump and some in supporting layers. It's impossible to know, at this point, what combination of bug fixes would address this specific failure, and even if that was possible, it wouldn't address other possible failures that look very similar on the client side. 
.
Relying on information in the log file is one way to verify that the job actually completed successfully. Problems like this one became much more intermittent by the 10.2.0.4 release and are rarely, if ever, seen in 11.1 or later.

References

BUG:5969934 - EXPDP CLIENT GETS UDE-00008 ORA-31626 WHILE THE SERVER SIDE EXPORT IS OK

관련 정보 표시 관련 자료


제품
  • Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
오류
UDE-8; ORA-6512; ORA-31626; ORA-39086; ERROR 31626

출처 : Oracle Support


Data Pump에 생각보다 많은 Bug들이 있다. 하지만, 성능상으로는 이런 Bug들을 감수할만큼 효율적이니 잘 피해서 사용해보자.
:     

TISTORY에 Login하려면 여기를 누르세요.


Oracle 10gR2이상에서 Automatic Tuning of Undo_retention Causes Space Problems

Oracle 2011. 8. 11. 11:39

Subject: Automatic Tuning of Undo_retention Causes Space Problems
  Doc ID: Note:420525.1 Type: PROBLEM
  Last Revision Date: 26-MAY-2008 Status: PUBLISHED

 


Applies to:

Oracle Server - Enterprise Edition - Version: 10.2 to 11.0
This problem can occur on any platform.

 

Symptoms

Look for: 

1.) System Managed Undo 
undo_management=auto in init.ora file 

2.) Fixed size undo tablespace
SQL> select autoextensible from dba_data_files where tablespace_name='<current_undo_tablespace >' 

returns "No" for all the undo tablespace datafiles. 

3.) The undo tablespace is already sized such that it always has more than enough space to store all the undo generated within the undo_retention time, and the in-use undo space never exceeds the undo tablespace warning alert threshold (see below for the query to show the thresholds). 

4.) The tablespace threshold alerts recommend that the DBA add more space to the undo tablespace: 

SQL> select creation_time, metric_value, message_type,reason, suggested_action from dba_outstanding_alerts where object_name='<current_undo_ts>'; 

returns a suggested action of: "Add space to the tablespace" 

Or,

This recommendation has been reported in the past but the condition has now cleared: 
SQL> select creation_time, metric_value, message_type, reason, suggested_action, resolution from dba_alert_history where object_name='<current_undo_ts>'; 

5.) The undo tablespace in-use space exceeded the warning alert threshold at some point in time: 

To see the warning alert percentage threshold: 

SQL> select object_type, object_name, warning_value, critical_value from dba_thresholds where object_type='TABLESPACE'; 

To see the (current) undo tablespace percent of space in-use: 
SQL> select 
((select (nvl(sum(bytes),0)) 
from dba_undo_extents 
where tablespace_name='<current_undo_ts>' 
and status in ('ACTIVE','UNEXPIRED')) *100) / 
(select sum(bytes) 
from dba_data_files 
where tablespace_name='<current_undo_ts>') 
"PCT_INUSE" 
from dual;

Cause

This is due to Bug 5387030 that is fixed in 11.1 version of RDBMS server.

 

Solution

Apply the patch for the Bug 5387030. Check metalink for patch availability for your platform and RDBMS version.

Workaround

There are 3 possible alternate workarounds (any one of these should resolve the problem of the alerts triggering unnecessarily): 

1.) Set the autoextend and maxsize attribute of each datafile in the undo ts so it is autoextensible and its maxsize is equal to its current size so the undo tablespace now has the autoextend attribute but does not autoend: 
SQL> alter database datafile '<datafile_flename>' 
autoextend on maxsize <current_size>; 

With this setting, v$undostat.tuned_undoretention is not calculated based on a percentage of the undo tablespace size, instead v$undostat.tuned_undoretention is set to the maximum of (maxquerylen secs + 300) undo_retention specified in init.ora file.

2.) Set the following hidden parameter in init.ora file: 
_smu_debug_mode=33554432 

or 

SQL> Alter system set "_smu_debug_mode" = 33554432; 

With this setting, v$undostat.tuned_undoretention is not calculated based on a percentage of the fixed size undo tablespace, instead v$undostat.tuned_undoretention is set to the maximum of (maxquerylen secs + 300) undo_retention specified in init.ora file.

3.) Set the following hidden parameter in init.ora: 
_undo_autotune = false 

or 

SQL> Alter system set "_undo_autotune" = false; 

With this setting, v$undostat (and therefore v$undostat.tuned_undoretention) is not maintained and and the undo_retention used is the one specified in init.ora file.

 

References

Bug 5387030 - AUTOMATIC TUNING OF UNDO_RETENTION CAUSING SPACE PROBLEMS




출처 : Oracle Support


alter system set "_IN_MEMORY_UNDO"=false;
Alter system set "_undo_autotune" = false;
:     

TISTORY에 Login하려면 여기를 누르세요.


EXPDP for a large table fails with ORA-1555

Oracle 2011. 8. 11. 11:30

수정 날짜 20-MAY-2010     유형 PROBLEM     상태 PUBLISHED  


Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4 - Release: 10.2 to 10.2
Information in this document applies to any platform.

Symptoms

Running an expdp on a certain table usually takes an hour.
However, it now runs for over a day. The problem appears to be with one table (the largest in the database).
When the expdp is started the first table that it processes has an estimated process time of over 24hrs.

When the same export is run from two other servers, it shows the elapsed time for the same table as around 20 minutes


ERROR
-----------------------
Processing object type SCHEMA_EXPORT/TABLE/MATERIALIZED_VIEW_LOG
ORA-31693 : Table data object "MERIDIAN"."LINEPAST" failed to load/unload and is being skipped due to error:
ORA-02354 : error in exporting/importing data
ORA-01555 : snapshot too old: rollback segment number 1 with name "_SYSSMU1$" too small

The table does not have any LOB columns.
Increasing the undo_retention parameter did not help.

Changes

Most of the rows in the table were recently updated.

Cause

Updating the rows in the table have caused high fragmentation (chained/migrated rows), which increased significantly the time to perform the export of this table.

Solution

1.Recreate the fragmented table through : 
SQL> create table <new_table_name> as (select * from <fragmented_table);

then drop the fragmented table.

You may re-name the <new_table_name> to the old table name.

2. Perform the expdp job. (this time it ended in few minutes) 

You may also refer to Note 746778.1 How to Identify, Avoid and Eliminate Chained and Migrated Rows ?

References

NOTE:746778.1 - How to Identify, Avoid and Eliminate Chained and Migrated Rows ?

관련 정보 표시 관련 자료


제품
  • Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
오류
ORA-31693; ORA-2354; ORA-1555

출처 : oracle support


                                                         ('' ) NOTE:746778.1의 내용

:     

TISTORY에 Login하려면 여기를 누르세요.


[Oracle Dictionary] PL/SQL과 Table간의 Dependency 정보 확인

Oracle 2011. 2. 22. 17:52

PL/SQL을 이용하여 생성한 Package, Procedure, Function 등 다양한 OBJECTS와 Tables간의

Dependency 정보를 확인하기 위해서 어떻게 해야 할까??

개발할 때 마다, 이를 관리하기 위한 정보를 생성해??

아니다. Oracle Dictionary 중에서 "USER_DEPENDENCIES"를 조회하면 된다.

USER_OBJECTS나 USER_TABLES 정보와 잘 Join해서 검색한다면 보다 다양한 형태로 원하는 Dependency

정보를 확인해볼 수 있을 것입니다.

그러면 이쯤에서 하나 더....

Package나 Procedure, Function등을 개발하고, 이를 Input Parameter를 Application 개발자에게 문서로

전달해야 한다면 어떻게 할 것인가??

Source를 일일이 하나씩 열어서 문서로 옮겨 적어??     

Oh~~ No!!

눈치 빠른 분이라면 이미 아시겠지만, 이 또한 Dictionary 중에서 USER_ARGUMENTS 정보를 이용하면 된다.

Oracle로 개발하고, 이를 문서화하고자 한다면 일단 Dictionary에 있는 정보를 잘 참고해보도록 하자.

정말 존재하지 않는 Data를 문서화 하려고 한다면야 어쩔 수 없겠지만, 활용할 수 있는 정보들이 있음에도

불구하고 일일이 백지에 Typing으로 입력하려면 그야 말로 "머리가 나쁘면 손발이 고생한다"는 속담을

상기시켜주는 꼴이다.

제발 이렇게 시간 낭비하지 말자. 개발만 해도 부족한 시간 아니던가....



:     

TISTORY에 Login하려면 여기를 누르세요.


Oracle REF CURSOR

Oracle 2011. 2. 18. 10:45

With the REF_CURSOR you can return a recordset/cursor from a stored procedure.

There are 2 basic types: Strong ref cursor and weak ref cursor
For the strong ref cursor the returning columns with datatype and length need to be known at compile time.
For the weak ref cursor the structure does not need to be known at compile time.

The STRONG_REF_CURSOR and until Oracle 9i also the weak-type need to be declared in a package structure lik this:

create or replace
package REFCURSOR_PKG as
      TYPE WEAK8i_REF_CURSOR   IS REF CURSOR;
      TYPE STRONG_REF_CURSOR IS REF CURSOR RETURN EMP%ROWTYPE;
end REFCURSOR_PKG;

The pl/sql procedure that returns a ref-cursor looks like this:

/** until Oracle 9 */
create or replace
procedure test( p_deptno IN number,
                      p_cursor  OUT REFCURSOR_PKG.WEAK8i_REF_CURSOR)
is
begin
     open p_cursor FOR
     select *
     from   emp
     where  deptno = p_deptno;
end test;


Since Oracle 9i you can use SYS_REFCURSOR as the type for the returning REF_CURSOR.

/** From Oracle 9 */
create or replace
procedure test( p_deptno IN number,
                      p_cursor OUT SYS_REFCURSOR)
is
begin
      open p_cursor FOR
      select *
      from   emp
      where  deptno = p_deptno;
end test;


/* Strong type */
create or replace
procedure test( p_deptno  IN number,
                      p_cursor  OUT REFCURSOR_PKG.STRONG REF_CURSOR)
is
begin
      open p_cursor FOR
      select *
      from   emp
      where  deptno = p_deptno;
end test;

Selecting the ref_cursor from JDBC
To get the cursor from Java you can use the following JDBC-code:

public void method() throws SQLException{
  Connection conn = getConnection();
  CallableStatement cstmt = null;
  ResultSet rs = null;
  int deptno = 10;
  Object temp;
  try{
      cstmt = conn.prepareCall("begin  test(?,?); end;");
      cstmt.setInt(1, deptno);
      cstmt.registerOutParameter(2, OracleTypes.CURSOR);
      cstmt.execute();
      rs = (ResultSet) cstmt.getObject(2);
      ResultSetMetaData rsm = rs.getMetaData();
      int columnCount = rsm.getColumnCount();
      while (rs.next()){
         for (int j=0;j< columnCount;j++){
            temp = rs.getObject(j+1);
         }
      }
  } finally {
      if (!rs==null){
        rs.close();
      }
      if (!stmt==null){
        stmt.close();
      }
      if (!conn==null){
        conn.close();
      } 
  }
}
Calling ref-cursor from pl/sql
create or replace procedure test_call is
  c_cursor REFCURSOR_PKG.STRONG_REF_CURSOR;
  r_emp    c_emp%rowtype;
begin
  test(10,c_cursor);
  loop
    fetch c_cursor into r_emp;
    exit when c_cursor%notfound;
    dbms_output.put_line(r_emp.name);
  end loop;
  close c_cursor;
end test_call;

출처 : http://www.oradev.com/ref_cursor.jsp

 

:     

TISTORY에 Login하려면 여기를 누르세요.


[Oracle9i] Update구문의 Returning Clause

Oracle 2011. 2. 18. 10:31
Oracle9iR2 Documents에서 SQL Reference 문서를 찾은 후, UPDATE 구문에 대한 설명을

확인해보시면, Update 구문이 아래와 같은 구조를 같는다고 설명이 되어 있습니다.

오른쪽 하단에 보시면 Returning_Clause라고 존재하죠.


Text description of statements_1026.gif follows

하지만, 실제로는 많이 사용되지도 않을 뿐더러, 각 교육기관을 통해서 배울 때, 대부분 알고 있듯이

UPDATE table_name SET update_contents WHERE where_clause;

로만 보아왔고, 사용하셨을 것입니다.

Returning_Clause를 잘 사용하면 도움이 될 수 있으니 일단 알고 넘어가도록 하겠습니다.

      UPDATE employees
            SET job_id ='SA_MAN', salary = salary + 1000, department_id = 140
       WHERE last_name = 'Jones'
 RETURNING salary*0.25, last_name, department_id
           INTO :bnd1, :bnd2, :bnd3;

위의 SQL문을 확인해보면 아래와 같습니다.

last_name이 'Jones'인 사람을 찾아서 jod_id와 salary, department_id 값을 변경해주고,

bnd1, bnd2, bnd3의 변수에 salary*0.25, last_name, department_id 값을 Return 하도록 작성된

것입니다.

흔히 이와 같은 형태를 구현할 때, 아래와 같이 2개의 SQL문을 작성하여 처리하는 경우가 많습니다.

      UPDATE employees
            SET job_id ='SA_MAN', salary = salary + 1000, department_id = 140
       WHERE last_name = 'Jones';

      SELECT salary*0.25, last_name, department_id
           INTO :bnd1, :bnd2, :bnd
         FROM employees
       WHERE last_name = 'Jones'; 


하지만, 동일한 Table에 2번을 접근해야 한다는 점에서 비효율적이죠.

이럴 때, 앞서 제시한 예제 구문처럼 Returning Clause를 이용한다면 보다 효율적으로 작업을 진행할

수 있을듯 합니다.

단, 아래와 같은 경우에는 Returning Clause를 사용할 수 없으니 숙지하시기 바랍니다.

(생각해보면 당연하게 받아 들여질 수 있는 내용입니다.)

  • Specify the returning_clause for a multitable insert.
  • Use this clause with parallel DML or with remote objects.
  • Retrieve LONG types with this clause.
  • Specify this clause for a view on which an INSTEAD OF trigger has been defined.
 
:     

TISTORY에 Login하려면 여기를 누르세요.