긍적적인 사고, 음식의 절제, 규칙적인 운동

사실 우리가 만나는 사람들 중에는 언젠가 다시 만날 사람도 있겠지만

다시는 만나지 못할 사람도 있을 겁니다.

한치앞도 알 수 없는 게 우리네 인생이라서 다시 만 날 보장이란 없는것이지요,

그럼에도 불구하고 우린 너무 경솔하게 사람들을 대하는건 아닌지요?


옷깃이라도 스치고 눈이라도 마주치며 지나는 사람들에게 좀더 좋은

인상을 주면서 좀더 짙은 애정을 느끼며 살아가야 함에도 우린 대부분

그렇게 하지 못하고 있는 것 같습니다...


사실 내가 어떤 사람과 만난다는 것은 거의 기적에 가까운 일입니다.

이 세상의 수많은 사람들 중에서 어떻게 유독 그 사람과 마주치게 된단 말입니까.

그 숱한 사람들과 그 숱한 세월 속에서 나와 만났다는 것은 설사

그것이 아무리 짧은 만남이었다 치더라도 참으로 그것은 우리에게

대단한 인연이 아닐 수 없습니다.

따라서 우린 어느 만남이라도 소홀히 할 수는 없는 일입니다.

아름다운 기억으로 꼭 다시 만나고 싶은 '잊을 수 없는 사람' 으로서

남의 가슴에 꼭꼭 간직되는 사람, 그런 사람이 되기위해 우린 모두

아낌없는 노력을 해야될 겁니다.


이정하님의< 만남에 대하여 >

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

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

Posted by 홍반장

삶이든 연애든 끝까지 가 본 사람은 안다

한번쯤은 연습이 필요하다는 것을

때로는 실패한 것들이 눈물나게 아름답다는 것을

혼자서 지내는 시간이 많다는 것을

더 이상 무서울 것도 두려울 것도 없다는 것을

그 누구도 날 찾지 않는데

세상은 쥐도 새도 모르게 잘도 돌아간다는 것을

막가는 인생에는 신호등이 없다는 것을

가끔 죽음에 대하여 생각한다는 것을

무엇이든 무너질 때에는

여지없이 무너져야 한다는 것을

눈을 오래 감을수록 별이 많이 떨어진다는 것을

어느 순간에도 살아남은 자가 결국 이긴다는 것을

삶이든 연애든 끝까지 가 본 사람은 안다.

이게 끝이 아니란 것을

詩. 박미숙

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

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

Posted by 홍반장

법정스님의 글

처음 만난 사람과 인사를 나눌 경우,

서투르고 서먹한 분위기와는 달리 속으로 고마움을 느낄 때가 있다.

이 지구상에는 36억인가 하는 많은 사람이 살고 있다는데,

지금 그 중의 한 사람을 만난 것이다.

그러니까 36억대 1이라는 아슬아슬한 비율로 그를 만난 것이다.

우선 만났다는 그 인연에 감사하지 않을 수 없다.

같은 하늘 밑, 똑같은 언어와 풍속안에 살면서도

서로가 스쳐 지나가고 마는 인간의 생태이기 때문이다.

설사 나를 해롭게 할 사람이라 할지라도

그와 나는 그만큼의 인연이 있어 만난 것이 아니겠는가.

그 많은 사람 가운데서 왜 하필이면 나와 마주친 것일까

불교적인 표현을 빈다면 시절 인연(時節因緣)이 다가선 것이다.

이러한 관계는 물건과 사람의 경우도 마찬가지일 것 같다.

많은 것중에 하나가 내게 온 것이다.

지금 이 글을 쓰고 있는 탁상에는

내 생활을 거동케하는 국적 불명의 시계가 하나 있다.

그놈을 보고 있으면 물건과 사람 사이의

인연도 정말 기구하구나 싶어진다.

그래서 그놈이 단순한 물건으로 보이지 않는다.

지난해 가을, 새벽 예불(禮佛) 시간에 일어난 일이었다.

큰 법당 예불을 마치고 판전(板殿)을 거쳐 내려오면

한시간 가까이 걸린다. 돌아와 보니 방문이 열려 있었다.

도선생(盜先生)이 다녀간 것이다.

평소에 잠그지 않는 버릇이라 그는 무사 통과였다.

살펴보니 평소에 필요한 것들만 골라 갔다.

내게 소용된 것이 그에게도 필요했던 모양이다.

그래도 가져간 것보다 남긴 것이 많았다.

내게 잃어버릴 물건이 있었다는 것이,

남들이 보고 탐심을 낼 만한 물건을 가지고 있었다는

