릴라강림의 일기장

원문: http://www.gurubee.net/lecture/2130

10046 Trace 사용 순서

  아래와 같은 순서로 사용을 하면 된다.

① 자신이 접속한 Session의 SPID(Server Process ID)를 확인한다.

 
-- SYSDBA 권한으로 접속한다. 
SQL> SELECT P.SPID SERVER
     FROM V$PROCESS P, V$SESSION S
     WHERE P.ADDR = S.PADDR
       AND S.AUDSID = USERENV('SESSIONID');

    SERVER
    ------
    218038
    

② 10046 Trace 활성화

  아래 명령어로 SQL Trace를 활성화 할 수 있다.

 
SQL> ALTER SESSION SET 
     EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    

③ SQL 수행

  Trace를 분석 할 SQL 문장을 실행 시킨다.

 
SQL> SELECT *
     FROM EMP E
     WHERE E.EMPNO = 9999999
     AND E.DEPTNO = 10;
    

④ 10046 Trace 비 활성화

  SQL_TRACE 옵션을 FALSE로 Trace 모드를 비 활성화 한다.

 
SQL> ALTER SESSION SET SQL_TRACE=FALSE;
    

⑤ Trace 파일 확인

  ①번 단계에서 조회한 SPID와 동일한 trc 파일이 생성되었는지 확인해 본다.

• - USER_DUMP_DEST(UDUMP)에서 SPID.trc 파일 확인
• - 일반적인 UDUMP 파일 경로
  • $ORACLE_HOME/admin/Instance Name/udump/spid.trc

⑥ 218038.trc 파일 확인

  아래 예제와 같이 trc 파일은 직관적으로 보기가 어렵다.

 
=====================
PARSING IN CURSOR #2 len=69 dep=0 uid=44 oct=3 lid=44 tim=65620558312435 hv=1079158054 ad='a3a0eaf0'
SELECT *
FROM   EMP E
WHERE  E.EMPNO  = 9999999
AND    E.DEPTNO = 10
END OF STMT
PARSE #2:c=0,e=4143,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=65620558312421
EXEC #2:c=0,e=159,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=65620558312792
FETCH #2:c=10000,e=3280,p=3,cr=4,cu=0,mis=0,r=0,dep=0,og=1,tim=65620558316229
    

⑦ TKPROF Util 사용하여 파일 변환

  tkprof 유틸을 사용하면 분석하기 쉬운 포맷으로 변환한다.

 
tkprof 218038.trc 218038.txt
    

TKPROF 구문

⑧ 변환한 218038.txt 파일 확인

  아래는 tkprof 유틸로 변환한 218038.txt 파일의 내용이다. 자세한 설명은 아래 표를 참고하기 바란다.

 
SELECT *
FROM   EMP E
WHERE  E.EMPNO  = 9999999
AND    E.DEPTNO = 10

-- #보기 1
Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.000        0.002          0          0          0          0
Execute      1    0.000        0.000          0          0          0          0
Fetch        1    0.000        0.028          3          4          0          0
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        3    0.000        0.031          3          4          0          0

-- #보기 2
Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user: APPS (ID=44)

-- #보기 3
Rows     Row Source Operation
-------  ---------------------------------------------------
      0  STATEMENT
      0   TABLE ACCESS BY INDEX ROWID EMP (cr=4 pr=3 pw=0 time=28400 us)
      1    INDEX UNIQUE SCAN EMP_U1 (cr=3 pr=2 pw=0 time=22438 us)(Object ID 6485271)
    

변환한 218038.txt 파일 설명

caucho가 먼가했더니 -_- 스페인어로 고무란다... 먼가 유연하고 그런걸 상징하고자 한건가?

찾아보니 caucho란 것이 resin + php 환경을 지원하는 오픈 프로젝트라고 한다. 

물론 여기서 resin은 상업용 (-ㅅ-) ;;;

대강 기존의 php가 인터프리터 방식으로 작동하면서 가지고 있던 속도의 한계나 로드벨런싱의 어려움 세션 공유의 어려움 등을 해결하기 위한 방식이라고 한다. (난 php를 본 적 없다 ㅎㅎㅎ)

이걸 찾은게 SystemClassLoader 문제로 웹을 뒤지다가 본 클래스 패스에 포함되어 있었던 명칭이다. 

흠 -_-; 이게 자바 프로젝트로 포함이 된건가?

먼지 모르겠네 ;;;

펌 http://xpace.tistory.com/20

클래스 로딩 순서

만약 동일한 클래스가 여러 곳에 설정되어있을 때 로딩 우선순위는 다음과 같다.

