반응형


참고 사이트 (Reference Site)

  1.MAT (Eclipse Memory Analyzer) 메모리 분석 GUI 툴
    http://www.eclipse.org/mat/downloads.php 

  2. IBM Diagnostic Tool Framework for Java Version 1.5
    http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html  

  3.일본 MAT 적용 참고 사이트   
     http://d.hatena.ne.jp/kakku22/20110910/1315646914 
 


heapdump는 시스템 운영 중 항상 발생할 수 있는 문제이며,

빵빵한 시스템에서는 IBM Heap Analyzer를 사용하여 분석한다

다만,

위와 같은 빵빵한(?) 시스템이 지원되지 않는 환경(Windows 32bit)에서는

분석하는 방법이 없을까 많은 고민을 하였고, 찾다보니 아에 방법이 없지만은 않았다.


1. GUI 툴 다운로드
    - 이클립스 사이트에서 dump 분석을 위한 툴을(MAT) 제공한다.
    - 위의 참고사이트 1번 항목을 방문하면 다운로드 가능하다.

 
     - 다운 받은 파일의 압축을 풀고 해당 디렉토이에 들어가면 MemoryAnlyzer.exe와 MemoryAnalyzer.ini 파일등이 보인다.
     - 32bit 환경에서 최대 할당 가능한 heap 사이즈로 로딩 가능하도록 MemoryAnlyzer.ini 파일을 수정한다.

  -vmargs
 -Xmx1372m
 
2. IBM Heapdump 분석을 위해서는 별도의 plug-in을 추가한다.
   (인터넷 검색하면 많은 내용이 나오지만 위의 DTFJ 파일 방식이 대용량의 힙 덤프 분석에는 최고다..)
   - 2번 사이트 방문하여 다운로드 한다.


위의 클릭을 하면 zip 파일을 받을 수 있다.
   
받은 zip 파일을 MAT 압축을 풀은 디렉토리 내에 DTFJ 폴더를 만들어 그안에 복사하여 놓는다.

3. MAT에 Plug-IN 설치
    - MemoryAnlyzer.exe 더블 클릭하여 MAT 를 실행함.
    - 실행화면
     

 
     -  Help -> Install New Software... 실행


   - Add.. 를 크릭하여 설치 가능한 소프트웨어를 추가함.


     - Name에는 명칭을 적고, Location 부분은 우측의 Archive를 클릭하여 다운받은 dtfj-updatesite.zip를 직접 지정함

 
    - Check 후 Next를 클릭 -> Next

 
 - 라이센스 동의 후 Finish 클릭

 

- local 설치이다 보니 보안 땜시 한번더 묻는거임... ok 살포시 눌러줌

 
 - 다시 시작함(Restart Now를 눌러)

 
  - File -> Open Heap Dump... 를 눌러 IBM Heapdump 파일을 선택하여 분석함..

 
나머지 분석과 관련된 상세한 사항은 인터넷 검색 ㄱㄱ 
반응형
반응형
반응형
반응형

출처 : http://logonjava.blogspot.com/2010/04/heap-dump-perm-area-memory-leak.html


Software 특히 Java 언어를 사용하는 Software 개발 조직에 몸담고 있지만, 마흔을 훌쩍 넘긴 나이에 이런 글을 쓰는 것이 적합한지 의심되는데 특히 국내 SW 환경을 고려한다면 몹시 우스꽝스럽다.

이젠 개발팀장도 아니고 개발실장도 아니고 그위의 관리자이지만, 아직 완전히 제품 코드로부터 역할을 분리하지 못했고, 이러한 시간이 많이 걸리고 책임 소재가 불분명한 문제를 해결할 전문 인력을 두고 있지 않기 때문에 결국 직접 하는 경우가 생긴다. 이것은 미흡한 관리 능력의 결과라고 봐도 좋겠다.

개인적으로는 이러한 일이 전혀 나쁘지 않다. 즐거운 Software Life의 하나일 뿐이다.
관리자가 이러한 삽질을 직접 하는 것이 관리 체계를 무너뜨리는 것 아니냐고 묻겠지만...

oh, give me a break.. 나중에 교육교재 만드는 데 도움이 될까해서 하는 관리 행위의 하나라고 봐주기 바람~~ ㅠ_ㅠ;;

