웹 개발과 관련된 모든 것들

입력되는 테이블을 NoLogging 상태로 만들기

alter table  TFEI_TEMP_SND_RCV_FILE nologging;

append 힌트 사용하기

대용량 데이타를 insert 할 경우는 시간이 매우 많이 걸리게 된다.

 그러다가 temp 사이즈나 데이타 오류로 인해 에러가 나더라도

바로 에러를 밷는것이 아니라 롤백을 모두 한후에야

에러를 나타낸다.
 

총 insert 하는 데 걸리는 시간이 3시간이라면

2시간 진행된 작업이 잘못 됐다는걸 알았다(또는 에러가 났다는걸 알았다)

그러면 바로 에러를 뱉어내는 것이 아니라 롤백을 2시간 해주어야 된다

즉..  잘못된 insert 작업을 2시간 하다가 취소하면 2시간 기다려야(롤백하느라) 된다는 것이다..

얼마나 짜증나는 일인가???
 

해답이 있다 APPEND 를 쓰면 된다.

insert /*+append*/ into aaa

select * from ......

append 힌트는 롤백을 쌓지않고 바로 테이블스페이스에 저장하게 된다.

취소할 경우에는 그동안 저장된 데이타만 날리기때문에 취소도 즉시 된다.

정말 빠르다~~

하지만 단점이 있으니....

롤백을 쌓는 insert 의 경우에는 얼마나 작업이 진행됐는지 롤백 세그먼트 크기를

보면서 모니터를 할 수 있다.

하지만 append 는 롤백을 쌓지 않기 때문에 얼마나 진행됐는지 확인하기가 쉽지 않다.

한가지 힌트가 있다면

insert 되는

테이블의 크기라 1024M 이고 익스텐트를 128M이라면

insert 되는 데이타가 1024M의 용량을 넘었다면 익스텐트를 일으키기 때문에

extend 를 하는지 안하는지를 보면 작업이 어느정도 진행되는지 알수 있다.

출처 : 일부 나... 그외

http://shinyoung.kr/514

또한 프로세스 개수가 넉넉하다면 PARALLEL 옵션을 주면 더욱 좋다 ㅋ

한번에 여러개의 레코드를 취득할수 있으므로 퍼포먼스 향상

Patten 1

Patten 2

Patten 3 커서 이용

즉,커서를 이용할시 취득할 데이터 수가 많을듯하면 Limit를 사용하여 일정 레코드 단위로

Fetch하는 것이 성능면에서 좋다.

FETCH emp_cur BULK COLLECT INTO emp_tbl LIMIT 100;

출처 : http://avang.tistory.com/65

참고로 대량의 입력 구문을 만들때도 유용하며

APPEND 힌트를 쓰면 아주 아주 좋다 !!!

rem -----------------------------------------------------------------------
rem Filename:   bulkbind.sql
rem Purpose:    Simple program to demonstrate BULK COLLECT and BULK BIND.
rem Notes:      Bulk operations on ROWTYPE only work from and above.
rem Date:       12-Feb-2004
rem Author:     Frank Naude, Oracle FAQ
rem -----------------------------------------------------------------------
set serveroutput on size 50000

DECLARE
  CURSOR emp_cur IS SELECT * FROM EMP;

  TYPE emp_tab_t IS TABLE OF emp%ROWTYPE INDEX BY BINARY_INTEGER;
  emp_tab emp_tab_t;            -- In-memory table

  rows NATURAL        := 10000;   -- Number of rows to process at a time
  i    BINARY_INTEGER := 0;
BEGIN
  OPEN emp_cur;
  LOOP
    -- Bulk collect data into memory table - X rows at a time
    FETCH emp_cur BULK COLLECT INTO emp_tab LIMIT rows;
    EXIT WHEN emp_tab.COUNT = 0;

    DBMS_OUTPUT.PUT_LINE( TO_CHAR(emp_tab.COUNT)|| ' rows bulk fetched.');

    FOR i IN emp_tab.FIRST .. emp_tab.LAST loop
      -- Manipumate data in the memory table...
      dbms_output.put_line('i = '||i||', EmpName='||emp_tab(i).ename);
    END LOOP;

    -- Bulk bind of data in memory table...
    FORALL i in emp_tab.FIRST..emp_tab.LAST
      INSERT /*+APPEND*/ INTO emp2 VALUES emp_tab(i);

  END LOOP;
  CLOSE emp_cur;
END;
/

/*

 bulk collection 관련 예제

출처 : http://hany4u.blogspot.com/2008/11/bulk-collect-and-bulk-bind.html

*/

