Blz ? Então, a primeira explicação que me vêm à mente é baseada no ** FATO **
de que, ao contrário do que os novatos pensam, ** NEM SEMPRE ** o acesso via
índice é melhor / mais rápido / mais performático para TODOS os casos
(https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6749454952894
tem um caso Clássico disso), E ao colocar um HINT vc ** ENGESSA **, vc **
FORÇA ** o CBO a usar o índice se possível, INDEPENDENTE de isso ser Bom ou
Ruim... A minha Suposição é que nessa tabela com esse índice forçado o COUNT(*)
é obrigado a ler todos (ou quase todos) os blocos do Índice (o que não acontece
com o SQL SEM o COUNT), e devido ao FATO de que essa leitura é feita
bloco-a-bloco, seria muito mais performático se obter os blocos todos de uma
vez via FULL TABLE SCAN, cujo I/O é MULTIBLOCK, lendo Múltiplos Blocos de uma
tacada só.... Essa diferença de performance entre ler uma larga porção de
blocos via index (em single-block) VERSUS se ler essa mesma larga porção de
blocos via TABLE SCAN (em multiblock) é o que estava por trás da diferença de
performance no caso que indiquei e Suponho que é o que está por trás da sua
situação, também : para PROVAR ou DESPROVAR, faça um trace+tkprof de uma sessão
fazendo COUNT com o tal hint, de uma outra fazendo o mesmo COUNT ** sem ** o
HINT e veja o que vc vai ver....
Não é o que vc perguntou mas ** tenho ** que dizer, também : se as minhas
suposições de que a coluna DTA_EXTRACAO é do tipo DATE ** E ** que há índice
considerando essa coluna estão corretas, esse SQL apresenta uma ** Péssima
Qualidade **, ele faz a proeza de numa só vez ele violar pelo menos DUAS best
practices : ele permite CONVERSÂO IMPLÍCITA, ao comparar a string '03-aug-2016'
com a coluna do tipo DATE dta_extracao, ** e ** como cereja do bolo ao mesmo
tempo ele Também mete uma função na coluna indexada - AMBAS as caquinhas podem
fazer um índice não ser usado/levado em conta, imagino que foi daí que veio o
HINT, inclusive - aquela historinha, ao invés de consertar o SQL lixento neguim
sai metendo HINTs...
SE for isso mesmo, a correção desse SQL é simples :
SELECT COUNT(*)
from stg_catalogo_status v
WHERE v.dta_extracao = between TO_DATE('03/08/2016 00:00:00', 'dd/mm/yyyy
hh24:mi:ss')
and TO_DATE('03/08/2016 23:59:59', 'dd/mm/yyyy
hh24:mi:ss');
==> Essas simples alterações tanto eliminam a necessidade de função na coluna
indexada(a TRUNC no caso, que suponho estava aqui para 'eliminar' a porção HORA
da coluna DATE), quanto Também permite comparação de coluna DATE com valores
DATE, yep ??
[]s
Chiappa