사실이 적잖이 부끄러웠다.

물건이란 본래부터 내가 가졌던 것이 아니고

어떤 인연으로 해서 내게 왔다가

그 인연이 다하면 떠나가게 마련이라 생각하니

조금도 아까울 것이 없었다

어쩌면 내가 전생에 남의 것을 훔친 과보(果報)인지 모른다

생각하면, 오히려 빚이라도 갚고 난 홀가분한 기분이었다.

그런데 그는 대단한 것이라도 있는가 싶어 있는 것

없는 것을 샅샅이 뒤져 놓았다.

잃은 것에 대해서는 조금도 애석하지 않았는데

흐트러 놓고 간 옷가지를 하나하나 제자리에

챙기자니 새삼스레 인간사(人間事)가 서글퍼지려고 했다.

당장에 아쉬운 것은 다른 것보다도 탁상에 있어야 할 시계였다

도선생이 다녀간 며칠 후 시계를 사러 나갔다.

이번에는 아무도 욕심내지 않을 허름한 것으로 구해야겠다고

작정, 청계천에 있는 어떤 시계 가게로 들어갔다.

그런데, 그런데, 허허 이거 어찌 된 일인가.

며칠 전에 잃어버린 우리 방 시계가 거기서

나를 기다리고 있는 게 아닌가.

그것도 웬 사내와 주인이 목하(目下) 흥정 중이었던 것이다.

나를 보자 사내는 슬쩍 외면해 버렸다.

당황한 빛을 감추지 못했다.

그에게 못지않게 나도 당황했다.

결국 그 사내에게 돈 천원을 주고 내 시계를 내가 사고 말았다.

내가 무슨 자선가라고 그를 용서하고 말고 할 것인가.

따지고 보면 어슷비슷한 허물을 지니고 살아가는 인간의 처지인데

뜻밖에 다시 만난 시계와의 인연이 우선 고마왔고,

내 마음을 내가 돌이켰을 뿐이다.

용서란 타인에게 베푸는 자비심이라기보다,

흐트러지려는 나를 내 자신이 거두어 들이는 일이 아닐까 싶다

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

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

Posted by 홍반장

Hash Function을 이용해서 메모리와 CPU를 많이 사용해서 일반적으로 배치작업에서 주로 사용됨


-. /*+ use_hash(테이블) */
-. 적은테이블과 큰테이블의 조인시에 유리
-. Equal 조인에서만 가능
-. Driving Table에 인덱스를 필요로 하지 않고 각 테이블을 한번만 읽음
-. 다른조인방법보다 CPU자원을 많이 소비하며 양쪽 테이블의 scan이 동시에 일어남


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

해시 조인(Hash-Join)은 두 테이블 중 하나를 기준으로 비트맵 해시 테이블을 메모리에 올린 후 나머지 테이블을 스캔 하면서 해싱 테이블을 적용하여 메모리에 로딩된 테이블과 비교하여 매칭되는 데이터를 추출하는 방식 입니다.

성능을 위해서는 당연히 사이즈가 작은 테이블이 메모리에 올라가는 것이 좋으며 이때 이 테이블을 드라이빙 테이블(driving/outer table) 이라고 합니다. 특히 이 해시 테이블이 메모리에 생성되면 성능은 좋으며(메모리에 생성되지 않으면 내부적으로 임시 테이블이 만들어 져야 합니다.) 두 테이블의 크기 차이가 클수록 성능은 좋아집니다.

또한 해시 조인은 안티 조인과 병렬처리와 잘 맞으며 범위 검색(Range scan)이 아닌 동등 비교(Equi-Join, where절에서 등호로 비교하는 경우)에 더 적합 합니다.


.

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

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

Posted by 홍반장

SORT MERGE JOIN

일반적으로 배치작업에서 주로 사용되며, 각 테이블을 Sort한 후 Merge 하는 조인을 말한다

-. /*+ use_merge(테이블) */
-. 동시에 각각의 테이블이 자신의 처리범위를 액세스하여 정렬해둠
-. 각 테이블은 어떠한 상수값도 서로 영향을 주지 않으며, 주어진 상수값에 의해서만 각자 범위를 줄이게됨
-. 전체범위처리를하며 부분범위처리를 할수 없음
-. 자신의 처리범위를 줄이기 위해 인덱스를 사용하는 경우에만 Random Access이고, Merge작업은 Scan방식
-. 선택적으로 연결고리가 되는 컬럼은 인덱스를 사용하지 않음
-. 조인의 방향과는 상관없음
-. Equal 조인에서만 가능

