잡동사니 보물섬

 코로나가 만연한 지금 결혼식을 준비한 커플들은 울상을 짓고 결혼식을 미루고 있다.
그런 오늘 결혼식장을 다녀왔다.

코로나로 인하여 사람들은 많이 줄었을 것이고 모두 마스크를 쓰고 피로연과 식사도 지급할 수 없어 현금을 나누어주는 진풍경을 자아냈다.

 신랑 신부는 실망했을 법도 하지만 그들의 얼굴에는 미소가 만연하였다.

그런 그들의 모습을 보고 ‘어바웃 타임’이라는 영화가 떠올랐다.
어바웃 타임에서 가장 인상 깊었던 장면은 주인공의 비가 오는 결혼식이었다.
흔히 결혼식에는 무엇이든 완벽하길 원한다.
좋은 날씨와 많은 사람들의 축복 속에서 결혼식은 그저 아름답게 잘 마무리되기를 원한다.
그러나 영화에서는 그런 야외 결혼식 도중 소나기가 내린다.
갑작스러운 소나기로 인하여 결혼식은 엉망이 되고 사람들은 비를 피하기에 바쁘다.
그러나 주인공 신랑과 신부의 얼굴에는 웃음이 만연하다
그들에게는 그런 소나기 정도는 그들의 행복함을 막을 수 없었던 것이다.
아마 그들의 인생도 그러하지 않을까 싶다.
결혼을 하면서 살다 보면 웃을 일들과 함께 분명 예기치 않은 불운들도 따로 올 것이다.
그때 그들은 오늘처럼 지나가는 소나기를 서로를 바라보며 미소 지으며 넘어갈 수 있기를 바란다.  

 흔히 사랑을 감기에 비유하는 사람들이 있다.
사랑과 감기의 여러 가지 공통점을 찾아서 비유하곤 하는데 오늘 본 두 명의 신랑 신부의 사랑은
감기보다 강했고 아름다워 보였다.

나는 어렸을 적부터 겁이 많았다. 

처음 겁이 났던 기억은 4~5살 때쯤으로 기억된다. 

그때 처음 집 근처에 있던 오락실을 갔다. 

그때의 오락실은 지금과 같이 대로변에 있는 모습과는 거리가 멀었고 

오히려 조금 무서운 형아(?)들이 있는 곳이었다. 

오락실 하면 어둡고 숨겨진 이미지가 먼저 떠올랐다. 

그러나 그럼에도 불구하고 어린아이 눈에는 뭔가 미지의 재미가 있는 곳으로 보였다. 

멋지고 강해 보이는 캐릭터들이 동전 하나를 넣으면 내 마음대로 움직였고 

게임을 잘하면 당시 무엇보다도 우월감을 느낄 수 있었다. 

그렇게 어린아이의 눈에는 너무나 매력적인 곳이었다. 

아직도 어른이들이 게임에 매달리는 것을 보면 당시 나와 같은 아이의 마음을

대부분의 남자들은 공감할 것이라고 생각한다. 

그런 오락실이 우리 집 근처에 있었다. 

길을 지나면서 한 번쯤은 가보고 싶은 곳이었지만 

그곳을 지날 때마다 오락실을 가면 혼난다는 엄마의 말은 늘 나의 발걸음을 메어두고 있었다. 

그런데 그날을 무슨 용기가 있던 건지 오락실을 가자고 마음을 먹었다. 

엄마에게 아이스크림을 사 먹겠다고 돈을 받고 오락실에 가서 

동전 몇 개를 쥐고 엄마에게 들키는 것에 대한 불안함과 게임에 대한 흥분과 

내 차례에 대한 기대가에 부풀어 있을 때 갑자기 어머니를 보았다. 

거기에 있어서는 안 되는 사람이었다. 

그 당시의 정확한 감정을 재현할 수는 없지만 당시 매우 겁에 질려 있었다는 것은 분명히 기억이 난다. 

