dm_exec_procedure_stats DMV 쿼리를 이용해서 프로시저가 실행되었는지 안했는지..카운트수와..
마지막 실행시간 등을 확인했는데요..
하루 지나니까 정보가 싹 사라지더라구요..
cached_time 이 보니 어제부터가 아닌 오늘로 되어 있고..
어제 실행되었던 모든 프로시저 정보는 하나도 안남아 있었습니다..(오늘 실행된것만 있더라구요)
일단 저의 의도는 한달동안 프로시저가 실행되었는지 안되었는지..몇번 실행되었는지 확인하고 싶은거였습니다.
그런데 하루 지나면 정보가 사라져서...슬프네요 ㅠㅠ
방법이 없을까요.?
Comment 8
-
Hisory
2014.06.02 10:17
-
쿨키이드
2014.06.02 11:54
음..답변 감사합니다 확인해봐야겠습니다
-
캐시에서 저장 프로시저가 제거되면 dm_exec_procedure_stats에서도 해당 행이 제거 됩니다.
cached_time이 모두 오늘 뿐이라는건 모든 프로시저들이 새로 컴파일 됐다는 거네요.
왜 새로 컴파일이 되었는지를 알아봐야 할거 같습니다.
"다음분" 나와주세요 -_-;;
-
쿨키이드
2014.06.02 11:55
답변 감사드립니다. 기본적으로는 하루가 지나던 한달이 지나던 원래는 남아 있어야 정상이란거지요? 음..
-
쿨키이드
2014.06.02 12:00
찾은것 같습니다.. SQL 에이전트에 작업으로 syspolicy_purge_history JOB 이 있었고..
이게 매일 새벽 2시에 돌아가도록 되어 있었네요..
저 JOB이 수행하는 sp_syspolicy_purge_history 이거고요.. 찾아보니..
기록 보존 간격 설정에 따라 정책 평가 기록을 제거합니다. 라는 설명이 검색됩니다..;;;
SQL 설치하면서 자동으로 생성되는것 같은데..현재 미사용으로 바꿔놨고..내일이나 내일 모레쯤 다시 확인해보아야겠네요..
이렇게 찾을수 있도록 도움 주셔서 감사드립니다.^^
-
그건 아닌거 같습니다.
sp_syspolicy_purge_history는 단계를 살펴보니 msdb관련인거 같구요.
예를 들어서 USP_S_TEST라는 SP가 지금까지 몇번이나 실행됐는지를 살펴보고 싶은데
dm_exec_procedure_stats에 cached_time이 최근 날짜라는거잖아요?
그렇다면 그것은 그 쿼리가 최근에 다시 컴파일 되었다는 뜻입니다.
-
쿨키이드
2014.06.03 13:49
일단 어제 sp_syspolicy_purge_history는 JOB을 미사용으로 바꾸고 오늘 다시 보니..cached_time이 어제꺼부터 오늘꺼까지
제가 원하는대로 있었습니다.. 아마 저 캐쉬되는 정보가 msdb에서 내부적으로 관리되고 있는게 아닐까요.?
프로시저를 다시 수작업으로 컴파일 하진 않았습니다.서버를 내린적도 없고요...
현재 2대 서버 모두 어제날짜와 오늘 날짜 2틀치의 cached_time이 존재하는데..
오늘은 1대 서버에는 JOB을 사용으로 해놓고, 1대 서버에는 미사용으로 해놓고.. 내일 확일해보려고 합니다..
제 추측이 맞다면..(맞아야 할텐데..ㅠ_ㅠ....) 미사용으로 해놓은 서버는 그대로 있을거고..사용으로 해놓은 서버는 다 없어져 있겠죠?
흐흐흐 내일 오후 결과 올리겠습니돠.! 두둥.! 깊은 관심 감사드립니다.
-> 사용으로 해놓고 수작업으로 실행해보았는데..변화없네요.......흐음.....좌절..OTL..
-
msdb는 sql agent가 개인용으로 사용하는 db입니다.
플랜하고는 상관이 없어요.
제 짧은 지식으로는 해당 정보는 하루가 지난다고 삭제되지 않는것으로 알고 있습니다.
DB서버 재시작 / SP 재컴파일 / 인덱스 통계등의 전체 재생성 등의 작업으로 인해서 해당 정보가 초기화 되지 않았나 생각되네여.
더 전문가적인 답변은 다음분이...