RDBMS ORACLE - Partition Range By Interval - parte 1

Salve oggi brevemente vi parlo di un paio di bug di oracle, che sono una gran rottura di BIP e sono legati al partizionamento di una tabella by interval su un campo numerico e by interval su campo data.
Inoltre se si aggiunge al primo partizionamento anche un sottopartizionamento by hash che supera le 4 partizioni siamo al top.

Uno si può chiedere perchè utilizzare questo tipo di partizionamento e la risposta come al solito è dentro di voi ed è pure sbagliata. No a parte le cazzate il perchè p molto semplice le partizioni si autocreano e non c'è bisogno di un software che le crei, questo fa si che la gestione viene demandata completamente al database, purtroppo con le conseguenze indicate sotto.
Purtroppo non ho molto tempo per spiegarvi il problema vi rimando alle note che affrontano nel dettaglio i bugs.

• Document  1507993.1 ORA-1841 on Select from Interval Partitioned Table when Predicate is 31-Dec-9999
• Document 1479115.1 Interval Partitioning Essentials - Common Questions - Top Issues Document 1447928.1 PARTITION_COUNT Shows Large Value 1048575 With Interval Partitioning
• Document 754642.1 How the PSTART/PSTOP Numbers are computed when a Interval Partition is used
• Document 1472941.1 Insert Fails With ORA-14300 On Partition Table  

Per quanto riguarda la prima nota esiste un workaround che è quello di non far partire la data dal 01 del mese ma di farla partire dal 17 del mese. Il bug in questo caso è legato alla trasformazione della data Juliana nel normale formato anno mese e giorno.
Il secondo bug invece è una emerita stronza.. ed è legato ad uno pseudo valore massimo di partizioni in oracle che però non ha alcuna attinenza col valore contenuto nel campo.
Per verificare quante siano le partizioni indicate sul sistema e quante ve ne siano realmente basta eseguire la seguente query:


set lines 300
col interval for a30
col TABLE_NAME for a30
select table_name, PARTITIONING_TYPE, STATUS, INTERVAL, PARTITION_COUNT,
(select count(*) from user_tab_partitions pts where pts.table_name = pt.table_name) real_count
from user_part_tables pt
where table_name ='MV_FACT_TDB'
order by table_name;

TABLE_NAME                     PARTITION STATUS   INTERVAL      PARTITION_COUNT        REAL_COUNT
------------------------------ --------- -------- ------------- ---------------------- ----------
MV_FACT_TDB                    RANGE     VALID    100                         1048575          2


Dove la tabella ha in realtà 2 partizioni sottopartizionate by hash 4-

Vi lascio alla lettura delle note e dei relativi workaround, appena ritrovo i test che avevo fatto vi integro questo scarno documento.