그렇게 집에 가서 어머니에게 크게 혼이 났다. 

그때 어머니가 혼을 냈던 것은 '오락실을 갔다'라는 것보다는 거짓말을 하였다는 부분이었다.

그래서 처음 알게 되었다. 

거짓말을 하면 안 된다는 것을 당시 이해하였다기보다는 거짓말을 하면 그렇게 혼이 난다는 것을 깨달았다. 

추후에는 왜 거짓말을 하면 안 되는지 이해하게 되었지만 거짓말의 대한 부정적인 부분은 그 기억에서부터 시작한다.  

아마 이런 거짓말에 대한 인식의 시작이 지금까지의 나의 삶에 중요한 영향을 주었던 것 같다. 

오랜만에 휴가에 낮잠을 잔 후 글을 쓰기 위해서 서점으로 향하였다.

낮잠을 잤음에도 불구하고 졸음이 몰려오고 귀찮기도 했지만 그래도 글을 쓰고 싶었다.

그렇게 글을 쓰기 위해 서점으로 향하였다.

서점에서 우연히 <시간은 흐르지 않는다>라는 책을 보게 되었다.

서점의 문을 닫는 시간을 몰라서 잠시 밖에 보지 못했지만

책의 처음 내용은 ‘높은 곳과 낮은 곳에 시간은 다르다’는 내용이었다.

물리적인 높고 낮음의 내용이었지만 어쩐지 나는 빈부격차를 떠올렸다.

글을 쓸면서 자주 글이 염세적으로 흐르는 것 같아서 자세하려고 하지만

어찌 자주 나의 글은 그렇게 흐른다...

그래도 나는 세상이 조금씩 긍정적으로 바뀌고 있다고 생각한다.

또 누군가는 세상을 더욱더 긍정적으로 바꾸는 방법을 생각해주기를 바란다.

본론으로 돌아가면 빈부 격 차이는 삶의 속도의 차이를 부른다.

나의 삶에서도 그런 예를 찾아볼 수 있다.

대학교 졸업반이 되고 취업을 위해서 나도 남들과 같이 미루었던 토익 공부를 시작하였다.

당시 집안 상황은 좋지 않아 등록금, 생활비를 내가 벌어서 학교를 다니던 상황이었다.

그런 상황에서 토익학원을 다니면서 공부하기는 너무 어려웠다.

그나마 아낀 생활비를 가지고 토익을 공부할 동안 생활비를 써야 했는데

그 상황에서는 학원들 다닐 엄두가 나지 않았다.

그렇게 학교 도서관에서 인터넷 무료강의와 서점에서 몇 권의 책을 구입하고

무료 자료들을 찾아가며 공부를 시작했다.

그렇게 3개월을 하고나서 토익 800점이 나왔다.

당시 문과인 나로서는 높은 점수는 아니었지만 토익에 집중할 수 있는 시간은 더 이상 없었다.

그 와중에 토익 시험비도 참 비쌌다...

그렇게 살면서 TV를 보다가 한 배우가 인터뷰를 하는데 리포터가 ‘어떻게 그렇게 빠르게 영어가 느셨어요?’라는 질문에 배우는 이렇게 이야기를 했다 ‘영어를 배우기 위해서 미국을 갔어요, 그리고 현지 영어 선생님과 계속 같이 있다 보니 자연스럽게 늘더라고요’ 그때 참 상대적 박탈감을 느꼈던 것 같다.

그 배우를 뭐라고 하는 게 아니라 그때 들었던 생각은 ‘그렇지 저렇게 하면 빠르게 늘겠다..’는 생각이었다.

이렇게 누군가는 힘들도 어렵게 해 나가야 하는 것을 어떤 이들은 너무나 쉽게 그 시간을 단축시킬 수 있다.

물론 노력하는 많은 이들이 있고, 내 능력의 부족했을 수도 있고 그 노력에는 과정에서 배우는 여러 것들이 있다.