-. 처리량이 많은 경우로 Random Access를 하지 않음으로 전체범위처리에 유리
-. 자신의 처리범위를 인덱스를 통해 어떻게 줄이느냐가 관건
-. 상수값을 받아 줄여진 범위가 30%이상이면 Sort Merge가 유리

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

드라이빙(Driving) 순서규칙

■ Sort-Merge 의 경우

- 두 개 컬럼 모두 같은 조건( 인덱스가 둘 다 없거나, 둘 다 있는 경우)인 경우에는 FROM절의
가장 오른쪽에 정의된 테이블이 구동테이블이 됨.

SQL>select a.empno , a.ename , a.sal, b.deptno, b.dname, b.loc
from big_emp a , big_dept b
where a.deptno = b.deptno
and b.deptno between 10 and 40
and b.loc = 'DALLAS' ;

Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: CHOOSE
14728 MERGE JOIN
4 SORT (JOIN)
3 TABLE ACCESS (FULL) OF 'BIG_DEPT' <= Driving Table
14728 SORT (JOIN)
28955 TABLE ACCESS (FULL) OF 'BIG_EMP' <= Inner Table


.

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

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

Posted by 홍반장

조인 방법 변경(USE_NL)


테이블을 조인 하는 경우 중첩 루프 조인(Nested Loop Join)이 일어나도록 하는 힌트 문장 입니다. 중첩 루프 조인은 중첩 반복이라고도 하는데 하나의 테이블(outer/driving table)에서 추출된 로우를 가지고 일일이 다른 테이블(inner/probed table)을 반복해서 조회하여 찾아지는 레코드를 최종 데이터로 간주하는 방법 입니다.

즉 조인 입력 한 개를 외부 입력 테이블로 사용하고, 한 개는 내부(최하위) 입력 테이블로 사용하고 외부 루프는 외부 입력 테이블을 행 단위로 사용하고 각 외부 행에 대해 실행되는 내부 루프는 내부 입력 테이블에서 일치되는 행을 검색 하는거죠… 이것을 원시 중첩 루프 조인이라고 하는데 검색에서 인덱스를 사용하는 경우에는 인덱스 중첩 루프 조인이라고 합니다.

예를 들어 EMP 테이블과 DEPT 테이블을 조인하는 경우 dept 테이블이 건수가 작다면 우선 이 테이블을 외부 루프로 해서 하나씩 읽으면서 이에 대응하는 emp 테이블의 데이터를 추출 하는 경우라면 중첩 루프 조인에 해당 합니다. 이때 emp 테이블의 경우 건수가 많다고 가정을 하면 대부분 인덱스를 이용하도록 emp 테이블의 외래키인 deptno 컬럼은 대부분 인덱스를 걸게 되죠^^

중첩 루프 조인은 테이블중 적어도 하나의 조인 컬럼에 대해 인덱스(or Hash Index)가 존재할 때 연관되는 방식으로 이 중첩 루프 조인에서 테이블중 하나의 테이블 또는 중간 결과 셋을 대상으로 FULL SCAN이 일어나게 됩니다. 이 테이블이 드라이빙 테이블이 되는데… 이 테이블의 데이터 건마다 나머지 테이블에서 원하는 데이터를 추출하기 위해 대부분 인덱스를 사용하게 되는 겁니다.

보통 USE_NL 힌트 구문은 ORDERED 힌트 구문과 같이 사용되는데 USE_NL이 취하는 인자는 FROM절에서 두번째 나오는 테이블(비드라이빙 테이블, inner/probed table)을 명시해 주어야 합니다. 안수로 사용되지 않은 첫 번째 테이블은 outer/driving table이 되는 것입니다.

[형식]
/*+ USE_NL ( table [table]... ) */


[예]

아래는 Oracle 10g에서 테스트 한 결과 입니다.

analyze table emp compute statistics
analyze table dept compute statistics

select /*+ORDERED USE_NLe) */
e.ename,
d.dname
from dept d, emp e
where e.deptno = d.deptno

------------------------------------------------------------
Operation Object Name Rows Bytes Cost
---------------------------------------------------------------
SELECT STATEMENT Optimizer Mode=ALL_ROWS 14 4
TABLE ACCESS BY INDEX ROWID SCOTT.EMP 4 32 1
NESTED LOOPS 14 266 4
TABLE ACCESS FULL SCOTT.DEPT 4 44 3
INDEX RANGE SCAN SCOTT.IDX_EMP_DEPTNO 5 0


FROM절에서 처음 나타나는 테이블이 드라이빙 테이블(DRIVING/OUTER? TABLE)이며 비드라이빙 테이블(PROBE/INNER TABLE)이 USE_NL의 인자로 들어갑니다!!

