[java] statement와 preparedStatement 의 차이, 특수문자 처리..

제목 : PreparedStatement 와 Statement 에 대한 이원영님의 고견을... 글쓴이: 손님(guest) 2003/08/22 12:07:32 조회수:15105 줄수:16

PreparedStatement 와 Statement에 사용에 대한 이원영님의 고견을 듣고 싶은 사람입니다. 이전글들에서 많은 고수분들이 PreparedStatement와 Statement에 대해서 비교하고 여러 측면에서 말씀을 해주시고 번역된 글도 잘 읽었습니다만 여전히 갈피를 못 잡겠습니다. 많은 고수분들의 글은 찾아볼 수 있었사오나 위 관련 사항에 대한 이원영님의 직접적인 답글은 찾지 못하여 고견을 여쭈어 봅니다. Statement보다 PreparedStatement의 사용이 더 효율적인것인지.. 고수님들이 여러 의견이 있으신데 저같은 우매한 중생은 어느 분의 말씀을 따라야 할지 몰라 이렇게 청을 드리는 것이니 넓은 마음으로 굽어 살피시어 한 수 지도해 주셨음 합니다.

제목 : Re: 저의 경우는 PreparedStatement를 권해드리고 싶군요 글쓴이: 손님(guest) 2003/08/29 11:02:17 조회수:1727 줄수:25

저도 예전에는 습관처럼 Statement를 사용해왔습니다. 언젠가, 오라클(8i)에서 쿼리를 실행하는데 엄청나게 리소스를 많이 잡아먹더군요. 한번실행하면 10초이상이 걸리는... 그런데, 오라클에선 한번실행했던 쿼리문을 그대로 사용하면 메모리에 저장되어 있어서 다음번 호출은 매우 빠르고요. 물론 검색조건을 틀리게 해주면 전혀다른 쿼리문으로 인식하기때문에 다시 시간이 오래 걸리고.. 이런 이유를 위해 sql문 작성시 바인드 변수를 사용한다고 알고 있습니다. Statement의 경우에는 db에 질의를 할때 전혀다른 쿼리문으로 넘겨주고 PreparedStatement는 바인드 변수를 사용해서 쿼리문을 넘겨주고요. 물론, 위의 리소스 많이 잡아먹는 쿼리문의 경우 PreparedStatement가 응답이 빨랐습니다. 단순쿼리문의 경우에는 별차이가 없을수 있고요.. 이내용은 지독히 저의 개인적인 경험입니다.

제목 : Re: 저는 Statement 권장합뉘다.. 글쓴이: 어렵군요.(whand76) 2003/09/01 18:30:32 조회수:1900 줄수:32

Statement / PreparedStatement 속도면에서는 윗분이 말씀하신 정도면 될듯하구요, 제가 실질적으로 속도를 측정해본적은 없습니다. 제 생각에는 개발자들이 서로 알아 보기 편한 Statement 가 더 낳다구 생각합니다. PreparedStatement 의 경우에는 1번엔 모 2번엔 모. 이런식으로 설정을 하는데. 실질적으로 웹상에서는 사용자 정보를 받는다 던지 기타 정보들을 받을때 변수들이 장난아니게(?) 많아 지죠 그럼 일일이 하나 하나 씩 따져보면서 넣어야 하는 불편함두 있고 , 버그가 발생하면 좀.. 찾기 어려워지구요, 실질적으로 값을 가져올떄는 디비 커넥션이 일어나야 잘못된 점을 찾을수 있어서 전 별루 권장하진 않습니다.~ 빠른만큼(?) 개발자의 수고가 배로 증가되는거 같아서요. 그만큼 업주가 시간을 주는것도 아니고 ? 돈두 주는것도 아니고 ? 농담이구요. 허나 Statement 경우는 명시적으로 변수이름을 맞춰서 넣을수 있어서 컴파일 하는 시점에서 무엇이 잘못되었는지 알수 있어 편하지요. 그리고 일일이 순서 맞출 일도 없구요. 맘에 드는 걸 가져다 쓰면 되니까요~ 또한 값을 가져올때도 타입이 잘못된 정도면 컴파일시점에서 찾을수 있어 편하구요~ 많이 유연한 코드가 되죠.. ㅡㅡ?? 실질적으로 그렇게 길거나 많은 양의 쿼리문을 날릴정도라면 프로시져나 ? 을 이용해야 할때라고 생각이 듭니다.~ 어떤게 빠르다 느리다로 결정하기 보다는 수정할때? 빨리 눈에 들어오는 코드가 더 낳다구 생각이 듭니다. 그래서, 오타 하나 찾으려고 밤을 새는 그런 코드보단, 좀 느리더라도(?) 일의 양을 줄일수 있는 Statement 강추입니다.! 그래야 다른 공부도 하고 발전도 하죠 ㅡ.ㅡ 노가다 줄이기 전쟁 ㅡ.ㅡ;; 현실형이죠 ㅡ.ㅡ;; 제 개인적인 생각입니다. 그럼 즐거운 하루 보내세용.~

제목 : Re: Oracle에서 bind변수는 이렇게도 가능합니다. 글쓴이: 허광남(heogn) 2003/09/01 18:58:44 조회수:2473 줄수:28

오라클에서는 PreparedStatement와 Statement는 차이가 많이 납니다. 한글처리에 문제가 조금 있지만, DB액세스가 많을 수록 PreparedStatement가 훨씬 효율이 좋습니다. SQL문의 가독성을 얘기하셨는데요. 오라클에서는 다음과 같이 ? 대신 :LABEL 로 바인드변수를 사용할 수 있습니다. 몇 번째가 무엇인지 확연히 알 수 있습니다. INSERT INTO BOARD (SEQ, REF, STEP, LEV, NAME, EMAIL, HOMEPAGE, SUBJECT, CONTENT, PASSWORD, HTML, LOGTIME, HIT, PSEQ, REPLY) VALUES ( :SEQ, :REF, :STEP,:LEV, :NAME, :EMAIL, :HOMEPAGE, :SUBJECT, EMPTY_CLOB(), :PASSWORD, :HTML, SYSDATE, :HIT, :PSEQ, :REPLY) 책 광고 같지만, 한빛미디어의 "모델2로 다시 배우는 JSP" 책의 7장 JDBC 부분에 제가 CPU 사용율 그래프를 캡쳐해서 비교해 올려놓은 것이 있습니다. 그 중에 하나의 이미지 첨부합니다. ps.개인 실험 결과 같은 소스로 mysql에서는 Statement가 PreparedStatment보다 근소한 차이로 빨랐습니다. ---------------------------------------------------- jsp/서블릿 정보공유; http://www.okjsp.pe.kr jakarta 문서 한글화; http://jakarta.apache-korea.org ----------------------------------------------------  PreparedstatementVsStatement.jpg (96907 Bytes)

제목 : Re: 디비에 따라 고려하여 사용하시는것이 좋을것같습니다. 글쓴이: 손님(guest) 2003/09/01 18:59:46 조회수:1435 줄수:8

Mysql의 경우 Statement / PreparedStatement 속도차이가 별로 나지않습니다. Oracle의 경우 확연히 속도차이를 체감할 수 있습니다. 속도는 윗분 정도 되겠죠.. 10만건 이상이라면 느끼실 수 있을 것 같습니다. 어떤 객체를 쓰냐보다는 얼마나 디비에게 적절하고 좋은 쿼리를 날리느냐가 관건인것 같습니다. 허접한 생각이었습니다.

제목 : Re: 개발시에 글쓴이: 나종원(nawon2000) 2003/09/02 02:08:59 조회수:1419 줄수:21

프리페어 스테이트먼트를 사용하여 개발시에 변수가 박혀서 만들어진 쿼리를 볼수 없어서 참 애를 먹을 때가 많습니다 개발코드가 +"and xxx='"+xx+"'"+ 가 난무하지 않고 가지런히볼수 있어서 프리페어 스테이트먼트를 많이 사용합니다 익스큐트 쿼리하기전에 쿼리안에 변수가 어케 박혔는지 볼수 없다는게 프리페어 스테이트 먼트의 가장큰 단점이었습니다 적어도 저한테는요 PreparedStatementPrinter 를 사용하시면 데이터까지 박힌 쿼리문을 확인하실 수 있습니다 프로퍼티스에 스위칭 옵션을 두시구 로그객체처럼 껏다가 켯다가하시면 되겠죠 http://www.javaservice.net/~java/bbs/read.cgi?m=devtip&b=javatip&c=r_p&n=1003484036 -워니- nawon2000 골뱅이 empal.com 말이 두서가 없습니다 공대생 맞긴맞나봅니다...

제목 : Re: 글쎄요.. 글쓴이: 손님(guest) 2003/09/02 12:07:43 조회수:1355 줄수:13

그건 개발자의 스타일에 따라 다르지 않을까요? +"and xxx='"+xx+"'"+ 가 난무하다는 것은 반대로 난무하지 않게 쓸 수 있을 수 있다는 것이 되겠죠. 또한 파라메터갯수같은것이 맞지 않을때 정상적으로 쿼리가 수행이 되지 않는데 PreparedStatementPrinter 가 사용가능한지 알려주시기 바랍니다. 제가 말하고 싶은건 Statement 건 PreparedStatement 건 상황에 맞게 적절히 써야지 무조건 PreparedStatement 을 쓰는것은 비효울적이라는것입니다.

제목 : Re: 글쎄요.. 글쓴이: 드리미(neo4elf) 2003/09/02 16:13:16 조회수:1514 줄수:29

손님의 말이 맞습니다.. 상황에 따라 적절히 사용해야 하겠죠... 그러나 지금 논제는 어느 하나만 쓰자는 것이 아님니다. 과연 statement 와 preparedstatement 둘중에서 어느 것을 어느때에 써야 가장 좋은 퍼포먼스가 나오고 좋은 코딩 습관이냐 하는 것이죠... 님의 말처럼 기준 없이 적절히 사용하라고 하는건 좀 무책임한 얘기죠.. 적절히 쓰려면 어느때를 기준으로 어떻게 써야 하는지 경험과 지식으로 가이드 라인을 제시 해야지 그냥 막연히 적절히 쓰라고 한다면 이런 주제로 포스팅을 하는 의미가 무색해져 버리죠.. 비단 이문제 뿐만 아니라 String 과 StringBuffer 등 많은 사람들이 고민하고 실험한 것들도 의미없어가 지지 않겠어요? 다시 말하자면 적절히 써야 하겠지만 과연 어느 상황에서 어느 것을 쓰는 것이 좋은지를 얘기 하고자 하는 것입니다. 이미 많은 경험과 지식을 갖고 있는 사람들의 생각을 토대로 얘기 해가며 오류를 없애고 새롭게 시작하는 사람들을 위한 가이드 라인을 만들자는 의미죠... 그렇기 때문에 이런 토론이 의미가 있는것이 아니겠습니까? 님에게 태클 걸고자 쓰는 글은 아니구요 많은 사람들이 관심있게 보고 있는 이 글들이 무의미한 글로 전락하고 더이상 유경험자들의 관심을 끌지 못하게 될까 걱정되어 쓴글입니다.(혹 기분이 상하셨다면 죄송합니다.)