perm gen 과 class leak
Permanent Generation 은 young과 old를 구분하는 Generational Collector 방식인 Sun (now, Oracle)의 HotSpot JVM에서 Old generation 중 한 영역이다.
lifetime이 길다고 판단된 object들을 old generation으로 옮겨서 빈번한 gc의 대상이 되지 않도록 하는 것이 generational collector의 기본 아이디어인데 permanent generation은 old 중에서도 거의 gc 대상이 될 일이 없다고 생각되는 object들을 딴 영역에서 관리하겠다는 아이디어의 산물이다.

HotSpot JVM의 Perm Area 에는 주로 자바의 클래스 객체들이나 문자열 상수 풀에 속한 String 객체들이 위치한다.
메모리 leak의 대상이 되는 것은 string constants 보다는 주로 class 객체들이다.

(class 객체는 주로 객체의 타입을 나타내는 클래스나 인터페이스를 표현하는 객체로 타입명 뒤에 .class 라는 literal을 붙임으로써 지칭할 수 있다. 예를 들어 자바 코드에서 String.class 라는 객체는 java.lang.String 이라는 클래스의 타입을 지칭하는 객체이다.)

memory leak이란 보통 reclaim되어야 할 memory space가 reclaim되지 못하고 있는 상황을 뜻하는데 Java와 같이 garbage collector 기능을 내장한 VM에서는 주로 코드 오류로 인해 gc 대상이 되는 객체를 불필요하게 reference(자바에서는 weak reference나 soft reference와 구분하여 strong reference)하는 gc 대상이 아닌 객체들이 존재하기 때문에 발생한다.

perm area 에 위치하는 class 객체들은 classloader에 의해 load 되기 때문에 이 class 객체들이 unload되는 유일한 방법은 classloader가 unload 즉, gc 되는 것이다.

보통 Java VM이 로드될 때 사용되는 classloader들(runtime에 필요한 클래스를 주로 로드하는 system classloader와 classpath에 설정된 클래스들을 로드하는 application classloader 등)은 JVM이 종료할 때까지 gc되지 않기 때문에 여기에서는 관심의 대상이 아니고, 주로 application이 dynamic하게 코드 상에서 만드는 classloader들이 관심의 대상이 된다.

즉, 다시 말해서 "gc되어야 하는 classloader 객체가 어떤 다른 strong object 에 의해 참조되는 것을 찾는 것이 오늘의 주제"이다.

OutOfMemoryError와 heap dump
heap dump 분석은 Java에서 OutOfMemoryError(이하 OOM)가 발생할 경우 원인을 찾기 위해 많이 사용된다.
OOM 시 heap dump를 자동으로 생성하는 HotSpot JVM 옵션이 있는데 이에 관해서는 앞의 다른 blog를 참고하기 바란다.

OOM은 주로 세 가지 경우에 발생한다. 하나는 전체 heap memory 부족, 또하나는 permanent area 부족, 나머지 하나는 native thread를 더 이상 생성할 수 없을 경우이다.

전체 heap memory 부족은 너무 많은 객체를 만들거나 strong reference에 의해 객체 일부가 reclaim 되지 않아서 발생하게 된다. perm area 부족은 앞과 동일한 이유이겠지만 해당 객체가 class 객체인 경우이고 전체 heap 영역 중 perm 영역이 분리되어 있기 때문에 다르게 발생하는 것이다. thread를 생성 못하는 이유는 OS 환경과 상관이 있을 테고, 또 코드 수준에서 thread를 지나치게 많이 만들거나 또 thread 종료가 제대로 안되어 leak이 발생한 때문일 것이다.

세 가지 중 어느 원인으로 OOM이 발생했는지에 대해선 OOM 에러의 메시지를 보면 쉽게 알수 있다.

heap dump 분석에 필요한 소프트웨어
heap dump 분석을 위해 사용하는 소프트웨어는 다음과 같다.
먼저 heap dump 분석 프로그램. HP에서 제공하는 jmeter 가 있고, IBM에서 제공하는 HeapAnalyzer, SAP에서 만들었다가 지금은 eclipse에 donate된 MemoryAnalyzer 등이 있다.

다들 한번씩 try는 해봤지만 지금은 swing 기반으로 된 순수 자바 프로그램인 IBM HeapAnalyzer를 쓴다.
jmeter는 예쁘게 생겼지만 지원하는 heap dump 포맷이 제약이 있었고, SAP MemoryAnalyzer는 적은 메모리로 큰 dump 파일을 읽어들일 수 있긴 하지만, 제공해주는 정보들을 이해하기 좀 어려웠다.
그러다보니 IBM HeapAnalyzer에 익숙해져버렸다.