select /*+ORDERED USE_NL(D) */
e.ename,
d.dname
from emp e, dept d
where e.deptno = d.deptno

--------------------------------------------------------------
Operation Object Name Rows Bytes Cost
--------------------------------------------------------------
SELECT STATEMENT Optimizer Mode=ALL_ROWS 14 3
NESTED LOOPS 14 266 3
TABLE ACCESS BY INDEX ROWID SCOTT.EMP 14 112 2
INDEX FULL SCAN SCOTT.IDX_EMP_DEPTNO 13 1
TABLE ACCESS BY INDEX ROWID SCOTT.DEPT 1 11 1
INDEX UNIQUE SCAN SCOTT.PK_DEPT 1 0


이번에는 USE_MERGE와 ORDERED가 같이 쓰이는 경우인데 이 경우엔 FROM 절 뒤 테이블의 순서는 실행계획은 다르게 나티날지 모르지만 성능에는 영향을 미치지 않습니다. 왜냐구요? 위 내용을 읽어 보세요!!


select /*+ORDERED USE_MERGE(D) */
e.ename,
d.dname
from emp e, dept d
where e.deptno = d.deptno


--------------------------------------------------------------
Operation Object Name Rows Bytes Cost
-------------------------------------------------------------
SELECT STATEMENT Optimizer Mode=ALL_ROWS 14 6
MERGE JOIN 14 266 6
TABLE ACCESS BY INDEX ROWID SCOTT.EMP 14 112 2
INDEX FULL SCAN SCOTT.IDX_EMP_DEPTNO 13 1
SORT JOIN 4 44 4
TABLE ACCESS FULL SCOTT.DEPT 4 44 3


select /*+ ORDERED USE_MERGE(E) */
e.ename,
d.dname
from dept D, emp E
where e.deptno = d.deptno


----------------------------------------------------------------
Operation Object Name Rows Bytes Cost
--------------------------------------------------------------
SELECT STATEMENT Optimizer Mode=ALL_ROWS 14 5
MERGE JOIN 14 266 5
TABLE ACCESS BY INDEX ROWID SCOTT.DEPT 4 44 2
INDEX FULL SCAN SCOTT.PK_DEPT 4 1
SORT JOIN 14 112 3
TABLE ACCESS BY INDEX ROWID SCOTT.EMP 14 112 2
INDEX FULL SCAN SCOTT.IDX_EMP_DEPTNO 13 1


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

NESTED LOOP JOIN

선행적 특징을 작는데 먼저 액세스되는 테이블의 처리범위에 의해 처리량이 결정됨
Driving Table에 의해 범위가 결정되며 Driving Table의 범위가 적을수록 수행속도는 빨라진다
고로 Driving Table을 어던 테이블로 결정하느냐가 중요하다

-. /*+ use_nl (테이블) */
-. 나중에 처리되는 테이블은 앞서 처리된 값을 받아 액세스하게됨, 즉 값을 받아서 처리범위가 정해짐
-. Driving Table의 인덱스 액세스는 첫번 로우만 Random Access이고, 나머지는 Scan, 연결작업은 Random Access임
-. 연결되는 방향에 따라 사용되는 인덱스들이 달라질 수 있음
-. 연결고리 인덱스 유무에 따라 액세스 방향 및 수행속도에 많은 차이가 있음
-. 연결작업 수행 후 체크되는 조건으로 부분범위처리를 하는 경우에는 조건의 범위가 넓거나 없다면 오히려 빨라짐

-. 전체가 아닌 부분범위 처리를 하는 경우 유리함
-. 조인되는 테이블중 어느 한쪽의 추출된 결과를 받아야 처리범위를 줄일 수 있는 상태라면 항상 유리함
-. Driving Table의 처리량이 많거나 연결 테이블의 Random Access량이 많을 경우에는 분리함
-. 일반적으로 처리량이 적은 경우로서 Random Access를 많이 하므로, 온라인 어플리에서 유리함
-. Driving Table의 선택이 관건임


■ Nested-Loop Join 의 경우

- 한쪽 컬럼에만 인덱스가 생성되어 있는 경우에는 FROM절에 열거된 테이블의 순서와는 상관없
이 인덱스 없는 테이블이 우선순위가 됨
(Join 문장에는 WHERE 조건절이 없기 때문에 어떤 경우라도 하나의 테이블이 전체스캔 되어야
하는데 인덱스가 있는 테이블을 구동테이블로 선택시 인덱스를 전체 스캔하고 다시 테이블을 전
체 스캔을 시켜야 하기 때문에 오히려 인덱스가 없는 테이블을 전체 스캔하는 경우보다 더 많은
액세스를 할 수 있기 때문)