제목 : Re: 파라메터 갯수가 유동적이어도 가능 글쓴이: 나종원(nawon2000) 2003/09/02 16:19:52 조회수:1536 줄수:16

파라메터 갯수가 유동적이어도 가능합니다 그리고 저는 무조건 전부 프리페어 스테이트먼트로 코딩합니다 개인적인 취향입니다..머.. 딴지거셔두 할말은 없습니다 프리페어스테이트먼트는 한프로그램내 에서 똑같은 쿼리를 반복적으로사용할때...유용합니다 그렇게 알고 있습니다 오라클이 파싱하는 걸 미리 해놓구쓰겠다는 거니까요 속도가 중요시되고 업무가 너무나두 복잡하여 원쿼리루 처리가 머리아플경우 프로시져로 간단히 짜놓구 콜러블스테이트먼트를 사용하면 몇배 빨라집니다 -워니- nawon2000 골뱅이 empal.com 말이 두서가 없습니다 공대생 맞긴맞나봅니다...

제목 : Re: 그래도 스테이트먼트가 좋은것 같습니다. 글쓴이: 어렵군요.(whand76) 2003/09/02 18:11:22 조회수:2161 줄수:67

안녕하세요~ 너무 개인적인 생각이라서 쓰기는 싫지만, 가독성이 젤 중요하다는 생각이 들어서요.. 저의 개인적인 생각을 좀 적어 보렵니다. 이해해 주시길 바랍니다. 제 생각에는 개발자는 시간과의 싸움이라고 생각이 됩니다. 저만 그런지 모르겠지만, 대부분의 어플리케이션 개발자나? 웹 개발자나 할 것 없이 항상 시간과 싸움이 가장 큰 문제점이라고 생각이 듭니다. 항상? 업주 측에서는 기회비용이란걸 무기삼아 개발자를 타박을 하죠 은근히 밤늦게 까지 일해야 한다 , 밤에 일을 해야 잘된다. 밤새는건 할수도 있고 안할수 있다. 어찌되었건, 이런 인식때문인지는 모르겠으나? 기회비용을 위해 시간을 맞추기 위해 밤을 지새운다거나 한다는 말이 맞는 말인거 같으나 실상은 그렇지 않은 경우가 대부분이라고 저는 생각합니다. 만약 임금을 준다면 그 임금 이상을 뽑아 내려는 쪽이 업주 측이고, 개발을 함에 있어 대규모의 사이트? 어플리케이션 ? 저의 적은 경험으로 비추어 볼때는 그 어떠한 기업도 어떠한 업주도 정말 훌륭한 코드를 위해서 비용을 지불하진 않는것 같습니다. 또한, 정말 10만건의 데이터를 A라는 방식으로 했을때 4초 빠르다거나, 4초 느리다거나를 체크 하는 업체나? 업주는 전무?? 하다고 볼수 있습니다. 4초느리고? 4초 빠르고를 업주나/기업에선 필요항목으로 생각하진 않죠?? 업주나 기업에서 최고의 관심사는 얼마나 빨리 만들수 있느냐? 얼마나 자유 자재로 유연하냐? 수정이 자유롭냐 이런게 더 크다고 봅니다. 처음에 요구사항을 아무리 잘 파악하고 듣고 / 설계하고 / 컨펌받고 / 코딩하고 서비스에 들어가면? 컨펌을 받으면? 대부분의 업주들이나 기획자들은 아 이거 넘 어려워 / 아 이거 넘 복잡해 / 아 이거 쉽게 할수 없나? 이런 수정이 많이 발생하게 됩니다 (개발자가 시다바리는 아니죠 ㅡㅡ, 기획을 하는것도 어렵지만 만드는건 더더욱 어렵다는걸 말로만 기획자들은 말하는거 같습니다. 지독히 개인적인 생각입니다.). 저만 그런지 모르겠으나. 제 경우는 그렇다는 거죠... 정말 새롭게 다시 만드는 경우가 대부분 이었던것 같습니다. 또한 이렇게 만들고 나서도 리뉴얼이니 ? 해서 또 바뀌게 됩니다.. 그래서 제 생각에는 여러 사람이 같이 작업하고 수정하는 상황에서는? (실질적으로 님이 만들었다고 하여도 다른사람이 수정하게 되죠 ㅡ.ㅡ? 아무리 혼자 일하는 사무실 이라도 ?? 다른 사람이 꼭 수정합니다 ㅡ.ㅡ;;)) 이런상황들이 많이 발생을 하죠.. 그럼 개발자들이 한눈에 알아볼수 있게 코딩하는것이 중요하다고 볼수 있지안나요? 저는 그래서 statement을 사용합니다. 일단 간단한 문장에서야 그렇게 큰 차이가 보이지 않습니다만, addBatch()를 시킨다덩가 ? 모 이런상황이 발생을 한다면 ? 쿼리문장 확인하려면 좀 짜증이 많이 나고, 귀찮아지죠.... ?? ㅡㅡㅋ 굳이 오라클에서 바인딩 시켜 확인하지 않아도! 굳이 쿼리문장 하나 확인하기 위해서! PreparedStatementPrinter 새로운 클래스를 만들어서 타 개발자가 분석하지 않고 사용하지 않아도!, 파라메터 갯수가 유동적이든 아니든 신경안쓰고! 누구나? 쉽게 쿼리문장만 신경쓰면 되는! 그런 statement 가 강추입니다! 쿼리문장의 복잡 (+"and xxx='"+xx+"'"+) 난무하다는 지적이 있습니다만. 쿼리문장을 확인하시기 위해서 PreparedStatementPrinter 새로운 클래스를 만들어서 사용하실 정도면, (+"and xxx='"+xx+"'"+) 이런문장은 깔끔하게 정리 되리라 생각이 됩니다. 제 나름대로의 결론은 개발할때 최대한 단순화 시키고, 최대한 가독성을 높이는 일이 제일 중요하다고 봅니다. 그런면에서 볼때 프리페어보단, 스테이트먼트가 더 좋다라는 생각이 듭니다. ㅡㅡ;; 넘 제 개인적인 생각을 적어 놓은것 같습니다.. ㅡㅡ;;; 그럼 즐거운 하루 보내세용.~

제목 : Re: 아직도 고민하시는지... 글쓴이: PSM(guest) 2003/09/09 09:35:11 조회수:1977 줄수:37

Statement가 PreparedStatement보다 디버깅이 쉬워 개발자가 사용하기 편리하다는 의견에는 동감합니다. 하지만 개발자의 입장에서만 동감한다는 의미입니다. 실제로 다량의 쿼리를 처리해야 하는 중대형 이상의 시스템의 경우 모든 쿼리는 반.드.시. PreparedStatement를 사용해야 합니다. (일단 DB를 오라클로 국한하겠습니다. 다른 DB는 대형 사이트에 사용한 적이 없어서...) 하루에도 수백 수천만건의 SQL을 실행해야 하는 사이트에 만약 모든 SQL이 Statement로 작성되었다고 가정할 경우... DB서버의 CPU부하 및 처리 속도가 감당하지 못합니다. 제 기억이 틀리지 않다면 오라클의 경우 하나의 SQL을 실행하기 위해 Parse-Execute-Fetch의 과정을 거칩니다. 여기서 Parse 과정은 해당 SQL의 최적 수행 경로 등을 계산하는 과정이라고 합니다. 근데 매번 동일한 SQL에 대한 Parse과정을 거치게 되면 대부분 동일한 실행경로를 얻기 위해 불필요하게 DB에서 CPU를 소모하게 됩니다. 이 의견은 예전 C/S 시절부터 bind변수를 사용하느냐 마느냐에 따른 성능상의 차이에 대한 이론과 결국 대등소이한 내용입니다. 자바의 PreparedStatement의 사용은 DB에서 bind변수를 사용하도록 함으로 해서 DB서버에 미리 준비된 SQL을 사용하게 되고 Parse과정을 생략하기 때문에 결국 DB리소스를 효율적으로 사용하도록 하는 방법이 됩니다. 이에 대한 내용은 자바 개발자보다는 오라클 DBA에게 문의하는 것이 더 정확한 대답을 얻을 수 있습니다. DB서버에 Trace를 걸어 놓으면 위에 대한 엄청난 차이를 쉽게 발견합니다. 동일한 문자열의 SQL이 실제 DB에서는 모두 다른 SQL로 인식되어 요청시마다 Parse를 위한 CPU 시간을 소모하는 것을 확인할 수 있습니다. 실제 자바로 구현된 엔터프라이즈급 사이트에서 Statement의 사용으로 인해 DB 서버의 리소스에 문제가 발생했고 이를 PreparedStatement의 사용을 통해 현저히 개선한 사례가 있었습니다. 물론 코드 구현상 PreparedStatement의 사용이 거의 불가능한 경우도 있습니다. Runtime에 SQL이 결정되는 경우가 있을 수 있기 때문이죠. 이런 경우는 불가피하게 Statement를 사용할 수 밖에 없겠지만, 이런 특별한 경우가 아닌 이상 무조건 PreparedStatement를 사용하셔야 합니다. 중소형 사이트의 경우라면 위의 논리가 별로가 없을 수 있습니다. 하지만 지금 DB서버의 CPU 사용율로 인해 어려움을 겪는 사이트가 있다면 바로 Statement를 PreparedStatement로 바꾸어 보십시오. 아마도 DB의 CPU 사용율이 절반으로 떨어질 수도 있을 것입니다. 도움이 되시길...

