DBA가 되고 싶은 병아리

Buffer Hit Ratio is NOT Everything -A badly tuned database can still have a hit ratio of 99% or better Buffer Hit Ratio 가 90% 이하로 낮아질 경우에 튜닝대상이 된다고하는데 이말에는 커다란 오점이있다. Buffer Hit Ratio 는 인스턴스가 시작된이래로 수집된 평균값이기 때문에 신뢰하기 어렵다. 즉 인스턴스시작이래로 Buffer Hit Ratio가 90%이어도 지금 인스턴스가 최적화 되어있다고 말할 수가 없다는것이다. 그래서 Delta Hit Ratio분석을 많이 사용한다. 이 방법은 전체적인 평균값이 아닌 일정 시간 간격의 Hit Ratio를 측정하는 방법으로 훨씬 유용하고 신뢰도가 높다. - Hit ..

OPEN_CURSORS-- SQL areas 연관 (기본 값 50/ rac 설치시 300으로 설정됨) SGA-> 최소 사이즈는 RAC 기준으로 1032M SHARED_POOL_RESERVED_SIZE - SHARED POOL에서 대용량의 연속된 작업을 수행하기 위한 파라메터 (12C부터 신규로 추가된 파라메터) - 5% of the value of SHARED_POOL_SIZE 최소 크기는 5000 v$sesstat 현재 세션 상태를 기록한 뷰 (user session statistics) V$SESSION 현재 접속된 모든 세션의 정보를 표시 (displays session information for each current session.) v$statname 위의 두 뷰에 관련된 추가정보를 표시 (..

-------------- Session cached cursors Hit Ratio ------------ 1. Open_cursors: 한 세션이 열수있는 최대 cursor 개수 2. Session_cached_cursors: 열려있는 세션이 가질 수 있는 최대 Cursors 개수SESSION_CACHED_CURSORS 파라메터는 동일한 SQL을 반복수행(3회이상)하는 경우에 유리하며, 보통 softer parse 라고 한다.모듈별로 특정 SQL 들을 반복 수행하는 세션들에 설정시 SOFT 파싱부하를 감소시켜준다. 시스템이 내부 수행하는 ReCursive SQL 도 포함되므로 최소 30 이하로 설정하는것은 효과가 없으며 보통 50 이상을 권장한다.동일한 SQL이 동일세션에서 3회 이상 수행 시 PGA..

For many types of operations, Oracle Database uses the buffer cache to store data blocks read from disk. Oracle Database bypasses the buffer cache for particular operations, such as sorting and parallel reads.To use the database buffer cache effectively, tune SQL statements for the application to avoid unnecessary resource consumption. To meet this goal, verify that frequently executed SQL state..

서비쿼리에 대한 기본 내용 이해하기 서브쿼리란?Where절에 비교조건으로 사용되는 Select 쿼리서브쿼리를 이용하여 절차적인 SQL 작성이 쉽다 서브쿼리를 사용하지 않고 조인으로 처리가 가능한 SQL임에도 불구하고, 단지 SQL 작성이 쉽다는 이유하나만으로서브쿼리를 남용 할 경우 => 성능문제가 발생할 가능성이 있음SQL에 서브쿼리가 여러 개 존재할 경우, Optimizer가 최적화 과정에서 잘못된 Cost 계산을 하는 경우가 많이 발생 서브쿼리를 사용해야 할 경우서브쿼리를 사용해야 의도한 결과 값을 가져올 수 있는 경우서브쿼리를 이용할 경우 성능이 좋아지는 SQL=>두 가지 경우가 아니라면 Join으로 작성하는 것이 Optimizer에게 더 좋다. 서브쿼리의 개수가 많은 SQL -> 비효율적인 실행계..

1. SQL 튜닝의 시작은 SQL의 의미(작성 의도)를 제대로 파악파악하지 못할 경우 원본과 다른 결과 집합이 아닌 다른 집합을 추출할 수도 있기 때문 수행 단축시간을 단축하기 위해 힌트를 남발하는 것은 상당히 위험한 일=> 우선 작성자의 의도를 파악하고 최대한 좋은 결과를 내는 것 신경써야 할 부분인덱스 구성과 힌트 사용이 적절한지에 대한 검토가 필요실행 계획 상으로는 SQL의 문제점을 찾기가 쉽지 않음 오류->인덱스를 잘못 사용하고 있다는 전제하에 타 인덱스를 사용하는 오류를 범할 수 있음 따라서 튜닝을 하는 경우 업무 담당자와 상의(문의)할 필요가 있고 그렇지 못한 경우라면 SQL의 작성 의도를 파악

프로그램에 많이 사용되는 sql을 뷰로 만들어서 좀더 빠른 속도로 엑세스 하기 위한 것이 인라인 뷰이지만 프로그램을 구성하거나 sql을 구성할때 잘못된 사용과 너무 많은 사용으로 인해서 엑세스 속도를 오히려 저하 시키는 경우가 많은듯 하다. 오히려 효과적인 작성을 하게 된다면 프로그램(SQL)의 성능을 좀더 향상 시킬수 있음에도 불구하고 많은 사람들이 잘못된 사용으로 데이터베이스의 Optimazer를 괴롭히는 현상이 나타나는 것이다. 효과적으로 사용하기 위해서는 아래의 사항을 자제하게 되면 좀더 낳은 프로그램 혹은 SQL을 작성할수 있다. -인라인 뷰가 주 쿼리로 합쳐지는 병합 가능 인라인 뷰의 사용자제 -인라인 뷰의 반복 사용 자제 물론 위의 내용 말고도 올바른 인덱스를 사용한다던가 하는 여러 문제가 ..