아케텍쳐14 04.라이브러리 캐시 최적화 원리 - 10. Dynamic SQL 사용 기준 (1)Dynamic SQL 사용에 관한 원칙 - Static SQL을 지언하는 개발환경이라면 Static SQL로 작성하는 것을 원칙으로 합니다. Static SQL은 Precompile 과정을 거치므로 런타임 시 안정적인 프로그램 build가 가능하다는 장점이 있습니다. 그리고 Dynamic SQL을 사용하면 애플리케이션 커서 캐싱기능이 작동하지 않는 경우가 있는데, 이 기능이 필요한 상황(예를 들면, 루프 내에서 반복 수해되는 쿼리)에서 Dynamic SQL을 사용하면 성능이 나빠지기 때문입니다. 아래의 경우에는 Dynamic SQL을 사용해도 무방합니다. - Precompille 과정에서 컴파일 에러가 나는 구문을 사용할 때, 예를 들어 Pro*C에서 스칼라 서브쿼리,분석함수,ANSI 조인 등 - .. 2020. 1. 19. 04.라이브러리 캐시 최적화 원리 - 09.Static vs. Dynamic SQL Static 과 Dynamic SQL의 용어를 제대로 확인해보도록 하겠습니다. (1)Static SQL String형 변수에 담지 않고 코드 사이에 직접 기술한 SQL문을 말합니다. 다른말로 embedded SQL이라고 합니다. (2) Dynamic SQL String 형 변수에 담아서 기술하는 SQL문을 말합니다. String변수를 사용하므로 조건에 따라 sql문을 동적으로 바꿀 수 있고, 또는 런타임 시에 사용자로부터 SQL문의 일부 또는 전부를 입력받아서 실행할 수도 있습니다.Toad,Orange,SQL*Plus과 같은 Ad-hoc쿼리 툴에서 작성하는 SQL은 모두 Dynamic SQL이라고 볼 수 있습니다. 이들 툴이 컴파일되는 시점에 sql이 확정되지 않았으며 사용자가 던지는 SQL을 런타임 시.. 2020. 1. 17. 04.라이브러리 캐시 최적화 원리 - 07.세션 커서 캐싱, 08.애플리케이션 커서 캐싱 07. 세션 커서 캐싱커서를 공유할 수 있는 형태로 SQL을 작성하면 하드파싱을 최소화해 궁극적으로 시스템 확장성을 높일 수 있습니다. 그런데 하드파싱을 하지 않더라도 SQL구문을 분석해서 해시 값을 계산하고, library cache래치를 획득한 후 라이브러리 캐시에서 커서를 탐색하는 과정 자체도 부담스러운 작업입니다.(소프트파싱) 특히 SQL 동시 수행이 많을 때는 경합까지 발생하므로 시스템에 부하를 주게 됩니다. 당연한 이야기이지만 SQL수행횟수가 높을 때 파싱관련 경합도 함께 증가합니다. 하지만 파싱경합을 줄여서 라이브러리 캐시 효율을 높이기 위해서는 SQL수행횟수를 줄여야 할까요? 아닙니다. 이것은 근본적 해결은 아닙니다. Shared Pool에 위치한 공유 커서를 실행하려고 PGA로 인스턴스화.. 2020. 1. 16. 04.라이브러리 캐시 최적화 원리 - 05.바인드 변수의 중요성, 06.바인드 변수의 부작용과 해법 05.바인드 변수의 중요성바인드 변수 사용에 따른 효과는 아주 분명하게 나타납니다. 커서를 많이 생성하지 않고 하나를 반복 재사용하므로 메모리 사용량과 파싱 소요시간을 줄여줍니다. 궁극적으로 시스템 전반의 메모리와 cpu 사용률을 낮춰 데이터베이스 성능과 확장성을 높이는데 기여하고, 특히 동시 사용자 접속이 많을 때는 그 영향력이 절대적입니다. 바인드 변수 사용 원칙을 잘 지키지 않으면 라이브러리 캐시 경합 때문에 시스템 정상가동이 어려운 상황에 직면할 수 있습니다. 그럴때 cursor_sharing 파라미터를 변경하는 것을 고려해 볼 수 있는데 이는 응급처방으로 사용해야지 절대 영구 적용할 목적으로 사용해서는 안됩니다. 06. 바인드 변수의 부작용과 해법바인드 변수를 사용하면 최초 수행할 때 최적화를 .. 2020. 1. 15. 이전 1 2 3 4 다음