제목 : Re: 적절히 구별해서 사용해야 하지 않을까요? 글쓴이: 손님(guest) 2003/09/15 11:28:09 조회수:1487 줄수:27

Statement나 PreparedStatement 중에 굳이 하나만 선택해서 사용해야 할까요? PreparedStatement가 분명 Statement보다 성능향상에 도움이 되기는 합니다. 하지만 매번 그러한 성능 향상을 기대할 수 없습니다. 같은 쿼리 문장을 만들어 테스트를 해보게 되면 처음 몇번의 쿼리에는 Statement가 더 빠른 속도를 보입니다 하지만 쿼리의 반복횟수가 늘어나게 되면 분명 PreparedStatement가 더 빠른 속도를 보입니다. 무슨 말이냐 하면 자주 사용하는 쿼리같은 경우에는 PreparedStatement 를 사용하면 좋지만 자주 사용하지도 않는 쿼리를 굳이 PreparedStatement 를 사용해서 작성할 필요가 없다는 얘기죠. 이전에 외국자료중에(지금은 그 문서가 없네요..죄송합니다) 오라클로 이 두개를 비교한 자료가 있었는데 이 문서에서는 PreparedStatement는 75번(?) 이상의 쿼리를 던질때나 유용하다고 하더군요 그리고 디비에서 PreparedStatement 에 의한 쿼리문을 캐싱하는데는 한계가 있습니다. 그 캐싱사이즈가 무한정 많은 것도 아니기 때문에 PreparedStatement 를 너무 자주 사용하게 되면 정작 PreparedStatement로 성능향상을 꾀할 부분에서는 캐싱되지 않아 속도향상을 느낄 수 없다는 겁니다. 즉 자주 사용되는 곳에는 PreparedStatement 를 가끔 사용되는 곳에는 Statement를 사용해야겠죠. 테스트한 자료가 있으면 첨부하면 좋겠지만 없네요..^^;;

제목 : Re: 쿼리의 재사용.. 글쓴이: 손님(guest) 2003/09/15 22:50:11 조회수:1706 줄수:24

statement가 75번? <-단순히 자바의 입장만에서만 바라봤을때입니다. 예를들어 preparedstatement로 바인드 변수써서 sql을 실행시키고 나면, 해당 쿼리와 실행계획은 캐쉬에 남아있고, 캐쉬내용과 비교해서 동일하면, 비교없이 막바로 캐쉬에 있던 그대로 수행합니다. 엄청나게 빠릅니다.. 75번.. <-단순히 자바의 입장에서의 비교겠죠.. 히트수를 생각하고 쿼리를 작성하고, 몇번실행되지 않을때는 굳이.. 라는 정도로, prepared, statement를 가지고 옥신각신 하는게 아니라, 성능을 요할 때를 두고 얘기하는 것임을 다시 한번 생각해 주시기 바랍니다. 결국 sql은 캐쉬의 힛트율을 기준으로 작성되고, if어쩌고, 조건문을 " " 로 엮기 때문에.. 어쩌고..라는 것은 말할 필요가 없습니다. 이는 모두 약간의 쿼리 최적화로 한개의 쿼리로 힛트율을 상당히 올릴 수 있습니다. 결과적으로 preparedstatement가 좋단 얘기입니다.

제목 : Re: 자바입장이라... 글쓴이: 손님(guest) 2003/09/16 09:10:56 조회수:1608 줄수:22

물론 자바입장에서 얘기하고 있습니다. jdbc가 자바를 위한거니.. 아무리 디비가 빨리처리해도 자바에서 해당 결과를 늦게 준다면 별 소용이 없지않을까요. 다시 말해 자바에서 쿼리를 던지는 거니 자바입장에서 속도를 비교해야 되지 않을까 합니다. 제가 얘기하고 싶은거니 그 히트율이라는 것이 캐쉬에 있을 때 얘기입니다. 만약 캐쉬 사이즈가 4라고 합시다. 이 캐쉬에 a, b, c, d라는 쿼리문이 있다고 합시다 이 쿼리문들은 모두 PreparedStatement에 의해 캐쉬되어있다고 하겠습니다. 이때 다른 ps가 e라는 쿼리를 캐싱합니다. 하지만 이미 abcd라고 꽉 찼기 때문에 캐싱할 수 없습니다. 그래서 히트율이 낮은 b라는 쿼리를 캐쉬에서 지우고 e를 캐시에 올립니다. 이때 클라이언트에서 b쿼리를 시도합니다. 또 다시 캐쉬사이즈에서 히트율이 낮은 쿼리를 내리고 새로운 쿼리를 올리겠죠. 비록 극단적일 수도 있는 예이지만 제가 하고 싶은 말은 여기에 다 있습니다. 자주 사용되지 않는 쿼리를 다 캐쉬에 올리게 되면 성능이 향상되기보다는 오히려 떨어진다는 거죠 또한 한번 실행되는 쿼리를 Statement와 PreparedStatement로 돌렸을 때 그 성능이 비슷하거나 Statement가 더 빠르게 나타납니다. 극단적으로 어느 한쪽이 좋은게 아니라 적절히 사용할 경우 최적의 성능을 낼 수 있다는 얘기를 하고 싶습니다.

제목 : Re: 파싱 타임과 전체 수행시간의 비율 글쓴이: 박영록(poci) 2003/09/18 13:25:06 조회수:3179 줄수:17

PreparedStatement가 '경우에 따라' Statement보다 나은 성능을 보이는 것은 맞습니다만 그렇다고 획기적인 속도 향상을 가져올 수 있는 것은 아닙니다. PreparedStatement가 줄여주는 것은 파싱 타임 뿐인데 평균적으로 파싱 타임은 전체 SQL 수행시간에서 그다지 큰 비율을 차지하지 않습니다. 1%도 안되는 경우도 많죠. 이걸 줄인다고 급격하게 성능이 향상되진 않습니다. 물론 쿼리 자체가 복잡해서 파싱 타임은 오래 걸리지만 테이블 크기가 작고 fetch해야할 양이 적은 경우라면 성능 향상이 적지 않겠죠. 그리고, Statement라 하더라도 여전히 같은 SQL은 많이 발생합니다. 일반인을 상대로 서비스하는 웹사이트일수록 더 그렇죠. 일반적으로 PreparedStatement보다 Statement가 더 나은 실행계획을 만들어준다는 점을 고려한다면 PreparedStatement로 인해 더 성능이 악화되는 경우도 있을 수 있습니다. 글을 쭉 읽다보니 무조건 PreparedStatement가 좋다는 식의 이야기가 많이 나오는데 경우에 따라 다른 문제고 정확한 벤치마크 없이 이야기할 수 있는 문제는 아니라고 봅니다.

제목 : Re: 한번 더 강조... 글쓴이: PSM(guest) 2003/09/19 11:26:07 조회수:1928 줄수:31

자바 개발자가 자바의 입장에서 어플리케이션을 접근하려고 하는 것은 당연하다고 생각합니다. 따라서 Statement, PreparedStatement를 자바의 입장에서 보면 별반 차이가 없습니다. 사용방식상의 차이겠지요. 그리고 간단한 프로그램 열번 스무번 던져서 수행시간을 계산해도 별 차이 없습니다. 따라서 자바 개발자의 입장에서는 둘중 어떤것을 사용해도 무방하다는 결과에 이를 수 있습니다. 하지만 자바 어플리케이션만 가지고 시스템이 구현되는 것은 아니지요. 동일한 현상을 오라클 DBA가 DB서버 입장에서 판단한다면... Statement를 사용하는 경우, PreparedStatement를 사용하는 경우보다 엄청나게 비효율 적인 처리를 하는 것을 쉽게 볼 수 있습니다. Statement를 통해 동일한 SQL을 날린다고 Parsing이 되지 않습니까? 동일한 변수를 사용한다면 그럴지 모르겠군요. 하지만 조건이 변하는 순간 오라클에서는 동일한 SQL로 인식하지 않습니다. DB에서 그렇게 처리하도록 미리 설정을 해야 한다는 이야기지요. 즉, DB에서 조건절의 변수를 bind 변수로 처리하도록 해야 한다는 의미입니다. 이는 자바 프로그램에서 PreparedStatement를 사용 해야 한다는 이야기입니다. 기억이 좀 가물거리는데, 오라클의 system 계정으로 SQL 로그인해서 Dictionary중 *sql_text* 비슷한 이름의 오브젝트를 조회하면 오라클 기동이후 Parsing되어 처리된 모든 SQL문장을 볼 수 있습니다. Statement를 사용하면 동일한 SQL일지라도 변수가 다르므로 이 Dictionary에 엄청나게 쌓여 있습니다. 만명의 사용자가 로그인하기 위한 SQL은 변수가 서로 다른 1만개일 것이므로 1만번의 Parsing이 일어나겠지요. 이는 바쁘게 돌아가는 DB서버에 엄청난 부하입니다. 놀고 있는 DB서버의 Parsing 시간을 보고 별거 아니라고 생각하시면 안됩니다. 자세한 것은 저보다 DB지식이 많은 오라클 DBA를 통해 확인하시면 명확하게 인식하실 수 있습니다. 수고하세요...

제목 : Re: 이 이야기는 끝이 없네요.. 글쓴이: 손님(guest) 2003/09/19 17:35:11 조회수:1389 줄수:26

1. Statement, PreparedStatement 중 어느걸 쓰는게 좋은지 글을 올린다. 2. PreparedStatement 의 장점에 대해 나열하고 PreparedStatement 가 Statement 보다 좋다고 답변을 한다. 그래서 PreparedStatement 만 써야 한다고 답변을 한다. 3. PreparedStatement 는 Statement 보다 무조건 적으로 좋을 수 없는 이유에 대해 설명하고 적당히 조절해야한다고 말을 한다. 4. 그래도 다량의 데이터 처리에는 PreparedStatement 가 좋기 때문에 PreparedStatement 를 사용해야 한다고 이야기 한다. 나원.. 이야기는 끝이 없네요.. 그런데. Statement 의 효용성에 대해 이야기 하는 분은 적절히 PreparedStatement 와 섞어 써야 한다고 이해되는 반면 PreparedStatement 를 써야한다고 주장하는 분들은 PreparedStatement 만 써야 한다고 이해되는데 저만 그런건가요? 10만건의 데이터를 update 하는데 Statement 를 쓰거나 1건의 데이터를 select 하는데 PreparedStatement 쓰는게 이상한거 아닌가요? Statement, PreparedStatement 의 효용성에 대해 이해를 하고 이걸 어디에 써야 하는지 의논해야지 맞는거라고 생각합니다. 이제 이런 논쟁은 끝으로 하면 좋겠습니다. 이미 두가지의 성능에 대해 잘 안것 같거든요.