또, 하나 많이 사용하는 것은 X 서버이다. PC 환경에서 heap analyzer를 돌리기엔 heap dump 파일이 너무 커서 메모리를 많이 사용하기 때문에 대용량 heap을 사용할 수 있는 64비트 JVM 환경(32비트 JVM에서는 max heap size를 1.4기가 정도밖에 줄 수 없다. 정확한 최대값은 모르겠음)에서 heap analyzer를 실행해야 했는데 그러다보니 PC용 X 서버가 필요했다.

요즘 사용하는 PC용 X 서버는 free open source인 cygwin-x 이다. 큰 문제 없이 쓸 수 있다.



HeapAnalyzer 실행
요즘 개발자들은 X 환경을 이해 못하는 경우가 많아서 간단하게 PC용 X 서버에서 원격지의 heap analyzer를 어떻게 실행하는지 절차를 적어본다. (예전에 motif application 개발을 잠깐 했었던 추억이 있음)

유닉스에서 주로 사용되는 윈도우 시스템인 X-Window 시스템은 서버/클라이언트 구조로 되어 있으며 X 서버는 display를 제공하는 쪽을 뜻하고, 실제 애플리케이션 프로세스가 실행되는 쪽이 X 클라이언트가 된다.

1. X 서버인 cygwin-x를 PC에서 실행하고 xterm 프로그램을 하나 실행시킨다.

2. xterm의 shell prompt 에서 "xhost +" 명령을 실행한다. xhost는 X 서버에 접속할 수 있는 X 클라이언트 호스트들에 대한 접근 제어를 하는 명령이다. cygwin-x가 PC에서 실행되고 원격지 유닉스 서버에서 heap analyzer를 띄울 것이므로 PC가 X 서버이고 유닉스 서버가 X 클라이언트 호스트이다. xhost + 다음에 호스트 명을 주지 않으면 모든 호스트에 대해서 allow한다는 뜻이다.
다음과 같이 불평할 것이다.

[mypc]/home/yoonforh 504> xhost +
access control disabled, clients can connect from any host

3. 해당 유닉스 서버로 telnet 등을 통해 접근한다.
해당 유닉스 서버의 셸에서 DISPLAY 환경 변수를 cygwin-x가 실행된 PC로 지정해야 한다.
예를 들면 ksh이나 bash에서 다음과 같이 지정한다.

export DISPLAY=<PC IP 주소>:0

보통의 X용 appliation은 실행시 -display 옵션을 통해서 지정할 수도 있다. DISPLAY 환경변수 값은 ip 주소와 display screen 번호로 구성된다.

보통 기본값인 0 혹은 0.0을 screen number로 사용한다. 윈도우 시스템 위에 실행되는 window manager 프로그램에 따라 CDE나 gnome-desktop, mwm, twm 등은 여러 개의 screen을 가지므로 screen number를 0이 아닌 다른 값으로 지정할 수도 있다. 사실 대부분의 X용 윈도우 매니저들은 multi screen을 지원한다.
사족이 길어졌다. 그냥 0번 스크린을 지정한다. ㅠ_ㅠ

4. DISPLAY가 지정된 환경에서 heap analyzer를 실행한다.
해당 셸에서 다음과 같이 heap analyzer를 실행한다. 현재 사용하고 있는 버전은 3.7이다.

jdk 5이상 가능

jdk 6이상.


java -Xmx5G -jar ha37.jar

큰 heap dump 파일을 분석할 때에는 메모리가 많이 사용되므로 heap 최대값을 5G로 줬다. dump 파일 크기에 따라 더 줘야 할 경우도 있을 것이다. 앞에서 얘기했듯이 이 JVM이 64비트인 경우에 주로 지원된다. OS나 JVM 버전, 비트 수마다 지원하는 최대 heap 크기가 다르므로 이 부분은 알아서들 체크하기 바란다.

사족이 길었지만 이 application을 remote에서 띄워보려고 했다. 매번 연구원들에게 일일이 이런 것 가이드하기 싫어서 교육용으로 부연해보았다. cygwin-x 위에 뜬 heap analyzer 아마도 상당히 촌스럽다고 느낄 것이다. 뭐, 잘생겼다고 일 잘하는 건 아니다.

5. heap dump 파일을 읽어들인다.
보통 HotSpot JVM에서 binary format으로 heap dump를 남기게 하면 heap analyzer는 "HPROF binary"라는 포맷으로 읽어들인다.
perm area 부족으로 인한 OOM인 경우는 전체 heap 부족으로 인한 OOM인 경우보다는 heap size가 작으므로 dump 파일도 상대적으로 작다. (이것도 다행이라고 생각하면 되려나 ㅎㅎ)