Implicit Cursor가 Explicit Cursor에 비해 성능이 뛰어나다는 언급을 여러 번 봤을 것이다.

실제로도 그렇다.
하지만 왜 그런가?

간단한 테스트로 많은 것을 알 수 있다.

우선 다음과 같이 필요한 Object를 생성한다.

view plaincopy to clipboardprint?

1. @ukja102   
2.   
3. drop table t1 purge;   
4. create table t1(c1 int, c2 char(10));   
5. insert into t1   
6. select level, 'dummy'  
7. from dual   
8. connect by level <= 200000;   
9. commit;   
10. select count(*) from t1;  

@ukja102

drop table t1 purge;
create table t1(c1 int, c2 char(10));
insert into t1
select level, 'dummy'
from dual
connect by level <= 200000;
commit;
select count(*) from t1;

Implicit Cursor를 사용하는 경우와 Exlicit Cursor를 사용하는 경우의 성능을 비교해 보자.

view plaincopy to clipboardprint?

1. -- Implicit Cursor를 사용하는 경우   
2. @ukja102   
3. @mysid   
4. @mon_on &v_sid   
5.   
6. begin  
7.   for r in (select * from t1) loop   
8.     null;   
9.   end loop;   
10. end;   
11. /   
12.   
13. @mon_off   
14. spool result1.txt   
15. @mon_show   
16. spool off  
17.   
18.   
19. @ukja102   
20. @mysid   
21. @mon_on &v_sid   
22.   
23. -- Explicit Cursor를 사용하는 경우   
24. declare  
25.   cursor v_cursor is  
26.     select * from t1   
27.   ;   
28.      
29.   v_rec v_cursor%rowtype;   
30. begin  
31.   open v_cursor;   
32.   loop   
33.     fetch v_cursor into v_rec;   
34.     exit when v_cursor%notfound;   
35.   end loop;   
36.   close v_cursor;   
37. end;   
38. /   
39.   
40. @mon_off   
41. spool result2.txt   
42. @mon_show   
43. spool off  

-- Implicit Cursor를 사용하는 경우
@ukja102
@mysid
@mon_on &v_sid

begin
  for r in (select * from t1) loop
    null;
  end loop;
end;
/

@mon_off
spool result1.txt
@mon_show
spool off


@ukja102
@mysid
@mon_on &v_sid

-- Explicit Cursor를 사용하는 경우
declare
  cursor v_cursor is
    select * from t1
  ;
  
  v_rec v_cursor%rowtype;
begin
  open v_cursor;
  loop
    fetch v_cursor into v_rec;
    exit when v_cursor%notfound;
  end loop;
  close v_cursor;
end;
/

@mon_off
spool result2.txt
@mon_show
spool off

여기서 한가지 질문을 던진다.

성능을 어떻게 비교할 것인가?

불행하게도 많은 사람들이 시작시간과 끝시간을 재는 것으로 만족한다. 그러지 말자.

Oracle은 성능을 비교하기 위한 많은 뷰들을 제공한다. 이들을 잘 활용해야 한다.

우선 v$sess_time_model 뷰를 통해 Time 정보를 비교한다. 이 뷰를 이용하면 별도의 코드를 통해 시간을 측정하지 않아도 된다.

view plaincopy to clipboardprint?

1. -- Implicit Cursor를 사용한 경우   
2. STAT_NAME                                      VALUE1       VALUE2         DIFF   
3. ---------------------------------------- ------------ ------------ ------------   
4. DB time                                        59,773    1,777,125    1,717,352   
5. sql execute elapsed time                       40,140    1,721,534    1,681,394   
6. DB CPU                                         51,929    1,683,972    1,632,043   
7. parse time elapsed                             42,324      256,573      214,249   
8.   
9. -- Explicit Cursor를 사용한 경우   
10. STAT_NAME                                      VALUE1       VALUE2         DIFF   
11. ---------------------------------------- ------------ ------------ ------------   
12. DB time                                        29,622    6,051,808    6,022,186   
13. sql execute elapsed time                       25,827    6,044,618    6,018,791   
14. DB CPU                                         29,331    6,034,029    6,004,698   
15. PL/SQL execution elapsed time                      60      558,753      558,693   
16. parse time elapsed                              1,509      131,440      129,931  

-- Implicit Cursor를 사용한 경우
STAT_NAME                                      VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
DB time                                        59,773    1,777,125    1,717,352
sql execute elapsed time                       40,140    1,721,534    1,681,394
DB CPU                                         51,929    1,683,972    1,632,043
parse time elapsed                             42,324      256,573      214,249