제목 : Re: 손님께서도 아직 다 이해하지는 못하신 듯 하네요. 글쓴이: 서민구(4baf) 2003/09/19 18:20:26 조회수:1764 줄수:15

데이터 페치량과 SQL파싱과는 무관합니다. SQL은 parse - execute - fetch 순으로 돌아갑니다. fetch 와 parse는 무관합니다. 아직 두가지의 차이에 대해서 알게 되신 것 같지는 않네요. fetch에 대해서 언급하고 싶다면 차라리 첫번째 퍼올리는 데이터량을 규정하는 파리미터에 대해서 이야기하는게 맞겠죠. 한발 물러서서 이곳에서 언급된 참고문서(오라클 메뉴얼, javaperformance.com, ibm 등)를 읽어보기로 하는게 나을듯합니다. 그리고 글은 그만올리고요. (아무래도 누군가 이길것(?) 같지는 않네요..) p.s. 오라일리 자바 퍼포먼스 튜닝 2판에 statement/prepared statement를 각각 언제 써야하는가에 대해서 언급하고 있고, 대용량 데이터베이스 솔루션에서도 언급하고 있습니다. 둘다 한가닥 하는 사람들이 한 얘기들이라 찾아보시면 도움이 될것입니다.

제목 : Re: 어떤 경우에 어떻게 쓸것인지.. 간단히 테스트를..  글쓴이: 손님(guest) 2003/09/25 11:23:40 조회수:1442 줄수:16

제가 지금까지 사용해본 DBMS는 Oracle, MsSQL 밖에 없어서.. 뭐라구 확실히는 말을 못하겠습니다.. 상황에 맞게 사용한다는 게 가장 좋은 표현인거 같긴 하지만.. 간단하게 테스트 해본 결과로는 같은 쿼리에 대해서도 DBMS마다 다르다는 거죠.. MsSQL 같은 경우 Statement가 PreparedStatement보다 조금이나마 빠르죠.. 그러나 Oracle경우는 둘다 차이가 나지 않는 결로 알고 있습니다.. 한마디로 Query를 저장해서 사용해야 한다면 PreparedStatement를 사용하시구요.. 단지 한번만 실행 시키는 쿼리 일경우는 Statement를 사용하는 것이 좋을것 같습니다.. 물론 DBMS도 충분히 고려 해야 겠죠.. 가장 좋은 방법은 평소에 사용하는 DBMS에 대해서 항상 테스트를 해 보는 습관을 가지는 것이 가장 좋을 듯 하네요.. 초보 프로그래머의 헛소리 였습니다.

제목 : Re: 어따써야할까나 글쓴이: 정구범(powerbox) 2003/09/25 16:45:54 조회수:1586 줄수:19

제가 그동안... Sybase, Informix, Oracle, MySQL, MS-SQL 등을 써서 프로젝트를 해본 경험으로는... Statement와 PreparedStatement는 공존해야 합니다. 딱부러지게... 너 이것만 써라... 라고 하면 아마도 PreparedStatement를 권장합니다만... Statement 사용이 더 좋은경우 1. DB에서 뽑아낼 필드를 매번 변경해야 하는 경우 (환경이 매우 동적인 경우) 2. 다량의 insert, delete를 섞어서 한번에 트랜잭션으로 처리하되, 배치로 하는경우 나머지는 사실 PreparedStatement가 더 효용성이 좋다는 결론이 나온다는거... 윗분들이 다 얘기해서 더 할말 없습니다. 이건 제 경험상으로 나온 추정일뿐입니다... 구냥 참고하시길...

제목 : Re: CallableStatement에 대해서.. 글쓴이: 4baf(guest) 2003/09/29 11:25:33 조회수:2139 줄수:11

제 생각으로는 CallableStatement가 코딩량을 늘이지는 않는 것 같습니다. 복잡한 로직을 java에서 보두 코딩한다면, 코딩량이 정말 많거든요.. 가령 이테이블에서 번호를 빼오고 저기에 업데이트하고 다시 select하고 등등을 java에 모두 코딩하면 길이가 많이 길어집니다. 제 경험상 그렇다고 생각합니다. CallableStatement의 단점이라면, DB independent하다는 점과 DB측의 언어 하나를 더 배워야하는 점이라고 생각됩니다. 코드가 길어지지는 않는다고 생각합니다. 장점으로 추가한다면, 네트워크 통신량이 적어집니다. (클라이언트가 모든일을 하지 않는다는 것과 상통)

제목 : Re: 오타 수정(DB independent -> DB dependent) 글쓴이: 4baf(guest) 2003/09/29 11:26:50 조회수:1262 줄수:1

죄송합니다. PC실이라서 로그인을 안해서 수정을 할 수가 없네요.

제목 : Re: PreparedStatement 의 성능에 대해 테스트가 필요할 것 같습니다. 글쓴이: 석기명(guest) 2003/09/30 09:18:37 조회수:1517 줄수:32

답글들을 보면 하나의 쿼리에 대해 반복적으로 테스트 한것을 볼수 있는데 javaService Net 처럼 1. http://www.javaservice.net/ 을 입력후 전체 게시판을 조회한다. select 어쩌구1 from 저쩌구11 2. 특정 게시물을 클릭한다. select 어쩌구2 from 저쩌구22 3. 다시 특정 게시물의 리스트를 조회한다. select 어쩌구2 from 저쩌구33 4. 특정 게시물을 클릭한다. select 어쩌구2 from 저쩌구22 5. 답변을 쓴다. insert .... 이런 식으로 쿼리문이 이곳 저곳에서 수행이 될텐데 1. 반복되는 쿼리의 기준은 어떻게 정의해야 하는지 2. 반복되는 쿼리를 캐쉬하는 캐쉬사이즈가 한계에 도달할 경우 이것을 처리하는 비용은 수행시간에 어느 영향을 미치는지 3. Statement 와 PreparedStatement 를 혼합해서 사용할 경우 수행시간에 어느 영향을 미치는지 결국 단순히 쿼리문을 반복수행하는건 의미가 없다고 생각되는데 다른분을의 의견이나 테스트 결과를 알고 싶습니다.

제목 : Re: 캐쉬문제에 대해서... 글쓴이: 석기명(guest) 2003/10/04 14:02:33 조회수:1415 줄수:28

좋은 기억 때문에 현실을 만족하지 못하고 나쁜 기억 때문에 현실에 고통을 주기 때문에 시간이 흐른 기억은 없어지게 됩니다. 시간이 지날 수록 기억하는 데이터가 증가되서 이것에 대한 처리방법에 대해 허덕이고 있을 가능성이 있는 모든 쿼리를 기억하고 있는 컴퓨터가 좋은 컴퓨터일까요? 그렇다고 해서 캐쉬의 무용론을 말하고 있는건 아닙니다. 적당한 캐쉬는 성능향상에 도움을 주는건 맞습니다. 하지만 그 적당한의 기준은 정의할 수 없는것은 잘 알고 있을겁니다. 따라서 이런 경우에는 PreparedStatement 를 쓰는것이 저런 경우에는 Statement 를 쓰는것이 효율적이다 라고 나오는 테스트를 통해 이야기 하는것이 맞지 않을까요? 이론상으로는 1+1 은 2가 맞습니다. 하지만 현실은 1 이 될 수 있고 3 이 될 수 있고 11 도 될 수 있습니다. 소금에 소금을 더하면 소금이 되고 남자와 여자를 더하면 자식이 생겨 3이 된다. 라고 이론을 현실에 적용했을때 나오는 결과에 대해 이야기 해본다면 반복되고 소모적인 논쟁은 피할 수 있을 것이라 생각합니다.

제목 : Re: 제가 말하고자 하는 것은 글쓴이: 석기명(guest) 2003/10/04 18:42:16 조회수:2170 줄수:34

물의 온도가 50 인 두 양동이를 커다란 양동이에 담아도 물의 온도는 50이 되지 않습니다. 옮겨 담는동안 온도가 빠져나가기 때문입니다. 이론으로 한다면 50이 되어야 하겠죠? 제가 말하고자 하는건 온도가 빠져나가는 이유와 50도를 맞추기 위해서 빠져나간 만큼 온도를 보충하는 방법 즉 이론을 실제 업무에 적용되었을때의 사례와 처리경험을 이야기 하자는 것이었습니다. 그리고 제가 쓴 윗 글에서 "적당한 캐쉬는 성능향상에 도움을 주는건 맞습니다. 하지만 그 적당한의 기준은 정의할 수 없는것은 잘 알고 있을겁니다." 에서 캐쉬의 효과나 PreparedStatement 의 사전 컴파일의 효과에 대해 기대를 안한다라는 뜻으로 쓴건 아니었습니다. 다시말하면 PreparedStatement 장점인 컴파일을 통한 파싱과정을 캐쉬에 보관하여 재사용하는 방법은 효과적이지만 실제 업무에 적용시켰을때의 성능향상이 어느정도 이루어 지는가 입니다. 반복되는 작업이 많아 캐쉬를 쓰면 효율적이다 라는게 A 이론이고 반복되는 작업이 없을 경우 캐쉬를 쓰면 비효율적이다 라는게 B 이론이라면 반복되는 작업과 그렇지 않은 경우가 섞여 있을 경우 효율에 대해 어떻게 정의를 해야 할까요? PreparedStatement 과 Statement 의 성능비교에서 제가 답답해 했던건 이론만 가지고 책에 나와있는것을 가지고 자기의 의견을 주장한다는 것입니다. 그것을 실제로 구현했을때 나오는 결과와 구현방법에 대해 이야기 해본다면 단순히 어느게 좋다 라고 싸우는 것보다 효율적이지 않겠느냐 라고 생각해서 글을 쓴것입니다.

제목 : Re: static sql과 dynamic sql의 성능 차이 글쓴이: 박영록(poci) 2003/10/05 03:18:42 조회수:1913 줄수:91

