반응형

관련 URL : https://mariadb.com/kb/en/library/installing-the-connect-storage-engine/

 

Installing the CONNECT Storage Engine

Installing the CONNECT storage engine.

mariadb.com

 

MariaDB 10.2 버전부터 connect engine 이 반영되었습니다.

 

CONNECT 스토리지 엔진은 MariaDB가 외부나 원격 데이터에 접근할 수 있습니다.

 

이 스토리지 엔진은 테이블 파티셔닝, MariaDB 가상 컬럼을 지원하며 ROWID, FILEID 및 SERVID와 같은 특수 컬럼을 정의할 수 있습니다.

 

0. CONNECT 스토리지 엔진 설치 여부

 

# mysql -uroot -p 접속

 

MariaDB [ (none) ] > show engines; 

 

 

위 출력 결과에 Engine 컬럼에 CONNECT가 보이지 않는다면 설치되어 있지 않은 상태입니다.

 

현재 이 글을 쓸때 10.3 버전의 최신은 10.3.19이나 버그가 발생하여 10.3.18로 다운 그레이드하여 사용합니ㅏㄷ.

 

1. 플러그인 패키지 설치

 

MariaDB를 설치할 때 레파지토리를 이미 구성하였다고 가정합니다.

 

패키지 설치를 위해 Centos 7 이하 yum / 이상 dnf 를 사용합니다.

 

아래 명령을 수행하면 설치를 위한 ha_connect.so 파일등이 로컬에 설치됩니다.

 

현재 이 문서는 Centos 7 로 수행합니다.

 

# yum install -y MariaDB-connect-engine

 

or

 

특정 버전 지정 설치 (DB 버전과 일치해야 합니다!)

# yum install -y MariaDB-connect-engine-10.3.18

 

 

2. 플러그인 설치

기본적으로 플러그인은 자동으로 설치되지 않습니다.

 

두가지 방법이 있습니다.

 

방법1. INSTALL SONAME  명령 수행하기

 

다음 명령을 통해 ha_connect 를 설치합니다.

 

# mysql -uroot -p

 

MariaDB [(none)]> install soname 'ha_connect';
Query OK, 0 rows affected (0.000 sec)

 

방법2. 환경 설정 파일(my.cnf / server.cnf) 에 추가

[mariadb]

...

plugin_load_add = ha_connect

 

설치후에는 다음과 같이 조회합니다.

 

MariaDB [(none)]> show engines;

 

Engine 컬럼에 CONNECT가 보이면 정상적으로 설치되어 해당 엔진을 사용할 수 있는 상태입니다.

 

3. 플러그인 제거

 

다음 명령을 통해 제거 할 수 있습니다.

 

MariaDB [(none)]> UNINSTALL SONAME 'ha_connect';

 

MariaDB [(none)]> show engines;

 

 

4. 종속성 설치

 

10.2 버전대에는 10.3 이후 버전대와 다르게 unixODBC 라이브러리를 별도로 설치했는거 같습니다.

현재 10.3 버전은 설치 시점에 종속성이 unixODBC라 같이 설치되었기 때문에 별도로 작업은 하지 않습니다.

 

별도 작업시에는 아래 명령을 통해 설치합니다.

 

# yum install unixODBC

 

 

5. 외부 테이블 연결

 

관련 정보 : https://mariadb.com/kb/en/library/connect-table-types/

 

CONNECT Table Types

 

mariadb.com

위의 내용 중 

 

CONNECT MYSQL Table Type: Accessing MySQL/MariaDB Tables

 

부분을 살펴보겠습니다.

 

A Maria 10.4 DB서버 : 192.168.10.191

B Maria 10.3 DB서버 : 192.168.10.194

 

B 서버에서 A서버 test 데이터베이스에 json_test 테이블을 Connect 하겠습니다.

 

※ 무한 루프를 피하기 위해 MYSQL 본인 자체를 참조하지 않도로 주의하세요!

 

※ Connect는 BLOC or TEXT 컬럼은 지원하지 않습니다. 

ERROR 1163 (42000): Storage engine CONNECT doesn't support BLOB/TEXT columns

 

A 서버 json_test 테이블 CREATE 구문

 

CREATE TABLE `connect_test` (
`id` INT(11) NULL DEFAULT NULL,
`DT` DATE NULL DEFAULT NULL,
`TXT` VARCHAR(1000) NULL DEFAULT NULL COLLATE 'utf8_unicode_ci'
)
COLLATE='utf8_unicode_ci'
ENGINE=InnoDB
;

아래 INSERT 문장을 통해 3줄의 데이터를 입력합니다.

INSERT INTO connect_test VALUES (1, CURDATE(), '첫번재 입력');

INSERT INTO connect_test VALUES (2, CURDATE(), '두번재 입력');

INSERT INTO connect_test VALUES (3, CURDATE(), '세번재 입력');

 

COMMIT;

 

 

B 서버에 test 데이터베이스에 new_connect_test를  아래와 같이 명령어를 입력하여 적용합니다.

CREATE TABLE test.`new_connect_test` ( 
`id` INT(11) NULL DEFAULT NULL, 
`DT` DATE NULL DEFAULT NULL, 
`TXT` VARCHAR(1000) NULL DEFAULT NULL COLLATE 'utf8_unicode_ci' 
) 
COLLATE='utf8_unicode_ci' 
ENGINE=CONNECT

table_type=mysql

dbname=test
tabname=connect_test
connection='mysql://root:비밀번호@192.168.10.191'
; 

table_type : Mariadb / mysql 일 때 명시

dbname : 원본(A DB 서버) 데이터베이스 명

tabname : 원본(A DB 서버) 테이블 명

 

아래 실행 결과와 같이 오류가 발생하지 않으면 정상적으로 데이터가 조회됩니다.

 

조회

 

위와 같이 연결된 상태에서 A원본 서버에 데이터를 한건 지우고 나면 B 서버에서도 동일하게 한건 지워진 상태로 조회됩니다.

 

또한 B서버에서 new_connect_test 에 데이터를 입력/삭제하여도 동일하게 원본서버에 connect_test 테이블도 변경됩니다.

 

좀더 상세한 것은 아래 링크를 참조하면 됩니다.

 

https://mariadb.com/kb/en/library/connect-mysql-table-type-accessing-mysqlmariadb-tables/

 

CONNECT MYSQL Table Type: Accessing MySQL/MariaDB Tables

Accessing a MySQL or MariaDB table or view

mariadb.com

 

반응형

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

MariaDB JSON 컬럼 및 함수들  (0) 2019.11.04
MariaDB 테이블 백업 및 복구  (0) 2019.11.01
MariaDB 우편번호 Import 하기  (0) 2019.11.01
MariaDB SHA2 512 방식으로 암호화 예제  (0) 2019.10.25
Mysql & MariaDB 튜닝 쉘  (0) 2019.08.14
반응형

우편번호는 아래 링크 사이트를 통해 최신 데이터를 받을 수 있습니다.

 

https://www.epost.go.kr/search/zipcode/cmzcd002k01.jsp

 

우편번호 DB와 검색기 소개 - 우편번호 안내

우편번호 검색기란? 우편번호 검색기 바로가기 ※ 우편번호를 검색하거나 고객이 보유한 다량의 주소록에 올바른 우편번호를 자동으로 생성해 주는 프로그램입니다.

www.epost.go.kr

 

1. 테이블 생성

 

ZIPDB라는 우편번호를 저장할 수 있는 테이블을 생성합니다.

 

저는 데이터베이스를 TEST라는 곳에서 아래 테이블을 생성하였습니다.

 

CREATE TABLE IF NOT EXISTS ZIPDB (
ZONE_NO VARCHAR(5) not null COMMENT '구역번호(우편번호)', 
CTPRVN VARCHAR(20) COMMENT '시도', 
CTPRVN_ENG VARCHAR(40) COMMENT '시도영문', 
SIGNGU VARCHAR(20) COMMENT '시군구', 
SIGNGU_ENG VARCHAR(40) COMMENT '시군구영문', 
EUP_MYEON VARCHAR(20) COMMENT '읍면', 
EUP_MYEON_ENG VARCHAR(40) COMMENT '읍면영문', 
RN_CODE VARCHAR(12) COMMENT '도로명코드', 
RN VARCHAR(80) COMMENT '도로명', 
RN_ENG VARCHAR(80) COMMENT '도로명영문', 
UNDGRND_AT VARCHAR(1) COMMENT '지하여부(0:지상, 1:지하)', 
BDNBR_MNNM INT(5) COMMENT '건물번호본번', 
BDNBR_DUCA INT(5) COMMENT '건물번호부번', 
BULD_MANAGE_NO VARCHAR(25) COMMENT '건물관리번호', 
MUCH_DLVR_OFFIC_NM VARCHAR(40) COMMENT '다량배달처명(null)', 
SIGNGU_BDNBR_NM VARCHAR(200) COMMENT '시군구용건물명', 
LEGALDONG_CODE VARCHAR(10) COMMENT '법정동코드', 
LEGALDONG_NM VARCHAR(20) COMMENT '법정동명', 
LI_NM VARCHAR(20) COMMENT '리명', 
ADSTRD_NM VARCHAR(40) COMMENT '행정동명', 
MNTN_AT VARCHAR(1) COMMENT '산여부(0:토지, 1:산)', 
LNM_MNNM INT(4) COMMENT '지번본번', 
EMD_SN VARCHAR(2) COMMENT '읍면동일련번호', 
LNM_DUCA INT(4) COMMENT '지번부번', 
OLD_ZIP VARCHAR(6) COMMENT '구 우편번호(null)', 
ZIP_SN VARCHAR(3) COMMENT '우편번호일련번호(null)'
) 
 ENGINE = INNODB 
 DEFAULT CHARSET=utf8
 ;

 

 -- 인덱스 (구역번호 5자리 신 우편번호)
CREATE INDEX ZIPDB_IX1 ON zipdb(ZONE_NO);

-- 인덱스 (시도,시군구,읍면)
CREATE INDEX ZIPDB_IX2 ON zipdb(CTPRVN, SIGNGU, EUP_MYEON);

-- 인덱스(도로명코드)
CREATE INDEX ZIPDB_IX3 ON zipdb(RN_CODE);

-- 인덱스 (도로명)
CREATE INDEX ZIPDB_IX4 ON zipdb(RN);

 

 

2. 데이터 로드
우편번호 사이트의 모든 zip 값들을 서버에 /tmp/zip 폴더에 업로드
다만! 파일을 반드시 utf8로 변경 합니다.(메모장 열고 다른이름 저장에서 UTF8로 지정하면 됨.)

 