dump 파일이 클수록 읽는 데 시간이 많이 걸리므로 open 시켜 놓고 다른 일을 하면 되겠다. 어차피 프로세싱은 원격지 서버에서 일어나는 것이니 PC에 몹쓸 짓은 안한다.

Object Reference 관계와 ClassLoader 간 계층 관계
이제 분석할 준비가 완료되었다. 몇 가지 필요한 사전 지식에 대해 언급해본다.

ClassLoader는 계층 구조를 가진다. 이 계층 구조는 ClassLoader를 생성할 때 반드시 부모 ClassLoader를 지정하도록 되어 있는데, 기본적인 자바의 class 정의 검색 방식은 부모 ClassLoader에 정의된 class 정의를 우선으로 찾고, 그 다음에 자식 ClassLoader에 정의된 class 정의를 찾는 구조이다.

자바의 각 ClassLoader들은 내부적으로 parent 라는 멤버 필드를 가지고 있고, 이 값이 부모 클래스로더 객체가 된다.
(classloader들의 parent/chlid 관계는 class inheritance의 parent class, child class와는 아무 상관이 없다.)

Object Reference 관계는 객체 간의 참조 구조를 나타내며 directed graph 형태이다. 즉, 참조자(Referencer)를 시작점으로 피참조자(Referencee)를 끝점으로 하나의 화살표가 그려지는 단방향 그래프 형태라고 생각할 수 있다.

표준적인 용어인지는 모르겠지만, HeapAnalyzer에서는 참조자를 parent, 피참조자를 child로 표현하고 있다. 그리고, parent가 없이 strong object인 경우를 root 라고 표현하고 있다.

즉, 단방향 그래프로 이루어진 forest 형태이지만 이것을 root node가 여러 개인 tree인 것으로 표현하고 있다. 생각해보면 root node들 위에 공통된 가상의 parent node 하나가 있다고 가정하면 하나의 tree로 볼 수 있다. 이렇게 보면 parent/child 용어는 적합하다고도 볼 수 있다. (엄밀하게 보면 상호 참조나 순환 참조가 가능하기 때문에 forest나 tree라고 볼 수 없다. 하지만, 여기에서 얘기하는 parent/child 관계를 적용하는 데는 큰 무리가 없으므로 child가 parent로도 되는 경우나 descendant가 ancestor의 parent가 되는 경우가 존재한다는 것을 예외로 간주하고 rough하게 metaphor를 적용해보자.)

이제 ClassLoader 간 parent/child 관계가 Object Reference 관계에서 어떤 관계를 가지는지 생각해보자. 이게 아마 이 논의의 핵심일 것이다.

Child ClassLoader 객체는 멤버 필드로 parent를 가지고 있으며 이 parent 필드의 값이 Parent ClassLoader 객체이다.
즉, Object Reference 관계로 보면 child classloader 객체가 parent란 필드를 통하여 parent classloader를 reference하고 있다.

다시 말하면 object reference 관계에서는 child classloader 가 referencer(parent), parent classloader가 referencee(child)로 되어 parent/child 관계가 뒤바뀐다.

용어적인 유사성 때문에 혼란이 오는 것이며 서로 관련없는 관계이지만, 결과적으로는 "일반적으로 classloader 객체 간 parent/child 관계는 객체 참조간 parent/child 관계와 반대가 된다"고 생각해도 되겠다.

분석 예
이제 실 예를 들어 perm leak을 찾아보자. 사실 perm leak 이 발생하려면 ClassLoader를 동적으로 만들어 사용하는 프로그램에서 가능하기 때문에 일반적인 application에서는 이런 경우가 많지 않다. 보통은 그냥 클래스를 많이 사용하는 경우이므로 JVM 옵션으로 perm area 영역을 늘려주면 된다.

하지만, plugin 과 같은 동적 프로그램 기능을 가지고 있는 application에서는 plugin을 위한 ClassLoader를 만들어 사용하기 때문에 이러한 경우가 종종 발생한다.

먼저 heap dump 파일을 HeapAnalyzer로 연 다음 "Analysis/Search Name" 기능을 사용하여 의심이 가는 클래스로더 객체를 찾는다. 클래스 명으로 찾을 수 있는데 dump 상에는 separator가 '.'이 아니라 '/'인 점을 주의하여 찾는다.