prepared statement에서는 보통 변수를 설정하고 바인딩하는 static sql이 사용되고 statement에서는 쿼리 자체에 조건이 들어가는 dynamic sql이 사용됩니다. prepared statement가 파싱 타임을 줄여주는 것은 분명히 중요한 장점입니다. static sql을 사용하는데 따르는 퍼포먼스 저하를 생각하지 않을 수가 없습니다. 이를테면 이런 예가 있을 수 있습니다. dynamic sql을 사용하는 경우 자바에서 다음과 같은 SQL을 생성했다고 가정해봅시다. SELECT ... FROM TAB1 WHERE COL1 LIKE '%' AND COL2 LIKE '%' AND COL3 LIKE 'ABC%' 그리고 인덱스가 COL1 + COL2 + COL3 로 걸려 있습니다. 그렇다면 실행 계획은 당연히 인덱스에서 COL3 컬럼만을 액세스하게 설정될 것입니다. 그런데 다음과 같은 static sql을 봅시다. SELECT ... FROM TAB1 WHERE COL1 LIKE :A || '%' AND COL2 LIKE :B || '%' AND COL3 LIKE :C || '%' 이런 식으로 SQL을 작성했다고 합시다. A, B, C에 어떤 값이 들어올지 모르니까 인덱스의 COL1, COL2, COL3 컬럼을 차례대로 스캔하도록 처리 경로가 잡힙니다. 그런데 조건으로 A, B는 NULL, C에는 'ABC'라는 값이 들어왔습니다. COL3 컬럼만 랜덤으로 액세스해서 테이블로 가면 될 것을 인덱스 풀스캔을 해버립니다. 이와 같이 static sql은 변수에 어떤 값이 바인딩되는지를 알 수 없기 때문에 가장 일반적인 형태로 실행 계획을 작성합니다. 때문에 통계 자료를 제대로 활용할 수 없고 인덱스 활용 등에서 비효율이 발생할 확률이 높아집니다. 이런 예는 정말로 많습니다. 이를테면 TABLE1의 COL1의 분포도가 값이 'A'인 게 100건, 'B'인 게 100만 건 있다고 할 경우, COL1 = :VAR 와 같이 바인딩을 시켜놓으면 늘 풀스캔을 하게 실행계획을 잡습니다. 그런데 :VAR에 'A'가 들어가는 경우 인덱스를 타면 금방 결과가 나올 것을 풀스캔 후에 결과를 리턴하게 되죠. static sql의 활용으로 파싱 타임을 절약해서 매번 실행 계획을 작성하는 것을 피하는 대가로 좀더 비효율적인 실행 계획이 수립된다는 것이죠. 일반적으로 SQL의 실행과정에서 파싱과 실행 계획 수립 과정은 전체 SQL 수행 시간에서 큰 비중을 차지하지 않습니다. 가장 큰 비중으로 차지하는 것은 테이블에서 로우를 가져오는 과정이고 파싱 시간은 이의 10분의 1에 불과합니다. 그런데, 이 10%의 시간을 줄이자고 90%의 시간에서 비효율이 발생하게 만드는 일이 생길 수 있습니다. 물론 쿼리 생성 단계에서부터 어느 정도는 해결할 수 있는 문제입니다만, 그로 인해 자바 코드와 SQL이 복잡하게 얽히는 문제도 결코 작은 문제가 아니죠. 그리고, statement가 정말로 재활용되지 않느냐..를 놓고 보면 이것도 재론의 여지가 많습니다. 사이트에 따라 판이하게 다릅니다. 실제로 사용자가 많고 로직이 단순한 사이트는 조건까지 똑같은 한두 가지 SQL이 전체의 50% 이상을 차지하는 경우도 많습니다. 이런 경우는 캐시에 들어가서 안 나오죠-_- 웹에서 대부분의 사람들이 첫 페이지 이상을 보지 않는다는 점을 감안하면 매번 달라지는 SQL은 그리 많지 않을 수 있습니다. 이론은 정말 중요한 것입니다. 그러나, 제가 보기에 지금 PreparedStatement의 성능이 더 낫다고 주장하시는 분들의 이론이 어느 정도 타당성이 있는지는 의문이 많이 듭니다. 더군다나 경우에 따라 더 낫다를 넘어서서 Statement를 대체해도 될 정도로 PreparedStatement가 유리하다고 말씀하시는 분이 많은대도 불구하고 어느 분도 PreparedStatement의 정확한 구현이 어떻게 되는지, 데이터베이스에서 어떻게 처리를 해주는지, 어떤 방식으로 테스트 해보았고 그 결과가 어떠했는지를 말씀해주시는 분이 없습니다. 검증 과정을 거치지 않은 이론은 그만큼 신뢰도가 떨어질 수 밖에 없습니다. 얼마전 대용량 데이터베이스 I, II를 모두 수강했습니다. 강사분께서 계속 강조하는 말씀이 두 가지가 있었습니다. 첫째는 원리를 이해하고 이론적으로 따져보는 것이 중요하다는 것, 그리고 둘째는 이론적으로 따져서 작성한 SQL에 대해 반드시 실행 계획을 떠보라는 것이었습니다. 상반되는 이야기인 것처럼도 보이고 일반적인 이론과 경험의 조화를 말하는 것처럼도 보이지만 저에게는 이론적인 체계를 먼저 잡아나가고 원리를 따져본 다음에 그 이론을 검증해보라는 말로 들렸습니다. PreparedStatement도 그처럼 논해야하는 일이 아닐까요? 우선 Statement와 PreparedStatement의 코드부터 뜯어보고 이것이 데이터베이스에 연결되면 데이터베이스가 어떻게 처리를 하는지도 알아보고 그렇게 분석한 이론에 따라 테스트 시나리오를 구성해서 벤치마크 테스트까지 해봐야 정확한 성능 분석이 될 것입니다. 단순히 두 가지를 사용하는 레벨에서만 분석하는 것으로는 정확한 이론조차 만들 수 없습니다. 마지막으로 한 가지 더, 정말 PreparedStatement가 Statement를 거의 다 대체해도 될 정도로 좋다면 Statement는 대체 왜 만들었을까요? 그냥 프로그래머 편하라고? 그냥 데이터베이스 연결 테스트 해볼 때 써먹으라고? 혹시나 PreparedStatement가 Statement보다 좋지 못한 성능을 내는 구현체가 있을 수 있으니까? 이번 기회에 자바서비스넷에서 제대로 된 퍼포먼스 테스트를 해보는 것은 어떨까요?

제목 : Re: 박찬우님에게 질문 합니다. 글쓴이: 석기명(guest) 2003/10/06 16:40:08 조회수:1384 줄수:9

테스트의 경우를 통해 PreparedStatement 와 Statement의 실제 성능의 차이를 비교하자고 하는것이 PreparedStatement 의 이론은 무시를 하는거라고 생각하시는 건지 궁금합니다. (글의 어느부분에 그런 뜻이 있는지 알려주시면 더욱 감사하겠습니다만..) 제가 말하고 싶은 이야기는 박영록 씨가 잘 설명해 주셨기 때문에 더 이상 하지 않겠습니다. (이후 개인적인 문의는 메일로 해주시기 바랍니다.) 소모적인 논쟁은 그만 하기를 바랍니다.

제목 : Re: Static SQL과 dynamic SQL의 차이점은? 글쓴이: 사랑전쟁(lovewar) 2003/10/07 19:45:28 조회수:1523 줄수:28

>prepared statement에서는 보통 변수를 설정하고 바인딩하는 static sql이 사용되고 >statement에서는 쿼리 자체에 조건이 들어가는 dynamic sql이 사용됩니다. Static SQL과 dynamic SQL의 차이점에 대해서 알려 주시면 좋겠습니다. Dynamic SQL이란 실행시에 table, column(?) 또는 column의 값이 결정되는것으로 알고 있습니다[sql92, sql99]. 그리고 궁금한것이 하나더 있는데요. prepared statement와 static SQL는 무슨 관계가 있는지도 알려 주시면 좋겠습니다. 디비에 대해서 자신있게 이야기 못하는것이 안타깝지만, 혹시나 제가 잘못 이해하고 있는것 같아 글을 기제합니다. 그리고 마지막으로 인덱스에 관한 내용인데요. 기본적인 전략이 순차검색아닌가 해서요. 이것은 디비마다 다르겠지만, 인덱스 설정(오라클의 Create Index)해주는것에 한해서 랜덤하게 움직이는것이 아니지 이것도 궁금합니다. --덧붙이는 글 -- 참고로 sql 관련 자료와 prepared statement에 대한 자료를 첨부합니다. http://database.sarang.net/database/sql/sql.html http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html

제목 : Re: 용어 상의 혼돈이 있는 것 같습니다. 글쓴이: 서민구(guest) 2003/10/08 00:26:46 조회수:1432 줄수:68