그러나 부족한 부는 선택지 자체가 줄어들고 더 많은 노력을 해야만 자신이 원하는 것을 얻을 수 있게 된다.

사회적으로 누군가 얻을 수 있는 것들은 역설적으로 다른 이들도 누릴 수 있다는 것이다.

그러나 그것을 누리는 이들은 소수이고 그것들은 타인과 구별 짓는 상대적인 것이 된다

물리적인 과학이야기에서 너무나 인간적인 이야기로 생각이 연결되었다...

이런 사회를 좀 더 긍정적으로 바꾸기 위해서는 어떻게 해야 할까?

오늘도 이런 고민은 계속해서 이어진다.

온천은 좋다. 

목욕탕은 좋아하지 않는데 이상하게도 온천은 좋아한다. 

정말 시국이 이렇지만 않았다면 일본의 야외 온천에서 눈이 오는 날 눈을 보며 느긋하게 온천욕을 즐기는 것이 버킷리스트 중 하나였는데 어디를 가야 하나 싶다. 

내가 느끼는 온천의 매력은 적당한 온도와 야외라는 점이다. 

목욕탕의 뜨거운 물은 온천과 비슷한 온도일지도 모르지만 나는 왠지 모르게 뜨거워서 오래 있지 못한다. 

이런 느낌은 서로의 단어에서도 느껴지는 것 같다. 

목욕탕은 씩기 위해서 물은 덥히는 느낌이라면 온천은 그저 따듯한 물이다. 

무엇인가 목적이 있기보다는 그저 그런 것이다. 

온천을 생각하면 야외 즉 밖과 이어져 있는 느낌이 든다. 

내가 있는 공간은 아늑하면서도 밖을 여유롭게 즐길 수 있게 된다. 

온천이 실내에 있어서 밖과 연결되어 있지 않다면 나는 그것을 온천이라 느끼지 못할 것이다. 

나에게 온천은 외부와 통해 있어야 한다. 

그렇게 자연스러운 모습이어야 한다. 

나는 이 두 가지가 있어야 비로소 온천이라 느낀다. 

글을 쓰다보니 이 추운 겨울 온천에서 지친 몸과 마음을 스르륵 풀어버리고 싶다.

오늘부터 나의 이야기도 같이 쓰기로 했다. 

사실 어린 시절의 기억이 많은 편은 아니라서 일대기보다는 단편적인 기억의 조각들로 표현되겠지만 

그럼에도 불구하고 나의 이야기를 쓰는 것은 앞으로 나의 이야기들의 깊이를 주는데 필요한 것이라는 생각이 들었다.

나의 성장 모습이 나의 생각의 근간이 되었음은 분명하기 때문이다. 

이제 나의 이야기를 시작하자면 나의 어린 시절은 나의 기억보다는 어머니의 기억으로부터 시작된다. 

흔히 "너는 이랬어~"가 나에게는 "그랬구나~"가 되는 것이다. 

나의 첫 이야기는 나의 이름부터 시작된다. 

나의 이름은 조금 특이한 편이라서 잘 잊히지 않는 이름인데,

이 이름은 천주교인이셨던 친할머니께서 절에서 지었다고 한다.

나는 이 이야기가 퍽 재미있다. 

손주에 대한 사랑이 종교를 초월했음을 보여준다. 

그래서 나는 나의 이름을 이야기할 때 이 이야기를 빠지지 않고 하는 편이다. 

비록 나는 나중에 할머니와 그리 친근하게 지내지는 못했지만 그럼에도 불구하고 이 이야기를 할 때만큼은 할머니의 애정이 느껴지는 부분이라서 좋았다. 

나는 식탐이 많았다. 

나는 우량아는 아니었다. 3.23kg으로 평범하게 태어났다고 한다. 