검색 결과를 보면 해당하는 타입의 객체와 클래스 객체가 나타난다. 아래 그림에서 클래스로더 객체는 12개가 존재한다. (13개 중 한 개는 클래스로더 타입을 나타내는 class 객체)


위 그림에서 보이듯이 각 클래스로더 객체를 선택하여 오른쪽 마우스 버튼(두번째 마우스 버튼)을 클릭하면 팝업 메뉴가 보이며 이를 통해 해당 객체의 parent 객체들이나 child 객체들을 추적할 수 있다.

클래스로더 객체를 참조하고 있는 객체 즉, object reference 관계에서 parent에 있는 객체들이 클래스로더 객체의 가비지 컬렉션을 막고 있는 상황을 찾아야 하므로, 계속해서 "List parents" 기능을 사용하여 object reference tree를 거슬러 올라가보면 문제가 되는 참조자 객체를 찾을 수 있을 것이다.

경우에 따라서는 parent 객체들이 sun/reflect/DelegatingClassLoader, java/security/ProtectionDomain, java/lang/Package 등만 나타나는 경우가 있는데 이런 객체들은 일시적인 참조이며, 이 경우는 garbage collection되기를 기다리고 있는 경우이기 때문에 leak이 아니다.

각 객체별로 parent를 추적해보면 알 수 있지만, ProtectionDomain 객체와 Package 객체는 ClassLoader 와 상호참조되는 객체들이며 다른 strong reference에 의해 연결되지 않으며 DelegatingClassLoader는 HotSpot JVM 에서 reflection을 사용하여 dynamic proxy 객체를 만들 때마다 일시적으로 사용되는 클래스로더이다.

object reference 상의 parent 추적은 여러 depth에 걸쳐 일어날 것이며 해당 클래스의 소스 코드를 알고 있다면 쉽게 연결하여 이해할 수 있을 것이다.


object reference graph 추적은 perm leak이든 일반적인 memory leak이든 동일하게 사용할 수 있다. 다만 여기에서는 classloader 객체가 leak이 되는 경우에 perm area problem이 발생한다는 것을 중심으로 설명하였다.

누구에게든 이 잡다한 내용이 작은 도움이 되길 바라면서...


출처 : http://logonjava.blogspot.com/2010/04/heap-dump-perm-area-memory-leak.html
반응형
반응형

오라플에서 에러가 발생했을 때, 어떤 SQL문이 문제인가를 찾아낼 필요가 있습니다. 예를 들어, Alert.log 파일에 다음과 같은 에러 메시지가 기록되어 있습니다.
1 Fri Mar 05 09:47:53 2010
2 ORA-1652: unable to extend temp segment by 128 in tablespace                 VERY_SMALL_TBS
어떤 SQL문이 범인인가를 알지 못하면, 해결하기가 쉽지 않습니다.

이런 경우에 시도해 볼 수 있는 것이 ErrorStack 덤프입니다. ErrorStack 덤프를 진단 이벤트와 함께 사용하면 에러를 일으키는 SQL 문장이 트레이스 파일에 기록되도록 할 수 있습니다.

간단한 예를 설명해 보겠습니다. 우선 작은 크기(10m)의 테이블스페이를 만듭니다.