1. Xbootclasspath에 설정된 파일 <- BOOT LOADER

2. JAVA_HOME/jre/lib/ext에 있는 파일 <- EXT LOADER

3. MENIFEST.MF의 Class-Path에 설정된 클래스 <- APP LOADER

4. -cp or -classpath에 설정된 파일 <- APP LOADER

5. 환경변수 CLASSPATH에 설정된 파일 <- APP LOADER

* Java -jar로 클래스를 실행한 경우 클래스패스를 추가하고자 하면 JAVA_HOME/jre/lib/ext에 복사하거나 MENIFEST.MF의 Class-Path를 편집하는 방법이 있다

* App Loader를 위한 클래스 패스 설정은 같이 사용할 수 없고 그 중에서 하나를 선택해야 한다

클래스 로더 구조

ClassLoader의 주요 메소드는 findClass, loadClass이다. (각 로더마다 구현해야 함)

Application Server의 ClassLoader

단순한 자바 Application의 ClassLoader는 SystemClassLoader(BootClassLoader), ExtClassLoader, AppClassLoader의 3계층으로 구성된다. 그러나 WAS는 Servlet 컨테이너와 그 아리에 각 Servlet Context를 위한 클래스 로더를 별도로 두고 있다. 

AppClassLoader와 ServletContainerClassLoader는 같이 사용되기도 하지만 보통 분리된다. Tomcat의 경우 ServletContainerClassLoader는 TOMCAT_HOME/common/lib의 클래스들을 로딩한다.

ServletContainerClassLoader나 ServletContextClassLoader는 WAS 벤더에 의해 구현되기 때문에 세부적인 상황이 버전에 따라 다를 수 있다. 따라서 구체적으로 클래스를 어떻게 배치할 것인가는 해당 WAS의 구현을 확인하고 결정해야 한다.

Servlet 2.3 spec for ClassLoader

서블릿 스팩을 보면 WAR를 위한 클래스 로딩 방식이 일반 자바 클래스 로더와 규칙이 다름을 알 수 있다.

Servlet Spec

SRV.9.5 Directory Structure

…

The web application classloader must load classes from the WEB-INF/ classes directory first, and then from library JARs in the WEB-INF/lib directory.

..

SRV.9.7.2 Web Application Classloader

The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource().

It must not allow the WAR to override J2SE or Java servlet API classes.

It is further recommended that the loader not allow servlets in the WAR access to the web container’s implementation classes.

It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs.

스팩과 클래스 로더

-         WEB-INF/classes와 WEB-INF/lib는 동일 로더에 의해 로딩되지만 로더는 WEB-INF/clasess를 먼저 검색/로딩한다(must)

-         Servlet-API를 구현한 서블릿 컨테이너 클래스를 웹 어플리케이션이 Access할 수 없도록 하라(recommend)

-         WAR내부의 클래스를 컨테이너 클래스 패스의 클래스보다 먼저 로딩하라(recommend)

서블릿 스팩의 일부 모호한 점으로 인해 (recommend)형태의 항목은 서브릿 엔진에 따라서 다르게 구현하고 있거나 옵션 처리되어 있을 것이다.

ServletContextClassLoader구현

서블릿 스팩을 근거로 하여 ServletContextClassLoader(이하 SCCL)의 구현하기 위해서는 다음과 같은 형태로 로직이 구현되어야 한다. 클래스 load 요청이 들어 오면 먼저 자기 자신의 클래스 패스를 검색하고 이후에 parent 로더에게 요청한다.

 protected synchronized Class loadClass(String name, boolean resolve) {

             // First, check if the class has already been loaded

             Class c = findLoadedClass(name);

           If(c == null){

try{

c = findClass(name); ç Own Classpath 먼저 검색

} catch (ClassNotFoundException e) {

if (parent != null) {

                     c = parent.loadClass(name, false);

                  } else {

                     c = findBootstrapClass0(name);

                  }

}

}

             return c;

    }

위 로직은 서블릿 스팩을 완전하게 구현한 것이 아니다. 실제 서블릿 스팩을 보면 servlet API 관련한 클래스는 WAR가 아닌 Servlet Container에서 로딩하도록 되어있다. 따라서c=findClass(name)을 수행하기 전에 로딩해야 할 클래스가 서블릿 API관련한 클래스인지를 검사하는 로직이 필요하다. 만약 로딩해야할 클래스가 서블릿API관련 클래스이면 parent.loadClass()를 먼저 호출하도록 구현되어야 한다.

