자수성가한 부자

DB암호화 이전에 암호화에 대한 성능 영향을 측정하는 것인 정말 쉬운일이 아니다.

가장 많이 사용하는 플러그인 방식에 촛점을 맞추어 생각해 보자.

플러그인 방식은 잘 알려진 바와 같이 DB서버에 암/복호화 라이브러리를 설치하고, 뷰와 내부 저장 함수를 사용하여 라이브러리를 연결한다. 또한 Instead of 트리거를 사용하여, Insert, Update SQL을 뷰 대신 원래의 테이블에 대해 수행하도록 변환한다.

이런 일련의 과정은 DB에 매우 심대한 영향을 주고, 특히 성능에 많은 영향을 미친다. 초기 많은 DB암호화 실패 사례가 나왔던 것도 결국 이런 영향이 얼마나 큰지 알지 못하고 무턱대고 암호화를 하다가 빚은 참사가 아닐는지.

DB암호화를 고려할 때, 가장 먼저 드는 생각이 “암호화 후에 성능이 얼마나 감소할 것인가?” 하는 의문이다.

필자도 이런 문제로 한참 고민을 한 적이 있었는데, 어떤 계기로 모 공공기관의 DB암호화 영향도 분석이라는 과제를 수행할 기회가 있었다.

주로 성능 관점에서 DB암호화 시의 영향도를 예측하는 작업이었는데, 현재 수행되는 SQL에 대한 정보를 DBMS에서 수집한 후에, SQL을 파싱(Parsing)하여 암호화 시에 영향받는 SQL을 분리하면 그에 대한 예측이 가능하지 않을까 하는 막연한 생각으로 출발하였다.

오라클 DBMS의 경우에는 V$SQL 등의 테이블에 해당 인스턴스에서 수행한 SQL에 대한 통계 정보를 저장하고 있는데, SQL 수행횟수, SQL로 처리한 로우 수, CPU Time 총합, Elapsed Time 총합 등이 그에 해당한다.

우선 이런 정보를 일정한 주기로 수집하였다. 해당 정보는 오라클의 메모리가 부족해지지 않는 한 메모리 내에 유지되므로 하루의 몇 회 정도만 수집을 해도 거의 빠짐없이 V$ 테이블의 정보를 수집할 수 있다. 특정 시점에서만 수행되는 SQL이 있을 수 있어서, 1 개월 정도 계속하여 SQL을 수집하였다.

이렇게 수집한 SQL을 파싱하여, SQL이 사용하는 테이블, 컬럼 정보를 추출하였고, 이를 기준으로 해당 SQL이 암호화 대상 테이블/컬럼을 사용하는지 여부를 판정할 수 있었다. 이렇게 분류를 해 보면, 어떤 테이블에 관련된 SQL이 몇 종이나 되며, 해당 테이블을 사용하는 SQL이 전체 CPU 사용량의 몇 %에 해당하는 지 등의 다양한 정보를 얻어낼 수 있다.

또한 암호화 대상 테이블이 실제로 사용되는 테이블인지, 아니면 한때 필요에 의해서 만들었으나 지금은 아무도 사용하고 있지 않은 테이블인지(물론 연말에 한번 사용하거나, 국정감사를 대비해서 만들어 놓은 테이블일 수도 있다) 등을 분류하여, 임시 성격의 테이블은 제거하는 등의 판단을 내리는 데도 활용할 수 있다.

이런 정보가 생성이 되면 각 테이블별로, 이런 추측이 가능하다.

“만약 A라는 테이블의 B라는 칼럼이 암호화 대상인 경우에, 해당 칼럼을 사용하는 SQL은 암호화 후에 일정한 비율로 영향을 받을 것이다”

여기서 우리가 알아내야 하는 것은 비율을 결정하는 요소인데, 플러그인 방식에서는 해당 SQL에서 암/복호화 함수가 얼마나 불려지는가가 핵심이다. 즉 어떤 SQL이 100개의 주민번호를 읽어오는 것이라면 100번의 복호화 함수가 호출되므로, 암호화 이전과 차이는 100번의 복호화 함수 수행시간이 된다. 물론 이런 비교는, 암호화 전후에 실행계획상의 변화가 없다는 전제를 기초로 한다.

쉬워 보이는 이 논리에 어려운 점이 숨어 있는데, 각 SQL별로 암호화 대상 칼럼을 얼마나 가져오는지 알 수 있어야 한다는 것이다. 이 부분은 현재도 해결하지 못한 과제인데, 해당 프로젝트를 수행하는 시점에서는 시간 관계상 모델을 매우 단순화하여 영향도를 측정하였다.

