가끔은 옳은 것으로 생각되는 SQL 쿼리로 인해 불합리한 결과가 나오는 경우가 있습니다.언제 올바른 SQL이 잘못된 결과를 산출합니까
이제 실제로 Oracle 버그이며 SQL이 올바른 것으로 밝혀졌습니다.
많은 지름길과 좌절을 막는 지름길이 있습니까?
가끔은 옳은 것으로 생각되는 SQL 쿼리로 인해 불합리한 결과가 나오는 경우가 있습니다.언제 올바른 SQL이 잘못된 결과를 산출합니까
이제 실제로 Oracle 버그이며 SQL이 올바른 것으로 밝혀졌습니다.
많은 지름길과 좌절을 막는 지름길이 있습니까?
당신이 할 수있는 한 가지는 Oracle 10g에서 소개 된 NO_QUERY_TRANSFORMATION 힌트를 적용하는 것입니다.
원하는 결과가 나오면 오라클 버그를 직면하고 있음을 알 수 있습니다. 아무런 힌트도 쿼리의 실제 결과를 변경하지 않아야합니다.
동시에 실행 계획이 만족스럽지 않을 경우를 제외하고는 문제를 해결했을 수도 있습니다.
당신이 직면하고있는 버그 (알려진 버그인지 잘 모름)는 오라클 옵티마이 저가 더 나은 실행 계획 (병합 뷰 등)을 위해 쿼리를 변환 할 때 원래 쿼리의 의도를 올바르게 해석하지 못할 수 있다는 것입니다.). 힌트를 사용하면 옵티마이 저가 그렇게하지 않도록 지시합니다.
이 현상은 인라인 성능 뷰가 포함 된 복잡한 쿼리에서 자주 발생합니다.
현재이 문제를 재현 할 수있는 코드 샘플이 없지만 아직 작업 중입니다. 을 위해 사실이하면 힌트가 무엇을 의미하는지 것으로 보인다 -이 발견 : UPDATE
쿼리 블록에 대한 마지막, 우리가 볼 수있는 결과에 영향을 줄 수있는 해당 뷰 병합 또는 하위 쿼리 unnesting주의를함으로써 쿼리 블록이 완전히 사라질 수 있습니다. 즉, 명명 된 쿼리 블록이 쿼리의 "변환 된"상태가되고 시스템 생성 쿼리 블록 이름이 대신 사용됩니다. 위의 첫 번째 설명 플랜에서 시스템 생성 쿼리 블록 및 별칭 이름의 예를 볼 수 있습니다. 물론이 의미는 명명 된 블록이 실제로 존재하지 않기 때문에 명명 된 쿼리 블록에 대한 일부 힌트가 예상대로 작동하지 않을 수 있음을 의미합니다.
그러나 두 가지 옵션이 있습니다. 첫째, 우리는 상세한 설명 계획을 사용하여 시스템 생성 쿼리 블록/별칭을 식별 한 다음이 식별자를 힌트로 사용할 수 있습니다. 조나단 루이스 (Jonathan Lewis)는이 기술에 대해 좋은 토론을하고 있습니다. 또는 Oracle은 명명 된 쿼리 블록을 "사라지게"하는 변환을 피하기 위해 NO_QUERY_TRANSFORMATION 힌트를 제공합니다. 그러나 이것은 오라클이 쿼리를 작성하는 방식과 정확히 일치시킬 것을 의미하므로 상당히 과감한 접근 방식입니다. 변환 손실 비용은 처음에는 사라지는 쿼리 블록에 적용해야 할 힌트의 이점보다 훨씬 클 수 있습니다.