즉 여기서 말하는 건 각 컨텍스트의 독립성(그리고 이동성)을 보장하기 위한 servlet spec에 대한 설명이다. 하지만 밑에서 설명하는 것처럼 이런 방식은 공통 클래스가 각 war에 들어가 있을 경우 (최악의 경우 어떤 war에만 들어가 있을 경우) 버그를 양산하는 문제가 발생된다. 

WAR 개념과 클래스 로딩의 우선순위

근원적으로 컴포넌트 컴포넌트 내부의 정보를 감추고 인터페이스 만으로 외부와 통신한다. WAR는 이러한 컴포넌트 개념을 지원하고 있으며 따라서 동일한 클래스가 WAR 외부와 내부에 존재할 때WAR는 내부의 클래스를 우선적으로 사용해야 한다

ContainerClassLoader는 WARClassLoader의 Parent 클래스이다. 따라서 Java클래스 로더 정책에 의해서는 Container의 ClassA가 로딩되어야 한다. 하지만 Servlet Spec2.3에 의해서 WAR의 Class A 가 로딩된다. 컴포넌트 개념에서는 외부 클래스가 아닌 내부 클래스 (Class A)가 사용되어야만 내부 로직이 바뀌어도 외부에 영향을 미치지 않으며, 컴포넌트(WAR)가 어느 컨테이너에 설치되더라도 내부 로직이 일관되게 동작할 것이다.

그러나 이것은 공통 클래스의 관리를 어렵게 할 가능성이 높다. 다음 예를 보자.

OracleConnection은 컴포넌트에 의존적이라기 보다는 외부자원(DBMS)에 의존적인 클래스 이다. JDBC드라이버가 WAR파일 안에 존재 한다면, JDBC 드라이버의 버전을 관리하는데 있어 모든WAR파일을 재배포해야 하는 상황이 발생하게 된다. 또한 위와 같이 Container의 공통클래스가DB를 사용하기 위해서 OracleConnection을 사용해야 하는 상황이 발생하고 이 클래스의 내용이WAR파일의 클래스와 참조관계가 형성되는 경우에는 VerifyError혹는 ClassCastException등이 발생할 수 있다.

따라서 WAR파일에 JDBC드라이버와 같이 외부 의존적인 클래스 혹은 Framework과 같은 공통 클래스를 같이 두는 것은 좋은 정책이 아니다. 내부 로직만을 위한 클래스이면서 외부요인에 의해서 변경되지 않아도 되는 라이브러리 클래스(ex. Regexp, Parser등)는 WAR파일 내에 두는 것이 좋다.

목적: DBMS의 주요 목적 중 하나인 동시 액세스에 대한 관리를 위해 오라클에서 도입한 serialize(직렬화) 방식

1. Enqueue

queue로 관리되며 대상 자원에 대한 Owner, Waiter, Converter Queue를 관리하면서 먼저 요청한 순서대로 Lock을 획득하는 구조이며 Exclusive 모드 뿐 아니라 다양한 수준의 공유를 허용함

내부적으로 Enqueue Resource 배열과 Enqueue Lock 배열에 저장되고 Resource에 대한 Lock이 요청되면 해당 요청은 Owner(LMODE > 0, REQUeSTS = 0), Waiter(LMODE = 0, REQUEST > 0), Converter(LMODE > 0, REQUESTS > 0) 중 한 개에 대응됨.

2. Latch

별도의 queue를 관리하지 않아 먼저 요청한 서비스가 latch를 획득한다는 보장이 없으며 대부분 Exclusive 모드로 동작됨. Enqueue에 비해 훨씬 단순한 구조로서 매우 짧은 시간 내에 획득되고 해제되므로 하위 레벨에서 Lock의 부하를 최소화하며 동작하는 메커니즘임 (Enqueue 역시 내부적으로 Latch로 동작됨)

Latch는 다양한 종류가 있으며 자주 사용되는 Latch는 다음과 같다.

* Parent latch와 Child latch
Latch 중에 동일한 기능을 하는 child latch을 set으로 운영되는 종류(cache buffers chains 등등)와 단일한 latch로 운영되는 종류(shared pool latch 등등)가 있으며 이들에 대한 통계는 V$LATCH_CHILDREN, V$LATCH_PARENT에서 조회 가능함

The power of the Web is in its universality, access by everyone regardless of disability is an essential aspect.

Tim Berners - Lee , W3C Director and inventor of the World Wide Web

웹 관련 일을 하면서 헤더 정보 같은건 사실 거의 중요하게 본 적이 없다.

한동안 해야되니까 -_-; 이제 정보를 잘 봐야겠다.

- 설명 정보

http://umz.kr/04Hml