여러 번의 DB암호화 프로젝트를 거쳐 암호화 영향도 분석의 효용성을 인식하게 되었는데,

 1)   암호화를 할 때 주의해야 할 테이블(핵심 테이블) 선정

 2)   많이 사용되고 CPU 점유율이 높은 SQL(핵심 SQL) 식별

 3)   추출된 SQL 중 암호화 대상 SQL만 분류하여, 효율적인 기능 및 성능 시험 수행

하는데 활용하고 있다. 더불어 정확한 값은 아닐지라도 암호화 후에 CPU 관점에서 얼마나 영향을 받는지를 계산하여, 플러그인 방식의 암호화를 적용하는 것이 가능한지 여부에 대한 판단을 내리는데 기초자료로 사용한다.

DB암호화를 고려한다면, 이런 방식의 영향도 분석을 꼭 해볼 것을 권하고 싶다.

출처 : http://www.dbguide.net/knowledge.db?cmd=specialist_view&boardUid=170383&boardConfigUid=93&boardStep=&categoryUid=

좀비 프로세스란 넘이 간간히 발생해 시스템의 자원을 낭비하고 있는 경우가 있다.
이런 애들은 과감하게 죽여줘야 한다...
요것과 관련해서 좋은 글들이 있어 요기에 정리(?)해본다. 뭐 그냥 배껴쓰는건 좀 그래서.. -_-;

1. 좀비 프로세스를 찾아서 그 결과를 변수로 받아서 kill -9 로 죽이기

2. kill -9로도 뒈지지 않는 프로세스 죽이기

참조(?) URL [내용을 훔쳤다는게 맞는 표현인 것 같다]

현상 :

vi 에디터로 파일을 열었을 때 다음과 같은 메시지가 나올 때

$ vi test.log
cputty: Unknown terminal type
I don't know what kind of terminal you are on - all I have is 'cputty'.
[Using open mode]

해결책 :

.profile 또는 .bash_profile에 다음과 같은 환경변수 추가후 적용

$ vi .profile

TERM=xterm; export TERM

$ . .profile

출처 : http://robertmarkbramprogrammer.blogspot.kr/2012/03/i-dont-know-what-kind-of-terminal-you.html

프리젠테이션시에 참고하면 좋은 글

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

1. 많이 만들어라!

어찌보면 당연한 얘기기도 하다. 당신이 많이 만들어야 한다. 뭘? 기획서를!

자신이 쓰지 않은 내용에 대해서 설명하는 것이 가장 어렵다. 프리젠테이션이라는 게 아무리 화면에 없는 내용도 말할 수 있다지만, 너무 화면이랑 따로 놀면 안되기 때문이다.

실제로 스크립트를 써보면 본인이 만든 부분보다 다른 팀원이 만든 부분에 대해 쓰는 게 더 많은 시간과 노력을 요한다는 것을 알 수 있을 것이다.

즉, 프리젠터는 되도록 가장 많이 만든 사람이 할 것.또는 가장 핵심 아이디어를 낸 사람이 할 것.

결국 요지는 프리젠터를 안하겠다고 뒤로 뺄 때는 제일 많이 만든 사람을 시키면 된다는 거다.

그런데 그 사람이 영 프리젠테이션에 잼병이라면?

훈련시키면 된다.

2. 스크립트를 써라!

자 이제 훈련을 시켜보자.(본인이든 다른 팀원이든.)

우선 스크립트는 프리젠터 개인이 쓰는 것이 좋다. 물론 프리젠터가 만든 부분이 아닐 경우에는 만든 이에게 그 장에 대한 조언과 설명을 구하는 것은 필수다.

그리고 쓸 때는 반드시 자신의 말투로 써라. 그냥 요약하듯이 '00함.'이렇게 쓰는 것이 아니라, '00합니다. 하지만 000할 수도 있다는 부분을 주목해야 하는 것입니다.'이런 식으로 아예 그대로 줄줄 읽기만 해도 발표가 될 수 있게 완성된 문장으로 써야한다.

그리고 다 썼다면, 이제 팀원들을 모아서 읽어본다.

분명 무수한 지적이 쏟아지고, 말은 버벅거릴 것이며, 문장은 어설플 것이다.

이는 당연한 결과다, 그냥 고치면 된다. 팀원들의 조언을 얻고 본인이 직접 읽어서 어색한 부분을 다시 고치고, 또 고치면서 스크립트를 완성시키면 된다.(이 과정이 가장 중요하다!)