-- Explicit Cursor를 사용한 경우
STAT_NAME                                      VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
DB time                                        29,622    6,051,808    6,022,186
sql execute elapsed time                       25,827    6,044,618    6,018,791
DB CPU                                         29,331    6,034,029    6,004,698
PL/SQL execution elapsed time                      60      558,753      558,693
parse time elapsed                              1,509      131,440      129,931

Implicit Cursor가 모든 면에서 Explicit Cursor에 비해 현격한 성능 우위를 보이는 것을 알 수 있다.

그 이유가 무엇인지 가장 쉽게 알 수 있는 방법은?
Statistics을 봐야 한다. v$sesstat 뷰를 통해 본 차이는 다음과 같다.

view plaincopy to clipboardprint?

1. -- Implicit Cursor인 경우                                                                                  
2. NAME                                           VALUE1       VALUE2         DIFF   
3. ---------------------------------------- ------------ ------------ ------------   
4. table scan rows gotten                             62      914,002      913,940   
5. session pga memory max                      1,826,388    2,154,068      327,680   
6. session uga memory max                      1,282,300    1,544,264      261,964   
7. session pga memory                          1,826,388    1,957,460      131,072   
8. session logical reads                             275        3,249        2,974   
9.   
10. -- Explicit Cursor인 경우   
11. NAME                                           VALUE1       VALUE2         DIFF   
12. ---------------------------------------- ------------ ------------ ------------   
13. table scan rows gotten                             62   69,366,045   69,365,983   
14. session pga memory max                      1,498,708    1,891,924      393,216   
15. session pga memory                          1,498,708    1,891,924      393,216   
16. session uga memory max                      1,151,372    1,413,336      261,964   
17. session logical reads                              72      200,261      200,189  

-- Implicit Cursor인 경우                                                                               
NAME                                           VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
table scan rows gotten                             62      914,002      913,940
session pga memory max                      1,826,388    2,154,068      327,680
session uga memory max                      1,282,300    1,544,264      261,964
session pga memory                          1,826,388    1,957,460      131,072
session logical reads                             275        3,249        2,974

-- Explicit Cursor인 경우
NAME                                           VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
table scan rows gotten                             62   69,366,045   69,365,983
session pga memory max                      1,498,708    1,891,924      393,216
session pga memory                          1,498,708    1,891,924      393,216
session uga memory max                      1,151,372    1,413,336      261,964
session logical reads                              72      200,261      200,189

차이가 무엇인가?
놀랍게도 일량(Reads)의 차이가 절대적이라는것을 알 수 있다. logical reads가 10배 정도 차이나며 그 차이로 인해 성능의 차이가 왔다.

이 차이는 어디서 온 것인가?
Fetch Array Size에서 온 것이다. 한번에 많은 로우를 Fetch하면 Block을 방문해야할 횟수가 줄어들며 그만큼 Logical Reads가 줄어든다. Implicit Cursor를 사용하는 경우에 Oracle은 내부적으로 10개를 한번에 Fetch한다. 반면에 Explicit Cursor를 사용하는 경우에는 한번에 한 개의 Row만 Fetch한다. 그 결과로 Logical Reads가 대략 10배의 차이가 나게 된다. 그 만큼 성능이 느린 것이다.

Explicit Cursor를 Implicit Cursor보다 빠르게 하는 유일한 방법은 Bulk Collection을 사용하는 것이다. 아래와 같이...

view plaincopy to clipboardprint?

1. @ukja102   
2. @mysid   
3. @mon_on &v_sid   
4.   
5. declare  
6.   cursor v_cursor is  
7.     select * from t1   
8.   ;   
9.      
10.   type c1tab is table of t1.c1%type;   
11.   type c2tab is table of t2.c2%type;   
12.      
13.   c1t c1tab;   
14.   c2t c2tab;   
15.      
16. begin  
17.   open v_cursor;   
18.   fetch v_cursor bulk collect into c1t, c2t; -- Do it bulk!!!   
19.   close v_cursor;   
20. end;   
21. /   
22.   
23. @mon_off   
24. spool result3.txt   
25. @mon_show   
26. spool off  

@ukja102
@mysid
@mon_on &v_sid

declare
  cursor v_cursor is
    select * from t1
  ;
  
  type c1tab is table of t1.c1%type;
  type c2tab is table of t2.c2%type;
  
  c1t c1tab;
  c2t c2tab;
  
begin
  open v_cursor;
  fetch v_cursor bulk collect into c1t, c2t; -- Do it bulk!!!
  close v_cursor;
