Chiappa, eu esqueci de mencionar.

Eu usei a query como passei para testar sua execução pois estava com
preguiça de setar as binds :P

Na verdade a query roda dessa forma:


SELECT  fcal.business_owner_dim_id,
fcal.date_dim_id,
dprd.call_type_cd,
DPRD.call_type_nm,
fcal.gl_product_dim_id,
CM.CLASS_OF_SERVICE_ID,
TRUNC (SYSDATE) start_effective_date,
SUM (billable_minutes) minutes,
COUNT ( * ) calls,
SUM (FCAL.ACTUAL_CONNECTIONS) connections,
SUM (netbasetotcallamt) revenue,
ut.USE_TYPE_CATEGORY,
:g_msg_program,
SYSDATE,
:g_msg_program,
SYSDATE
 FROM   gdwhs_adm.f_call fcal,
gdwhs_adm.d_product dprd,
ODS_SFDC.SFDC_BTC_GL_COS_MAP cm,
gdwhs_adm.d_use_type ut
WHERE   partition_key BETWEEN :i_6c_bi_from_date AND :i_refresh_date
AND fcal.product_dim_id = dprd.product_dim_id
AND FCAL.GL_PRODUCT_DIM_ID = CM.GL_PRODUCT_DIM_ID
AND FCAL.USE_TYPE_DIM_ID = UT.USE_TYPE_DIM_ID
GROUP BY   fcal.business_owner_dim_id,
fcal.date_dim_id,
dprd.call_type_cd,DPRD.call_type_nm,
fcal.gl_product_dim_id,
ut.USE_TYPE_CATEGORY,
CM.CLASS_OF_SERVICE_ID;

Dessa forma, o indice também não foi ativado.

Chiappa, me corrija se eu estiver errado, por favor. No caso do indice
quando usamos uma função.

Nessa query, o predicado não está usando função alguma (partition_key)
apenas o valor pelo qual essa coluna deve ser comparada, que no caso é
sysdate - 6 meses.

Se eu utilizar a mesma clausula em um count, por exemplo, então o indice é
utilizado:

select count(*) from f_cal
WHERE   partition_key BETWEEN ADD_MONTHS (TRUNC (SYSDATE, 'mm'), -6)
                             AND  SYSDATE


SQL> set pages 999 lines 180
SQL> explain plan for
  2  select count(*) from
  3  gdwhs_adm.f_call fcal
  4  where partition_key BETWEEN ADD_MONTHS (TRUNC (SYSDATE, 'mm'), -6) AND
 SYSDATE;

Explained.

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3191905543

--------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name                       |
Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ
Distrib |
--------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                            |
  1 |     8 |    75   (0)| 00:00:02 |       |       |        |      |
     |
|   1 |  SORT AGGREGATE                    |                            |
  1 |     8 |            |          |       |       |        |      |
     |
|*  2 |   PX COORDINATOR                   |                            |
    |       |            |          |       |       |        |      |
     |
|   3 |    PX SEND QC (RANDOM)             | :TQ10000                   |
  1 |     8 |            |          |       |       |  Q1,00 | P->S | QC
(RAND)  |
|   4 |     SORT AGGREGATE                 |                            |
  1 |     8 |            |          |       |       |  Q1,00 | PCWP |
     |
|*  5 |      FILTER                        |                            |
    |       |            |          |       |       |  Q1,00 | PCWC |
     |
|   6 |       PX BLOCK ITERATOR            |                            |
 20M|   155M|    75   (0)| 00:00:02 |   KEY |   KEY |  Q1,00 | PCWC |
     |
|   7 |        BITMAP CONVERSION COUNT     |                            |
 20M|   155M|    75   (0)| 00:00:02 |       |       |  Q1,00 | PCWP |
     |
|*  8 |         BITMAP INDEX FAST FULL SCAN| F_CALL_PARTITION_KEY_BMIDX |
    |       |            |          |   KEY |   KEY |  Q1,00 | PCWP |
     |
--------------------------------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6)<=SYSDATE@!)
   5 - filter(ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6)<=SYSDATE@!)
   8 - filter("PARTITION_KEY">=ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6) AND
"PARTITION_KEY"<=SYSDATE@!)

22 rows selected.


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com



Em 14 de julho de 2014 17:18, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Bom, a primeira coisa que Salta aos olhos é que vc tá metendo uma
> alteração na coluna partition_key :
>
>
> WHERE   partition_key BETWEEN ADD_MONTHS (TRUNC (SYSDATE, 'mm'), -6) AND
> SYSDATE
>
> é via função TRUNC, no caso, mas fosse Qualquer outra alteração caímos na
> mesma situação, que é : no RDBMS Oracle, se vc alterar a coluna indexada
> dentro da cláusula WHERE , o índice na esmagadora maioria das vezes é
> Impossibilitado de ser usado - afinal, se vc indexou X . Logicamente não
> vai encontrar TRUNC(x) no índice, nem X+n , nem nada que não seja Apenas ee
> Tão Somente X ....
>  Para esses casos, OU vc cria uma BIND VARIABLE com o valor desejado, ou
> passa a indexar as funções que modificam a coluna, não apenas a coluna em
> si...
>
>   []s
>
>    Chiappa
>
>  
>
  • [oracle_br] Ajuda... Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
    • [oracle_br] ... jlchia...@yahoo.com.br [oracle_br]
      • Re: [ora... Andre Santos andre.psantos...@gmail.com [oracle_br]
      • Re: [ora... Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
        • Re: ... jlchia...@yahoo.com.br [oracle_br]

Responder a