그런데 어렸을 때 몸이 약해서 잔병치레가 많았음에도 식탐이 많았다고 한다. 

젖을 토할 때까지 먹었다고 하니 어린아이가 무엇에 그렇게 목이 말랐던 것일까?

지금도 아프면 많이 먹는 습관이 있는데 어렸을 때도 그 영향이 아니었을까? 하고는 혼자 생각한다. 

그런데 왠지 모르게 슬픈 것은 현재는 그런 식탐이 없다. 

지금은 오히려 먹는 것조차 귀찮아질 때가 있다. 

어렸을 적부터 나는 불효자였다. 

즉, 순한 아기는 아니었다. 

밤에 자다 깨는 것은 다반사였고 한 번 잠에서 깨면 앉고 달래주지 않으면 잠도 잘 자지 않았다고 한다. 

어린애가 성격도 급해서 꼬물거릴 때부터 다리로 밀고 올라가서 장롱에 머리를 찧고는 있었다고 한다. 

참 어린놈이 여러모로 어머니를 힘들게 하였다. 

그래도 걷기 시작하고는 사정이 조금 나아졌다.

지금은 아니지만 어렸을 적에는 귀여운 편에 속했다. 

어린 시절이 리즈시절이라는 것이 아쉽기는 하지만 그래도 그때라도 리즈시절인걸 다행이라는 생각도 든다. 

여하튼 그때 사정이 조금 나아진 것은 귀여운 외모(?)로 인하여 동네의 누나들이 나를 귀여워해서 낮에 근처 공원을 산책하고 나면 피곤해서 잠을 자니 어머니가 한결 나아지셨다고 한다. 

그나마 다행이다. 

아마 얼굴로 하는 효도는 그때 다하지 않았을까 싶다.

죄송합니다. 어머니 ...  

의문을 사전에서 찾아보면 어떤 것에 대해서 의심스럽게 생각함 또는 의심스러운 문제나 사실이라고 정의한다. 

'의심스럽다'라고 하면 왠지 부정적인 생각이 든다. 

영화나 소설에서 누군가 범인나 안 좋은 무슨 일이 있을 때 '의심스럽다' 또는 그의 행동에 의문이 든다고 표현한다. 

그런데 이는 내용만 보면 호기심 또는 궁금증이라고 표현할 수 있다. 

그러나 우리는 좀처럼 의문을 호기심 또는 궁금증이라고 생각하지 않는다. 

이는 순수한 마음 보다는 이미 자신의 감정이 담겨 있다. 

그 현상을 있는 그대로 바라보고 파헤치는 것이 아닌 이미 내가 생각하는 무언가가 있다.

그것이 비록 표현 할 수 없는 무엇인가 하더라고 나의 마음은 이미 긍정적이든 부정적이든 어느 방향으로 쏠려 있다. 

지금의 나를 보면 궁금증, 호기심보다는 의심, 의문이라는 표현을 자주 사용하게 된다. 

이런 표현을 보면 나는 이미 궁금증과 호기심에서 멀어져 가는지도 모른다. 

궁금증, 호기심을 더욱 많이 가지고 싶어 진다.  

설렘과 동시에 편안할 수 있을까?

나에게는 전자는 동적으로 후자는 정적으로 느껴진다. 

그래서 이 둘은 양립할 수 있을까?라는 의문이 든다. 

만약 이 둘이 상충되는 의미라면 사랑이는 감정에서는 무엇을 택해야 할까??

옆에 앉아만 있어도 설레는 사람과 

품고 있으면 편안함에서

무엇을 선택해야 사랑에 가까운 것일까?

기차를 타고 내려오는 길에 생각하였다 

글을 쓴다는 것은 무슨 의미일까?

나에게 언어는 표현이다. 

나의 감정을 타인에게 보일 수 있게 하는 힘이다. 

우리는 대부분 영화나 소설처럼 손만 잡아도 상대방의 감정을 느낄 수 없다. 

