성능고도화54 04.라이브러리 캐시 최적화 원리 - 03.라이브러리 캐시 구조 라이브러리 캐시는 Shared Pool 내에 위치하며, SQL 공유 커서 및 데이터베이스 오브젝트(테이블,인덱스)에 대한 정보를 관리합니다. 그리고 여기에 저장되는 정보의 단위를 라이브러리 캐시 오브젝트(LCO)라고 부릅니다. SQL 커서 뿐만 아니라 컴파일을 거친 프로시저, 함수, 패키지, 트리거 등 PL/SQL프로그램을 담는 PL/SQL Area도 라이브러리 캐시에 저장합니다. (실행가능 LCO) 뿐만 아니라 거기서 참조하는 테이블,인덱스, 클러스터 같은 데이터베이스 오브젝트 정보들도 동등하게 하나의 오브젝트로써 관리됩니다.(오브젝트 LCO) 스키마 오브젝트 정보는 데이터 딕셔너리 캐시에도 캐싱돼 있는데 라이브러리 캐시에 중복 저장하는 이유가 무엇일까요. 라이브러리 캐시에 스키마 오브젝트 정보를 캐싱.. 2020. 1. 10. 04.라이브러리 캐시 최적화 원리 - 01.SQL과 옵티마이저, 02.SQL처리과정 01.SQL과 옵티마이저 옵티마지어가 내장된 DBMS를 사용한다면 개발자가 프로시저를 직접 코딩할 필요없이 옵티마이저가 대신해서 프로그래밍해주고 프로시저를 생성해 줍니다. 예를들어, 아래와 같은 쿼리를 작성해서 결과값을 리턴받았다고 가정할때 예전에는 두 개 테이블을 조인해 사용자가 원하는 결과집합을 얻으려면, 기준 테이블을 select하고 한 건씩 fetch하면서 반대편 테이블로부터 조인 레코드를 seek하는 과정을 루핑을 통해 반복 수행하는 프로시저를 직접 개발했었어야 했습니다. 하지만 옵티마이저가 우리를 대신해 프로그래밍 해주게되고 프로시저가 자동으로 생성되는 것입니다. select e.ename,e.job,d.dname from emp e, dept d where d.deptno=e.deptno a.. 2020. 1. 9. CH03.오라클 성능관리 - 10.V$SQL, 11.End-To-End 성능관리,12.데이터베이스 성능 고도화 정석 해법 10.V$SQL튜닝을 할때 가장 효율적인 방법 중 하나는 주기적으로 사용되는 상위 10%이내의 프로그램만 집중적으로 튜닝하는 것입니다. 전체 SQL을 다 튜닝할 수 없기 때문에 시스템부하가 높은 쿼리나 자주 수행되는 쿼리 등 전략적으로 접근하여야 합니다. v$sql은 집중 튜닝이 필요한 대상 SQL을 선정하는 데 활용할 수 있는 매우 유용한 도구입니다. 그 뿐만아니라 튜닝 전후 성능 향상도를 비교할 목적으로 통계를 내는 데도 활용 할 수 있습니다. v$sql은 라이브러리 캐시에 캐싱돼 있는 각 child커서에 대한 수행통계를 보여줍니다. 그리고 v$sqlarea는 parent 커서에 대한 수행통계를 나타내며, 많은 컬럼이 v$sql을 group by 해서 구한 값입니다. v$sql은 쿼리가 수행을 마칠 .. 2020. 1. 6. CH03.오라클 성능관리 - 09.ASH(Active Session History) Ratio 기반 분석방법론과 대기이벤트 기반 분석방법론의 한계점은 문제가 있다고 진단했을때 그 원인을 찾아 실제 문제를 해결하는 데까지 많은 시간이 걸리는 데 있다고 합니다. 그래서 오라클이 10g에서 ASH기능을 탄생시켰습니다. 10g AWR은 데이터 수집을 아주 빠르게, 좀 더 많이 한다는 것 외에 외형적으로 Statspack과 크게 달라진 것이 없다고 느낄 수 있습니다. 하지만 ASH는 다릅니다. 이것은 별도의 Third Party 모니터링 도구 없이 오라클 내에서 세션 레벨 실시간 모니터링을 가능케 하는 강력한 기능으로써 OWI 활용성을 극대화 해줍니다. SQL> select * from v$sgastat where name = 'ASH buffers'; POOL NAME BYTES CON_ID .. 2020. 1. 5. 이전 1 ··· 7 8 9 10 11 12 13 14 다음