인용하신 글에서 얘기하신대로 dynamic sql이란 말을 썼지만, 거기서는 실행계획이 매번 새로 생성된다는 의미입니다. 그리고 사랑전쟁님이 얘기하신건 오라클의 DBMS_SQL 패키지나 NDS 가 수행하는 동적인 SQL문 생성입니다. DB내에서요. >> prepared statement와 static SQL는 무슨 관계가 있는지도 알려 주시면 좋겠습니다. 이건 prepared statement의 경우 실행계획이 매번 재사용된다는 의미입니다. 그건 당연하죠. 한번 파싱하면서 실행계획을 만드니까요. 그러나 DB내에서도 CBO(비용기반 최적화)를 사용한 경우라면 테이블에 대한 통계정보가 바뀜에 따라서 실행계획이 invalidate되기때문에 무조건 재사용된다 이런것은 아닙니다. RBO(규칙 기반 최적화)의 경우도 테이블 자체의 modification이 일어나면 SQL이 invalidate됩니다. >>그리고 마지막으로 인덱스에 관한 내용인데요. >>기본적인 전략이 순차검색아닌가 해서요. 이것은 디비마다 다르겠지만, >>인덱스 설정(오라클의 Create Index)해주는것에 한해서 랜덤하게 움직이는것이 >>아니지 이것도 궁금합니다. 그건 아니고요. DB마다 다르겠지만 (전 아는것이 오라클 밖에 없습니다. 페이퍼 DB2 자격증이 있긴 하지만 자세히는 모름), 과거에는 RBO를 썼습니다. 그러니까 규칙기반 최적화를 썼습니다. 오라클 메뉴얼을 뒤져보면 나오지만, 인덱스가 있으면 인덱스를 쓰고 뭐 어떻게 되면 어떤 식으로 조인하고 이런 규칙이 정해져있고 점수를 줘서 실행계획중 최상의 점수를 받은 방식으로 데이터를 접근하게 됩니다. CBO를 사용한 경우라면 비용을 산정하고, 그 비용에 따라 움직입니다. RBO의 경우는 인덱스가 풀 테이블 스켄보다 무조건 우선하는 반면 CBO의경우에는 - 인덱스를 사용한 접근은 테이블의 10~15% 이상의 데이터를 접근하는 경우 풀 테이블 스켄보다 느립니다 - 무조건 인덱스가 있다고 인덱스를 쓰는것이 아니라, 실제 비용을 추정해보고 그 추정치에 따라 움직입니다. 최근에는 DB가 하도 발달하다보니 SQL의 캐시 원칙에 대해서도 조작의 범위가 넓어졌습니다.. 그리고 하는 것도 많고.. 오라클 홈페이지에보면 아마 SQL문 실행방법에 대한 whitepaper가 있습니다. 어떻게 분석하고 실행되는가를 다룬 글 말이죠.. (제목은 "Query Optimization in Oracle9i" 입니다.) 제 개인적인 의견은 prepared statement를 쓰더라도 CBO를 사용하고 비용을 적시에 산정하는 스크립트를 활용하고 있다면 prepared statement 를 쓰는게 낫다고 생각합니다. 그러나 사실은 그렇게 까지 하는 경우는 드물죠. 단지 응답 시간이 느린 쿼리에 대해서만 힌트를 주고 FIRST_ROWS로 OPTIMIZATAION_GOAL을 설정할텐데, 그렇게 힌트를 썼다는 것 자체가 데이터 속성 변화에 대해서 앞으로 신경 안쓰겠단 것입니다... 결과적으로 그런 경우에도 prepared statement가 역시나 낫다고 생각하고요. 저도 캐시에 대해서도 의문을 제기하고 테스트를 해보는게 좋을 거라고 생각은 합니다. 하지만 LRU 를 사용해서 캐시가 돌아가고 있고, rule of thumb(혹은 pareto law)는 정말 긴 시간동안 검증된 것입니다. 캐시가 오히려 성능을 저하시키는 결과가 나온다 하더라도 그건 그 머신의 그 테스트에서만 그것이 증명된 것일 뿐이 아닐까 생각합니다.. 그래서 벤치마킹이란게 무의미 할 수 있죠.. 그런 이유로 알고리즘의 성능 분석도 big-oh를 사용하고, 데이터 크기의 변화에 대한 시간의 변화 추세만 분석하는게 아닐까요... 원하든 원하지 않든 DB에선 열심히 캐싱을 하고 있습니다. 단지 실행계획 뿐만 아니라요. 만약 default 로 놓고 시스템을 사용하고 있다면, 이미 대부분의 데이터들이 다 캐시에 들어가고 있습니다. 정말 원하신다면 일일히 이런것들을 조작하고 캐시의 재활용 시간을 조정할 수도 있지만 (기억이 가물가물하지만 3가지 이상으로 데이터의 캐싱 policy를 줄 수 있습니다) 그게 가능한 일인지는 잘 모르겠습니다. DB앞에 앉아서 DB 튜닝만 할 수 있게 여유가 있지는 않잖습니까.... 저도 게시판 질의 튜닝에 관심이 많아서 항상 constant time내에 질의가 끝나는 방식으로 토론 게시판같은 것을 작성해보았지만, 별로 알아주는 사람도 없고, 사실 사용자도 적어서 별 효과가 없더군요... 일일히 테스트 해보고 데이터에 대한 캐시방식부터, 세그먼트, 클러스터 크기의 조정, 리두로그 조정, 아카이빙 하는 시간간격 조정, 그리고 늘 인덱스 검사해서 depth 4넘어가면 rebuild 하기 기타 등등.. 이런것 다 하려면 정말 끝이없습니다.. 적당한 선에서 캐시를 믿으셔도 될 것 같습니다... 쓰고나니 괜히 썼다 생각도 드네요.. 속좁은 개인적인 의견입니다..

제목 : Re: 저두 질문.. 글쓴이: 박영록(poci) 2003/10/08 00:46:14 조회수:1206 줄수:33

>제 개인적인 의견은 prepared statement를 쓰더라도 CBO를 사용하고 비용을 >적시에 산정하는 스크립트를 활용하고 있다면 prepared statement 를 쓰는게 >낫다고 생각합니다. 그러나 사실은 그렇게 까지 하는 경우는 드물죠. 단지 >응답 시간이 느린 쿼리에 대해서만 힌트를 주고 FIRST_ROWS로 OPTIMIZATAION_GOAL을 >설정할텐데, 그렇게 힌트를 썼다는 것 자체가 데이터 속성 변화에 대해서 >앞으로 신경 안쓰겠단 것입니다... 비용을 적시에 산정하는 스크립트..란 게 뭐죠? static sql이라도 cost에 따라 실행계획을 재수립하게 만드는 그런 건가요? CBO야 어차피 대부분 CBO로 쓸 테고(오라클 말고는 RBO를 지원하지도 않죠.) OLTP라면 힌트 차원이 아니라 아예 FIRST_ROWS를 옵션으로 설정해두게 될 테니 일반적으로 접하는 상황과 크게 다를 게 없는데 비용 산정 스크립트는 어떤 건지 궁금하네요. >이건 prepared statement의 경우 실행계획이 매번 재사용된다는 의미입니다. >그건 당연하죠. 한번 파싱하면서 실행계획을 만드니까요. 그러나 DB내에서도 >CBO(비용기반 최적화)를 사용한 경우라면 테이블에 대한 통계정보가 바뀜에 >따라서 실행계획이 invalidate되기때문에 무조건 재사용된다 이런것은 아닙니다. >RBO(규칙 기반 최적화)의 경우도 테이블 자체의 modification이 일어나면 >SQL이 invalidate됩니다. 이건 static sql의 맹점을 해결해준다는 뜻에서 적으신 건 아니죠? 어차피 static sql의 비효율은 테이블이 변경되지 않아도 발생하니까 말입니다. >저도 게시판 질의 튜닝에 관심이 많아서 항상 constant time내에 질의가 끝나는 >방식으로 토론 게시판같은 것을 작성해보았지만, 별로 알아주는 사람도 없고, >사실 사용자도 적어서 별 효과가 없더군요... 저두 여기에 관심이 많습니다. 요즘 개인적으로 커뮤니티를 하나 작업하고 있는데 역시나 게시판이 제일 신경이 쓰이네요. 서민구님의 작품을 한 번 감상해봤으면하는 소망이.. 그냥 돌아가는 모습이라도 구경할 수 있게 해주시면 감사하겠습니다.

제목 : Re: 박영록님께 글쓴이: 서민구(guest) 2003/10/08 01:32:35 조회수:3955 줄수:44

>비용을 적시에 산정하는 스크립트..란 게 뭐죠? static sql이라도 cost에 따라 실행계획을 >재수립하게 만드는 그런 건가요? >CBO야 어차피 대부분 CBO로 쓸 테고(오라클 말고는 RBO를 지원하지도 않죠.) >OLTP라면 힌트 차원이 아니라 아예 FIRST_ROWS를 옵션으로 설정해두게 될 테니 일반적으로 >접하는 상황과 크게 다를 게 없는데 비용 산정 스크립트는 어떤 건지 궁금하네요. analyze table 명령을 말하는 것입니다. analyze가 되면 sql의 실행계획이 모두 바뀝니다. analyze를 안하고 cbo를 한다면 사실상 cbo가 아니죠.. 통계 정보가 있어야 비용을 산정하고 그에따라 프로그램을 실행하니까요.. >이건 static sql의 맹점을 해결해준다는 뜻에서 적으신 건 아니죠? 어차피 static sql의 >비효율은 테이블이 변경되지 않아도 발생하니까 말입니다. 지적하신 부분은 prepared statement를 사용하더라도 analyze를 통해서 테이블을 분석하면 sql이 모두 비용이 재산정된이유로 새로 실행계획을 작성한다고 쓴 것입니다. 게시판은 http://www.encore.co.kr/bin/main/module/solution/list.asp?state=list&board_id =solution&solution_code=&column=TITLE&searchString=%B0%D4%BD%C3%C6%C7 (한줄로 이어서 주소에 입력하시면 됩니다.) 에서 본 아이디어를 그대로 적용하여 만들었습니다. 이 내용을 토대로 게시판을 만들고, 그 내용을 공개하려고 했는데 저작권이 마음에 걸려 원 저자분께 메일을 보냈더니 어느 대학교에서 지금 교수를 하고 계시고 엔코아를 나오셨고, 자기한테 저작권이 없다고 엔코아에 말해보라고 하시더군요.. 엔코아에 메일을 보냈더니 답이 없고요.. 그래서 그냥 포기했습니다... 자바스터디 토론 게시판에 응답글이 없는 게시판의 부분범위처리를 적용하여 게시판을 만들었습니다. 소스를 공개하려고 생각도 했었는데, 운영중인 시스템의 버그가 드러날 수도 있을 것 같아 그것도 할 수가 없더군요.. jsp에서 해킹의 위협은 나름대로 다 막았다고 생각하지만, 제가 생각못한 버그로 인해 피해를 볼 수도 있고 그래서요... 엔코아 글을 참고해보세요.. 사이트가 개편되면서 편집도 잘 되서 보기 좋게 되어있습니다. 그런데 막상 적용할때는 바인딩변수가 너무 많고 쿼리가 너무 길어서 무슨의미인지 생각해보는데 정말 오래걸렸습니다. (그나마 지금은 거의 잊어버렸습니다..) 어쨌건 지금까지 자바서비스넷에서 엔코아에 설명된 방법의 게시판 소스는 본적이 없고, 이와 비슷한 성능을 보일것이라고 예상되는 게시판도 본적이 없습니다. 엔코아에서 설명한 방법의 문제점은 검색기능입니다. 검색에 대한 고려가 없어서.. 검색용 질의는 새로 만들어야할 것 같습니다.

제목 : Re: 또다른 궁금증이 유발되네요.(수정) 글쓴이: 사랑전쟁(lovewar) 2003/10/08 09:54:47 조회수:1239 줄수:38