end;
/

@mon_off
spool result3.txt
@mon_show
spool off

결과는 다음과 같다.

view plaincopy to clipboardprint?

1. -- Implicit Cursor를 사용한 경우   
2. STAT_NAME                                      VALUE1       VALUE2         DIFF   
3. ---------------------------------------- ------------ ------------ ------------   
4. DB time                                        59,773    1,777,125    1,717,352   
5. sql execute elapsed time                       40,140    1,721,534    1,681,394   
6. DB CPU                                         51,929    1,683,972    1,632,043   
7. parse time elapsed                             42,324      256,573      214,249   
8.   
9. -- Explicit Cursor + Bulk Collection을 사용한 경우   
10. STAT_NAME                                      VALUE1       VALUE2         DIFF   
11. ---------------------------------------- ------------ ------------ ------------   
12. DB time                                        28,024    1,503,542    1,475,518   
13. DB CPU                                         18,620    1,489,167    1,470,547   
14. sql execute elapsed time                       24,547    1,493,775    1,469,228   
15. PL/SQL execution elapsed time                      59        5,512        5,453   
16. parse time elapsed                              1,302        4,793        3,491  

-- Implicit Cursor를 사용한 경우
STAT_NAME                                      VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
DB time                                        59,773    1,777,125    1,717,352
sql execute elapsed time                       40,140    1,721,534    1,681,394
DB CPU                                         51,929    1,683,972    1,632,043
parse time elapsed                             42,324      256,573      214,249

-- Explicit Cursor + Bulk Collection을 사용한 경우
STAT_NAME                                      VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
DB time                                        28,024    1,503,542    1,475,518
DB CPU                                         18,620    1,489,167    1,470,547
sql execute elapsed time                       24,547    1,493,775    1,469,228
PL/SQL execution elapsed time                      59        5,512        5,453
parse time elapsed                              1,302        4,793        3,491

Bulk Collection과 함께 Explicit Cursor를 사용한 경우 오히려 성능이 더 뛰어나다. 그 이유는?

view plaincopy to clipboardprint?

1. -- Implicit Cursor인 경우                                                                                  
2. NAME                                           VALUE1       VALUE2         DIFF   
3. ---------------------------------------- ------------ ------------ ------------   
4. table scan rows gotten                             62      914,002      913,940   
5. session pga memory max                      1,826,388    2,154,068      327,680   
6. session uga memory max                      1,282,300    1,544,264      261,964   
7. session pga memory                          1,826,388    1,957,460      131,072   
8. session logical reads                             275        3,249        2,974   
9.   
10. -- Explicit Cursor + Bulk Collection인 경우   
11. NAME                                           VALUE1       VALUE2         DIFF   
12. ---------------------------------------- ------------ ------------ ------------   
13. session pga memory max                      1,498,708   21,618,260   20,119,552   
14. session uga memory max                      1,151,372    1,478,800      327,428   
15. table scan rows gotten                             62      200,062      200,000  

-- Implicit Cursor인 경우                                                                               
NAME                                           VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
table scan rows gotten                             62      914,002      913,940
session pga memory max                      1,826,388    2,154,068      327,680
session uga memory max                      1,282,300    1,544,264      261,964
session pga memory                          1,826,388    1,957,460      131,072
session logical reads                             275        3,249        2,974

-- Explicit Cursor + Bulk Collection인 경우
NAME                                           VALUE1       VALUE2         DIFF
---------------------------------------- ------------ ------------ ------------
session pga memory max                      1,498,708   21,618,260   20,119,552
session uga memory max                      1,151,372    1,478,800      327,428
table scan rows gotten                             62      200,062      200,000

Bulk Collection을 사용한 경우 한번에 필요한 Row를 Fetch하기 때문에 일량은 현격하게 주는 반면에 많은 양의 메모리(20M)를 사용한다. 그만큼 성능은 개선되었지만 그 대가는 메모리가 되는 셈이다.

위의 테스트 결과는 많은 것을 말해 준다.

• 왜 성능 차이가 나는지는 알아야 하며, 또 알 수 있다.
• 성능의 개선에는 대가가 따르며, 그 대가가 무엇인지도 알 수 있다.
• 성능을 측정하는 다양한 뷰를 잊지 말라. 단순히 시간이나 일량만 보지 말라.
• 자동화하라. Toad나 Orange같은 툴을 사용하지 말고 SQL*Plus를 이용해 [Enter]한번으로 결과가 나오게끔 하라

