SQL

Oracle 공부 경험담

멋쟁이천재사자 2023. 2. 1. 16:23

저는 오라클이 인정한 전문가였습니다. 뭔 소리냐고요?


Oracle Certified Professional 을 해석하면 오라클이 인정한 전문가 맞지요?

 

그런데 OCP 8i 합격은 아주 오래전이고 자격이 언제인지도 모르게 만료되었기 때문에 "전문가였습니다"라는 과거형으로 이야기했습니다. 2003년도 10월 이였군요!


조그마한 회사 다니며 Visa3D 인증 기술지원하던 시절이었는데, 우연한 기회에 오라클 바우처를 얻었고 덤프를 달달 외워서 땄었지요.

 

OCP8i 합격 후 1년이 되지 않은 어느날이었어요.

엘지카드에서 SM 파견 근무 중인 Java  개발자가 퇴사한다고 저보고 가서 대신 일할 수 있겠냐고  사장님께서 헬프 치시더라구요.

비트교육센터에서 Java 공부를 그렇게 해놓고 SI SM 을 한번도 해보지 못한터라, 땡큐하고 이력서에 OCP 8i 도 한 줄 추가해서 자랑스럽게 면접을 보러 갔지요.

 

그런데, 면접관이 그 부분을 보시고는 DB 잘하던 친구가 나가는 거라 걱정했는데 잘 됐다고 좋아하더라고요.

아니 뭐 덤프만 보고 외워서  딴 건데 잘하는  하고는 거리가 멀잖아요.

당시 실제 실력은, 쿼리 공부한지 몇 달 지나기도 했고 실전 경험도 없어서 Join 구문도 부담스러운 수준이었던 것 같아요.

내가 Java 개발하고 싶어서 간 것이었는데, DB 이야기를 하니 겁이 나잖아요. 프로필에 괜히 썼나 싶기도 하고요.

그래서 있는 그대로 다 이야기하고 별로 잘 못한다 했는데, (저를 놀리려고 그러는지 진짜로 그런 생각인지)웃으면서 그래도 OCP인데 잘 하시겠죠라고 하는 거예요.

와! 그 부담감~

20년이 지난 지금도 어제처럼 생생합니다.

 

암튼 쪽팔리지 않으려고 그다음 날부터 바로 엄청 공부 시작했어요.

 

그래서, 어떻게 공부했는지 이야기해 볼게요


1. 기본 sql 강의 싸이트를 하나하나 따라 치면서 실습을 해보았습니다. 

oracleclub.com

오랫만에 다시 방문해보니 주소가 gurubee.net 으로 리다이렉트 되는군요.

싸이트가 많이 바뀐 것인지 아니면 도메인이 팔린 것인지 모르겠네요

 

당시에는 간단 간단한 CRUD 구문들과 DDL 기본적인 것들이 따라 하기 좋게 되어 있었는데, 참으로 쉽고 친절하게 되어 있었고 무료였습니다. 


전부 실습해보는데 며칠 안 결렸어요. 그 때의 각오가 남달랐잖아요. 

 


2. 다음에는 인터넷에서 중고급 오라클 연습 문제를 검색해서 열심히 풀어보았어요.

 


어렴풋한 기억을 돌이켜 보면은요,
세로로 되어있는 데이터를 group by 해가지고 max 때려서 가로로 표현하는 문제들,
copy_t 라는 엘리어스 주고 cross-join 으로 뻥튀기 시킨 다음에 기교를 부리는 문제들,
connect by 활용하는 문제 들 등등 다양했어요.

아무리 어려워도 최소 하루 이틀은 답을 보지 않고 고민을 하고 여러 가지 시도를 해보았고요.
대부분 결국 못 풀었고, 답을 보고는  '와~ 이런 것도 가능하구나' 감탄을 여러 번 했었지요.

실력 향상의 핵심은 얼마나 많은 고민과 시도를 해보느냐인 것 같습니다.
일단 답을 본 문제는 감탄한 만큼, 고민하는라 보낸 시간 만큼,외우고 연습을 해서 내 것으로 만들려고 노력했어요.
한 달 정도는 이렇게 연습한거 같아요

 


3. 실전용 연습

 

어느 정도 쿼리가 된다 싶은 이후에는 데이터베이스 사랑넷을 매일 점심 때마다 들어가서 보았습니다.
거기 올라운 질문들 중 쿼리 문제는 다 풀어보려고 시도했고, 답글도 올려 보고 남들의 답도 보고 했었어요.

 

이렇게 한 석달 매일 매일 연습하니 sql로 기능 구현하는 데에는 어려움을 느끼지 않게 되었습다.

 

저의 흔적을 몇 개 공유해봅니다.

 

https://database.sarang.net/?inc=read&aid=19731&criteria=oracle&subcrit=&id=0&limit=20&keyword=%EA%B9%80%EC%9A%A9%EC%8B%9D&page=2

 

https://database.sarang.net/?inc=read&aid=18694&criteria=oracle&subcrit=&id=0&limit=20&keyword=%EA%B9%80%EC%9A%A9%EC%8B%9D&page=3 

 

 