>>이건 prepared statement의 경우 실행계획이 매번 재사용된다는 의미입니다. >>그건 당연하죠. 한번 파싱하면서 실행계획을 만드니까요. prepared statement 의 경우 JDBC 드라이버에서 파싱해서 그 문장을 디비에 전송 하는것으로 이해하고 있는데요. 이때 실행계획은 디비가 만들고 그것을 캐쉬하는건가요? 아마 이부분은 디비마다 구현이 다를수 있을거란 생각을 합니다. 추가로 볼만한 자료가 있으면 기제해 주시면 좋겠습니다. 제가 이해하고 있는 prepared statement란 statement문과 다를것이 없고, 단지 파싱 타임을 디비서버가 아닌 JDBC 드라이버에서 하는걸로 이해하고 있는데, 혹시 잘못이해하고 있나해서요. 자바 API의 일부를 기술합니다. A SQL statement is precompiled and stored in a PreparedStatement object. This object can then be used to efficiently execute this statement multiple times. -- 덧붙이는 글 -- 기본적으로 SQL문장을 JDBC드라이버에서 파싱하고 SQL의구조를 디비에 보내서 바로 실행에 참여한다. 그럴경우 공통적인 기본 개념이되므로 JDBC드라이버를 만드는 측이나 디비를 만드는측 모두에게 편리(유용)하다할 수 있을것 같은 생각을 합니다. 디비 프로세스의 기본 구조를 변경할 필요는 없으므로 여러가지 장점이 있을것 같습니다. >>prepared statement에서는 보통 변수를 설정하고 바인딩하는 static sql이 사용되고 >>statement에서는 쿼리 자체에 조건이 들어가는 dynamic sql이 사용됩니다. 이경우 오라클에서만 그런건지 아니면 전체 디비엔진들이 일관적으로 그런건지에 대한 설명이 필요할것으로 보입니다(표준 문서에는 정의되어 있지 않습니다). 그래서 prepared statement이 static sql이란 표현은 위험성을 내포하고 있습니다. 또한 statement에 대한 dynamic sql도 맞찮가지입니다. 이부분에 대한 좀더 정확한 설명을 듣고 싶습니다.

제목 : Re: 다시 질문.. 글쓴이: 박영록(poci) 2003/10/08 15:34:36 조회수:1258 줄수:13

제가 static sql의 맹점이라고 제시한 것은 위에서 예로 제시한 것과 같이 똑같은 sql로 똑같은 테이블에 쿼리하더라도 바인드되는 변수값에 따라서 실행계획이 달라지는 것이 효율적인데 그게 안된다는 것이었습니다. 이건 통계정보가 업데이트 안되어서 발생하는 문제랑은 다릅니다. 정확한 통계정보가 나와 있어도 비효율이 발생하는 상황이죠. 오히려 문제는 바인드된 변수를 예측할 수 없기 때문에 통계정보가 있어도 정확한 SQL의 수행비용을 예상할 수 없다는데 있습니다. 제가 궁금했던 것은 디비가 이런 것까지 예상해서 static sql이라도 실행 계획을 여러 개로 준비해두고 있다가 바인드 변수값에 따라 좋은 실행 계획을 실행시켜주는 기능이 있는가..하는 거였습니다. 그런 게 있다면 참 좋을 텐데 말입니다. 하지만 역시 아직은 어려운 일이겠죠?

제목 : Re: 답변입니다. 글쓴이: 서민구(guest) 2003/10/08 17:48:30 조회수:1331 줄수:38

사랑전쟁님께. 캐싱은 2가지가 이루어집니다. 하나는 JDBC 드라이버상에서이고 다른 하나는 DB상에서입니다. 오라클은 DB상에서 캐싱하며, 다른 DB에 대해서 전 모릅니다. JDBC 드라이버상에서의 캐싱은 JDBC의 최신버전(3.0이던가요)부터 지원되고 그 이전에는 지원하지 않았습니다. 확실히 말씀하신대로 표준 같은 것은 없습니다. 저도 사실 DB상의 차이가 제품 상호간의 우열을 가리는 것이니, 모두다 똑같을리는 없을 거라고 생각합니다. 박영록님께. 바인드 변수값에 따라 실행계획을 바꿔주는 예를 수강하셨다던 대용량 데이터베이스 솔루션 강의에서 보았었습니다. (정말 그 쪽 컨설팅하시는 분들 무지하게 똑똑한 사람들이라고 생각합니다.) 강의를 수강하고 계신다니 한번 강사님께 여쭈어보는게 어떨까요. SQL문 한가지로 조건에따라 플랜이 다르게 풀리는 예였습니다. 온라인 강좌(데브피아)에서도 보았는데, 그때 들던 예가 삼성 SDS에서 삼성회사 사람은 많고, 다른 회사 사람은 적을 것입니다. 이 상황에서 삼성 회사 사람을 검색할때는 풀테이블 스캔이 나와야 하고, 다른 회사 사람이 조건일때는 인덱스 스캔이 나오도록 하는 질의를 설명했었습니다. 이런 상황에서 질의 한개로 할 수 있단 거죠. 전번의 prepared statement 에 대한 쓰레드에 올렸던 질의를 다시 인용하겠습니다. SELECT * FROM EXP_TABLE WHERE :id = 'A' AND id||'' = 'A' UNION ALL SELECT * FROM EXP_TABLE WHERE :id = 'B' AND = 'B' 이 경우 A와 B에 대한 질의가 각각 플랜이 다르게 풀립니다. 여기까지가 제 한계인듯합니다. 이 내용을 DB 관련 사이트에서 이야기해보는게 좋을 것 같단 생각이 드네요.

제목 : Re: 참고자료입니다. 글쓴이: 서민구(guest) 2003/10/08 18:07:30 조회수:1520 줄수:15

http://asktom.oracle.com/pls/ask/f?p=4950:8:1493517184285843249 여기서 prepared statement와 statment에 대한 글을 보실 수 있습니다. 이 글의 저자는 WROX에서 나온 expert one on one이라는 책의 저자이기도합니다. 정보문화사에서 번역서도 나왔죠. asktom.oracle.com으로 바로 접속하면 때때로 질문을 할 수 있게 링크가 열립니다. (현재는 질문이 많아서 close 상태입니다.) 그때 또다른 궁금증을 질문하면, 답변을 직접 보내줍니다. 오라클에 관련한 궁금증은 이쪽을 사용하시면 편리합니다.

제목 : Re: 참고 자료입니다. 글쓴이: 사랑전쟁(lovewar) 2003/10/08 20:08:19 조회수:1360 줄수:21

좀더 궁금해서 OTN을 보다가 찾은 JDBC관련 문서입니다. 오라클 9i JDBC에 대한 문서로 JDBC 2.0대의 스펙을 지원하며. 추가적으로 성능에 대한 사항들도 언급되어 있습니다. 12장의 Performance Extensions와 18장의 Statement Caching 부분이 주목되는군요. 또한 이문서에서는 JDBC3.0대에 Statement-caching 에 대한 정의될것으로 되어 있군요. 현재 JDBC는 4.0대의 표준문서가 나와 있는것으로 알고 있습니다. 자세한 사항은 아래 사이트를 참조해 주시기 바랍니다. Oracle9i JDBC Developer's Guide and Reference 입니다. http://otn.oracle.com/tech/java/sqlj_jdbc/pdf/a96654.pdf

제목 : Re: 다른 관점에서의 접근 글쓴이: 지니(guest) 2003/10/09 12:06:42 조회수:1647 줄수:16

저는 반드시라고 할 정도로 prepared statement를 사용하고 있습니다. 많이들 말씀하듯이, statment 보다는 caching에 의한 효율이 낫지 않을까하는 막연한 추측도 있구요.. 하지만, prepared statement 를 사용하는 더 중요한 이유는 보안 때문입니다. statement 의 경우에는 SQL 문장을 만들 수 있기 때문에 보안문제가 발생할 수 있습니다. SQL Injection 이라는 해킹방법 중의 하나입니다. (뭐, 로그인, 허가되지 않은 Data 접근 등 SQL 문을 만듦으로써 얼마든지 가능하죠..) statement를 사용하면서 이를 방지하려면, 이런저런 Check를 해야 하는 데.. 그냥 prepared statement를 사용하면 이런 보안문제는 쉽게 해결 가능하죠..

제목 : Re: 파라메터에 ' 를 입력할 때 문제점을 말씀하시는 건가요? 글쓴이: 석기명(darksw) 2003/10/09 14:55:22 조회수:1421 줄수:11

statment 를 사용하고 있다면 파라메터에 대해서 그냥. ' 를 '' 로 변환시키면 보안 문제나 쿼리 오류를 방지할 수 있을텐데요. (파라메터가 클 경우는 제외 ' 를 '' 로 변환시키는데 시간 문제가 있으니까 제외) 이거 외에 SQL 을 조작해서 해킹하는 경우는 어떤게 있을까요? 아시는분은 글 올려주시겠어요? ps : 윗글은 prepared statement 쓰지 말라는 이야기 아닙니다. --;

제목 : Re: SQL Injection 글쓴이: 서민구(guest) 2003/10/11 12:16:58 조회수:2553 줄수:25

음.. 쓰레드와 별 상관없는 글이지만 어디선가 보게되어 퍼옵니다. SQL injection 막기입니다. Preventing SQL injection from happening is simple once you understand the problem. There are really two strategies you can use to prevent the attacks: • Validate user input • Use parameterized queries Validating user input involves parsing a field to restrict the valid characters that are accepted. In most cases, fields should only accept alphanumeric characters. Also you can escape single quotes into two single quotes although this method is riskier since it is much easier to miss parsing input somewhere. Using parameterized queries involves binding variables rather than concatenating SQL statements together as strings. The biggest challenge will be reviewing and updating all the old CGI scripts, ASP pages, etc… in your web applications to remove all instance of this vulnerability. It is also suggested that you setup a programming guideline for web programmers that includes emphasis on using parameterized queries and not constructing SQL by concatenating strings with input values.

제목 : Re: SQL Injection 글쓴이: 손님(guest) 2004/04/13 15:25:13 조회수:1586 줄수:12