SQL>create index i_dept_deptno_loc On big_dept(deptno,loc) ;
SQL>select a.empno , a.ename , a.sal, b.deptno, b.dname, b.loc
from big_emp a , big_dept b
where a.deptno = b.deptno
and b.deptno between 10 and 40
and b.loc = 'DALLAS' ;

Rows Row Source Operation
------- ---------------------------------------------------
14728 NESTED LOOPS
28956 TABLE ACCESS FULL BIG_EMP <= InnerTable
14728 TABLE ACCESS BY INDEX ROWID BIG_DEPT <= Driving Table
43683 INDEX RANGE SCAN (object id 27502)

- 조인에 참여되는 공통컬럼 중 한쪽만 인덱스가 생성되어 있고 하나의 비조인 컬럼에 유일 인덱스
가 생성되어 있는 경우 유일 인덱스를 가진 테이블이 구동 테이블이 된다.
(Unique Index는 검색방법 중 대단히 좋은 성능을 보장해 주는 Index Type 임)

SQL>create unique index i_emp_empno on big_emp(empno);
SQL>create index i_emp_deptno on big_dept(deptno);
SQL>select big_emp.ename , big_dept.dname
from big_emp,big_dept
where big_emp.deptno = big_dept.deptno
and big_emp.empno = 4000;


Rows Row Source Operation
------- ---------------------------------------------------
1 NESTED LOOPS
2 TABLE ACCESS BY INDEX ROWID BIG_EMP <= driving table
2 INDEX UNIQUE SCAN (object id 27505)
1 TABLE ACCESS BY INDEX ROWID BIG_DEPT <= inner table
2 INDEX RANGE SCAN (object id 27506)

- 조인에 참여하는 공통컬럼이 모두 인덱스가 생성되어 있는 경우 FROM절로 부터 가장 오른쪽에 정
의된 테이블이 구동테이블.

SQL>create index i_emp_deptnoon on big_emp(deptno);
SQL>create index i_dept_deptno on big_dept(deptno);
SQL>select big_emp.ename , big_dept.dname
from big_emp,big_dept
where big_emp.deptno = big_dept.deptno
and big_emp.empno = 4000 ;

Rows Row Source Operation
------- ---------------------------------------------------
1 NESTED LOOPS
290 TABLE ACCESS FULL BIG_DEPT <= driving table
1 TABLE ACCESS BY INDEX ROWID BIG_EMP <= inner table
18806 INDEX RANGE SCAN (object id 27508)



.

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

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

Posted by 홍반장

백 마디 말을 들려주는 것보다
하나라도 행동으로 보여주는 것이 훨씬 더 효과적이다.
만일 부모가 결단력과 책임감을 갖고 있고
낙천적인 태도를 보여줄 수 있다면
‘자녀를 키우는 법’에 관한 책들은 모두 불쏘시개로 사용해도 무방하다.

- 정신과 전문의 고든 리빙스턴


세월의 변화에 따라 전문가로서의 부모 역할에 대한 학습이 필요합니다.
그러나 역시 가장 중요한 것은 부모의 솔선수범입니다.
배우는 것은 흉내내는 것에서 시작된다고 합니다.
아이들은 우리가 생각하는 것보다 훨씬 일찍부터
부모를 평가한다고 전문가들은 지적합니다.
부모들은 아이들이 접하는 첫 번째 성인입니다.
아이들의 성격과 인성, 습관은 부모를 모방하는 것에서 형성되기 시작합니다.

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

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

Posted by 홍반장

때때로
자신의 삶을 바라보십시오.
자신이 겪고 있는 행복이나 불행을
남의 일처럼 객관적으로 받아들일 수 있어야 합니다.
자신의 삶을 순간순간 맑은 정신으로 지켜보아야
합니다. 그렇게 하면 행복과 불행에
휩쓸리지 않고 물들지 않습니다.


- 법정의《일기일회(一期一會)》중에서 -


* 자신을 객관적으로 보기 위해서는
첫째, 조금 떨어져서 바라보아야 합니다.
멀리서 봐야 '나'의 위치를 바로 볼 수 있습니다.
둘째, 한 계단 높은 곳에 올라서서 보아야 합니다.
그래야 욕심의 그림자까지 볼 수 있습니다.
셋째, 잠깐 멈춰서서 보아야 합니다.
그러면 나의 '속사람'도 보입니다.
'잠깐 멈춤'이 곧 명상입니다.

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

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

Posted by 홍반장