위 링크에 있는 질문을 퀴즈로 한번 풀어보세요

질문자 아이디 metsgo로 테이블을 만들어서 풀어보세요

create table metsgo as
select 'AAA' as A from dual
union all
select 'AAA' as A from dual
union all
select 'AAA' as A from dual
union all
select 'BBB' as A from dual
union all
select 'BBB' as A from dual
union all
select 'AAA' as A from dual
union all
select 'CCC' as A from dual
union all
select 'CCC' as A from dual

 

제 답안은 아래였는데요, 질문자는 원하던 결과라고 했었고요, 더 좋은 답안이 있을 수도 있습니다.

select
 a,
 seq- nvl(lag(seq) over (order by null),0) as cnt
from (
 select seq,a,next,decode(a,next,0,1)as gubun
 from (
  select
  rownum as seq,
  a.a ,
  lead(a.a,1,null) over (order by null) as next
  from metsgo a
 )
)
where gubun = 1



4. Oracle Expert One on One 이라는 책을 공부했어요.

이 즈음에 보았던 것 같은데 정확한 시기는 기억나지 않아요.
비트교육센터에서 공부하던 시절 Java 개발자 시각에서 PreparedStatement가 Statemet 보단 보안과 성능이 좋다는 이야기를 들었던 것 같아요.
그런데 보안은 인정하지만 성능은 인정하지 못했어요. 왜냐하면 제 나름으로 성능 테스트를 직접해보았는데 결과가 비슷했기 때문이에요. 그러니깐 preparedStatement Statemet 두 가지 방식으로 간단한 select 문장 만들어서 천번 만번을 뱅뺑이 돌려서 소요시간을 비교해보았지요.
결과는 둘이 똑 같았습니다. 그래서 인정을 할 수가 없었지요.

 

PreparedStatement 가 성능에도 좋은가?
Oracle Expert One on One 을 읽으면서 드디어 그 답을 알게 되었지요.
해당 책을 보면 오라클 부사장이며 저자인 위대한 Tom Kyte가 binding variable 의 중요성을 알려줍니다.
그 숨겨진 매커니즘과 올바른 비교 테스트 방법을 알려주고 있는데,직접 코딩해서 비교해보았을 때야 두 방식의 엄청난 차이를 알게되었습니다.
암튼 학원 다니던 시절의 테스트는 테스트가 잘못된 것이었지요.

6. 책에서 본 내용을 실무에서 활용해보며 또 공부했어요.

 

materialized view , analytic function 등 여러 가지 새로운 내용을 책에서 보았는데요, 어떻게든 실무에서 활용해보고 싶은 거에요.

그 책에는 Oracle Job 을 이용한 배치 기능 소개도 있었는데, 싸이트에서 활용하려고 했다가 파트장님께 혼나기도 했습니다. 당시 파트장님의 질문은 "Oracle Job을 왜 쓰려고 하니?"였는데, crontab 처리가 표준이었기 때문이에요.

Job 보다도 당시 고백하지 않은 더 큰 폭탄도 있었는데요,제가 혼자서 구현한 소규모 싸이트라 나중에 큰 문제는 안돼었을 텐데 자칭 검색엔진급 게시판이에요.

표준 프레임워크가 있었고 그것을 재활용해서 신규 사이트를 만드는데 게시판 속도가 제가 볼때 너무 느린 것 같았어요.
그래서 검색엔진, 형태소 분석 등등에 대해서 공부를 또 몰래 빡시게 했지요. 

사전 테이블 구성 -> 형태소 분석 -> 역색인 테이블(Tf-idf) 구성 -> 쿼리는 order by 안쓰면서 hint 처리하는 법이나 (엔코아 공개자료인)페이징 처리 고급 기법 활용하여 작성.
인터넷에서 스크랩해서 100만 건 정도 가라데이터 등록해서 검색 테스트해보았는데요,실시간 파싱도 문제 없고 검색 속도나 페이징 처리 속도도 어마 무시 빨랐어요.
하지만 게시글 저장하는 과정은 말할 것도 없고, 역색인 구조로 파싱된 구조에서 다시 꺼내오는 조회 쿼리는 A4 몇 페이지 길이에 달할 정도로 길고 복잡했어요.

만에 하나 수정할 일이 생겼다면 게시판을 새로 만드는 것이 고치는 것보다 빨랐을 수 있어요


파트장님께 혼났던 Job 도 게시글을 형태소 분석하여 역색인 테이블로 파싱하는 것을 배치로 처리하려고 했던건데요, 그냥 trigger 를 통해 실시간 처리로 바꿔버렸지요.

 

어린 시절  이야기이고요, 성능보다 중요한 것이 표준 준수이고,가독성 유지보수성이니 이렇게 하면 안되요!

 

 

 

암튼, 이런 과정을 거치면서 나름 DB 의 고수라는 자신감 뿜뿜으로 Java 개발자에서 DW 개발자로 변신을 했었네요.