사랑하는 이들의 손을 맞잡은 떨림이야 느낄 수 있겠지만 

그들의 복잡한 감정 전부를 알 수는 없다. 

그러나 언어는 그러한 감정을 조금이나마 타인에게 이해시킬 수 있다. 

기독교인은 아니지만 성경에 나와 있는 이야기 중 인간은 바벨탑을 짓기 전까지는 동일한 언어를 사용했다고 한다. 

무엇이 진실인지는 알 수 없지만 설사 그랬다만 참 아쉬운 일이다. 

아마 같은 언어를 썼다면 우리는 조금 더 우리를 이해할 수 있었을지도 모른다. 

물론 가은 언어를 쓴다고 하더라도 타툼은 발생하고 남을 상처를 입히고 전쟁은 일어난다. 

그러나 언어로 인하여 우리는 타인의 감정을 공유할 수 있는 것 또한 사실이다. 

나는 이 부분에 초점을 맞추고 싶다. 

나의 '언어'는 감정을 공유하는 수단이 되고 싶다. 

책을 읽었다 

나는 힘이 들 때면 책에 의지하곤 한다 

볼썽사납게도 다른 이의 불해에서 나의 행복을 찾고 버틸 힘을 얻는다. 

다른 이에게 하는 말을 보면 나는 위선자가 따로 없다. 

이번에 보았던 책은 생각보다 힘이 되는 책은 아니었지만 

다만 하나 생각되는 것은 나는 내가 좋아하는 것을 하지 못하고 있다는 것은 분명했다. 

내가 좋아하는 것을 정말 쉽고 간단하게 생각하면 

나는 풍경이 좋은 곳에서 잠들고 책을 읽고 글을 쓰는 것을 좋아한다. 

딱히 직업적인 작가를 생각한 것은 아니지만 

나의 글을 많은 이들이 공감할 수 있다면 하고 생각한다. 

그래서 나는 이제 글을 써보려고 한다.

내가 좋아하는 것을 통해서 나의 어려움과 힘듬을 이겨내고 많은 이들이 공감할 수 있는 글을 쓰기 위해서

누구에게 배운 적도 없지만 내가 읽은 책들과 경험을 통해서 공감할 수 있는 문장들이 나오기를 바란다. 

매번 작심삼일이었지만 이제 나에게는 대청댐이 있고 좋은 카페가 있고 여러 책을 살 여유도 있다 

그것을 버팀목으로 글을 쓰겠다. 

Direct Path Read 

 - 오라클은 그래서 병렬 방식으로 Full Scan 할 때는 버퍼 캐시를 거치지 않고 곧바로 

   PGA 영역으로 읽어들이는 Direct Path Read 방식을 사용한다. 

   병렬도를 2로 주면 쿼리 수행 속도가 2배보다 훨씬 더 향상되는 이유가 바로 여기에 있다. 

 - 자주 사용되고 버퍼 캐시에 충분히 적재도리 만큼의 중소형 테이블을 병렬 쿼리로 읽을 때는 

   오히려 성능이 나빠지는 경우가 있는데, 버퍼 경합이 없는 한 디스크 I/O가 메모리 I/O보다 

   빠를 수 없기 때문이다. 게다가 Direct Path Read를 하려면 메모리와 디스크간 동기화를 

   위한 체크포인트를 먼저 수행해야 한다.  

 - 따라서 병렬 쿼리의 Direct Path Read 효과를 극대화하려면 그만큼 테이블이 아주 커야 한다. 