테스트에 사용한 스크립트는 아래에서 볼 수 있다.

• moninit.sql
• mon_on.sql
• mon_off.sql
• mon_show.sql

<script language=javascript src="http://wiki.ex-em.com/hilite/Scripts/shCore.js">

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

'Advanced Oracle' 카테고리의 다른 글

Deterministic Function의 비밀  (10)	2008/08/18
LOB 데이터와 Cache 속성 - 두번째 이야기  (1)	2008/08/13
Implici vs. Explicit Cursor - Who Wins?  (3)	2008/08/09
Calculationg Clustering Factor Manually  (4)	2008/08/07
10704 Event - Troubleshooting Enqueue Problem  (0)	2008/08/04

출처 : http://ukja.tistory.com/156

아래 내용은 http://home.bcline.com/hoya1/ 의 게시판에 있는 내용으로서 오라클 사용자 분들에게 유용할 것으로 판단되어 올려 둡니다. 참조하시기 바랍니다. 혹시 도움이 되셨다면 원래의 홈페이지에 들리셔서 감사의 말씀 좀 전하도록 하세요. :-)

==============================

ORA-01157 cannot identify data file %s

01157, 00000, "cannot identify data file %s - file not found"

// *Cause: The background process was not able to find one of the data files.

// The database will prohibit access to this file but other files will

// be unaffected. However the first instance to open the database will

// need to access all online data files. Accompanying error from the

// operating system describes why file was not found.

// *Action: Have operating system make file available to database. Then either

// open the database or do ALTER SYSTEM CHECK DATAFILES.

1. 데이타 화일을 백업받아놨다면

--- ERROR위치에 데이타화일을 옮겨 놓고 기동시킨다.

2. 데이타 화일이 없을시

--- 문제의 데이타 화일을 확인후 회이을 오라클상에서 삭제하여 오라클이 정상적으로 가동하도록 만들어 주어야 한다.

가동한 후에는 이 데이타 화일로 구성된 테이블 스페이스도 지워주어야 한다.

1>connect internal

2>startup mount

3>alter database datafile '/oracle/data/user1.dbf' offline drop

4>drop tablespace 테이블스페이스명 including contents;

ORA-1547 Tablesapce에서 Free Space 부족시

***ORA-1547(Failed to allocate extent of sizes% in tablespace ‘USERS’)

***발생원인

1. table이 요구하는 next extent의 크기가 tablespace의 freespace를 초과할때.

2. index생성시 rollback segment나 sort area로 쓰이는 temporay tablespace부족할때

3. SQL*Forms30등을 사용할때, 관련 table을 포함하고 있는 Tool tablespace부족할때 발생한다.

***해결방법

1. 다음 스크립트을 이용해 테이블 스페이스별 프리영역을 체크한다.

SELECT a.tablespace_name,

a.total "Total(Mb)",

a.total - b.free "Used(Mb)",

nvl(b.free,0) "Free(Mb)",

round((a.total - nvl(b.free,0))*100/total,0) "Used(%)"

from ( select tablespace_name,

round((sum(bytes)/1024/1024),0) as total

from dba_data_files

group by tablespace_name) a,

( select tablespace_name,

round((sum(bytes)/1024/1024),0) as free

from dba_free_space

group by tablespace_name) b

where a.tablespace_name = b.tablespace_name(+)

order by a.tablespace_name;

->FREE영역의 사용율을 보고 사용되는 FREE SPACE를 볼수 있다.

2. 해당 테이블 스페이스가 사용하는 SEGMENT를 DBA_SEGMENTS를 이용해 조사하여 불필요하게 혹은 TEMP성으로 생성된 테이블을 DROP한다.

3. 해당 tablespace의 datafile size를 늘려준다

-> alter database datafile ‘users01’ resize 10m;

-> alter tablespace add datafile ‘users02’ to TBLSPACE;

4. table의 next를 check 후 지나치게 큰 next size 조정한다

-> alter table AAA storage ( next 2m);

5. export/Import로 fragmenation을 정리한다.

ORA-00604 error occurred at recursive SQL level %s

// *Cause: An error occurred while processing a recursive SQL statement

// (a statement applying to internal dictionary tables).

// *Action: If the situation described in the next error on the stack

// can be corrected, do so; otherwise contact Oracle Support

이 에러는 내부적으로 SQL명령이 실행될 때 발생한다. 예를 들어 현재 할당된 익스텐트가 가득 차서

다음 익스텐트를 할당 받으려고 할 때 오라클이 다음 익스텐트의 크기와 위치를 결정하기 위하여