1 UKJA@ukja1021> create tablespace very_small_tbs
2   2  datafile size 10m;
3   
4 Tablespace created.
ORA-01652 에러가 발생하면, ErrorStack 덤프를 실행하도록 진단 이벤트를 겁니다.
1 UKJA@ukja1021> alter system set events '1652 trace name errorstack level 1, forever';
2   
3 Session altered.
10m보다 큰 테이블을 만들면 ORA-01652 에러가 발생합니다.
01 UKJA@ukja1021> create table tbig(c1)
02   2  tablespace very_small_tbs
03   as
04   select rpad('x',1000) from dual
05   connect by level <= 10000
06   6  ;
07 select rpad('x',1000) from dual
08                            *
09 ERROR at line 4:
10 ORA-01652: unable to extend temp segment by 128 in tablespace VERY_SMALL_TBS
11   
12 UKJA@ukja1021> alter system set events '1652 trace name context off';
13   
14 Session altered.
Alert.log 파일에는 다음과 에러 메시지가 남습니다.
1 Fri Mar 05 09:47:53 2010
2 ORA-1652: unable to extend temp segment by 128 in tablespace                 VERY_SMALL_TBS
프로세스의 트레이스 파일에는 에러 발생시의 SQL문과 CallStack 트레이스가 기록되어 있습니다.
01 ORA-01652: unable to extend temp segment by 128 in tablespace VERY_SMALL_TBS
02 Current SQL statement for this session:
03 create table tbig(c1)
04 tablespace very_small_tbs
05 as
06 select rpad('x',1000) from dual
07 connect by level <= 10000
08 ----- Call Stack Trace -----
09 calling              call     entry                argument values in hex      
10 location             type     point                (? means dubious value)     
11 -------------------- -------- -------------------- ----------------------------
12 _ksedst+38           CALLrel  _ksedst1+0           0 1
13 _ksedmp+898          CALLrel  _ksedst+0            0
14 _ksddoa+2088         CALLreg  00000000             1
15 _ksdpcg+238          CALLrel  _ksddoa+0            A9615C0 93C78C0
16 _ksdpec+230          CALLrel  _ksdpcg+0            674 C04A478 1
17 __PGOSF89__ksfpec+1  CALLrel  _ksdpec+0            674
18 18                                                 
19 _kgesev+88           CALLreg  00000000             A0C6760 674
20 _ksesec2+39          CALLrel  _kgesev+0            A0C6760 93C0020 674 2 C04A4E4
21 _ktsxterr+316        CALLrel  _ksesec2+0           674 0 80 0 1 E C04A55E
22 _ktfbtgex1+969       CALLrel  _ktsxterr+0          792DE5C 80 0
23 _ktsxs_add+1766      CALLrel  _ktfbtgex1+0         C04AD8C 3D C04AA50 80 18 A 3
24                                                    0 0 C04AD50 37B3EE88
25 _ktsxssr_sadd+1409   CALLrel  _ktsxs_add+0         C04B048 C04AD8C 80 A 3 0 18 1
26                                                    C04B11C C04AE08 C04ADC0 0
27                                                    C04AD50
28 _ktrsexec+372        CALL???  00000000             C04B0D8
29 _ktelwbl+770         CALLrel  _ktrsexec+0          C04B0D8
30 _kdblba+168          CALLrel  _ktelwbl+0           792DE5C 1
31 _kdblGetBlockDba+58  CALLrel  _kdblba+0            
32 _kdblgb+26           CALLrel  _kdblGetBlockDba+0   C04B3C8 792DD9C
33 _kdblailb+2101       CALLrel  _kdblgb+0            
34 _kdblai+1560         CALLrel  _kdblailb+0          C04B3C8 792DC9C 792DD9C 0 1 1
35 _klclil1r+187        CALLrel  _kdblai+0            
36 _qerltRop+514        CALLrel  _klclil1r+0          792DBEC
37 _qercbiFetch+935     CALLreg  00000000             34C4F034 7FFF
38 _rwsfcd+95           CALL???  00000000             34C4F384 1C72EB4 34C4F034
39                                                    7FFF
40 _qerltFetch+368      CALL???  00000000             34C4F148 1C72EB4 34C4F034
41                                                    7FFF
42 _ctcdrv+7674         CALL???  00000000             34C4F034 1D28394 C04CE30 1
43 _opiexe+12257        CALLrel  _ctcdrv+0            34EE5F50 C04D548 C04D510
44 _opiosq0+6088        CALLrel  _opiexe+0            4 0 C04D8C0
45 _kpooprx+232         CALLrel  _opiosq0+0           3 E C04D9D8 A4
46 _kpoal8+775          CALLrel  _kpooprx+0           C04F6F8 C04E224 6D 1 0 A4
47 _opiodr+1099         CALLreg  00000000             5E 17 C04F6F4
48 _ttcpip+1273         CALLreg  00000000             5E 17 C04F6F4 0
49 _opitsk+1017         CALL???  00000000             
50 _opiino+1087         CALLrel  _opitsk+0            0 0
51 _opiodr+1099         CALLreg  00000000             3C 4 C04FC8C
52 _opidrv+819          CALLrel  _opiodr+0            3C 4 C04FC8C 0
53 _sou2o+45            CALLrel  _opidrv+0            3C 4 C04FC8C
54 _opimai_real+112     CALLrel  _sou2o+0             C04FC80 3C 4 C04FC8C
55 _opimai+92           CALLrel  _opimai_real+0       2 C04FCB8
56 _OracleThreadStart@  CALLrel  _opimai+0            
57 4+708                                              
58 7C80B710             CALLreg  00000000
ErrorStack 덤프는 그 레벨에 따라 다양한 유용한 정보를 제공해줍니다. 아래 아티클에서 상세한 정보를 얻을 수 있습니다.

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