병렬 DML 

 - 병렬 처리가 가능해지려면 쿼리, DML, DDL을 수행하기 전에 각각 아래와 같은 명령을 

   먼저 수행해 주어야 한다. 

     ● alter session enable parallel query ;

     ● alter session enable parallel dml ;

     ● alter session enable parallel ddl ;

 - 이와 관련해 각 세션의 상태를 v$session을 통해 확인할 수 있다. 

     ● select pq_status, pdml_status, pddl_status from v$session ;

 - 다행히 parallel query와 parallel ddl은 기본적으로 활성화돼 있으므로 사용자가 의도적으로 

   비활성화하지 않는 한 신경 쓸 필요가 없다. 하지만, parallel dml은 사용자가 명시적으로 

   활성화 해주어야 하는데, 이 사실을 몰라 병렬 DML을 효과적으로 활용하지 못하는 개발팀을 

   여러번 보았다고 한다. 

 - 오라클 9iR2부터 병렬 DML이 블록 기반 Granule로 바뀌었다. 

   ( 메뉴얼에는 비파티션에 대한 병렬 DML이 여전히 블가능하다고 돼 있지만, 

     9iR2 New Features를 보면 주요 개선사항 중 하나로 기술돼 있다. ) 

 - 주의할 점은, 병렬 DML을 수행할 때 Exclusive 모드 테이블 Lock이 걸리나는 사실이다. 

   성능은비교할 수 없을 정도로 빨라지겠지만 해당 테입르에 다른 트랜잭션이 DML을 수행하지 

   못하게 되므로 트랜잭션이 빈번한 주간에 이 옵션을 사용하는 것은 절대 금물이다. 

병렬 인덱스 스캔 

 - Index Fast full scan이 아닌 한 인덱스는 기본적으로 병렬로 스캔할 수 없다. 

 - 파티션된 인덱스일 때는 병렬 스캔이 가능하며, 파티션 기반 Granule이므로 당연히 

   병렬도는 파티션 개수 이하로만 지정할 수 있다. 

병렬 NL 조인 

 - 병렬 조인은 항상 Table Full Scan을 이용한 해시 조인 또는 소트 머지 조인으로 처리된다고 

   생각하기 쉽지만 인덱스 스캔을 기반으로 한 병렬 NL 조인도 가능하다. 

 - Parallel Full Scan에는 블록 기반 Granule이 사용되므로 병렬도는 파티션 개수와 무관하다. 

병렬 인덱스 스캔으로 드라이빙하는 경우 

 - 병렬 NL 조인을 수행하려면, 드라이빙 인덱스가 반드시 파티션 인덱스여야 한다. 

   드라이빙 테이블과 두 번째 인덱스 및 테이블의 파티션 여부와는 상관없다. 

 - 인덱스를 드라이빙한 병렬 NL 조인에는 파티션 기반 Granule이 사용되므로 병렬도가 

   파티션 개수를 초과할 수 없다. 

 - 사용되는 파티션 보다 크게 병렬도를 지정해주더라도 실제로는 사용되는 파티션 개수 만큼의 

   프로세스만 사용된다. 만약 더 적게 지정한다면 각각 하나씩 처리하다가 먼저 일을 마친 

   프로세스가 나머지를 처리한다. 

병렬 NL 조인의 효용성 

 - NL 조인을 병렬로 수행하는 것도 가능하지만 실무적으로 활용할 기회가 많지는 않다. 

 - 유용하게 사용할 수 있는 상황 가정 

    1. Outer 테이블과 Inner 테이블의 둘 다 초대용량 테이블이다. 

       ( 어느 한쪽이 작은 테이블이면 병렬 해시 조인으로 해결 가능하다. ) 

    2. Outer 테이블에 사용된 특정 조건의 선택도가 매우 낮은데 그 컬럼에 대한 인덱스가 없다. 

    3. Inner 쪽 조인 컬럼에는 인덱스가 있다. 

    4. 수행 빈도가 낮다. 

        ( 수행 빈도가 높다면 Outer 쪽에도 인덱스를 만드는 편이 낫다. ) 

