프로파일러를 사용해보시면 어떨까요

http://www.sqlskills.com/blogs/joe/hunting-down-the-origins-of-fetch-api_cursor-and-sp_cursorfetch/

참고 하시면 될 것 같습니다.

어플리케이션이 결과를 가져가려면 서버커서나 클라이언트커서 중 하나를 써 데이터를 가져가야 합니다 이것은 어플리케이션의 쿼리연결속성에서 셋팅됩니다. 예를들어 쿼리 결과가 10000건이 나온다고 생각했을 때 어떤 어플리케이션은 마지막 10건만 보고 나머지 결과는 관심없는 비즈니스도 있을겁니다. (예를들어 네이버에서 서비스하는 라인 채팅에 들어갈때 들어갈때마다 대화방이 최초 생성된 때부터의 전체 데이터를 다 받는다면 성능이 매우 느릴겁니다. 이때는 사용자가 과거 대화목록을 다시 보고싶을때만 어플리케이션이 서버에 요청해 서비스하면 성능이 매우 빨라질 것입니다. [예를든것이지 라인이 이렇게 구현되었다는 것은 아닙니다.])  이 때 서버커서는 가져오는 패치단위를 10건으로 해 단 한번 클라이언트로 가져오고 나머지 필요없는 결과는 요구가 있을때만 다시 서버로 요청해 가져오면 어플리케이션 속도가 비약적으로 높아질수 있습니다. 그러나, 실제 어플리케이션 개발자가 이 옵션에 대한 이해가 없이 모든 데이터가 필요한 상황에서  패치 기본값 1로 모든 데이터를 패치하고 보여주는 경우가 있습니다.  이런 상황이 생기면 디비서버와 클라이언트의 네트워크 라운드 트립이 비약적으로 높아지고 성능이 하락 합니다.

이런경우 비지니스를 이해하고 클라이언트커서를 써 서버와 클라이언트의 라운드트립을 줄이면 전체 어플리케이션 속도는 비약적으로 빨라집니다. 이런경우가 아니고 서버커서를 적절히 쓴 경우에는 데이터베이스 서버와 클라이언트의 패치 단위를 변경 (더 큰 단위로) 해 이러한 라운드트립 횟수를 줄일수 있습니다.

sqltag 운영과 튜닝 2편에 상세한 내용이 예제와 함께 기술되어있습니다. 아직 책이 출판되기 전이고 이러한 문제에 대한 자세한 가이드를 받고 싶다면 언제든지 연락 주세요. 또한 다른 내용이더라도 책에 추가로 설명되었으면 하는 부분도 건의하시면 목차에 넣을수도 있습니다. 전화 및 팀뷰어 가이드는 무료입니다. SQLTAG 저자는 티어1 데이터베이스를 운영하거나 기술지원 엔지니어들 입니다.