반응형
반응형

1. command line 에서 expdp 사용
    결과물을 저장할 디렉토리를 지정한다.
        SQL> create directory data_pump_test as '/home/oracle/data_pump_test/';

    생성한 디렉토리 오브젝트에 대한 권한을 유저에게 부여한다.
        SQL> grant read, write on directory data_pump_test to hr;

    사용자에게는 EXP_FULL_DATABASE, IMP_FULL_DATABASE 롤을 부여한다.
    실제로는 resouce 롤만으로도 기본적인 expdp, impdp 동작을 수행할 수 있다.
   
    expdp 실행
    # expdp hr/hr directory=data_pump_test dumpfile=test_dump.dmp

    - interactive command line
        expdp 진행 중에 컨트롤+C 키를 누르면 Export> 프롬프트가 뜬다.
        여기서 help를 타이핑하면 사용할 수 있는 명령들을 확인할 수 있다.

    data_pump_test 디렉토리에 생성된 export.log 파일의 내용을 확인한다.

    ※ {exclude|include} object_type[: "name_expr"]
            ex)
            - # expdp hr/hr directory=data_pump_test dumpfile=test_dump.dmp exclude=index:"like 'EMP%'"
            - # expdp hr/hr directory=data_pump_test dumpfile=test_dump.dmp include=view
        exclude는 해당 오브젝트를 제외하고 추출/입력
        include는 해당 오브젝트만을 추출/입력
       
        contents={all | metadata_only | data_only}


2. 병렬 처리
    parallel 파라메터는 몇 개의 스레드로 병렬 처리 할 것 인지 지정한다.
        # expdp hr/hr tables=paratest directory=data_pump_test dumpfile=paratest%U.dmp parallel=3 job_name=parr_test;

    paratest01.dmp, paratest02.dmp, paratest03.dmp 세 개의 파일이 생성된다.    

        # impdp hr/hr directory=data_pump_test dumpfile=paratest%U.dmp job_name=parr_test;

실행 예

SQL> create user dpumpuser identified by dpumpuser;
SQL> grant connect, resource, exp_full_database, imp_full_database to dpumpuser;
SQL> create directory data_pump as '/home/oracle/data_pump';
SQL >grant read, write on directory data_pump to dpumpuser;

$ expdp dpumpuser/dpumpuser full=y directory=data_pump dumpfile=20081030.dmp
$ impdp dpumpuser/dpumpuser directory=data_pump dumpfile=20081030.dmp

SQL> revoke read, write on directory data_pump from dpumpuser;
SQL> revoke connect, resource, exp_full_database, imp_full_database from dpumpuser;
SQL> drop directory data_pump;
SQL> drop user dpumpuser;

※ 만약 impdp 가 퍼미션 문제로 실행되지 않는다면 SYSDBA 로 로그인한 후,
SQL> execute dbms_metadata_util.load_stylesheets;
을 실행한 후 재시도.

특정 스키마의 구조와 데이터 추출
$expdp dpumpuser/dpumpuser schema=PORTAL directory=data_pump dumpfile=portal_schema_20081031.dmp

content를 사용해 특정 스키마의 데이터만 추출 (all | metadata_only | data_only)
$expdp dpumpuser/dpumpuser schemas=PORTAL content=data_only directory=data_pump dumpfile=portal_schema_data_20081031.dmp

table_exists_action 옵션 사용, 기존의 데이터를 truncate 하도록 (skip | append | truncate | replace)
    skip - 존재하는 오브젝트에 대해 임포트 스킵
    append - 기존 오브젝트에서 업는 행만을 임포트
    truncate - 기존 테이블 truncate
    replace - drop & recreate
$ impdp dpumpuser/dpumpuser table_exists_action=truncate directory=data_pump dumpfile=portal_schema_data_20081031.dmp

데이터 파일, 테이블 스페이스, 유저는 각각 다음의 옵션으로 변경할 수 있다.
REMAP_DATAFILE=’C:\user01.dbf’:’/usr/data/user01.dbf’
REMAP_TABLESPACE=’users’:’user’
REMAP_SCHEMA=scott:stralth

다음 옵션으로 expdp에 사용되는 공간을 추정할 수 있다.
estimate_only=Y
$ expdp dpumpuser/dpumpuser full=y estimate_only=Y