SELECT명령을 내리게 되는 것과 같은 경우이다.

이 문제가 발생하 우선 alert.log 화일을 검사하여 ORA-600 과 같은 에러가 발생했는가를 확인한다. ORA-600 에러가 발생했다면 오라클측에 지원을 요청하도록 하고 그렇지 않다면 다른 원인을 검사해 봐야 한다.

가장 먼저 고려할 사항은 ?/dbs/init.ora 화일에 지정된 open_cursors 의 크기를 알아보는 것이다.

이 값이 설정이 안되어 있으면 Default가 50이므로

open_cursors=255

----------------

와 같이 설정하도록 한다. 이 값은 단지 커서의 최대 값을 지정하는 것이므로 커서를 적게 쓰는 프로그램에 아무런 영향을 끼치지 않는다. open_cursors를 변경하고 DB를 Shutdown 하고 Startup 시키면 된다.

* Cursor란 무엇인가?

Cursor는 SQL문장을 실행하기위해 DATABASE가 사용하는 Memory의 영역을 말한다.

DATABASE에서 갖는 Open_Cursor의 Default값은 50이다.

Maximum값은 User가 사용하는 System 에 따라 결정된다.

User의 환경에 따라 Open_Cursor의 적정값을 설정할 필요 있다.

만약 이 방법으로 해결이 안되면 다음의 방법을 따른다.

정확한 에러의 원인을 찾기 위해서 init.ora 화일에 다음과 같은 라인을 추가한다.

events = "604 trace name errorstack"

이렇게 init.ora를 변경하고 DB를 Shutdown 하고 Startup 하면 ORA-604 에러가 발생하는 경우에 자세한 정보를 Trace 화일에 기록해 주므로 이 화일을 검사하여 에러의 원인을 찾을 수 있다.

에러의 다른 원인으로는 init.ora 화일의 파라미터 가운데 DC_FREE_EXTENTS 나 ROW_CACHE_ENQUEUES 의 값이 너무 작게 설정된 경우를 생각해 볼 수 있다.

이와같은 경우는 이들 값을 크게 설정해 주도록 한다.

테이블 스페이스가 가득 차거나 Extent 갯수의 최대 허용값을 초과해서 에러가 발생하는 경우 ORA-604 에러가 함께 발생할 수가 있는데 이와같은 경우에는 이들 문제를 먼저 해결하면 ORA-604 에러는 함께 해결 된다.

**참조:ORACLE BULLETIN NOTES

ORA-12154: TNS:서비스명를 해석할 수 없습니다.

oracle 홈아래 network\admin의 tnsnames.ora file에서 설정한 alias를 해석못한다는 의미입니다.

아마도 tnsnames.ora file에서 설정한 host나 db sid등이 맞는지 확인 해 조세요,,,

< 예제 : TNSNAMES.ORA >

NT_SRV.world =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS =

(COMMUNITY = NTCommun.world)

(PROTOCOL = TCP)

(Host = 127.1.1.10)

(Port = 1521)

)

)

(CONNECT_DATA = (SID = ORCL)

)

)

ORA-01658: unable to create INITIAL extent for segment in tablespace WEBDB01

ORA 01658 ERROR는 다음과 같은 경우에 발생합니다.

* DML 수행시

* OBJECT 생성시

* Forms, Reports, CDE TOOL 수행시

* application. 수행시

ct40:/user4/guest/sdh/sql> oerr ora 01658

01658, 00000, "unable to create INITIAL extent for segment in tablespace %s"

// *Cause: Failed to find sufficient contiguous space to allocate INITIAL

// extent for segment being created.

// *Action: Use ALTER TABLESPACE ADD DATAFILE to add additional space to the

// tablespace or retry with a smaller value for INITIAL

오라클에서 EXTENT를 ALLLOCATE할려구 할시.. 충분한 여유공간이 없어서 생기는 에러입니다..

그럼 원인은

1. WEBDB01에 층분한 여유공간이 없다.

2. INITIAL EXTENT의 크기가 지나치게 크게 잡혔다.

CASE1 :

다음 스크립트로 먼저 FREESPACE를 CHECK하시면 FREE영역이 거의 없음을 확인 할수 있을 겁니다..

SELECT a.tablespace_name,
             a.total "Total(Mb)",
             a.total - b.free "Used(Mb)",
             nvl(b.free,0) "Free(Mb)",
             round((a.total - nvl(b.free,0))*100/total,0)  "Used(%)"