병렬 쿼리와 스칼라 서브 쿼리 

 - 병렬 쿼리에 트레이스를 걸면 QC의 트레이스 파일은 user_dump_dest 디렉토리 밑에 

   생기지만 병렬 서버의 트레이스 파일은 background_dump_dest 디렉토리 밑에 생긴다. 

 - 병렬 쿼리는 대부분 Full Table Scan으로 처리되는데, 도중에 이처럼 인덱스를 경유한 

   Random 엑세스 위주의 스칼라 서브쿼리까지 수행해야 한다면 수행 속도를 크게 저하시킨다. 

   따라서 병렬 쿼리에서는 스칼라 서브쿼리를 가급적 일반 조인문장으로 변환하고 

   [Full Scan + Parallel] 방식으로 처리되도록 하는 것이 매우 중요한 튜닝 기법 중 하나이다. 

 - 만약 병렬 쿼리 결과집합 전체를 Fetch 하지 않고 중간에 멈추는 상황, 즉 부분범위처리가 

   가능한 상황이라면 불필요한 스칼라 서브쿼리 수행을 최소화하는 것만으로도 쿼리 응답 속도를

   크게 향상시킬 수 있다. 

 - 스칼라 서브쿼리를 기술하는 위치에 따라 QC가 수행하기도 하고 병렬 서버가 수행하기도 하며, 

   이는 병렬 쿼리 수행 속도에 지대한 영향을 미친다. 병렬 처리 효과를 높이려면 부분범위 처리, 

   전체범위처리 여부에 따라 스칼라 서브쿼리 위치를 옮기거나 아예 일반 조인문으로 바꾸는 

   등의 튜닝을 실시함으로써 큰 효과를 얻을 수 있다. 

병렬 쿼리와 사용자 정의 함수 

 - 사용자 정의 함수를 생성할 때 아래와 같이 Parallel_enable 키워드를 선언해 주어야 

   병렬 실행이 가능하다고 흔히 생각하는데, 그렇지 않다. 

 - 세션 변수를 참조하지 않는다면 이 키워드를 지정하든 안 한든 병렬 수행이 가능하며, 

   세션 변수를 참조하는 함수일 때는 parallel_enable을 선언하느냐에 따라 함수의 병렬 수행 

   여부가 결정된다. 

Parallel_enable 키워드 역활 

 - SQL 수행 결과는 병렬로 수행했는지 여부와 상관없이 항상 일관된 상태여야 한다. 

   그런데 함수가 패키지 변수 같은 세션 변수를 참조한다면 병렬 수행 여부에 따라 결과가 

   달라질 수 있다. 원인은, 병렬 쿼리 시 각 병렬 서버가 개별적인 세션ID를 부여받고 

   실행된다는 데에 있다. 

 - 패키지 변수는 세션 레벨에서만 유효하다는 특징을 갖는다. 즉, 세션이 수립될 때 초기화 되어 

   같은 세션 내에서는 지속적으로 참조할 수 있지만 다른 세션과는 값을 공유하지 못한다. 

 - SQL 수행겨로가는 병렬로 수행하지는 여부와 상관없이 항상 일관된 결과를 반환해야 한다. 

   그런데 패키지 변수를 참조하는 함수는 병렬로 실행했을 때 일관성이 보장되지 않이 때문에 

   오라클은 기본적으로 병렬 수해을 거부한다. 

 - parallel_enable의 역할은 직렬로 수행할 때와 비교해 함수 수행 결과가 달라질 수 있음에도, 

   사용자가 parallel_enable 키워드를 선언하면 오라클은 사용자 지시에 따라 함수를 병렬로 

   실행할 수 있도록 허용한다. 하지만 겨로가에 대한 책임은 사용자의 몫이다. 

 - 굳이 이 키워드를 사용하지 않더라도 병렬 수행이 가능하다. 

병렬 쿼리와 Rownum 

 - SQL에 rownum을 포함하면 쿼리문을 병렬로 실행하는 데에 제약을 받게 되므로 주의해야 한다. 

 - sort order by를 QC가 담당한다. 

