Oracle 데이터베이스 통계는 얼마나 자주 실행되어야 합니까?

https://stackoverflow.com/questions/79229

09-06-2019
|

문제

경험상 Oracle 데이터베이스 통계를 얼마나 자주 실행해야 합니까?우리 개발자 팀은 최근 2개월 반 넘게 통계가 생산 상자에서 실행되지 않았다는 사실을 발견했습니다.나에게는 오랜 시간이 걸리는 것처럼 들리지만 나는 DBA가 아닙니다.

해결책

나의 마지막 직장에서는 일주일에 한 번씩 통계를 실행했습니다.내 기억이 맞다면 우리는 목요일 밤에 일정을 잡았고, 금요일에는 DBA가 예상치 못한 일이 발생하지 않도록 가장 오랫동안 실행되는 쿼리를 매우 주의 깊게 모니터링했습니다.(금요일은 코드 릴리스 직후인 경우가 많고 트래픽이 상당히 적은 날인 경향이 있기 때문에 선택되었습니다.) 잘못된 쿼리를 발견하면 더 나은 쿼리 계획을 찾아서 저장하여 예기치 않게 다시 변경되지 않도록 했습니다. .(오라클에는 이 작업을 자동으로 수행할 수 있는 도구가 있습니다. 최적화할 쿼리를 지정하면 최적화됩니다.)

많은 조직에서는 잘못된 쿼리 계획이 예기치 않게 나타날 것을 두려워하여 통계 실행을 기피합니다.그러나 이는 일반적으로 시간이 지남에 따라 쿼리 계획이 점점 더 나빠진다는 것을 의미합니다.그리고 통계를 실행하면 여러 가지 문제에 직면하게 됩니다.이러한 문제를 해결하기 위한 쟁탈전은 통계 실행의 위험성에 대한 두려움을 확인시켜줍니다.그러나 정기적으로 통계를 실행하고 모니터링 도구를 예상대로 사용하고 문제가 발생할 때마다 수정하면 두통이 줄어들고 한꺼번에 발생하지 않을 것입니다.

다른 팁

Oracle 11g에서는 기본적으로 통계가 자동으로 수집됩니다.

Oracle 데이터베이스 설치 시 두 개의 스케줄러 창이 사전 정의됩니다.

WEEKNIGHT_WINDOW는 오후 10시에 시작됩니다.그리고 오전 6시에 끝나요.매주 월요일부터 금요일까지.
WEEKEND_WINDOW는 토요일과 일요일 전체를 포함합니다.

통계가 마지막으로 수집된 때는 언제입니까?

SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.

자동화된 통계수집 현황은?

SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';

Windows 그룹?

SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;

창 일정?

SELECT window_name, start_time, duration FROM dba_autotask_schedule;

이 스키마에서 데이터베이스 통계를 수동으로 수집합니다.

EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.

모든 스키마에서 데이터베이스 통계를 수동으로 수집하십시오!

-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;

데이터가 "크게" 변경될 때마다.

테이블이 1행에서 200행으로 바뀌면 이는 중요한 변화입니다.테이블의 행이 100,000개에서 150,000개로 늘어나더라도 그다지 큰 변화는 아닙니다.테이블이 일반적으로 쿼리되는 X 열에 동일한 값이 포함된 1000개 행에서 X 열에 거의 고유한 값이 포함된 1000개 행으로 변경되면 이는 중요한 변화입니다.

통계는 항목 수 및 상대 빈도에 대한 정보를 저장합니다. 이를 통해 주어진 기준과 일치하는 행 수를 "추측"할 수 있습니다.추측이 잘못되면 최적화 프로그램은 다음을 선택할 수 있습니다. 매우 차선의 쿼리 계획.

어떤 Oracle 버전을 사용하고 있습니까?Oracle 10을 참조하는 이 페이지를 확인하세요.

http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm

그것은 말한다:

통계 수집에 권장되는 접근 방식은 Oracle이 자동으로 통계를 수집하도록 허용하는 것입니다.Oracle은 모든 데이터베이스 개체에 대한 통계를 자동으로 수집하고 정기적으로 예약된 유지 관리 작업을 통해 해당 통계를 유지 관리합니다.

제가 Oracle이 지원하는 대규모 다중 사용자 계획 시스템을 관리하고 있을 때 우리 DBA는 매주 통계를 수집하는 작업을 수행했습니다.또한 통계에 영향을 주거나 영향을 받을 수 있는 중요한 변경 사항을 출시할 때 작업을 따라잡기 위해 작업 주기가 끝나도록 강제했습니다.