from     (select   tablespace_name, round((sum(bytes)/1024/1024),0) as total
             from     dba_data_files
             group   by tablespace_name) a,
           (select  tablespace_name, round((sum(bytes)/1024/1024),0) as free
            from      dba_free_space
            group by tablespace_name) b
where   a.tablespace_name = b.tablespace_name(+)
order by a.tablespace_name

TABLESPACE_NAME                 Total(Mb)   Used(Mb)   Free(Mb)    Used(%)
------------------------------ ---------- ---------- ---------- ----------
BRS1_CODE                               4          1          3         25
D2K_D1                               2000       1232        768         62
D2K_D2                               2000       1418        582         71
..............................................

WEBDB01에 여유분의 데이타 화일을 추가시키시거나, 불필요하게 그 테이블스페이스를 점유하고

있는 OBJECT를 정리합니다.

CASE2: 
   select SEGMENT_NAME, SEGMENT_TYPE, INITIAL_EXTENT, NEXT_EXTENT
   where TABLESPACE_NAME ='WEBDB01'
   and    SEGMENT_NAME= 'AAA '

로 INITIAL_EXTENT의 크기를 확인해 크게 잡혔다면 작게 사이즈를 조정합니다.

ORA-20003 - The object that you specified is invalid and cannot be described.

1. 호출하고 있는 프로시져의 권한이 있는지, VALID 한지 확인 합니다.

** PROCEDURE 의 INVALID

select count(*) from dba_objects

where status='INVALID';

select object_name,object_type,owner

from dba_objects

where status='INVALID';

OBJECT_NAME OBJECT_TYPE OWNER

----------- ----------- -----

CURSOR_TEST PROCEDURE SCOTT

-> INVALID 하다면 재 컴파일 합니다.

2. 프로시져가 실제로 존재하는지 확인합니다.

3. 포로시져 이름이나 파라미터를 확인합니다.

ora-00102 에러중에서 MTS_DISPATCHERS

발생윈인:

ORA-00101 에러는 MTS_DISPATCHERS 파라미터에 대한 잘못고니 SETTING 으로 발생합니다.

o You are installing 8.1.5 software and creating the default

database on NT (or Linux) and receive the ORA-0101 error.

00101, 00000, "invalid specification for system parameter mts_dispatchers"

// *Cause: The syntax for the "mts_dispatchers" parameter is incorrect.

// *Action: refer to the manual for correct syntax.

o You ignore this error and continue with the install and

immediately receive the ORA-0102 error.

00102, 00000, "network protocol %s cannot be used by dispatchers"

// *Cause: The network specified in "mts_dispatchers" doesn't have the

functionalities required by the dispatchers.

// *Action: refer to the manual on network protocols supported by the

dispatchers.

해결 방법:

Solution Description:

=====================

mts_dispatchers = "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)"

# Uncomment the following line when your listener is configured for

# SSL

# (listener.ora and sqlnet.ora)

# mts_dispatchers =

# "(PROTOCOL=TCPS)(PRE=oracle.aurora.server.SGiopServer)"

mts_servers = 1

o After this you should be able to complete your install without

receiving these errors.

o A possible workaround may be to # out the parameters

mts_dispatchers and mts_servers.

00102 문제에서 log 파일에서 에러와 어떻게 풀어야 할지

## listener.ora

LISTENER =

(ADDRESS_LIST =

(ADDRESS= (PROTOCOL= TCP)(Host=192.168.1.1)(Port= 1521))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(SID_NAME = naun)

(ENVS = 'EPC_DISABLED = TRUE')

)

)

STARTUP_WAIT_TIME_LISTENER = 0

CONNECT_TIMEOUT_LISTENER = 10

TRACE_LEVEL_LISTENER = OFF

## tnsnames.ora

linux.world =

(DESCRIPTION =

(ADDRESS = (PROTOCOL=TCP) (host= 192.168.1.1)(port= 1521))

(CONNECT_DATA =

(SID = naun))

)

이와같이 고치시고 리스너 다시 START후 실행해보세요

ORA-12571: TNS:packet writer failure 에러

LISTENER.ORA and TNSNAMES.ORA,의 IP와 host명을 확인해 보세여

또한

SQLNET.ORA 의 다음 entry를 Client, 서버단에서 모두 제거 하세요..

SQLNET.EXPIRE_TIME=0

출처 : http://database.sarang.net/?inc=read&aid=9199&criteria=oracle&subcrit=&id=&limit=20&keyword=exp+%C6%C4%C0%CF+%B0%CB%BB%E7&page=1