② Accept : 클라이언트가 허용할 수 있는 파일 형식(MIME TYPE) 
                 */* 은 특정 유형이 아닌 모든 파일형식을 다 지원한다는 말입니다

③ User-Agent : 클라이언트 소프트웨어(브라우저,os등) 의 이름과 버전 등.
                        위의 정보에서는 MS IE 6.0, 윈도우 XP, .NET Framework 1.1 버전이
                        클라이언트에 설치되어 있음을 나타냅니다

④ Host : 요청을 한 서버의 Host 입니다          

⑤ If-Modified-Since : 페이지가 수정되었으면 최신 버전 페이지 요청을 위한 필드.
                                  만일 요청한 파일이 이 필드에 지정된 시간 이후로 변경되지 않았다면,
                                  서버로부터 데이터를 전송 받지 않습니다.
                                  단, 이 경우 서버로부터 net modified (304) 상태코드를 전송 받습니다

   위의 헤더 정보는 동일한 파일을 재 요청 했을 때의 응답헤더 입니다
파일을 변경사항이 없으므로 304(수정되지 않음)과 Content-Length : 0 (데이터

받지 않음) 응답을 받았습니다. 이렇게 함으로써 http 는 요청의 부하를 줄이고 있습니다

⑥ Refer : 위의 요청 헤더에는 나와 있지 않지만 이 정보도 헤더에 자주 등장하는
필드 입니다.
특정 페이지에서 링크를 클릭하여 요청을 하였을 경우에 나타나는 필드로써
링크를 제공한 페이지를 나타냅니다 

⑦ Cookie : 역시 위의 요청에는 없지만 자주 등장하는 필드 입니다ㅏ.
웹 서버가 클라이언트에 쿠키를 저장해 놓았다면 해당 쿠키의
정보를 이름-값 쌍으로 웹 서버에게 전송합니다 

⑧ Accept-Language : 클라이언트가 인식할 수 있는 언어. 
           우선 순위 지정이 가능합니다

⑨ Accept-Encoding : 클라이언트가 인식할 수 있는 인코딩(압축) 방법
               위의 내용에서는 서버에서 gzip,deflate 로 압축한 리소스를

                                   클라이언트가 해석 할 수 있다는 말이 됩니다

                                   만일 서버에서 압축을 했으면 응답헤더에 Content-Encoding 헤더에

                                   해당 압축 방법이 명시 됩니다

- 응답 헤더 ?

① HTTP /1.1 200 OK : HTTP 버전과 응답 코드 (200 성공)

   ② Server : 웹 서버 정보를 나타냅니다

                   위의 정보에서는 Microsoft IIS 5.1 입니다. 

③ Date :  현재 날짜 

④ Content-Type : 요청한 파일의 MIME 타입을 나타냅니다

                               Text/html 은 text 중 html 파일임을 나타냅니다 

⑤ Last-Modified : 요청한 파일의 최종 수정일을 나타냅니다

⑥ Content-Length : 헤더 이후 이어지는 데이터의 길이입니다(바이트 단위)
                                  이어지는 데이터란 요청한 파일의 데이터라 보시면 됩니다 

⑦ ETag : 캐쉬 업데이트 정보를 위한 임의의 식별 숫자

이상 요청과 응답 시 생성되는 HTTP Header 중 자주 등장하는 필드에 대한

설명 이었습니다. HTTP Header 는 위의 명시된 것 이외에도 많이 있습니다.

아래에 링크로 가시면 HTTP 1.1 기준의 Header 의 상세 정보를 보실 수 있습니다. 

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

꽤 좋은 확인 방법 (무슨 -_- 성격 테스트 게임 같긴 하지만 ;;)

http://ailov.blog.me/60185838900

블로그를 보면 확인 방법이 있다.

아래는 주요한 확인 방법의 흐름을 정리한 그림

하나 기억할 건 stage 모드와 no-stage 모드에 대한 내용이다. 결국 복사본을 보여주느냐 원본을 보여주느냐인데 stage 모드로 하면 복사해서 복사한 내용을 보여준다고 한다. (원본 보호 -_-? 그게 되는건가?)

자기참조형 hierarchy 테이블에 입력하기 위해서 sys_connect_by_path 이외에 아래 함수를 사용해야 함

- regexp_substr(source, pattern [, position [, occurrence [, match_param [subxpr]]]])

- regexp_count(source, pattern [, position [, match_pattern]])

오늘 찾아 놓은 정규식과 결합해서... 말하자면 구분자로 연결된 것에서 상위를 찾아야 한다.

regexp_count가... 11g에서 적용된 것이라고 한다. (슬프네 ㅠㅠ)

결국 함수를 만들어 쓰던지 해야할 것 같은 느낌