10g 이상의 Oracle 버전에서는 최적화 프로그램이 "좋은" 실행 계획 결정을 내리기 위해 테이블과 인덱스에 대한 최신 통계가 필요합니다.통계를 얼마나 자주 수집하는가는 까다로운 작업입니다.이는 애플리케이션, 스키마, 데이터 속도 및 비즈니스 관행에 따라 다릅니다.이전 버전의 Oracle과 호환되도록 작성된 일부 타사 앱은 새로운 최적화 프로그램에서 제대로 작동하지 않습니다.이러한 애플리케이션에서는 DB가 규칙 기반 실행 계획으로 다시 돌아갈 수 있도록 테이블에 통계가 없어야 합니다.그러나 평균적으로 Oracle은 오래된 통계가 있는 테이블에서 통계를 수집할 것을 권장합니다.테이블을 모니터링하고 상태를 확인하고 오래된지 여부를 분석하도록 테이블을 설정할 수 있습니다.종종 그것으로 충분하지만 때로는 그렇지 않습니다.실제로 데이터베이스에 따라 다릅니다.내 데이터베이스에는 성능을 유지하기 위해 야간 통계 수집이 필요한 OLTP 테이블 세트가 있습니다.다른 테이블은 일주일에 한 번 분석됩니다.대규모 dw 데이터베이스에서는 전체 DB 로드 및 성능에 영향을 주지 않고 정기적으로 분석하기에는 테이블이 너무 크기 때문에 필요에 따라 분석합니다.따라서 정답은 애플리케이션, 데이터 변경 및 비즈니스 요구 사항에 따라 다르다는 것입니다.

오래된 통계로 인해 쿼리 계획이 변경될 수 있는 위험과 새로운 통계로 인해 쿼리 계획이 바람직하지 않게 변경될 위험 사이의 균형을 유지해야 합니다.

ISSUE 테이블과 CREATE_DATE 열의 값이 다소 단조롭게 증가하는 버그 데이터베이스가 있다고 가정해 보겠습니다.이제 이 열의 값이 2008년 1월 1일부터 2008년 9월 17일 사이에 균일하게 분포되어 있음을 Oracle에 알려주는 히스토그램이 이 열에 있다고 가정합니다.이를 통해 최적화 프로그램은 지난 주에 생성된 모든 이슈(예:9월 7~13일).하지만 애플리케이션을 계속 사용하고 통계가 업데이트되지 않으면 이 히스토그램의 정확도가 점점 낮아집니다.따라서 최적화 프로그램은 "지난주에 생성된 문제"에 대한 쿼리가 시간이 지남에 따라 점점 더 정확해질 것으로 예상하고 결국 Oracle이 쿼리 계획을 부정적으로 변경하게 만들 수 있습니다.

데이터 웨어하우스 유형 시스템의 경우 통계를 전혀 수집하지 않고 동적 샘플링에 의존하는 것을 고려할 수 있습니다(optimer_dynamic_sampling을 레벨 2 이상으로 설정).

일반적으로 데이터베이스에서 대량 삽입이나 빅 데이터 변경이 자주 발생하는 등 강력한 타당성이 없는 한 전체 데이터베이스에 대해 그렇게 자주 통계를 수집하는 것은 권장되지 않습니다.이 빈도로 데이터베이스에 대한 통계를 수집하면 쿼리 실행 계획이 새로운 잘못된 실행 계획으로 변경될 수 있습니다. 이로 인해 새로운 잘못된 계획의 영향을 받는 모든 쿼리를 조정하는 데 많은 시간이 소요될 수 있습니다. 이것이 바로 수집의 영향을 테스트해야 하는 이유입니다. 테스트 데이터베이스에 대한 새로운 통계를 수집하거나 이에 대한 시간이나 인력이 없는 경우 최소한 새 통계를 수집하기 전에 원래 통계를 백업하여 대체 계획을 유지해야 합니다. 새 통계를 사용한 후 쿼리가 예상대로 수행되지 않은 경우 원래 통계를 쉽게 복원할 수 있습니다.

원래 통계를 백업하고 새 통계를 수집하는 데 도움이 될 수 있으며, 새 통계를 수집한 후 예상대로 진행되지 않은 경우 원래 통계를 다시 복원하는 데 사용할 수 있는 SQL 명령을 제공하는 매우 유용한 스크립트가 있습니다.다음 링크에서 스크립트를 찾을 수 있습니다.http://dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow