stored procedure(저장 프로시저)와 프레임워크의 상관관계 / 프로시저 에러 발생

[프레임워크가 프로시저 사용을 권장치 않는 이유]

 

얼마전 stored procedure를 수정함으로써 운영중 장애를 겪는일이 있었다. 

stored procedure.... 줄여서 SP라고도 하는데,,  장단점이 명확했다. 

 

SP를 쓰는 이유는 빠르기 때문이다. 

클라이언트 입장에서는 동일 SP를 반복 호출시에는 메모리에 가져다 놓고 쓰는것으로 보인다. 

때문에 부하 측면이나 속도측면에서 장점을 가지고 있다.

 

하지만, 프레임워크에서는 SP 사용을 권장하진 않는다. 

소스 revision 관리에 민감한 프레임워크 입장에서는 SP 관리가 안될 뿐더러 AP단이 아닌 DB단 

어쩌면 서버레벨에서의 프로그램을 자유롭게 코딩함으로써,, 유지보수가 어렵게 느껴질것이다. 

또, emb를 지원하는 프레임웍에서는 SP를 emb디자인에서 찾기가 불투명해서 로직 흐름을 파악하는데 어려움을 안겨준다... 

SP내에서 Commit&Rollback 처리를 하여 데이터의 부정합성의 가능성이 충분하고,, 

제일 중요한것은 로깅이라는 강력한 기능을 지원하는 프레임웍에서 SP는 별도 로깅하기 어렵기에 권장하지 않는다. 

 

이런 문제를 해결할수 있는 방안은 SP로 가져갈 내용들을 모듈로 쪼개서 가져가는 방법이 있다. 

이미 대량의 SP가 적용되어있는 시스템에서는 어쩔순 없지만.... ( 모듈화 진행시 대공사가 예상되므로.....)

 

[프로시저 사용시 장애를 맞았던 경험]

SP를 수정하고 에러를 맞게되자 다시 원상복구 하였다.  그래도 에러현상은 지속 되었다. 

납득하기 어려운 상황이다.  프로시저를 변경해서 에러를 맞았다는것은 수정된 내용이 뭔가 반영 된듯한데,, 

원복을 해도 에러가 난다는 것이.... 

 

AP를 재기동하니 에러현상이 해결되었다.  또는 DB모듈을 재컴파일해서 해결이 되었기도 했다. 

이런 현상에 대한 원인을 명확하게 찾기 어려웠지만,,  추측컨데,, 

찾아보니 SP는 생성 후, 첫 실행시에 개체 이름, 사용권한등을 확인하고 최적화를 거친 뒤 컴파일 및 실행계획에 등록도 하며 캐시 메모리에 실행계획을 옮긴다. 

두번째 실행시 실행계획을 담고있는 캐시메모리에 접근한뒤 그대로 가져와 재사용한다는 것을 알게 되었다. 

SP의 이름도 아닌, 내용을 살짝 바꾸고 원복을 해서 인지,,, 캐시 그대로 접근한게 아닐까라는 의문이 생긴다.

 

아직 원인파악을 명확히 하진 못하였기에,, 일단 SP 수정 하는 절차를 정립하는게 맞다고 생각한다...