실행한 MariaDB는 10.3 버전으로 약간의 문법이 다릅니다.

 

다음 명령을 실행하여 LOAD DATA 문장을 자동으로 만듭니다.

 

# ls -lsa /tmp/zip/*.txt | awk '{print "LOAD DATA INFILE " "\x27" $10 "\x27" " INTO TABLE ZIPDB character set " "\x27" "utf8" "\x27" " fields terminated by " "\x27" "|" "\x27" " IGNORE 1 LINES;"}' 

 

아래 문장은 root 계정으로 local 시스템에 TEST 데이터베이스에 접속하라는 의미입니다.

# mysql -u root -p --local-infile=1 TEST (접속) 

 

MariaDB [TEST]> LOAD DATA INFILE '/tmp/zip/강원도.txt' INTO TABLE ZIPDB character set 'utf8' fields terminated by '|' IGNORE 1 LINES; 

 

위와 같이 수행하면 아래 그림과 같이 오류가 없는 경우 Query OK와 함께 Insert된 수가 출력됩니다.

 

2019.11.01 일 데이터 기준으로 약 1.3GB의 용량이 입력됩니다.

건수 : 3,112,960 건 

 

 

 

반응형

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

MariaDB JSON 컬럼 및 함수들  (0) 2019.11.04
MariaDB 테이블 백업 및 복구  (0) 2019.11.01
MariaDB SHA2 512 방식으로 암호화 예제  (0) 2019.10.25
Mysql & MariaDB 튜닝 쉘  (0) 2019.08.14
MySQL 백업용 쉘스크립트입니다.  (0) 2010.01.18
반응형

무료 DB 접근툴로 역 ERD도 정상적으로 잘 그려지는것을 확인하였습니다.

 

아무래도 한국어가 지원하다보니 뭔가 보여지는 모습도

 

산출물 형태를 띄고 있어 맘에 듭니다.

 

특징

 

1. 역 ERD 아주 잘 그려짐

2. 여러가지 DB를 웹 상에서 가능

3. 웹 상으로 띄우기 때문에 여러사람이 사용 가능

 

라이선스 : 일반버전 LGPL 라이선스 

 

소스 및 컴파일 다운로드 주소

https://sourceforge.net/projects/tadpoledbhub/

 

Tadpole DB Hub

Download Tadpole DB Hub for free. Web based Database collboration tools. Original home : https://github.com/hangum/TadpoleForDBTools It is a tool to manage Altibase, Amazon RDS, Apache Hive, Apache Tajo, MongoDB, CUBRID, MariaDB, MySQL, Oracle, MSSQL, SQLi

sourceforge.net

 

https://www.tadpolehub.com/tadpole

 

TadpoleHub | tadpolehub

라이브러리 aws-java-sdk-1.4.7 입니다. 작성되는 시점에서 최신 버전입니다. 

www.tadpolehub.com

 

 

 

오픈소프 버전 vs 엔터프라이즈 버전 차이

https://www.oss.kr/oss_case/show/2b6ac347-f8d4-4fc0-9c5c-33d56745f377

 

[공개SW 스타트업/테드폴허브]올챙이가 대왕개구리 되는 그날까지 - 공개SW 포털