출처 ; http://devideby0.egloos.com/2097445

반응형
반응형

imp userid/passwd file=/dmp/file.dmp tables=table_name1,table_name2, ... , table_nameN fromuser=abc touser=new_abc

imp userid(오라클 id)/passwd(오라클 id의 사용암호) file=(exp를 통해 백업받은 덤프 파일) tables=덤프파일내에 있는 테이블중 입력시킬 테이블들 fromuser=(dmp를 받았던 계정) touser=(입력시킬 계정)


매개 변수

  - userid : IMPORT를 실행시키는 계정의 사용자이름/암호명

  - buffer : 행 데이터를 가지고 오는데 사용되는 Buffer의 Bytes 값

  - file : Import(입력)시킬 파일명

  - show : dmp 파일 내용이 화면에 표시되는 여부를 선택
               선택 값 : Y/N

  - ignore : IMPORT중 CREATE명령을 실행시 에러가 발생하면 무시할 것인지 선택
                선택 값 : Y/N

  - indexes : 테이블 INDEX의 IMPORT여부 선택

                 선택 값 : Y/N

  - rows : 테이블 데이터를 IMPORT할 것인가 여부 선택

              선택 값 : Y/N 

              만약 "N"로 설정하면 데이터베이스 객체들에 대한 DDL만이 실행

  - full : FULL엑스포트 덤프 파일이 IMPORT 할때 사용

            선택 값 : Y/N

  - tables : IMPORT될 테이블 리스트

  - commit : 배열(배열의 크기는 BUFFER에 의해 설정됩니다) 단위로 COMMIT을 할것인가 결정
                 기본적으로는 테이블 단위로 COMMIT

  - fromuser : EXPORT덤프 파일로 부터 읽혀져야 하는 객체들을 갖고 있는 테이터베이스 계정

  - touser : EXPORT덤프 안에 있는 객체들이 IMPORT될 데이터베이스 계정

반응형

'Database > ORACLE' 카테고리의 다른 글

ORA-01659 해결방법  (1) 2009.03.07
ORA-12541 오류 대처 방법  (0) 2009.03.07
오라클 EXP 사용하기  (0) 2009.03.07
오라클 강제 제거하는 방법  (0) 2009.03.07
오라클 설치시 발생할수 있는 오류 해결방법  (0) 2009.03.07
반응형

10g 이상에서는 expdp를 사용하면 좋음....

단 속도가 빠른만큼 별도로 약간(?)의 작업은 필요함...

물론 exp 자체는 다른 서버 작업이 불필요하다 ㅎㅎ;



exp test/testpwd@test1 tables=CNG_INFO, MBR file=20080519_table_backup.dmp log=20080519_table_backup.log  rows=y

분석 : exp(구조 및 데이터 출력 명령으로) test(아이디)/testpwd(암호)@test1(오라클 Sid값) 으로 tables=... (포함하는 테이블들을) file=...dmp (..dmp으로 파일을 백업하고) log=..log(log로그를 남기며) rows=y (데이터 행들을 포함한다.)

 

기본 형식

exp userid/passwd tables=table_name file=/tmp/file.dmp

 

매개 변수

 

  - userid : EXPORT를 실행시키고 있는 username/password명.

 

   - buffer : 데이터 행들을 가져오는데 사용되는 버퍼의 크기.

 

   - file : 생성되는 EXPORT덤프 파일명.

 

   - filesize : EXPORT덤프 파일의 최대 크기

 

   - grants : 데이터베이스 객체에 대한 권한 정보의 EXPORT여부 (Y/N 플래그)

 

   - indexes : 테이블에 대한 INDEXES의 EXPORT여부 (Y/N 플래그)

 

   - rows : 행들에 대한 EXPORT여부. (Y/N 플래그)
               만약 “no”이면 데이터는 EXPORT되지않고 테이블의 정의만 EXPORT

 

   - constraints : 테이블에 대한 제약조건 정보의 EXPORT여부 (Y/N 플래그)

 

   - compress : IMPORT에 대비하여 테이블의 데이터를 한 extent로 압축 할것인가의 여부
                      (Y/N 플래그)

 

   - full : 전체 데이터베이스를 EXPORT할것인가의 여부 (Full Level Export) (Y/N 플래그)

 

   - owner : EXPORT될 데이터베이스의 소유자명 (User Level Export)[owner=user]

 

   - tables : export될 테이블의 리스트(Table Level Export) [tables=(table1, table2, ...)]

반응형

+ Recent posts