sysaux 테이블스페이스는 오라클 10g 버전을 통하여 새롭게 소개되는 테이블스페이스로서 기존의 시스템 테이블스페이스에 저장되어 관리되어 오던 여러 요소들 가운데, 일부 또는 별도의 테이블스페이스의 생성을 요구하는 이들 요소를 한 공간에 저장, 관리하는 기능을 제공하게 될 시스템 관리 테이블스페이스이다.

sysaux 테이블스페이스에 저장, 관리되어지는 기능은 다음과 같다.

기본적으로 오라클을 설치하면 sysaux 테이블스페이스가 설정되지만, 사용자가 다음과 같이 임의로 데이터 파일의 위치와 이름을 지정하여 만들 수도 있다.

SQL> crerate database jo  2  datafile '/export/home0/oracle/app/oracle/oradata/orcl/jo_system.dbf' size 500M 3  sysaux datafile '/export/home0/oracle/app/oracle/oradata/orcl/jo_sysaux.dbf' size 200M 4  default temporary tablespace temp_ts 5  tempfile '/export/home0/oracle/app/oracle/oradata/orcl/jo_temp.dbf' size 50M 6  undo tablespace undo 7  datafile '/export/home0/oracle/app/oracle/oradata/orcl/jo_undo.dbf' size 100M; 그리고 다음과 같이 이미 생성된 sysaux 테이블스페이스의 공간을 인위적으로 조절할 수 도 있다. SQL> alter tablespace sysaux add datafile 2  '/export/home0/oracle/app/oracle/oradata/orcl/jo_sysaux02.dbf' size 200M; sysaux 테이블스페이스는 다음과 같은 점에 유의해야 한다.

. 일단 데이터베이스를 시작하게 되면 sysaux 테이블스페이스를 제거할 수 없다.
. sysaux 테이블스페이스는 오라클 이동 가능 테이블스페이스(transportable tablespace) 기능을 사용하여 다른 데이터베이스에 이동할 수 없다.
. 데이터베이스가 시작되어진 상태에서 sysaux 테이블스페이스의 이름을 변경(rename)할 수 없다.
. 오라클 10g 버전으로 migration하는 경우 sysaux 테이블스페이스를 생성해 줄 수 있는데 이때 반드시 데이터베이스는 migrate 모드에서 오픈 되어져 있어야 한다.
. sysaux 테이블스페이스에 손상이 발생한 경우 전체 시스템에는 별 영향을 주지 않는다.
단, sysaux 테이블스페이스에 저장, 관리되고 있는 아큐펀트에 대한 기능을 사용할 수 없다.

SQL>  select occupant_name,schema_name from v$sysaux_occupants; 

 
OCCUPANT_NAME      SCHEMA_NAME
------------------ -----------------------
LOGMNR             SYSTEM
LOGSTDBY           SYSTEM
STREAMS            SYS
XDB                XDB
AO                 SYS
XSOQHIST           SYS
XSAMD              OLAPSYS
SM/AWR             SYS
SM/ADVISOR         SYS
SM/OPTSTAT         SYS
SM/OTHER           SYS
STATSPACK          PERFSTAT
ODM                DMSYS
SDO                MDSYS
WM                 WMSYS
ORDIM              ORDSYS
ORDIM/PLUGINS      ORDPLUGINS
ORDIM/SQLMM        SI_INFORMTN_SCHEMA
EM                 SYSMAN
TEXT               CTXSYS
ULTRASEARCH        WKSYS
JOB_SCHEDULER      SYS
 
22 rows selected.
 
SQL>
[출처] sysaux 테이블스페이스란?|작성자 레인보우
 
 
 
 -- 조회방법



select OCCUPANT_NAME,SCHEMA_NAME,SPACE_USAGE_KBYTES from V$sysaux_occupants;


select sum(bytes)/1024/1024/1024 from dba_segments where tablespace_name='SYSAUX';
 

결정 요소 : UNDO_RETENTION, DB_BLOCK_SIZE, 초당 생성되는 UNDO 데이터 블럭 수

SELECT SUM(UNDOBLKS)/SUM((EDN_TIME-BEGIN_TIME)*86400) FROM V$UNDOSTAT;

==> 초당 UNDO 데이터 블럭 수

SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes"

FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'),

          (SELECT (SUM(undoblks)/SUM(((end_time-begin_time)*86400))) AS UPS

           FROM v$undostat),

          (SELECT value AS DBS FROM v$parameter WHERE name = 'db_block_size');

토드에서 스키마 브라우져(Schema Brwoser) 에서

TAB들이 난무할때 좌우 선택 형태로 변환시키는거...