프로젝트 유지보수때 이와 관련된 일을 해서 좀 고생했답니다. 보통 검색기능에 select name, contents from board where title = '" + title + "'... 이런 식으로 statement로 처리하고 input text로 값을 받아 처리하도록 일반적으로 되어 있을겁니다. 그럼 text에 ' or 1=1 union ... 이런 식으로 입력한다면 그 테이블 뿐만 아니라 권한이 있는 모든 테이블과 object를 볼 수 있어 심각한 보안 문제가 생깁니다. 기존 프로젝트 하던 사람들이 statement로 모두 처리했기에 가능하면 prepare...로 전환 했고 나머지는 입력받은 값중에 특수 문자를 쓸수 없도록 전부 처리해야하는 노가다(?)를 해야 했답니다. 이후론 가능하면 prepare...를 꼭 쓰도록 권장하고 다닙니다. 보다가 그냥 생각나서 몇자 두서없이 적습니다.

제목 : Re: 그것도 문제이긴 하지만. 글쓴이: 손님(guest) 2004/04/13 18:58:37 조회수:1317 줄수:9

당연히 검색어에 ' 를 입력하면 쿼리에 오류가 나지 않나요? 기본적으로 처리해야 할 문제를 보안오류라고 생각하는지 모르겠네요. ' 하고 prepare... 는 별도의 문제라고 생각합니다.

제목 : Re: 오라클 뻗는것도 봤습니다. 글쓴이: 김응원(lasher76) 2005/03/08 17:42:43 조회수:1630 줄수:21

현재 수출보험공사에서 프로젝트 수행중인 4년차 개발자 입니다. 저희쪽에선. 개발편의를 위해서 초기에 statement로 많이 개발을 햇었는데요. 이놈이. 유저수가 올라가고, 사용율이 높아지면서, 어느순간. 오라클이 미쳐버린 (@.@) 현상은. 딕셔너리가 깨져서 딕셔너리 테이블 뒤지는데 상당히 오랜시간 걸리는 그런현상을 목격했습니다. 오라클에서 오셔셔 진단해주셧는데 다이나믹쿼리가 많아서 shared-pool에 기록을 많이 하고, 검색하는데도 상당히 오래걸린다고 하네요. 저흰지금 preparedStatement로 바꾸는 작업을 계속 진행중입니다. 전부다요...ㅠㅠ 저같은 삽질을 막기 위해서 애초부터 preparedStatement로 코딩하시길 바랍니다. 개발편의성? 시중에 나도는 preparedStatment Util들 많습니다. 이런것들 적용해서 사용하시면 코딩 금방하시구요. 보기도 더 조아요. 그럼 담ㅇㅔ ~~ ^^

제목 : Re: 수정전/후 결과를 알려주시면 좋은 자료가 될 것 같습니다. 글쓴이: 손님(guest) 2005/03/09 15:15:34 조회수:1615 줄수:5

수정전/후 결과를 알려주시면 좋은 자료가 될 것 같습니다. 수고하세요.

제목 : Re: PrepareStatement Query Viewer 글쓴이: 명랑폐인(guest) 2005/03/10 14:25:30 조회수:2645 줄수:15

PrepareStatement 쿼리가 길어지고, 바인드하는 ? 개수가 많아지면, 작업자가 쿼리를 디버깅하기 힘들어집니다. (위에도 이런 얘기가 있군요..) jakarata common-util 의 dbutils 를 이용하다가 생각나서 만들어봤습니다. 자세한 건 첨부된 파일을 확인해보세요. PrepareStatement 를 쓰는걸 저도 좋아합니다만, 쿼리 오류가 생기면 고치는게 쉽지 않더군요. 쿼리를 자동정렬해주는 기능도 포함되어 있으니... 한번 참고해보세요. 그럼.  PstmtQueryViewerTest.java (3970 Bytes)  common_utils.zip (7246 Bytes)  PstmtQueryViewer.java (4724 Bytes)

제목 : Re: 사랑스런 PS... 글쓴이: 테이(insicj) 2005/09/14 20:14:24 조회수:1499 줄수:46

안녕하세요. 여기에 처음 써 보네요. 커뮤니티를 운영하는 곳에서의 일입니다만. SQL을 전부 스태틱으로 짜놨더군요. 매일 DB서버는 미쳐서 날뛰고있고... 어느날 회사안의 DBA(?)에게 컨설팅(?)을 했는데 두번에 걸쳐서 일주일 동안의 QUERY을 따더군요. 분석결과를 보여주면서 하는말이 PrepareStatement가 없어서 Hit가 높은 쿼리 데이터가 나오지 않는다고 하더군요 하는말 즉, PS로 전부 바꾸라더군여 --; 지금의 데이터는 쓰레기라구 하더군여 ㅠ_ㅜ 열심히 바꿔 줬습니다. 그 다음주엔 수십만(?;가물가물)번 실행되는 쿼리가 제대로 뽑혀 나오더군요. (당연히 순번대로 수십개의 고히트율의 쿼리들을 뽑았지요) 그 친구가 하는말은 즉. 잘 기억안나지만(그리고 독일넘이어서-_-a..), PS가 파싱시 좋긴 하지만 한 메서드 안에서 실행될때 얘기지 일반적인 자바PG때에는 별 효율을 내지 못한다구 하더군여 머, 큰 기대하지말고, 걍 그저 그렇다는 얘기로 기억하고 있습니다. (물론 좋답니다만, 흘려 들어 주시궁..) 다만, 저희는 히트 쿼리 데이터를 바탕으로 수십만실행되는 그 쿼리를 타겟으로 적게는 코스트 다운된 쿼리로 만들고, 테이블을 손질하고, 로직(자바)을 바꾸고, 필요하면 임시 테이블(클론)을 만들고 해서, 좀더 다운 안되는 사이트(?)로 만들었습니다. 그전에야 걍 히트율 높을것 같은, 걍 페이지 뷰가 느리면 손질하고 그랬습니다만, 페이지 뷰가 느리더라도 1분에 한번 히트하는 쿼리(뷰까지1초)랑 , 페이지 뷰가 빠르더라도 1분에 10번 히트하는 쿼리(0.5초)랑... 있다면 여지껏 전자를 손질해 왔던 셈입니다. 좀 극단적인 이야기 같지만 실무에서 흔히 일어납니다. 예를 들면 SELECT * FROM BOARD WHERE SEQ = iBoardSeq 같은쿼리같이 스태틱으로하면 이런 쿼리는 10만개의 다른쿼리로 오라클(DB)은 해석해서 데이터를 뽑아도 수면위로 안나옵니다만 (단순한 사이트라면 눈에 걸려 보이기도 하겠지요) SELECT * FROM BOARD WHERE SEQ= ? 같이 PS로 바꾸어주면 동일한 쿼리가 10만번 실행된 것으로 나옵니다. 어짜피 10번 실행 시켜주는 쿼리를 애써 1/10로 코스트를 낮추든, 파싱이 빨라지던 멀 하든... 별 의미 없는것 같습니다. 결국 PS의 용도는 이런 의미에서 PS를 쓰는것 같습니다. 두서없이 이런글을 작성해 죄송합니다. 너무 좋은것을 많이 얻어가서 제가 느낀것을 조금 적어보았습니다. 없는것 같기에. 행복하세요~.

제목 : Re: 그래도 PS가 쫌더 효율적이겠죠 글쓴이: 손님2(guest) 2005/09/15 13:24:13 조회수:1436 줄수:9

쿼리를 파싱하고 옵티마이저가 실행계획을 짜는 일도 코스트가 들어가는 일입니다. 대량 트랜잭션에서는 이 비용도 많많지 않을 것입니다. 그리고 오라클의 경우 한번 수행된 sql은 캐쉬되기 때문에 ps를 쓰지 않는 sql을 많이 날리면 shared pool size 초과 에러가 날 수도 있습니다. 아무쪼록 ps를 사용하는것이 더 효율적일 것입니다.

제목 : Re: 지나가는 사람입니다. 글쓴이: 김병주(darkping1980) 2006/02/10 16:51:24 조회수:2377 줄수:21

앞의 글들을 잘 봤습니다. 대화의 논점이 PreparedStatement 와 Statement 를 가지고 효율성이 있다. 없다라는 얘기를 많이 하시던데.. 실제로 간단하게 정의하자면 PreparedStatement 는 반복되는 쿼리 그러니까 웹페이지의 쿼리문을 연상하시면 됩니다. 그리고 Statement 는 반복되지 않는 쿼리.. 예를 들면 웹으로 SQL문을 넣고 결과를 보는 쿼리를 생각하시면 됩니다. 실제로 저는 웹프로그래밍 시에 PreparedStatement 를 사용합니다. 그리고 웹으로 SQL문을 작성해서 보내면 거기에 맞게 결과를 보여주는 페이지를 작성한 적이 있는데 거기에는 Statement 를 썼습니다. 사용자가 그날 그날 쓰고 반복되서 쓰일이유가 없는 데이터 베이스 공용풀에 쿼리를 저장할 필요가 없죠.. 여기까지가 일반적인 상황에 들어가는 이야기이고 만약 실행계획 이라던가 인덱스라는 여러가지 상황에서는 이야기가 바뀔수 있습니다. 어쨌든 결론은 반복되는 쿼리는 PreparedStatement 를 쓰고 반복되지 않는 쿼리는 Statement 입니다. 그리고 앞의 어느분께서 원리를 규명하고 란 글을 봤습니다. PreparedStatement 데이터베이스의 공용SQL풀 이란 곳에 저장이 됩니다. 거기서 반복되는 것은 캐싱해서 더빨리 쓰고 쓸데없는 메모리 소모를 줄이는 것이죠 그럼 이만..

제목 : Re: DB입장에서 PS 글쓴이: 손님(guest) 2010/06/22 15:17:39 조회수:1753 줄수:25

이는 Java에서가 아닌 DB 입장으로 보시면 됩니다. 위의 DB의 query parsing은 별것 아니라고 하셨지만. Query Parsing은. 실제로는 Query Parse -> Query Plan Tree 생성 -> Query Optimizer 실행 -> Query parse Tree 실행 의 단계로 이어집니다. 즉, 쿼리를 단순히 실행하는것이 아니라. 내부 표현형식 (그래프 , 트리 ...등등) 으로 재 조립하고, 옵티마이저에 따라서 다시 표현형식을 재조합하여. 최종적으로 된 그래프를 실행하게 되지요. 여기도 메모리가 많이 소요되고 그래프 만드는데도 시간이 소요 된답니다. 그렇게 따지면 PS가 훨씬~ 낫지요 ㅋ 이건 DB를 만들어본 입장에서 드리는겁니다.!