Oracle에 대한 최적화 프로그램 인덱스 비용 조정 매개변수를 설정하는 올바른 방법은 무엇입니까? 개발자로서 저는 이 매개변수가 낮아짐에 따라 성능이 크게 향상되는 것을 목격했습니다. 일반적인 쿼리가 2초에서 200ms로 단축되었습니다. 이 값을 낮추면 데이터베이스에 심각한 문제가 발생할 수 있다는 경고가 인터넷에 많이 있지만 무엇이 잘못되기 시작하는지에 대한 세부 정보는 제공되지 않습니다.
나는 현재 긍정적인 점, 훨씬 향상된 애플리케이션 성능만을 보고 있으며 부정적인 점은 없습니다. 이러한 매개변수를 조정하면 발생할 수 있는 부정적인 영향을 더 잘 이해해야 합니다.
답변1
이 매개변수를 변경하지 않는 것이 권장되는 이유는 최적화 프로그램에 DB 전체에 영향을 미치기 때문입니다. 따라서 특정 쿼리를 조정하기 위해 매개변수를 변경하면 다른 많은 쿼리에도 영향을 미칠 수 있습니다. 따라서 전체 앱을 주의 깊게 테스트하지 않고 프로덕션 환경에서 이를 변경하는 것은 위험합니다.
하지만:
- 개발/테스트 환경에서 설정하고 프로덕션에서 동일한 값을 유지하는 것이 허용될 수 있습니다(OLTP 시스템에서 일반적인 관행이었습니다). 그러나 앱이 전용 DB에서 실행될 것이라고 확신할 수 있습니까? 기본 매개변수 세트를 사용하여 다른 DB에 통합되지 않습니까?
- 매개변수는 Oracle이 CPU 대비 I/O의 상대적 비용에 대한 일부 경험적 방법을 사용하기 때문에 도움이 되며 귀하의 경우 경험적 방법이 충분하지 않아 Oracle은 최적이 아닌 실행 계획을 선택합니다. 경험적 방법을 수정하기 위해 권장되는 방법은 Oracle이 수집하도록 하는 것입니다.시스템 통계DB 머신의 경우 - CPU 속도, 일반 시스템 로드 중에 I/O 시스템에서 단일 블록/다중 블록을 가져오는 데 걸리는 시간 등Oracle 설명서를 참조하세요..
시스템 통계와 최적화 매개변수를 모두 사용하려면 Google에서 검색해 보세요. Jonathan Lewis가 이에 대해 썼습니다(죄송합니다. 이 사이트에서는 링크를 두 개 이상 게시할 수 없습니다).
도움이 되었기를 바랍니다.
답변2
프로덕션 환경에서는 매개변수를 변경하면 안 됩니다. 주요 용도는 다양한 실행 계획으로 성능을 확인하기 위해 계획을 강제로 변경하는 것입니다. 기본적으로 데이터베이스의 모든 인덱스가 다른 액세스 경로보다 사용 비용이 저렴하다는 것을 최적화 프로그램에 제안하는 것입니다. 그리고 이것은 일부 SQL에서는 사실일 수도 있고 다른 SQL에서는 거짓일 수도 있습니다.
좋은 성능 계획이 있으면 최적화 프로그램이 이를 사용하지 않는 이유를 이해하고 수정을 시도해야 합니다(즉, 신선하고 정확한 통계를 사용할 수 없음 -> 신선하고 보다 정확한 통계 수집).
이것이 도움이 되기를 바랍니다, 스테파노
답변3
이 두 매개변수의 기본값은 가장 일반적인 유형의 데이터베이스인 OLTP 시스템에 적합하지 않습니다. 이로 인해 더 많은 전체 테이블 스캔과 잘못된 쿼리가 발생합니다. 일반적으로 라이브로 전환하기 전에 이러한 매개변수를 설정하려고 합니다. 테스트 단계에서 수행합니다.
라이브로 전환한 후 이를 변경하면 잘못된 설정으로 조정된 다른 쿼리가 변경될 위험이 있습니다. 쿼리 계획 대신 응답 시간을 언급하니 데이터베이스 튜닝에 대해 잘 모르는 것 같습니다. 이 매개변수를 건드리면 안 됩니다.
대부분의 DBA는 수정과 설계 사이의 개념 차이를 파악하지 못합니다. 라이브 후에는 수정 작업을 수행하므로 이 매개변수를 주의 깊게 변경해야 합니다. 실제로 시작하기 전에는 설계 및 개발 단계에 있습니다. 바로 이와 같이 매개변수를 조정하는 경우입니다.
그런데, 이러한 매개변수로 시작하기 좋은 곳입니다(생산에 들어가기 전, 현재 수행 중인 작업을 알고 있는 경우에만 참고하세요!)
Optimizer_index_cost_adj=10 최적화 캐싱=90
OLTP용입니다. 일괄 처리의 경우 시작하려는 설정이 매우 다릅니다. 나는 이것을 약간 수정하지만 이러한 설정은 OLTP에서 99%의 경우 최상의 결과를 제공합니다. 하지만 제작에 들어간 후에는 손을 대지 않습니다. 나쁜 경우에는 나쁜 상태로 두고 쿼리를 조정합니다.