안녕하세요
구글링을 아무리 하고..몇날 몇일 튜닝고민을 해도 답이 안나와 도움 요청합니다ㅠㅠ
특정 select 쿼리문을 T-sql로 실행, EXEC SP로 실행, 응용프로그램을 통한 SP실행의 속도차이가 천지차이입니다.
T-sql 실행할때는 1초 내로 실행되고, EXEC SP는 1분, 응용프로그램 실행 시 5분 정도 소요됩니다
recompile도 해보고 index 타는 것을 변경하려고 sp 실행계획도 변경해보았지만 소용이없습니다.
ARITHABORT 설정값을 스튜디오에서 확인해도 ON 인것을 확인할수있었습니다...
혹시 이런경우 어떤 걸 확인해야할까요?
ㅜㅜㅜㅜ
Comment 22
-
ilovejsp
2016.04.12 17:03
-
항해자™
2016.04.12 18:28
프로파일러로 플랜을 수집해 보세요,,,
일단 파라미터 바인딩은 잘 하고 있나요?
프로시저와 실행한 스크립트 그리고 어플에서 호출하는 부분의 코드를 올려주시면 좋겠네요,,,
-
쏭쏭쏭
2016.04.12 19:16
네 유첨하였습니다~도움감사드립니다~
-
항해자™
2016.04.12 19:32
소스는 c# 인가요?
위 아래로 코드를 조금 더 보여 주실 수 있나요?
파라미터 바인딩 되지 않는 형태 같아 보이네요,, -
항해자™
2016.04.12 19:33
또, 프로시저 콜이 발생해야 하는데, 첨부된 코드를 봐서는 as-hoc 쿼리로 호출될 듯 하네요,,
-
쏭쏭쏭
2016.04.14 10:23
유첨하였습니다. AS-HOC으로 호출되나요?? SP명으로 기입하였는데도요?
흠.. 어플에서 실행 시 다른 실행계획을 타고있는것 같긴...했는데..
-
항해자™
2016.04.14 12:54
어떤 어플에서든 호출하는 형태가 매우 중요하고, 파라미터를 바인딩하는 것이 매우 중요합니다,,
물론 비지니스의 요구에 따라 이러한 형태는 상황에 맞는 방법을 사용해야 되겠지요,,
위에 청부해 주신 코드 중에서 NonServiceSql() 클래스를 확인해 볼 수 있을까요?
다시 말씀드리지만, 프로시저 형식으로 호출하고, 파라미터를 명시적으로 바인딩하고 자료형도 명시해야 합니다,,
그래야 원하는 성능을 유도할 수 있습니다,,,,
-
쏭쏭쏭
2016.04.14 14:27
네 지원 감사드립니다.
NonServicedSql 클래스 파일 유첨하였고요,
파라미터는 모두 SP내에서 varchar형식으로 받고 어플단에서 string 값으로 보내기에,,동일하다 생각됩니다
프로시저 형식으로 호출되는 것은,,
제 생각엔 그런것같은데 확실하지않네요,
검토 부탁드려요
-
항해자™
2016.04.14 15:33
자체 프레임웍을 구현해서 사용하는 것 같군요,,,
위와 같은 형태로 사용하면 편의성 증대는 가져올 수 있으나, 다소 문제가 발생할 소지가 있을 듯 합니다,,
프로시저 타입으로 호출은 하고 있으나, 파라미터 바인딩을 명시적으로 하지 않는 것 같습니다,,
InitializeCommand 를 이용해서 AllocateDbContext 하는 것을 볼수 있습니다,,
위 커멘드의 정확한 내부 로직은 알수 없으나, 형태로 미루어 볼 때 파라미터가 바인딩되는 것 같지 않아 보입니다,,
디비 호출하는 부분은 가급적이면 불편하더라도 아래와 같이 파라미터를 바인딩 해 주는 것을 추천합니다,,
...
-
쏭쏭쏭
2016.04.20 09:38
네 답변감사드립니다 한번 해봐야겠네요
-
처리짱
2016.04.15 17:21
업무의 전체적인흐름, 테이블 구조등을 잘 몰라 뭐라 말씀드리긴 그렇지만..
프로시져 안에서. 너무 많은 테이블들 조인이 일어나네요... 주석달린걸 보니 2009년도도 보이고..
2009년에 만들어진 프로시져를 지금까지 조금씩 수정하면서 사용하다가 저 상태까지 온거 같아 보이네요...
쿼리 한문장이 대략 400줄... 수정도 쉽지 않아 보이네요..
튜닝을 한번 해보시는건 어떨지요?
-
항해자™
2016.04.15 18:59
업종에 따라서 위와 같이 다수의 조인, 하나의 쿼리가 매우 긴 경우를 심심치 않게 만나 볼수 있습니다,,
어떤 경우에는 쿼리를 분리할 수 있지만, 그렇지 않은 경우도 있지요,,
이미 잘 사용하고 있는 이런 복잡한 쿼리를 수정해서 같은 결과를 보장하기 힘들 수도 있습니다,,,
-
쏭쏭쏭
2016.04.20 09:40
네 맞아요,
튜닝을 조금 씩 한뒤 DB단에서 SP호출시 응답시간은 대폭 감소시켰음에도
응용프로그램 단에서는 오래 걸리더라구요,,
-
향지
2016.04.18 13:50
해당 SP로 실행계획이 2개 만들어졌나 확인해보시구요
응용 프로그램과 SSMS에서 SET 옵션 다른거 있는지 확인 한번 해보세요~
-
항해자™
2016.04.21 18:48
위 상황은 플랜이 다수개 발생했을 것 같고, 파라미터 스니핑이 되지 않으므로, 덴시티 통계로 쿼리가 될 것이라고 생각되네요,,
프로파일러 등으로 플랜을 캡쳐해 보시기 바랍니다,,,
-
쏭쏭쏭
2016.05.26 16:12
네, 답변 감사합니다
유첨된 파일과 같이 exec 를 통해 SP 실행시와 파라메타 값 declare 후 쿼리를 직접 실행시 시간차이가 발생하는 것을 확인하였습니다.
덕분에 파라미터 스니핑에 대해 찾아보게되었는데요
지역변수 선언 후 쿼리를 실행할때는 파라미터 스니핑되지않았을텐데 더 빠른이유는 무엇일까요?;;
제가 잘못이해한 부분이있을까요?
도움주시면 감사하겠습니다~
-
minsouk
2016.05.26 16:42
일단 파라메터 스니핑 이구요,
declare 해서 실행한것과 SP 에서 같은 속도를 내게 임으로 조작하고자 한다면
1)
create proc a
(@a int)
as
select * from tblx where a = @a
라는 프로시저가 있다면
create proc a
(@v_a int)
as
declare @a int = @v_a
select * from tblx where a = @a
라고 바꾸어 주시면 t-sql 에서 실행한 것과 동일한 실행계획을 가지게 만들 수 있습니다.
2)
쿼리마다 마지막에 OPTION (querytraceon 4136) 를 추가하면 가능합니다.
*)
또 질문 하신분의 쿼리에 만능 쿼리가 많은데요, 프로시저에
,@ERRORMESSAGE VARCHAR(3000) --OUTPUT
--WITH RECOMPILE 20160415 주석
이렇게 하면 적용되지 않구요 매 구문마다 option (recompile) 을 넣어주면 파라메터 스니핑을 통해 통계 히스토그램을 읽고 동작하게 할 수 있습니다. 요건 버전마다 좀 틀립니다.
sql 플랜은 별거 없습니다...
쿼리가 좀 길어서 분석하는데 시간은 좀 걸리지만 항상 1초로 나오게 튜닝 가능합니다.
방법은 알겠는데 읽어보고 적용하기 귀찮다라면............돈을 주거나 맞으면서 배우면 됩니다. 쿨럭~ (농담 입니다. ^^)
화이팅!!
-
쏭쏭쏭
2016.05.26 17:36
네! 1번과 같이 해보았더니 정말 동일한 시간이 나오네요!!
질문을 하나 더 드리자면, 제가 파라미터 스니핑에 대해서 잘못이해한것인지,,
파라미터 스니핑을 할경우엔 T-sql 실행시보다 exec를 통한 SP실행할때가 이미저장되있는 실행계획을 통해 쿼리를 실행하기에 빨라야하는거 아닌가요??
정말!! 감사합니다~
-
minsouk
2016.05.26 17:43
짬뽕해서 개념을 잡으셨군요....일단 넘어가시고....나중에 천천히 공부해 보세요~ ^^;;
죽이죠? ^^;; 제가 이런거 전문 입니다. ^^;;
-
쏭쏭쏭
2016.05.26 17:55
ㅎㅎ네 열심히 공부해야겠네요
정말 감동스럽습니다!!!ㅠㅠㅠ
-
minsouk
2016.05.26 17:58
엇 스터디가 있네요? 한번 배워보시겠어요?
http://cafe.naver.com/sqlmvp/4982
감동의 튜닝을 알려드리죠.....^^;;
-
쏭쏭쏭
2016.05.26 18:21
네 관심이 생기네요! 그런데...정자동이면,,,분당 맞지요?ㄷㄷㄷ
T-SQL,EXEC,응용프로그램에서 실행할때
각각 실행계획이 같은가요?