3. 시간을 맞춰라!

자 이제 스크립트가 완성이라면, 시간을 재보자.

보통 넉넉한 공모전은 20분 정도, 까칠한 공모전은 15분 정도를 준다.

각각의 상황에 맞게 시간을 맞춘다. 이때 가장 좋은 시간은 -40초 정도다.

14분 20초나, 19분 20초. 개인적으로 발표들을 들어보면 이 정도가 아주 무난하고 성의있어 보인다.

아마 이 시간을 맞추려 하다보면 말 속도부터 모든 게 신경쓰이기 시작할 것이다.

대부분 너무 자세히 설명하려하다 보면 다 초과하기 마련이다.

과감하게 삭제해라. 분명히 명심해야 할 것은 본인이 아는 대부분의 것은 심사위원으로 앉아있는 실무자가 거의 다 알고 있다는 것이다.(물론 심사위원 중 교수님들은 모르기도 하지만.)

왠만한 것들은 다 그냥 넘어가라. 신개념 단어나, 본인들이 만든 정의 정도는 설명하되, 그게 아닌 이미 있는 약어나 개념은 굳이 설명할 필요가 없다.

그리고 될 때까지 스크립트를 바꿔가며 읽고 또 읽어라. 그리고 그 스크립트를 읽는 시간이 -1분 정도로 맞춰진다면 성공이다.

이런, 글이 밑도 끝도 업이 길어졌다! 어찌보면 너무나 평이한 내용의 3탄이기도 하지만, 가장 중요하고 기본이 되며 실제로 필자도 주로 쓰는 방법이기 때문에 길게 쓸 수 밖에 없었다. 다시 한 번 말하고 싶은 것은 프리젠테이션에 왕도는 없다.

스크립트를 써서 외우면 딱딱한 발표가 된다고 말하는 이들도 꽤 되니 말이다.

하지만 본인의 말투로 된 스크립트로 수많은 연습을 거듭해서 외우면 오히려 아주 자연스러운 발표가 될 뿐 아니라 애드립도 중간에 넣을 수 있는 여유까지 생긴다는 것을 말하고 싶다.

물론 본인에게 적절하다고 평가되는 스타일로 연습하면 그 뿐이다.

언제나 그랬듯이 지식의 공유는 정답은 아니다. 단지 필자가 아는 것의 전달일 뿐.

출처 : http://kin.naver.com/open100/detail.nhn?d1id=4&dirId=40401&docId=687886&qb=7LWc6rOgIO2UhOumrOygoO2FjOydtOyFmA==&enc=utf8&section=kin&rank=1&search_sort=0&spq=0&pid=ReUJP35Y7vRssabzFphsssssssG-084195&sid=URX7e3JvLDUAAFGzkJk

		< Previous  | TOC | Index | Next  >

Oracle log files

 To check the Oracle log file

• For Oracle 10g Release 1, access:

  $CRS_HOME/crs/log

• For Oracle 10g Release 2, access:

  $CRS_HOME/log/hostname/crsd

  where hostname is the string returned by the hostname command.

The log file in this directory contains the logs pertaining to the CRS resources such as the virtual IP, Listener, and database instances. The file indicates some configuration errors or Oracle problems, since CRS does not directly interact with any of the Veritas components.

 To check for crs core dumps

Access:

$CRS_HOME/crs/init

Core dumps for the crsd.bin daemon are written here. Use this file for further debugging.

 To check the Oracle css log file

• For Oracle 10g Release 1, access:

  $CRS_HOME/css/log

• For Oracle 10g Release 2, access:

  $CRS_HOME/log/hostname/cssd

  where hostname is the string returned by the hostname command.

The log files in this directory indicate actions such as reconfigurations, missed checkins, connects, and disconnects from the client CSS listener. If there are membership issues, they will show up here. If there are communication issues over the private networks, they are logged here. The ocssd process interacts with vcsmm for cluster membership.

 To check for ocssd core dumps

Access:

$CRS_HOME/css/init

Core dumps from the ocssd and the pid for the css daemon whose death is treated as fatal are located here. If there are abnormal restarts for css the core files are found here.

출처 : https://sort.symantec.com/public/documents/sf/5.0/solaris/html/sf_rac_install/sfrac_troubleshoot7.html

 - ADG
   Disaster : 천재지변, 장애상황
   일반적 오라클의 기능
  
   아키텍쳐
    : Active DB의 리두 로그를 Standby DB로 적용
      Standby는 read only모드로 사용 가능
      redo log의 전송 방식
       - sync : 데이터 무손실(maximum protection)
                standby DB에 redolog가 기록된 것을 확인 받음.
                MSP : block 단위로 적용하는 프로세스
                LSP : SQL의 재수행을 하여 적용하는 프로세스
       - async : maximum performance
                 네트워크 장애와 같은 문제 발생시 standby 뿐 아니라
                 active DB에도 안좋은 영향을 미칠 수 있음.
      네트워크 대역폭 제한으로 인한 문제 발생시
       => compression으로 전송데이터량 줄임. 

 - OGG
   이 기종 간에 사용 가능
   Zero downtime migration
   Capture process : transaction log capture
   trail file
   pump process : standby 로 전송
  
   trail file
   replicat : 반영

   양방향으로 data sync가 맞춰질 수 있다.
   업무 부하의 분산 가능
   간단한 ETL 작업을 위한 function 제공

   DATA filtering 가능(특정 테이블 제외, 유저의 변경, 특정테이블만 적용 등)
   ADG와는 다르게 일부데이터만 sync 가능.
  
   암호화 (blowfish)
  
   veridata : 데이터 정합성 체크 옵션. 변경된 내용만 확인 가능하고 변경된 부분을 수정은 불가

   OGG 구매시 ADG 사용 가능

SQL*Loader의 성능을 향상시키는 여러가지 방법들

1. Data를 load하는 방식에 따라 성능을 증가시키는 방법이 다름
  1) 기본경로(conventional)

     ROWS=n를 사용하고 bind array를 크게 지정하라.
     (ROWS=n은 n개마다 commit을 하라고 명시하는 것.
      bind array는 bindsize 파라미터에 정의)

  2) 직접경로(direct path) : direct=true 옵션을 지정
      unrecoverable 옵션을 지정하면 더욱더 성능을 높여줌 : redo data를 남기지 않음

  3) 병렬직접경로(parallel direct path)
     direct=true와 parallel=true를 지정할 것.

2. data load 전에 index 삭제

3. replace 대신에 truncate사용할 것(if 기존 데이터를 삭제한다면)

4. 구분자(, | .)대신에 고정폭 데이터를 사용하라.

5. 11g 파라미터 변경
   STATISTICS_LEVEL = BASIC 이면 timed_statistics=false;
   STATISTICS_LEVEL = TYPICAL, ALL 이면 timed_statistics=true;

참고 :

http://databaser.net/moniwiki/wiki.php/SQLLoader%EC%82%AC%EC%9A%A9%EB%B0%A9%EB%B2%95

http://satya-dba.blogspot.kr/2009/06/sqlloader.html : 파라미터 정의(히든 포함)

●현재 디렉토리의 확장자가 trc인 수정된지 30일지난 파일은 강제로 삭제하시오.

find . -name "*.trc" -mtime +30 -exec rm -f {} \;

●현재 디렉토리의 확장자가 trm인 수정된지 30일지난 파일은 강제로 삭제하시오.

find . -name "*.trm" -mtime +30 -exec rm -f {} \;

각 항목 설명

find : 파일 찾는 명령어

. : 현재 폴더

-name : 찾고자 하는 파일이 이름이란 것을 지정

"*.trc" : 찾고자 하는 파일의 이름

-mtime : 최종 수정된 시간

+30 : 30일이 지난

-exec : 실행하여라

rm : 삭제를

-f : 묻지말고

{} : 모두를

참고 : http://blog.naver.com/PostView.nhn?blogId=dasol&logNo=70012728433

아래의 사이트 참고할 것

ipcs중 ipc는

inter processing communication 의 약자

무슨 역할을 하는 것인가?

한 프로세스가 다른 프로세스에 공유하기 위해 만들어 놓은 메모리 영역이 어떻게 구성되어 있는지 보여주는 툴이다.

ipcs실행시 보이는 값들은?

key : 공유 메모리를 구분하기 위해 사용되는 ID

nattach : 해당영역에 붙어있는 프로세스들의 갯수

shmid : shared memory id

owner : 소유자

perms : 이 공유메모리에 설정된 권한

bytes : 점유하고 있는 크기

status :

참고 : http://exem.tistory.com/81

Sequential Access Method file
어떤 연관된 내용들끼리 모아서 저장해 놓은 방식이 아니라,
데이터가 생성되는 순서대로 이어붙여 저장하는 방식

참고사이트 :
http://fendee.egloos.com/2234349