올챙이가 대왕개구리 되는 그날까지 백지영/디지털데일리 엔터프라이즈 솔루션부 팀장/jyp@ddaily.co.kr 시높시스와 가트너 등 시장조사기관의 조사에 따르면 상용 소프트웨어(S...

www.oss.kr

 

 

반응형

'Database' 카테고리의 다른 글

「SQLP 핵심노트」 Ⅰ & Ⅱ 출간  (0) 2021.09.08
무료 ERD 툴 ERMASTER  (0) 2019.08.08
damo 암호화 컬럼 복원시 주의사항  (0) 2017.08.20
Sybase IQ Administrator 사용 Script  (0) 2012.10.18
JNDI Log4SQL 적용 예...  (0) 2011.04.21
반응형


사실 제일 중요한건... 고객사의 담당자가 신규 시스템일 경우에는 메인 업무들의 양을 아는것이 굉장히 중요하다.

즉, 어떤 업무는 어떻게 처리되고 얼마동안의 시간에 출력되어야 하며, 향후 증가세는 얼마고(큰 업무 위주)

이런 정보를 알아야 서버 용량에 대한 정확한 값을 추출할 수 있다.

사실 대부분... 동시 사용자 수 정도 밖에 몰라 추정치로 산출하다보니 장비의 spec이 고사양으로 밖에 할 수 없는

상황이 나온다.



※ 참고 자료는 정부통합전산센터에서 발췌하였습니다. ~



= 서버 용량 산정 =


2008년 12월 19일 자 정보시스템 하드웨어 규모산정 지침



정보시스템 하드웨어 규모산정 지침(TTAK[1].KO-10.0292).pdf



= 서버 성능 측정 =


TPC-H.pdf


Tier 및 용도에 따라 측정 방법은 다름

즉, DB 쪽 => TPC-H를 통한 QphH 로 측정

WAS/WEB 쪽 => SPECjbb2005 를 통한 bops로 측정


뭐 둘다 아래와 같이 추정 tpmc 값으로 역산하여 산출함.




= 추정 tpmC 산출 방식(예) =


▢ Orastress 등 유사도구를 통한 해당 장비의 tpmC 인정기준치

    - 추정기준치 tpmC = 산정 tps(전체tps * new-order 트랜잭션 비율) * 60 * 보정치

     - transaction은 tpmC에서 규정하고 있는 transaction(new-order)과 유사하여야 함.

       예로 orastress는 전체 tps가 구해지는데 산정 tps는 전체 tps가 아니고

       전체 tps에 new-order 트랜잭션 비율을 곱한 수치로 본다.

       단, 보정치는 15%로 하고 제안한 사양에 대해서 성능점검 실시

▢ OPSs로부터 해당 장비 tpmC의 인정기준치

    - 추정기준치 tpmC = OPS * 환산비(C) * 보정치

    - OPS 값은 주어졌으나 tpmC 인증을 받지 않은 경우, 다른 장비에 대한

      tpmC와 OPS 값의 비율을 계산하여 이를 환산비(C)로 곱한다.

▢ tpc-H(QphH) 공인성능치로부터 해당 장비의 tpmC 인정기준치

    - 추정기준치 tpmC = QphH * 환산비(C) * 보정치

    - QphH 값은 주어졌으나 tpmC 인증을 받지 않은 경우, 다른 장비에 대한

      tpmC와 QphH 값의 비율을 계산하여 이를 환산비(C)로 곱한다.


※ 환산비(C)와 보정치가 기술의 발전 및 각 제조사의 아키텍처 설계 방식 등에 따라 상이할

     수 있으므로 실적용 값에 대하여서는 제조사의 객관적인 자료와 내용을 밝혀야 한다.

※ 성능증빙의 객관성을 위해 5년 이내의 기준으로 된 근거자료를 제출하여야 한다.

※ ’11년 정부통합전산센터 제1차 정보자원 통합구축『추정 tpmC 산출방식(예시)』과 동일

반응형
저작자표시

'Private' 카테고리의 다른 글

svn 백업 및 복구  (1) 2019.05.08
node-red oracledb  (0) 2018.06.25
오라클 접속 ORA-12505 에러 관련  (0) 2013.05.02
Magicar AF BRONZE (매직카 브론즈)  (0) 2011.11.30
압력 밥솥 구매 ... 예정  (0) 2011.11.26
반응형

개발자의 실수를 줄여주는 java.sql.Connection 만들기







흔히 close()를 하지 않아서 발생하는 자원 누수 현상을 줄여주는 Connection 클래스를 만들어본다.

JDBC API 사용시 흔히 하는 개발자의 실수

JDBC API를 사용하여 데이터베이스 프로그래밍을 할 때 가장 많이 사용되는 코드는 아마도 다음과 같은 형태일 것이다.

    Connection conn = null;
    Statement stmt = null;
    ResultSet rs = null;
    
    try {
        conn = DBPool.getConnection(); //
        stmt = conn.createStatement();
        rs = stmt.executeQuery(..);
        ...
    } catch(SQLException ex) {
        // 예외 처리
    } finally {
        if (rs != null) try { rs.close(); } catch(SQLException ex) {}
        if (stmt != null) try { stmt.close(); } catch(SQLException ex) {}
        if (conn != null) try { conn.close(); } catch(SQLException ex) {}
    }

그런데 위와 같은 프로그래밍을 할 때 흔히 하는 실수가 close()를 제대로 해 주지 않는 것이다. 특히, 하나의 메소드에서 5-10개의 (PreparedStatement를 포함한)Statement와 ResultSet을 사용하는 경우에는 개발자의 실수로 같은 Statement를 두번 close() 하고 한두개의 Statement나 ResultSet은 닫지 않는 실수를 하곤 한다. 이처럼 close() 메소드를 알맞게 호출해주지 않을 경우에는 다음과 같은 문제가 발생한다.

  1. Statement를 닫지 않을 경우, 생성된 Statement의 개수가 증가하여 더 이상 Statement를 생성할 수 없게 된다.
  2. close() 하지 않으므로 불필요한 자원(네트워크 및 메모리)을 낭비하게 된다.
  3. 커넥션 풀을 사용하지 않는 상황에서 Connection을 닫지 않으면 결국엔 DBMS에 연결된 새로운 Connection을 생성할 수 없게 된다.
위의 문제중 첫번째와 두번째 문제는 시간이 지나면 가비지 콜렉터에 의해서 해결될 수도 있지만, 만약 커넥션 풀을 사용하고 있다면 그나마 가비지 콜렉션도 되지 않는다. 따라서 커넥션 풀을 사용하는 경우 Statement와 ResultSet은 반드시 닫아주어야만 한다. 하지만, 제아무리 실력이 뛰어난 개발자라 할지라도 각각 수십에서 수백줄로 구성된 수십여개의 .java 파일을 모두 완벽하게 코딩할 수는 없으며, 따라서 한두군데는 close()를 안 하기 마련이다. 운이 좋으면 빨리 찾을 수 있겠지만, 그렇지 않다면 close() 안한 부분을 찾는 데 몇십분, 몇시간, 심한 경우 1-2일 정도가 걸리기도 한다.

Statement를 자동으로 닫아주는 MVConnection 클래스 구현

실제로 필자도 앞에서 언근했던 문제들 때문에 고생하는 사람들을 종종 봐 왔었으며, 그때마다 그 버그를 고치기 위해서 소스 코드를 일일이 찾아보는 노가다를 하는 개발자들을 보기도 했다. 그래서 만든 클래스가 있는데, 그 클래스의 이름을 MVConnection이라고 붙였다. 이름이야 여러분의 입맛에 맛게 수정하면 되는 것이므로, 여기서는 원리만 간단하게 설명하도록 하겠다.

먼저, MVConnection을 구현하기 전에 우리가 알고 있어야 하는 기본 사항이 있다. JDBC API를 유심히 읽어본 사람이라면 다음과 같은 내용을 본 적이 있을 것이다.

  • Statement를 close() 하면 Statement의 현재(즉, 가장 최근에 생성한) ResultSet도 close() 된다.
  • ResultSet은 그 ResultSet을 생성한 Statement가 닫히거나, 또는 executeQuery 메소드를 실행하는 경우 close() 된다.
MVConnection은 바로 이 두가지 특성을 사용한다. 위의 두 가지 특징을 정리하면 결국 Statement만 알맞게 닫아주면 그와 관련된 ResultSet은 자동으로 닫힌다는 것을 알 수 있다. 따라서 ConnectionWrapper 클래스는 Connection이 생성한 Statement들만 잘 보관해두었다가 각 Statement를 닫아주기만 하면 되는 것이다. PreparedStatement나 CallableStatement는 Statement를 상속하고 있으므로 따로 처리할 필요 없이 Statement 타입으로 모두 처리할 수 있으므로, PreparedStatement와 CallableStatement를 위한 별도의 코드는 필요하지 않다.

다음은 MVConnection 클래스의 핵심 코드이다.

    public class MVConnection implements Connection {
        
        private Connection conn; // 실제 커넥션
        
        private java.util.List statementList; // statement를 저장
        
        public MVConnection(Connection conn) {
            this.conn = conn;
            statementList = new java.util.ArrayList();
        }
        
        public void closeAll() {
            for (int i = 0 ; i < statementList.size() ; i++) {
                Statement stmt = (Statement)statementList.get(i);
                try {
                    stmt.close();
                } catch(SQLException ex) {}
            }
        }
        
        public void close() throws SQLException {
            this.closeAll();            conn.close();
        }
        
        public Statement createStatement() throws SQLException {
            Statement stmt = conn.createStatement();
            statementList.add(stmt);
            return stmt;
        }
        
        public CallableStatement prepareCall(String sql) throws SQLException {
            CallableStatement cstmt = conn.prepareCall(sql);
            statementList.add(cstmt);
            return cstmt;
        }
        
        public PreparedStatement prepareStatement(String sql) throws SQLException {
            PreparedStatement pstmt = conn.prepareStatement(sql);
            statementList.add(pstmt);
            return pstmt;
        }
        
        ...
    }

위 코드를 보면 Statement를 저장하기 위한 List와 그 List에 저장된 Statement 객체를 모두 닫아주는 closeAll() 이라는 메소드가 정의되어 있다. 바로 이 List와 closeAll() 메소드가 이 MVConnection 클래스의 핵심이다. Statement를 생성해주는 메소드(createStatement, prepareCall, prepareStatement)를 보면 생성된 Statement를 statemetList에 추가해주는 것을 알 수 있다. 이렇게 저장된 Statement는 실제로 Connection을 닫을 때, 즉 Connection의 close() 메소드를 호출할 때 닫힌다. (코드를 보면 close() 메소드에서 closeAll() 메소드를 먼저 호출하고 있다.) 따라서, close() 메소드만 호출하면 그와 관련된 모든 Statement와 ResultSet은 자동으로 닫히게 된다.

위 코드에서 다른 메소드들은 모두 다음과 같이 간단하게 구현된다.

    public boolean getAutoCommit() throws SQLException {
        return conn.getAutoCommit();
    }

MVConnection은 java.sql.Connection을 implements 하기 때문에, 그 자체가 Connection으로 사용될 수 있다. 따라서 MVConnection을 사용한다고 해서 특별히 코드가 많이 변경되지는 않으며 다음과 같이 전체적으로 코드가 단순하게 바뀐다.

    Connection conn = null;
    Statement stmt = null;
    ResultSet rs = null;
    
    try {
        // MV Connection 생성
        conn = new MVConnection(DBPool.getConnection());
        stmt = conn.createStatement();
        rs = stmt.executeQuery(..);
        ...
    } catch(SQLException ex) {
        // 예외 처리
    } finally {
        // conn 만 close() 해준다.
        if (conn != null) try { conn.close(); } catch(SQLException ex) {}
    }

때에 따라서는 Connection을 close() 하지 않고 커넥션 풀에 되돌려 놔야 할 때가 있다. 그런 경우에는 다음과 같은 형태의 코드를 사용하면 된다.

    Connection conn = null;
    Statement stmt = null;
    ResultSet rs = null;
    
    try {
        // MV Connection 생성
        conn = new MVConnection(DBPool.getConnection());
        stmt = conn.createStatement();
        rs = stmt.executeQuery(..);
        ...
    } catch(SQLException ex) {
        // 예외 처리
    } finally {
        if (conn != null) try { 
            ((MVConnection)conn).closeAll();
            DBPool.returnConnection(conn);
        } catch(SQLException ex) {}
    }

즉, Connection을 닫지 않는 경우에는 위와 같이 커넥션 풀에 반환하기 전에 closeAll() 메소드 하나만을 호출해주면 된다. 그러면 Connection과 관련된 모든 Statement, ResultSet 등이 닫히게 된다.

결론

필자의 경우는 이 글에서 작성한 MVConnection을 실제 프로젝트에 응용하여 코드 작성의 편리함 뿐만 아니라 실수로 인해서 발생하는 시스템의 버그 문제를 어느 정도 해결할 수 있었다. 특히, Statement를 생성하거나 ResultSet을 생성할 때 발생하는 커서부족 문제를 획기적으로 줄일 수 있었다. 여러분도 이 클래스를 응용하여 보다 나은 방법으로 코딩의 실수 및 자원의 낭비를 줄일 수 있는 클래스를 작성해보기 바란다.

반응형
저작자표시

'Language > JAVA' 카테고리의 다른 글

간단한 포트 확인용 에코 프로그램  (0) 2013.01.29
Java 성능 모니터링에 대해 모르고 있던 5가지 사항, Part 1  (0) 2012.05.02
엑셀 대용량 다운로드 가능하게 자바 만들기  (0) 2012.04.05
OOM(Out Of Memory) 없이 IBM Heapdump 파일 분석하기  (0) 2012.02.15
System.out.println()은 잊어라 log4sql이 온다.  (0) 2011.03.15
반응형

출처 : http://cafe.naver.com/prodba

sysdba로 접속하여 알아낸다...

또한 결과는 alert.log로 찍힌다 ~

$> sqlplus '/as sysdba'

sql>


create trigger logon_denied_to_alert
after servererror on database
declare
message varchar2(4000);
begin
    select 'ip='||sys_context('userenv','ip_address')||',host='||sys_context('userenv ','host')||',osuser='||SYS_CONTEXT('USERENV', 'OS_USER')
    into message
    from dual;
IF (ora_is_servererror(1017)) THEN
message := to_char(sysdate,'Dy Mon dd HH24:MI:SS YYYY') || ' logon denied for ' || message;
sys.dbms_system.ksdwrt(2,message);
end if;
end;
/
반응형
저작자표시

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

오라클 TRANSLATE  (0) 2011.03.31
오라클 자격증 신청 절차  (0) 2011.03.28
테이블 정의서 추출 생성 스크립트  (0) 2011.01.06
ORACLE SESSION Monitoring SQL  (0) 2011.01.05
오라클 공부 방법  (0) 2010.12.08
반응형


Oracle version이 10.2.0.4로 동일하고 DB간 character set 도 동일하다고 가정한다면....

 

그냥 데이타파일을 copy하면 안되고요...

Cross-Platform Transportable Tablespaces 기능을 사용하시면 됩니다.

 

이때 Source 와 Target DB에서 아래를 조회해서 endian format이 같은지 검사해서...

아래 경우 little endian인데...source db와 target db의 os가 동일한 endian이면 상관없지만

 

 

        SQL> select PLATFORM_ID, PLATFORM_NAME  from v$database;
       
        PLATFORM_ID PLATFORM_NAME
        ----------- ------------------------------
                 10 Linux IA (32-bit)

 

        SQL> select  * from v$transportable_platform;
       
        PLATFORM_ID PLATFORM_NAME                  ENDIAN_FORMAT
        ----------- ------------------------------ --------------
                  1 Solaris[tm] OE (32-bit)        Big
                  2 Solaris[tm] OE (64-bit)        Big
                  7 Microsoft Windows IA (32-bit)  Little  
                 10 Linux IA (32-bit)              Little   <--- Little endian임.
                  6 AIX-Based Systems (64-bit)     Big
                  3 HP-UX (64-bit)                 Big
                  5 HP Tru64 UNIX                  Little
                  4 HP-UX IA (64-bit)              Big
                 11 Linux IA (64-bit)              Little
                 15 HP Open VMS                    Little
                  8 Microsoft Windows IA (64-bit)  Little
                  9 IBM zSeries Based Linux        Big
                 13 Linux 64-bit for AMD           Little
                 16 Apple Mac OS                   Big
                 12 Microsoft Windows 64-bit for A Little
                    MD

 

다를 경우 Rman으로 Data File Conversion 을 해야 합니다.

 

     - Source 에서
       > rman target=/
       RMAN> Convert Tablespace 'FINANCE, HR' to Platform ='AIX_Based System (64-bit)'  <--    

                  v$transportable_platform.platform_name
                     DB_FILE_NAME_CONVERT = '/orahome/dbs1', '/orahome/dbs/transport_aix',
                                            '/orahome/dbs2', '/orahome/dbs/transport_aix'; 
         <--해당 디렉토리 아래 FINANCE, HR TS에 해당하는 모든 것을 convert하여 지정된 디렉토리 아래로 copy
        
     또는
    
     - Target 에서
       > rman target=/    
       RMAN> Convert Datafile '/tmp/transport_stage/*' From Platform = 'Solaris[tm] OE (32-bit)'
                     DB_FILE_NAME_CONVERT = '/tmp/transport_stage/fin', '/orahome/dbs1/fin',
                                            '/tmp/transport_stage/hr',  '/orahome/db2/hr';
     - DB_FILE_NAME_CONVERT 가 없으면 flash recovery area에 같은 이름으로 만들어진다.
     - Parallelism option은 parallel하게 복수개의 file을 convert할때 사용.  Convert 시간은 Rman으로
       백업할때 걸리는 시간과 같다. Convert 전후의 file size는 변함이 없다.




TDB라는 방법도 있습니다.

http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-platformmigrationtdb-131164.pdf

Platform Migration Using Transportable Database Oracle Data.pdf

HP.UX -> AIX로 진행 해 봤는데..

시간이 많이 걸리던 순서대로 나열하면 exp/imp, TTS, TDB 순서 더군요...

참고 하세요..

[출처] unix -> xp 데이터베이스 복제 질문입니다. (ProDBA) |작성자 개굴개굴




반응형
저작자표시

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

오라클에서 사용량 많은 프로세스 죽이기  (0) 2010.12.03
오라클 일일 모니터링  (1) 2010.11.05
ORACLE PATCHSET Upgrade  (0) 2010.09.14
오라클 라이브러리 (참고문서)  (0) 2010.09.10
proc: error while loading shared libraries: libclntsh.so.10.1: cannot open shared object file: No such file or directory  (0) 2010.09.09
반응형

--- Arup Nanda 의 사이트에 자주 들어가봅니다. DBA 로서의 장애 Case 를 대응하는 절차가 비교적 자세히 나와있더군요. 요즘 일이 많아서 빠르게 쓰다보니 오역과 중간중간 빼먹는게 많은건 이해해주시길...아래는 실제로 DMA (direct memory access)를 사용해서 처리한 사례더군요..

  

Diagnosing Library Cache Latch Contention: A Real Case Study

 

어느날 DW 서버가 갑자기 다운됐다. 그래서 데이타베이스를 올리고 다시 구동했지만 모든 접속을 시도하면
hang 이 걸리는 것이였다. 따라서 접속은 실패하고 DBA는 접속된 세션들이 구동되고 있는지 어떤지를 확인할 수 조차도
없었다. DBA 는 WAIT 이벤트를 체크했다 (그러나 로긴조차도 안되기 때문에 실행할수 없었다)
흥미롭게도 CPU는 70% 정도의 수준이였고 이는 낮시간대의 일반적인 수치이다. 그리고 I/O또한 약 90%로서 이또한
일반적인 수치였다.

따라서 전형적인 방법인 system 관리자에게 보고하고 재부팅을 하는 방법을 사용했다. 재부팅은 30분정도
소요되었고 그 후로 10여분간은 모든것이 정상적으로 보였다. 그러나 얼마되지 않아 아까와같은 똑같은 문제에 부딪쳤다- 데이타베이스가 먹통이 되어버린 것이였다.

이것 때문에 DBA가 나에게 도움을 요청하였다. 이 블로그에서는 내가 이후의 30분동안에 어떻게 수행했고 문제를
해결했는지에 대해서 기술해보도록 하겠다.

 

증상


(1) 데이타베이스 접속 Hanging
(2) SQL*PLUS AS SYSDBA 로 접속해도 동일한 HANGING 현상: 증상을 확인할 수도 없는 상태
(3) 시스템은 아무때나 리부팅할 수 없는 상태

 

Action

 

여기서 접속이 불가능할 때 데이타베이스 인스턴스에서 바로 써먹을 수 있는 꼼수가 존재한다.
대부분의 사람들은 SQL*Plus 에서 "prelim" 이라고 불리는 옵션을 잘알지 못한다. 이 옵션은 세션을 열지 않고
SGA에 바로 접속한수 있는 옵션이다. (10g 이상에서만 가능) 

 

(1) 먼저 SQL*plus 를 실행시키고 아래의 명령문을 실행했다.

 

$ sqlplus -prelim / AS SYSDBA
SQL>

 

명심하라. "Oracle Database 10.2.0.3 에 접속" 과 다르다. 지금 보이는 SQL> 프롬프트는 실제로는
데이타베이스에 접속한 상태가 아니다.

 

(2) 그다음 SGA 를 분석하기 위한 "oradebug" 를 사용하였다.

 

SQL> oradebug setmypid
SQL> oradebug hanganalyze 12

 

이 명령은 USER_DUMP_DEST 에 trace파일을 생성한다. 이 파일을 가장 최근에 생겨났기 때문에
쉽게 찾을 수 있다. 심지어는 내가 파일을 찾지 못해도 process ID를 사용해서 파일을 찾을 수 있다.
내가 찾은 파일은 프로세스ID 가 13392인 crmprd1_ora_13392.trc 였다.

(3) 파일을 조사하니 다음과 같았다.

 

*** 2008-08-23 01:21:44.200
==============
HANG ANALYSIS:
==============
Found 163 objects waiting for
<0/226/17/0x1502dab8/16108/no>
Open chains found:
Chain 1 : :
<0/226/17/0x1502dab8/16108/no>
<0/146/1/0x1503e898/19923/latch:>

이 파일을 많은 것을 말해준다. SID 146 에 Serial# 1 이 library cache latch 를 대기하고 있는 것을 보여준다.(맨마지막줄)
그리고 blocking 세션은 SID 226 Serial# 17 로 나와있다. 

나는 일단 이 OS process ID 인 16108 과 19923 을 기록해두었다.

 

(4) 다음으로 위의 두개의 OS PID 명으로 되어 있는 TRACE 파일을 체크했다.

 

crmprd1_ora_16108.trc
crmprd1_ora_19923.trc

 

(5) 먼저 BLOCKER인 첫번째 파일을 열었다. 다음 몇줄의 예이다.

 

*** 2008-08-23 01:08:18.840
*** SERVICE NAME:(SYS$USERS) 2008-08-23 01:08:18.781
*** SESSION ID:(226.17) 2008-08-23 01:08:18.781
LIBRARY OBJECT HANDLE: handle=c0000008dc703810 mtx=c0000008dc703940(8000) cdp=32737
name=UPDATE DW_ETL.FRRS_PROFILER SET CONSUMER_LINK = :"SYS_B_0", ADDRESS_LINK = :"SYS_B_1", ADDRESS_MATCH = :"SYS_B_2", PROC
ESSED=:"SYS_B_3" WHERE RNUM = :"SYS_B_4"
hash=a029fce7bb89655493e7e51a544592a4 timestamp=08-23-2008 00:10:23
namespace=CRSR flags=RON/KGHP/TIM/OBS/PN0/MED/KST/DBN/MTX/[504100d0]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=10 hpc=0058 hlc=0058
lwt=c0000008dc7038b8[c0000008dc7038b8,c0000008dc7038b8] ltm=c0000008dc7038c8[c0000008dc7038c8,c0000008dc7038c8]
pwt=c0000008dc703880[c0000008dc703880,c0000008dc703880] ptm=c0000008dc703890[c0000008dc703890,c0000008dc703890]
ref=c0000008dc7038e8[c0000008dc7038e8,c0000008dc7038e8] lnd=c0000008dc703900[c0000008dc703900,c0000008dc703900]
LOCK OWNERS:
lock user session count mode flags
---------------- ---------------- ---------------- ----- ---- ------------------------
c0000008d079f1b8 c0000006151744d8 c0000006151744d8 16 N [00]
c0000008d4e90c40 c0000006151bcb58 c0000006151bcb58 16 N [00]
c0000008d0812c40 c0000008151a0438 c0000008151a0438 16 N [00]

 
(6) 이것은 디버깅을 위해 보물과 같았다. 첫번째에 SID와 Serial#(226,17) 를 확인할수 있다.
이를 사용해서 정확한 SQL문장을 볼수 있다. 또한 락에 대한 전체적인 상황을 볼 수 있다. 락의 자세한 사항은 신경쓰지 않아도 되지만 SID 226 이 전체 세션의 대기를 유발시키는 것이라는 충분한 정보를 제공해주었다.

 

(7) 나의 조사는 여기서 그치지 않고  이 대기를 유발하는 세션을 찾기를 시도했다. 따라서 나는 파일의 "PROCESS STATE" 이라는 섹션을 조사했다. 다음은 이 파일의 일부분이다.

 

PROCESS STATE
-------------
Process global information:
process: c00000081502dab8, call: c000000817167890, xact: 0000000000000000, curses: c00000081519ef88, usrses: c000000815
19ef88
----------------------------------------
SO: c00000081502dab8, type: 2, owner: 0000000000000000, flag: INIT/-/-/0x00
(process) Oracle pid=370, calls cur/top: c000000817167890/c000000817167890, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 115 0 4
last post received-location: kslpsr
last process to post me: c000000615002038 1 6
last post sent: 0 0 24
last post sent-location: ksasnd
last process posted by me: c000000615002038 1 6
(latch info) wait_event=0 bits=20
holding (efd=4) c0000008d7b69598 Child library cache level=5 child#=10
Location from where latch is held: kglhdgc: child:: latch
Context saved from call: 13
state=busy, wlstate=free
waiters [orapid (seconds since: put on list, posted, alive check)]:
291 (197, 1219468295, 197)
279 (197, 1219468295, 197)
374 (197, 1219468295, 197)
267 (197, 1219468295, 197)
372 (197, 1219468295, 197)
... several lines sniped ...
307 (15, 1219468295, 15)
181 (6, 1219468295, 6)
waiter count=58
Process Group: DEFAULT, pseudo proc: c0000008e03150d8
O/S info: user: oracrmp, term: UNKNOWN, ospid: 16108
OSD pid info: Unix process pid: 16108, image: oracle@sdwhpdb1


 

 

(8) 이파일은 내가 알기를 원하는 것을 모두 말해준다. 여기에 SID 226 에 의해서 발생하는 CACHE LATCH
로 인해서 대기하는 58 session들이 있다. 여기서 OS PROCESS ID 와 BLOCKING 세션의 SQL 문장을 알 수 있다.

 

 

(9) 나는 application 사용자가 어떠한 것을 실행했는지를 조사해봤더니 사용자는 loop를 돌면서 처리하는
update 문장을 실행시킨 것이였다. 그리고 그게 다가 아니라 다른 8개의 thread 에서 실행을 하였다.(역: 아마도 화면상에서 처리 가 되지 않으니 화면을 새로고쳐서 계속해서 8번을 처리 버튼을 누른것으로 생각됨)
의심할 여지가 없이 library cache latch 경합에 걸렸다. 모든 세션은 각각의 덤프 정보를 남겼다.
그리고 나는 같은 문장을 실행한 파일을 디렉토리에서 조사해보기로 했다.

 

$ grep “UPDATE DW_ETL” *.trc

 

(10) 나는 9개 이상의 세션(프로세스) 파일을 찾았다. 이중 한개의 파일의 일부분이다.

 

350 (167, 1219470122, 167)
197 (167, 1219470122, 167)
waiter count=185
Process Group: DEFAULT, pseudo proc: c0000008e03150d8
O/S info: user: oracrmp, term: UNKNOWN, ospid: 16114

 

이 프로세스 한개가 185개 waiter 를 가졌다!!!


 

$ kill -9

 

(12) 위의 명령으로 몇개의 프로세스를 죽인 후에야 데이타베이스는 응답하기 시작했다. 모든 프로세스를 죽인 후에는 데이타베이스 wait event 가 완벽히 정상적으로 돌아왔다.

 

참고사항


(1) Hang 이라고 생각되면 너무 그것에 대해 불안해하지 마라. 세션은 언제나 어떤것을 대기한다. 드물게 행을 만날 뿐이다.

v$session (10g) 이나  v$session_wait 의 EVENT 컬럼을 조회해서 대기하는 것이 무엇인지를 먼저 체크하라.

(2) 데이타베이스에 로긴하지 못해 정보를 얻을 수 없을 때는 oradebug 명령을 사용한다.

(3) oradebug 를 사용할때 SQL*Plus 를 이용한다. 로긴하지 못할때 "sqlplus -prelim " 로 SQL prompt 를 얻을 수 있을 것이다.

(4) oradebug setmypid  이용해서 oradebug 세션을 시작하고 oradebug hanganalyze  로 모든 hang 과 관련되어 있는

문제에 대한 덤프를 생성한다.

(5) oradebug help 를 사용해서 oradebug 커맨드의 모든것을 볼 수 있다.

 

 

[출처] DB에 Connect 할수 없을 때의 진단 - Case Study(Library Cache Latch Contention)|작성자 꾸니

반응형
저작자표시

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

오라클 일괄 컴파일  (0) 2010.06.30
프로시저에서 엑셀파일 출력하기  (0) 2010.06.29
Oradebug 사용법  (0) 2010.03.26
ErrorStack 덤프를 이용해 문제 SQL 찾아내기  (0) 2010.03.26
간단한 방법으로 SID 변경하기 (nid 사용)  (0) 2010.03.15
반응형

 

박중수 | 엔커블루 기술본부 대표 컨설턴트

기업에서의 데이터 증가는 기하급수적으로 늘어나고 있으며 그에 따른 데이터베이스 성능도 대용량을 처리할 수 있도록 발전하고 있다. 따라서 데이터베이스 관리자는 예전과 달리 데이터베이스의 운영을 매뉴얼하게 할 수 있는 상태에 직면해 있으며, 자동화된 모니터링 및 Alerts로 안정적인 서비스에 대응할 수 있는 툴을 원하고 있다. 이러한 요구사항을 위한 토드의 GUI 환경에서의 데이터베이스 모니터링 기능을 살펴보자.

데이터베이스 개발에 있어 토드(Toad)를 사용하는 사람들은 일반적으로 “토드는 개발자들을 위한 개발 툴”이란 생각을 많이 한다. 즉 단순히 SQL 문장이나 PL/SQL 문장을 빠르고 쉽게 개발할 수 있고, 데이터베이스 객체의 생성 및 변경 작업을 GUI 환경에서 간단하게 수행하며 소스코드 상의 문제점들을 자동으로 찾아주고, 디버깅 기능을 통해 개발자들의 수고를 덜어 줄 수 있는 툴 정도로만 인식하고 있는 것이다. 하지만 토드를 좀 더 세밀하게 들여다보면 개발자만을 위한 툴이 아닌 데이터베이스를 관리(management)하는 DBA(Database Administrator)가 사용할 수 있는 다양한 기능들이 숨겨져 있다. 이 글에서는 토드에 숨겨진 유용한 기능에 대해 소개하고자 한다.

DBA의 역할은 무엇일까?

DBA는 현재 운영되고 있는 시스템, 데이터베이스, 애플리케이션, 네트워크, 서비스 등의 다양한 환경을 구성하고 설치, 보안, 운영 및 설계나 개발 단계에 직, 간접적으로 참여해 전체 구성이 원활하게 유지되도록 하는 업무를 담당하고 있다.
이러한 업무를 수행하다 보면 원하는 서비스가 제대로 동작하지 못하고 특정 부분에 대한 장애가 발생하거나 알 수 없는 그 무엇인가에 의해 성능이 원하는 만큼 나오지 않을 경우도 있다. 특히 DBA에게 내·외적 요소에 의한 뜻하지 않는 돌발상황으로 인해 소비되는 시간이나 노력은 가장 큰 부담이다. 이럴 경우 DBA는 누군가가 현재의 시스템이나 데이터베이스의 부하 없이 효율적으로 문제점을 찾아내어 원인 파악을 해주고 문제점을 해결할 방법을 제시해 준다면 하늘로 날아갈 것 같은 기분을 느낄 것이다.
실제 DBA들은 이로 인해 발생하는 비용을 최소화하기 위해 툴을 사용한다. 하지만 문제점을 감지하는 툴, 문제점을 분석하는 툴, 문제점을 해결하는 툴에 이르기까지 다양한 툴 도입에 따라 발생하는 비용 부담과 함께 툴을 효과적으로 사용하고 있는가를 생각해보면 힘이 빠질 수밖에 없다.
이 글에서는 툴을 효과적으로 사용할 수 있는 정보를 제공하기 위해 가장 널리 사용되는 토드라는 데이터베이스 개발 툴을 선택했다. 특히 토드는 개발 툴 위주로 개발이 됐지만 ‘DBA 모듈’이라는 옵션 기능이 있어 토드 하나만 갖고도 데이터베이스를 최적의 상태로 유지할 수 있는 기능이 있다. 물론 전문적으로 감지·분석·해결에 초점을 맞춘 방대한 툴과의 비교는 어렵겠지만 그래도 적은 비용으로 문제를 해결할 수 있는 솔루션이 있다면 좋지 않겠는가.

DB의 문제점을 발견하라!

토드를 구입했다고 해서 DBA 기능을 전부 사용할 수 있는 것은 아니다(‘토드 DBA 모듈’은 옵션 제품이다). 제품을 구입할 당시에 DBA 모듈이라는 제품을 추가적으로 구입해야 사용이 가능하다. 하지만 개발 위주의 작업이 아닌 전사적인 방법으로 토드를 사용할 것이라면 추천할 만한 사항이라고 생각한다. 그러면 자신이 사용하고 있는 토드를 갖고 이 DBA 기능을 어떻게 사용할 수 있을까?
확인할 수 있는 가장 간단한 방법은 토드의 메인 메뉴 중에서 DBA 메뉴를 클릭해 보면 그 아래 리스트가 길게 나와 있느냐 짧게 나와 있느냐에 따라 확인할 수 있다. <화면 1>처럼 길게 리스트가 나온다면 DBA의 기능을 최적의 상태에서 사용할 수 있다는 뜻이다. 그럼 토드의 DBA 기능을 Detect, Diagnostic, Resolve라는 3개의 단계에 초점을 맞추어 살펴보자.

<화면 1> DBA 메뉴


데이터베이스에 문제가 발생하면 DBA는 일단 원인부터 파악한다. 하지만 어느 부분이 문제가 있는지를 감지하기란 사막에서 모래알을 찾는 것만큼 어려운 일이다. 토드에서 지원하고 있는 DBA 기능 중에서 데이터베이스 모니터(Database Monitor), 헬쓰 체크(Health Check), 인스턴스 매니저(Instance Manager)를 통해 현재의 데이터베이스 상태를 감지할 수 있다.

데이터베이스 모니터

우선 데이터베이스 운영자는 데이터베이스의 성능을 높이기 위해 물리적인 I/O의 병목현상을 제거함으로써 시스템의 메모리와 CPU 자원의 경합을 줄이며 안정적인 서비스를 제공할 수 있다. 그리고 데이터베이스 운영자는 각 세션들에서 발생되는 Wait Event(네트워크 통신이나 I/O 요청 또는 데이터베이스의 특정 자원을 여러 프로세스가 동시에 액세스할 때 발생하는 경합에 의한 대기)의 원인을 제거함으로써 원활한 응답속도를 유지해야 한다.
데이터베이스 모니터 기능은 데이터베이스의 Data Dictionary (V$SYSSTAT, V$SYSTEM_EVENT)를 이용해 메모리, I/O, Latch, 세션 그룹으로 나눠 관련 정보를 추출해 <화면 2>와 같이 9가지 그룹으로 사용자가 Refresh Rate(Interval)를 적용해 주어진 시간에 따라 변화되는 모습을 한 화면에서 볼 수 있다. 이에 성능과 관련된 문제점을 쉽게 파악할 수 있으며, 성능에 지장을 초래한 SQL의 진단 또는 초기 파라미터를 조정할 수 있다.

<화면 2> 데이터베이스 모니터


◆ 데이터베이스 모니터의 주요 기능
① Auto Refresh 설정 기능
② Refresh Rate 설정 기능
③ Alerts에 대한 Propagation 기능
④ 데이터베이스의 Data Dictionary(V$) 정보 그래픽 디스플레이 기능

이터베이스 모니터의 그래프 정보
① Logical I/O : 논리적인 I/O는 SGA(메모리)에 존재하는 데이터베이스 블럭의 Change, Current, Consistent Read들에 대한 통계 추이의 정보
② Physical I/O : 물리적인 I/O는 데이터파일(디스크)의 해당 블럭을 읽어 SGA(메모리)로 올리거나 또는 메모리에서 변경된 블럭을 데이터파일(디스크)로 작성, 그리고 LGWR에 의해서 온라인 리두(redo) 로그 파일로 작성되는 통계 추이의 정보
③ Event Wait : 데이터베이스는 시스템 또는 세션별로 발생하는 Wait 이벤트 통계 정보를 누적해 기록하는데 풀 스캔(Full Scan)시 I/O를 요청하고 대기하는 ‘Mulit-block Read’, 인덱스 스캔시 I/O를 요청하고 대기하는 ‘Single-block Read’, 테이블 스캔시 버퍼 캐시를 거치지 않는 ‘Direct Patch Read’ 등의 통계 추이의 정보
④ Sessions : Sessions는 데이터베이스에 접속한 모든 세션들을 활동 세션(active), 백그라운드 세션(system), 아이들(Idle) 세션으로 분류해 표현한 정보
⑤ all Rates : 사용자가 요청한 SQL에 대한 구문 분석(parse), 실행(execute), 변경 정보 영구저장(commit), 변경 정보 취소(rollback) 정보
⑥ Miss Rates : 데이터베이스의 대표적인 성능 지표인 버퍼 캐시(Buffer Cache) 미스율, 라이브러리/딕셔너리 미스율(SQL Area), 래치 미스율(Latch)의 정보
⑦ SGA Memory Usage : SGA에 할당된 메모리의 사용률에 대한 정보(Shared Pool, 버퍼 캐스, 로그 버퍼)
⑧ Shared Pool : SGA에 할당된 메모리 중 SQL에 대한 공유 메모리의 Detail 사용률에 대한 정보(라이브러리 캐시, 딕셔너리 캐시, Misc Area 등)
⑨ Index Query % : 데이터베이스에서 사용된 SQL 중 쿼리에 대해 인덱스 사용(Indexed %)과 미사용(Non-Indexed %)에 대한 정보

데이터베이스 모니터의 Alert
그렇다면 DBA는 현재 데이터베이스가 문제점이 있는지의 여부를 판단하기 위해 항상 데이터베이스 모니터링 툴을 보고만 있어야 하는가? 그렇다면 진정한 탐지 툴(Detection Tool)이라고 할 수가 없을 것이다. 이를 위해 Alert 기능을 제공한다. 토드 옵션의 데이터베이스 모니터를 찾아보면 모니터링하고자 하는 앞의 9가지 항목들에 대해 임계치(Thresholds)를 설정해 해당 임계치에 도달하면 Alert를 DBA에게 보여줄 수 있도록 지정할 수도 있다. 그러면 토드가 설치되어 있는 PC의 맨 아래에 Toad Database Monitor라는 아이콘이 나타나서 DBA에게 신호를 보내준다.

헬쓰 체크

데이터베이스 구축 후 시간이 지남에 따라 데이터의 크기는 현저하게 증가하게 되고 또한 다양한 문제점들이 나타나게 되는데, 인스턴스에서 발생하는 문제점들을 DBA가 찾아서 조치하기에는 시간과 비용이 만만치 않다. 이에 DBA는 C 검사를 원하는 항목(SGA, Analyze, Extent, JOB……)들에 대해 조건을 설정한다. 해당 조건을 만족하는 내용에 대해 자동으로 체크해 결과를 보여준다면 DBA의 역할은 그만큼 줄어들 것이며, 이를 통해 데이터베이스에 지장을 초래할 수 있는 원인들을 미연에 방지할 수 있다.

◆ 헬쓰 체크의 주요 기능
① 전체의 아이템을 수행하거나 특정한 아이템만 선택해 체크할 수 있다.
② 분석 결과에 대한 리포트
③ SGA 사용 내역
④ Unanalyzed Segments(테이블, 인덱스, 파티션 테이블/인덱스)
⑤ 100개가 넘는 Extent를 소유한 세그먼트
⑥ JOB의 Broken, Sysdate보다 이전의 JOB, Long running JOB 등

<화면 3>은 토드의 헬쓰 체크 기능을 수행한 화면이다. 여기에는 Checks and Options, Other Settings, Report Output 등 3가지 탭으로 구성되어 있는데, Check and Options 탭에서 이미 지정되어 있는 다양한 인스턴스 체크 사항 중에서 원하는 항목을 지정하고 그에 따른 값을 입력하고 실행하면 Report Output 탭에 Health Check를 수행한 결과를 보여준다.

<화면 3> 데이터베이스 헬쓰 체크


인스턴스 매니저

이 기능은 현재 동작 중인 데이터베이스의 인스턴스에 커넥션을 자동으로 수행해 Startup 상태인지 Shutdown 상태인지를 체크할 수 있으며, 토드에서 직접 Startup/Shutdown 명령을 수행하거나 Init 파라미터 파일을 빌딩(building)할 수도 있다.

<화면 4> 인스턴스 메니저


DB의 문제점을 분석하라!

데이터베이스의 문제점을 파악했으면 과연 이 문제점의 원인은 무엇이며, 현재 데이터베이스 성능에서 병목현상(Bottleneck)이 발생하는 영역은 어디인지에 대해 자세하게 분석해야 한다.
분석 작업은 시작해야 하는 포인트가 중요하다. 예를 들어, 오라클 데이터베이스에서 현재 심각하게 성능이 다운되는 현상이 발생하고 있다면 과연 이 문제가 메모리 쪽인지, I/O 쪽인지, I/O라면 데이터파일인지 리두 로그 파일인지를 파악해야 한다. 메모리라면 Shared Pool인지 데이터베이스 버퍼 캐시인지 리두 로그인지 판단해야 한다. DBA 입장에서 특정 문제점이 발생한 영역을 알 수 있다면 그 부분을 집중적으로 분석해 문제점을 해결해야 하는데, 토드는 이러한 분석을 쉽게 할 수 있는 다양한 기능들을 갖고 있다.

Database Probe

데이터베이스의 구성은 크게 메모리(SGA), 프로세스, 데이터파일(Online Redo Logfile, User Datafile)로 구성되며 서버 프로세스와 백그라운드 프로세스에 의해 자동적으로 운영된다. Database Probe는 <화면 5>와 같이 3개의 그룹으로 나뉘어 각 그룹별로 중요한 정보를 보여주게 된다.

<화면 5> Database Probe


먼저 프로세스 부분은 전용 서버 프로세스와 공유 서버 프로세스의 수 및 병렬 처리 내용과 데이터베이스 서버 프로세스가 사용하는 독점 메모리인 PGA 메모리의 사용 현황의 관계를 보여주고 있으며, 메모리(SGA) 부분은 서버 프로세스가 데이터를 처리하는 버퍼 캐시, SQL과 PL/SQL 문장을 저장하기 위한 Shared Pool, 공유 서버의 세션 정보를 저장하는 Large Pool, 데이터 블럭의 변경된 정보(Before/After)를 저장하는 리두 로그 버퍼, 자바 프로그램을 이용하는 영역의 Java Pool의 사용률을 보여주며, 마지막으로 데이터파일 부분은 파일의 크기와 현재까지의 사용률을 그래픽하게 처리하고 있어 데이터베이스의 전반적인 리소스를 얼마나 사용하고 있는지를 시각적으로 판단해 데이터베이스의 초기 파라미터 및 데이터파일의 크기 또는 리두 로그 파일의 크기 및 개수 등을 조정하는 데 필요한 정보를 제공한다.

◆ Database Probe의 주요 기능
① SGA 각 영역의 Hit Ratio 및 사용률 및 Wait/Retry 정보
② 전용 서버 프로세스 및 공유 서버 프로세스의 수 및 PGA 정보
③ 데이터파일의 전체 크기 및 사용률

Top Session Finder
현재 시스템에서 특정 리소스를 많이 사용하는 오라클 세션들을 발췌해 탑 리스트(Top List)로 보여준다. 앞의 Database Probe를 이용해 현재 데이터베이스 측면을 분석했으면, 그 내부에서 작업 중인 세션들에 대한 자세한 정보를 분석해야 할 것이다. 하지만 그 많은 세션들을 일일이 분석하기란 여간 힘든 일이 아니다. 그 중에서 시스템의 리소스를 많이 사용하는 세션이 문제점을 갖고 있기 때문에, 그에 따른 이벤트 정보를 토대로 탑 세션을 발췌한다. 예를 들어 CPU를 많이 사용하는 탑 세션, I/O를 많이 발생시키는 탑 세션처럼 DBA가 원하는 시스템 리소스 측면을 강조한 기능이라고 할 수 있다. <화면 6>에서는 세션들 중에서 ‘session logical reads’, 즉 논리적인 읽기가 큰 세션부터 내림차순으로 정렬된 정보를 Dataset 형태로 제공하고 있다.

<화면 6> Top Session Finder


◆ Top Session Finder의 주요 기능
① CPU, 메모리, 커서(CURSORS) 등과 같은 자원 그룹별로 문제 세션을 검색
② 데이터베이스 세션 정보의 결과를 Dataset 형태나 Pie Chart 형식으로 제공

세션 브라우저
세션 브라우저 기능은 데이터베이스에 접속 중인 모든 세션들에 대해 총괄적으로 세션 액티비티(Session Activity)를 분석하기 위해 제공된 기능이다. <화면 7>은 특정 세션의 Wait Event에 대한 상세 정보를 ‘Current Waits’와 ‘Total Waits’로 분리해 제공하고 있다. 특정 세션을 선택하면 다음과 같은 상세정보를 동적으로 추출할 수 있다.

<화면 7> 세션브라우저


- 세션 : 선택한 세션의 ID, 프로그램, 모듈, Machine, OS 유저, DB 유저 등의 정보를 제공
- 프로세스 : 선택한 세션의 프로세스 정보 제공
- I/O : 선택한 세션이 발생시킨 I/O 정보인 읽기/쓰기 정보 제공
- Waits : 선택한 세션에서 발생한 Wait Event 정보 제공
- Current Statement : 선택한 세션에서 수행 중인 SQL 문장 정보 제공
- Open Cursors : 선택한 세션이 오픈한 커서 정보 제공
- Access : 선택한 세션이 액세스한 객체 정보 제공
- Locks : 세션 잠금 정보 제공
- RBS Usage : 선택한 세션이 사용한 롤백 세그먼트(Rollback Segment) 정보 제공
- Long Ops : 선택한 세션이 배치(Batch)성 작업을 수행했을 경우 현재까지 진행된 상황에 대한 정보 제공
- Statistics : 선택한 세션에 대한 통계 정보 제공

OS 유틸리티
이 기능은 데이터베이스 측면이 아닌 데이터베이스가 동작 중인 시스템(OS) 부분의 정보를 분석하고자 할 경우 사용한다. 유닉스나 윈도우 계열의 OS를 사용할 경우 또는 해당 OS에 해당되는 정보를 분석하고자 할 경우 유용하게 사용할 수 있다. <화면 8>은 CPU의 사용률을 시스템, 사용자를 구분해 사용되고 있는 정보와 프로세스 정보 및 디스크 I/O에 대한 정보를 그래프로 제공하고 있어, 시스템의 전반적인 자원 사용율을 나타내고 있다.

<화면 8> OS 유틸리티 메뉴


<화면 9> 유닉스 모니터


DB상의 문제점을 어떻게 해결할 것인가?

데이터베이스의 문제점을 감지(detect)하고 분석(diagnostic)했으면, 그에 따른 행동을 취해야 한다. 일반적으로 제시하는 해결방안은 시스템 튜닝, 데이터베이스 튜닝, 애플리케이션 튜닝, SQL Statement 튜닝으로 구분할 수 있는 데, 토드에서는 문제점을 해결하기 위한 다양한 기능이 존재한다.

테이블 스페이스와 테이블 스페이스 맵

이는 데이터베이스의 논리적 구조를 이루는 가장 핵심적인 요소이다. 데이터베이스의 데이터가 존재하는 물리적인 데이터파일과 연결되어 있으며, 그 안에 세그먼트, 익스턴트(Extent), 블럭이라는 구조가 존재하고 있다. 만약 테이블 스페이스의 공간이 부족하거나, 데이터파일에 Fragmentation이 발생해 장애가 발생한 경우라면 해당 테이블 스페이스의 공간을 늘려주는 작업과 그 안에 존재하는 Fragmentation을 Coalesce하는 작업을 수행해 다시 재구성하는 문제를 생각해야 할 것이다. 또한 이로 인해 I/O Wait가 발생해 성능이 떨어지는 원인이 된다면 해당 데이터파일도 다시 재구성하거나 재구축하는 절차를 수행해야 한다. 이러한 과정을 손쉽게 수행할 수 있도록 하는 기능이 바로 테이블 스페이스 기능이다.
토드에서 테이블 스페이스와 데이터파일에 대한 정보를 변경할 수 있으며, 프리 스페이스(Free Space)와 해당 테이블 스페이스에 존재하는 객체 정보를 확인할 수 있다.
그리고 뒤에 있는 Space History와 I/O History 탭에서는 특정 테이블 스페이스나 데이터파일에 대한 Capacity Plan 정보를 확인할 수 있다. <화면 10>은 데이터베이스의 각 테이블 스페이스에 대해 할당된 크기와 가장 큰 연속된 공간 및 프리 스페이스를 보여주고 있다. 만약에 특정 세그먼트의 크기가 부족해 확장될 때 ‘MAX Mb’의 값보다 크다면 확장하지 못하고 에러가 발생하게 된다. 따라서 DBA는 이러한 정보로 각 테이블 스페이스에 속한 오브젝트 중 MAX 값보다 큰 테이블이나 인덱스가 존재한다면 해당 테이블 스페이스에 데이터파일을 추가한다거나 다음 익스턴트의 크기를 줄이기 위해 테이블과 인덱스의 NEXT 옵션을 변경해야 할 것이다.

<화면 10> 테이블 스페이스 예


또한 특정 테이블 스페이스의 물리적인 구조 중에서 가장 작은 단위인 블럭들을 그래픽하게 보여줘 해당 테이블 스페이스의 객체가 차지하고 있는 블럭의 갯수나 세그먼트 정보를 자세하게 확인할 수도 있으며, 데이터파일에 존재하는 Fragmentation도 분석해 Coalesce 과정을 수행할 수 있는데, 이 기능은 <화면 11>의 테이블 스페이스 맵을 활용해 수행할 수 있다.

<화면 11> 테이블 스페이스 예


　　　　 컨트롤 파일과 리두 로그 매니저
물리적인 데이터베이스 구조인 컨트롤 파일(Control File)과 리두 로그 파일(Redo Log File)에 대한 정보를 확인할 수 있으며, 로그 스위치(Log Switch), 리두 로그 파일 변경 작업, 아카이브 스타트/스톱(Archive Start/Stop)과 같은 특정 작업을 직접 수행할 수 있다. 컨트롤 파일은 데이터베이스의 물리적인 구조에 대한 정보를 저장하고 있으며 각 타입별로 레코드 세션(Record Section)을 사용하게 된다. <화면 12>에서의 컨트롤 파일의 상세내용을 보면 각 세션(“REDO LOG”, “DATAFILE”…)별로 최대 레코드를 갖고, 또한 사용량을 표시하는데, 만약 각 세션의 토탈 레코드들과 사용된 레코드가 동일하게 되면 더 이상 해당 세션에 대한 자원 할당을 할 수 없게 되므로 컨트롤 파일을 재생성해야 된다. 그리고 이러한 정보를 미리 확인해 대처할 수 있다.

<화면 12> 컨트롤 파일 관리


<화면 13> 칸트롤 파일과 리두 로그 매니저


Log Switch Frequency Map
<화면 14>는 하루를 1시간 그룹으로 구분해 각 시간대별로 로그 스위치의 발생 정도를 나타내어 트랜잭션 양을 파악할 수 있으며, 또한 하루 중에 가장 트랜잭션이 많은 시간대를 파악해 그 시간대에 발생할 수 있는 작업(Batch Job) 등을 다른 시간대로 변경해 수행할 수 있도록 하고 있다. Log Switch Frequency Map 기능은 현재 데이터베이스에서 발생하는 로그 스위치의 회수를 체크해 보여준다.

<화면 14> Log Switch Frequency Map


시간대별로 몇 번의 로그 스위치가 발생했는지 파악할 수 있으며 가장 많은 로그 스위치가 발생한 시간이 언제인지를 확인해 DBA로 하여금 로그 파일의 재구성과 리두 로그 버퍼의 크기에 대한 어드바이스를 받을 수 있도록 정보를 제공하고 있으며, 이를 통해 인스턴스에서 체크포인트의 발생 빈도를 예측할 수 있도록 해준다. DBA는 이 정보를 토대로 SGA 메모리의 최적화 상태를 점검할 수 있다.

Rebuild Objects
테이블 스페이스에 대한 문제를 해결하다 보면 그 안에 존재하는 특정 객체에 대해 다시 재구성해야 하는 경우가 발생한다. 테이블 스페이스 레벨에서만 문제가 해결되면 가장 좋겠지만 실제로는 데이터가 존재하는 테이블이나 인덱스 쪽에 더 무게를 둘 수밖에 없게 된다. 이 기능을 이용해 특정 테이블이나 인덱스 또는 특정 유저, 테이블 스페이스에 해당하는 객체에 대해 일괄적으로 또는 개별적으로 Rebuild 과정을 진행할 수 있다.

　　 Repair Chained Rows
데이터베이스의 block_size가 적거나 특정 테이블의 Row가 데이터베이스 블럭의 크기보다 큰 경우에 UPDATE 문장이 발생하는 테이블에 종종 발생되는 Chaining이나 마이그레이션이 일어나게 되는데, 이렇게 하나의 Row가 여러 블럭에 걸쳐 있으면 데이터베이스의 성능이 떨어지기 마련이다. 이 기능은 데이터베이스의 특정 테이블에서 Chaining이나 마이그레이션이 발생할 경우 해당 테이블을 분석해 Chained Row를 해결하고자 제공하는 기능이다. <화면 15>는 ‘CHAIN_TEST’ 테이블에 Chain된 Row가 약 3만 건 정도가 발생한 것인데, 화면 오른쪽에 ‘Repair’ 버튼을 누르면 Chained Row를 제거할 수 있게 된다.

<화면 15> Repair Chanined Rows


Export/Import Utility Wizard와 SQL*Loader Wizard
Export/Import Utility Wizard와 SQL*Loader Wizard는 오라클의 Export/Import 명령과 SQL*Loader를 Wizard 를 통해 쉽게 구현할 수 있도록 제공하는 기능이다. Export/Import를 이용해 일반적으로 해당 객체를 재구성하는 과정을 거치게 되는데 GUI 환경에서 누구나 손쉽게 사용할 수 있도록 제공하고 있으며, 테이블, 유저, 테이블 스페이스, 데이터베이스 모드를 모두 지원한다. 또한 SQL*Loader의 모든 기능을 지원해 컨트롤 파일을 구성할 경우 이미 지정되어 있는 많은 옵션들을 간단하게 설정할 수 있다.

Server Statistics
이 기능은 현재 인스턴스에 대해 통계 정보를 분석해 보여주며, 인스턴스 내부에 발생하는 다양한 항목들을 DBA가 확인할 수 있다.
Analysis, Waits, Latched, Session, Instance Summary 등의 5가지 탭을 통해 전체 데이터베이스의 통계 정보를 파악한다. 또한 데이터베이스에서 통계치의 값이 어떠한지에 대해 분석해 DBA에게 제시해 준다. 이를 통해 현재 통계정보의 부정확한 값들에 대한 어드바이스를 제시해 DBA로 하여금 최적의 인스턴스 상태를 유지할 수 있는 방향을 제시한다. DBA는 <화면 16>에서 빨간색으로 표시되어 있는 값들에 대해 체크해 인스턴스 환경을 수정할 수 있다.

<화면 16> Server Statistics, 데이터베이스의 대표적인 성능 지수들의 현재 값


이 외에 토드에서 지원되는 문제를 해결할 수 있는 기능을 보면 다음과 같다.

◆ Oracle Parameter and NLS Parameter : Server Statistics 기능에서 제시한 내용을 기준으로 특정 데이터베이스 파라미터를 수정할 경우, 이 기능을 사용해 쉽게 변경할 수 있다.

◆ New Database Wizard : 이 기능은 새로운 데이터베이스를 생성하기 위해 Create Database 명령을 수행하도록 하는 기능이다. DBA가 새로운 데이터베이스를 생성(create)하고자 할 경우 쉽게 GUI 환경에서 생성할 수 있도록 도와주는 위저드 기능이다.

◆ Compare Schema and Compare Database : 서로 다른 데이터베이스끼리 비교를 하거나 특정 스키마들끼리의 비교처럼 DBA가 특정 작업을 수행하기 이전과 이후에 대한 비교 작업을 수행할 경우 적용한다.

데이터베이스 브라우저 기능이란?

지금까지 DBA 기능에 대해 각 기능별로 소개를 했다. 하지만 DBA가 이 모든 기능들을 일일이 하나씩 확인한다면 이것 또한 너무 불편할 것이다.
이를 위해 토드에서는 데이터베이스 관리를 위해 필요한 내용들을 종합적으로 구성해 하나의 화면에서 확인하고 설정할 수 있도록 통합관리 체제로 관리하고 있다. 이 기능이 바로 데이터베이스 브라우저(Database Browser)이다. <화면 17>처럼 데이터베이스 브라우저는 하나의 데이터베이스를 기준으로 정보를 제공하는 것이 아니라 현재 네트워크 상에 존재하는 모든 데이터베이스를 한눈에 확인할 수 있도록 중앙집중 방식을 선택하고 있다. DBA가 A DB, B DB 등을 분산해 관리한다면 업무 효율성도 떨어질 뿐만 아니라 그로 인해 발생하는 시간과 노력에 대한 비용도 한이 없을 것이다. 데이터베이스 브라우저는 다음의 다양한 탭을 갖고 있다.

<화면 17> 데이터베이스 브라우저


◆ 데이터베이스 브라우저의 다양한 탭
- 오버뷰(Overview) : SGA 크기, Shared Pool의 크기, Hit Ratio, Event Wait 정보 확인
- 인스턴스 : 인스턴스 정보 확인
- 데이터베이스 : 데이터베이스 정보 확인
- Options : 해당 데이터베이스에 설정되어 있는 제품의 옵션 리스트 확인
- 파라미터 : 데이터베이스 파라미터 정보 확인
- 세션 : 현재 데이터베이스에 연결되어 있는 세션 정보 확인
- 탑 세션 : 현재 연결되어 있는 세션 중에서 탑 세션 리스트 확인
- RBS 액티비티 : 롤백 세그먼트의 액티비티 정보 확인
- Space Usage : 각 테이블 스페이스의 스토리지 파라미터 정보와 스페이스 정보 확인
- 데이터파일 I/O : 각 데이터파일의 토탈 사이즈, 프리 사이즈(Free Size)와 내부 블럭마다의 읽기/쓰기 회수 등에 대한 정보 확인

SQL 튜닝 엑스퍼트

SQL 튜닝 엑스퍼트는 토드의 DBA 모듈에 포함되어 있는 기능은 아니며, 토드의 엑스퍼트 튜닝 모듈(Xpert Tuning Module)에 있는 기능이다.
DBA가 시스템 퍼포먼스 튜닝만 수행하는 것이 아니라 그 안에서 동작하는 애플리케이션 튜닝에 더욱 많은 시간을 소비할 것이기 때문에 토드를 이용해 이 부분을 해결할 수 있는 방법을 제시하고자 한다. 데이터베이스를 운영하다 많이 접하게 되는 문제는 바로 잘못 작성된 SQL 문장이 될 것이다. 토드의 엑스퍼트 에디션은 현재 데이터베이스에서 잘못 작성되어 성능이 다운되는 요인이 되고 있는 SQL 문장을 찾아 가장 최적의 SQL 문장으로 바꿔주는 기능을 갖고 있다.
SQL 튜닝 엑스퍼트 기능은 SQL 에디터나 프로시저 에디터(Procedure Editor)에서 SQL 문장이나 PL/SQL 문장을 대상으로 개발시에 최적의 SQL과 PL/SQL을 만들고 싶을 경우이거나, 실행했으나 반응 시간(Response Time)이 너무 높게 나타나서 현재 환경에 맞는 최적의 문장을 만들고 싶을 경우 사용한다. 일단 SQL 에디터와 프로시저 에디터 아이콘 버튼을 실행하면 SQL 튜닝 엑스퍼트라는 화면으로 이동할 수 있다. SQL 튜닝 엑스퍼트 화면의 왼쪽에는 네비게이터 패널(Navigator Panel)이라는 것이 있는데, 이 네비게이터 패널의 순서에 따라 SQL 튜닝 과정을 진행하면 된다. 다음은 SQL 튜닝 엑스퍼트에서 SQL 튜닝 과정을 진행하는 절차이다.

1단계, SQL Detail

여기서는 SQL 에디터나 프로시저 에디터에서 수행 중인 SQL 문장을 드래그해 Execution Plan과 해당 SQL 문장에 나타난 객체의 정보를 확인할 수 있다. Execution Plan을 통해 현재 SQL 문장이 어떻게 수행될 것이지 예측할 수 있으며, 해당 테이블에 생성되어 있는 인덱스나 컬럼의 정보를 확인할 수 있다.

<화면 18> SQL Detail Window


2단계, View Advice

이 부분은 현재의 SQL 문장에 대해 Execution Plan의 정보만 갖고 튜닝 액션을 결정할 수가 없을 경우 개발자나 DBA에게 현재 환경에 적합한 가장 최적의 SQL 솔루션을 제공한다.

<화면 19> View Advice Window


- Auto Tune : 이는 오라클 옵티마이저가 판단한 근거를 기준으로 자동으로 현재 SQL 문장에 맞는 최적의 솔루션 리스트를 제공한다. 이는 튜닝 초보자에게 적합한 것으로 SQL 튜닝에 대한 지식이 없더라도 튜닝 솔루션을 찾을 수 있게 한다.

- Advice : 이는 현재 환경에 적합한 Advice List를 보여줌으로써 어느 정도 숙련된 튜너가 자기가 생각한 튜닝 솔루션과 일치하는 사항을 찾아 수행할 수 있도록 정보를 제공한다.

- Manual Tune : 토드의 SQL 튜닝 엑스퍼트에게 의존하지 않고 직접 SQL 문장을 코딩하는 경우 사용한다.

3단계, Compare Scenario

Advice에서 선택한 사항을 토대로 Original SQL 문장과 Advice SQL 문장의 Explain Plan과 SQL 문장을 기준으로 비교할 수 있도록 정보를 제공한다.

<화면 20> Compare Scenario Window


4단계, Execution Scenario

Compare Scenario 스텝까지는 직접 SQL 문장을 실행하지 않은 상태에서 간접적으로 비교를 수행한 것에 반해 이 부분은 직접 Original SQL 문장과 Advice SQL 문장을 실행해 비교할 수 있는 정보를 제공한다. 만약 Trace 정보를 만들고 싶다면 옵션으로 지정할 수도 있다.
실행 과정이 끝나면 Original SQL과 Advice SQL에 대해 그래픽하게 비교할 수 있는 그림이 나타나며 이를 통해 시각적으로 최적의 솔루션을 찾을 수 있다.

<화면 21> Advice 적용 후 성능 향상 기대치 비교


- Index Advice : 만약 View Advice 단계에서 선택한 Advice가 인덱스를 추가·삭제·변경하는 작업이었다면 이번 단계에서는 인덱스에 대한 DDL 명령을 수행해야 한다. 하지만 이를 적용했을 경우 다른 SQL 문장이 영향을 받을 수 있기 때문에 조심스럽게 접근해야 할 것이다. 따라서 실제로는 실행시에 인덱스에 대한 DDL 명령을 수행하지 않고 버추얼하게 수행해 현재 데이터베이스에 영향을 주지 않는 선에서 비교할 수 있도록 정보를 제공한다.

- Rewrite : View Advice 단계에서 선택한 Advice가 문장을 바꾸는 선에서 제공되고 있다면, 현재 Original SQL문장을 대신할 수 있는 대체 SQL 문장을 선택한 경우이다. 이를 통해 현재 과정을 진행하면 Original SQL과 Advice SQL을 전부 실제로 실행하는 과정을 거치게 된다.

- Other Advice : DDL Advice나 SQL Rewrite가 아닌 다른 내용들을 제시한 것을 선택한 경우가 해당된다.

5단계, Execution Results

실행한 내용을 토대로 그 결과를 보여주며 실행시에 생성된 통계 정보를 비교할 수 있다. 토탈 CPU, Elapsed Time, Logical Read, Physical Read 등의 많은 통계 정보를 서로 비교할 수 있다.

6단계, Best Practice

앞의 Advice에서 선택한 사항을 토대로 실제 실행과정을 거친다. 예를 들어, 인덱스 생성 Advice를 선택했다면 4번 단계에서는 가상적으로 생성해 비교를 수행했는데, 이를 비교 검토 후 적용하는 과정이라고 생각하면 된다. 또한 추가적으로 수행할 때 더 적합한 내용들이 있다면, 예를 들어 분석 작업 같은 내용이 여기에 포함될 수 있는데 최적의 상태가 될 수 있는 리스트를 제시하면 튜너는 여기에서 원하는 내용을 선택할 수 있다.

7단계, Tuning Resolution

지금까지 진행해온 모든 사항을 기본으로 해 Original SQL과 Advice SQL에 대해 어느 정도 성능 효과를 보였는지를 확인할 수 있다.

토드의 다양한 기능을 습득하기 바라며

지금까지 토드에서 제공하는 DBA 모듈에 대한 일부 기능을 소개했다. 토드라는 툴은 너무나 많은 기능들을 갖고 있기 때문에 사용자의 입장에서 어떤 기능들이 토드에 있는지조차 모르는 경우가 다반사라고 생각한다. 이렇게 토드에는 숨겨진 많은 기능들이 독자의 업무에 도움이 될 수 있으면 하는 바람이다.

제공 : DB포탈사이트 DBguide.net

출처명 : 마이크로소프트웨어[2004년10월호

[출처] toad 숨은 기능 ~ |작성자 에러


반응형

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

오라클 SYSDATE 로 반환하는 날짜 값을 변경하기  (0) 2009.11.18
TOAD for Oracle Freeware 9.7  (3) 2009.11.09
OCP 강좌 - Backup and Recovery (1)  (0) 2009.11.05
Oracle Database 10g: DBA를 위한 20가지 주요 기능 (impdp, expdp)  (0) 2009.10.29
OEM 재구축  (0) 2009.10.26
반응형

1. 나비켓 (Navicat mysql)  

   (속도도 빠르고 좋다고 함) ->   유료

    http://www.sendspace.com/file/6h3q6v

    http://filebeam.com/8b6e269bc3325283fbe2a13d3601d75e

 

2. SQLyog(프리웨어)

    http://www.webyog.com/en/

 

3. Mysql-Front (프리웨어) -> 강추

    http://www.sql-front.com/

 

4. PHPMYADMIN (프리웨어) -> 강추

    http://www.phpmyadmin.net/

 

5. YourSQL

    http://www.mludi.net/YourSQL/

 

6. EMS(프리웨어) -> 강추

    http://www.snapfiles.com/get/emsmysqllite.html

 

7. Toad for mysql(프리웨어) -> 강추

   http://www.toadsoft.com/toadmysql/FreewareDownload.htm

난 oracle 을 사용할 때 DBA가 지원되는 최상위 버젼 토드를 써서 그런지...

왠지 Toad for mysql 조차도 너무 좋음....

단 DBA 관점이라는거....

반응형

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

MariaDB SHA2 512 방식으로 암호화 예제  (0) 2019.10.25
Mysql & MariaDB 튜닝 쉘  (0) 2019.08.14
MySQL 백업용 쉘스크립트입니다.  (0) 2010.01.18
C를 이용한 성적관리 예제  (0) 2009.03.06
mysql(latin1 -> euckr 변경)  (0) 2009.03.06

+ Recent posts

티스토리툴바