병렬 처리 시 주의사항 

 - 언제 병렬 처리 기법을 사용하는 것이 바람직한가 

    ● 동시 사용자 수가 적은 애플리케이션 환경에서 직렬로 처리할 때보다 성능 개선 효과가 

        확실할 때 

    ● OLTP성 시스템 환경이더라도 작업을 빨리 완료함으로써 직렬로 처리할 때보다 오히려 

        전체적인 시스템 리로스 사용률을 감소시킬 수 있을 때

 - 야간 배치 프로그램에서는 병렬 처리가 자주 사용되기 마련인데, 야간 배치 프로그램은 

   전체 목표 시가을 달성하는 것을 목표로 해야지 개별 프로그램의 수행속도를 단축하려고 

   필요 이상의 병렬도를 지정해선 안된다. 

   ( 업무적으로 10분 이내 수행이 목표인 프로그램을 5분으로 단축하려고 병렬 처리 기법을 

     남용해서는 안된다. ) 

 - 시스템 리소르를 최대한 사용해야 할 때도 있는데, 데이터 이행이 대표적이다.  이 때는 모든 

   애플리케이션을 중시시키고 이행 프로그램이 시스템을 독점적으로 사용하기 때문에 가능한 

   모든 리소스를 활용해 이행 시간을 최대한 단축하는 것을 목표로 삼는 것이 당연하다. 

 - 병렬 쿼리와 관련해 기타 주의사항 

   ● workarea_size_policy를 manual로 설정한다면, 사용자가 지정한 sort_area_size가 모든 

       병렬 서버에게 적용된다. 따라서 sort_area_size를 크게 설정한 상태에서 지나치게 큰 

       병렬도를 지정하면, OS 레벨에서 페이징이 발생하고 심할 경우 시스템을 마비시킬 수 있음 

   ● 병렬도를 지정하지 않으면 cpu_count x parallel_threads_per_cpu 만큼의 병렬 프로레스가 

       할다 된다. adaptive multiuser 기능을 사용하려는 경우가 아니라면 반드시 병렬도를 지정

   ● 실행계획에서 P ->P가 나타날 때면 지저안 병렬도의 2배수만큼 병렬 프로세그가 필요 

   ● 쿼리 블록마다 병렬도를 다르게 지정한 경우, 여러 가지 우선 순위와 규칙에 따라 

       최종 병렬도가 결정됨, 하지만 이런 규칙을 외우려는 노력보다는 쿼리 작성 시 병렬도를 

       모두 같게 지정하는 것이 바람직 

   ● parallel_index 힌트를 사용할 때는 반드시 index 또는 index_ffs 힌트를 사용하는 습관이 

       필요, 옵티마이저에 의해 Full table Scan이 선택될 경우 parallel_index 힌트가 무시 

   ● 병렬 DML 수행시 Exculsive 모드 테이블 Lock이 걸리므로 업무 트랜잭션이 발생하는 

       주간에는 삼가해야 함 

   ● 테이블이나 인덱스를 빠르게 생성하려고 parallel 옵셥을 사용했다면 작업을 완료하자마자 

       noparallel로 돌려 놓는 것을 잊지 말아야 함 

   ● 부분범위처리 방식으로 조회하면서 병렬 쿼리르 사용한 때에는 필요한 만큼 데이터를 

       Fetch  하고 나서 곧바로 커서를 닫아 주어야 함 

 - Toad나 Orange 처럼 부분범위처리를 지원하는 쿼리 툴에서는 EOF에 도달하기 전까지 

   커서를 오픈한 채로 유지하기 때문에 오라클은 병렬 서버들을 해제하지 못하고 대기 상태에 

   머물도록 한다. 이는 불필요한 리소스를 낭비하는 결과를 초래하므로 조회가 끝나자마자 

   select * from dual  같은 문장을 수행해 병렬 쿼리의 커서를 닫아 주어야 한다.