RDBMS ORACLE- Come estrarre il nome di una partizione generata automaticamente

Nel caso in cui si partiziona o sottopartiziona una tabella e non si fornisce in input il nome, Oracle lo genera in maniera automatica come SYS_P<xxxx>, a questo punto se si volesse conoscere il nome della partizione, conoscendo solo il valore di partizionamento, occorre andare in join per il campo HIGH_VALUE ed estrarsi il nome della partizione.
Sembra tutto semplice, peccato che il campo HIGH_VALUE è un campo di tipo long il che lo rende un pò ostico in fase di interrogazione. Per ottenere quanto indicato sopra possiamo utilizzare una semplice query che sfrutta xml generator.
Vediamo un caso pratico:

1. Tabella partizionata by LIST 

 

A questo punto vogliamo trovare il nome della partizione che corrisponde a HIGH_VALUE =222.
Per trovare il nome della partizione possiamo eseguire la seguente query:

   

Fatto abbiamo trovato la partizione interrogando un campo long.
Giocando sulla select interna possiamo trovare anche le sottopartizioni ecc.

ODI 11g- Groovy Decrypt Password

Di seguito un semplice script groovy per decriptare le password generate da ODI.

//Created by ODI Studio
import com.sunopsis.dwg.DwgObject;

        /** Development Repository ****/

     def Password_encode="e4yXKDTu5Q6cyJMzpTCLp1in";
// definizione variabili per calcolo password ODI ed DB    
     def strEncodePass=DwgObject.snpsDecypher(Password_encode);
 // output con info su connessione al repository
      println("§*********************   Repository Info *****************************")
      println("§***  Password_encode: "+strEncodePass)
      println("§*********************************************************************")
    
Logicamente la password deve essere criptata con l'encode.sh di ODI.

Il tutto funziona per le versioni di ODI precedenti alla 12c e solo per 12.1.2.
Dalla versione 12.1.3 purtroppo è stato modificato tutto e le password al momento una volta criptate non è più possibile decriptarle.

ODI - Dynamic Topology Connection

Hi,

I came across this interesting situation during a project in this week.

Imagine the following scenario:

You have different target schema, and in thi target schem I have the tables with have the same name and structures.

Your task is to load data in all these differents database schema.

 

Because the target are 23 and since all the tables have the same structures, how can you accomplish that with ODI without creating a lot of duplicate model target?

 

We create a dynamic connection topology connected to execution context as follows:

 

1. Create a context ODI with contains a schema name of database where you want connect
2. Create a variable with contains a execution context.
3. Insert this variable into physical schema in the schema name

 

When the process started the connection changed with the execution context and insert o read data from database schema associate to context.

 

 

 

 

OWM - Come verificare le differenze su una stessa tabella tra workspace diversi - parte II

Nella parte I abbiamo visto come trovare le differenze utilizzando le features del prodotto, adesso vediamo come ottenere lo stesso o quasi risultato non utilizzando le funzioni di prodotto.
Partiamo dal presupposto di dover confrontare una tabella posta nel workspace LIVE ed una posta in un workspace figlio di LIVE e di voler estrarre le differenze.

Per estrarre le differenze effettueremo delle minus tra la vista xxx_HIST filtrata per WS=LIVE e la tabella presente nel WS figlio e viceversa. Per semplificare un pò considereremo sulla tabella xxx_HIST solo che le operazioni fatte sul record devono essere diversa da DELETE. Se poi vogliamo estrarre anche i record cancellati o sul WS figlio o sul LIVE basta omettere la condizione nel filtro.

Come primo step ci posizioniamo nel WS figlio verificando che se già non ci siamo:

...
SELECT DBMS_WM.GetWorkspace  into v_get_owks FROM DUAL;

IF v_get_owks!=v_owks_child THEN
dbms_wm.GotoWorkspace(v_owks_child);
END IF;
...

 A questo punto possiamo fare la prima minus tra ciò che è presente sul LIVE e ciò che è presente nella tabella:

SELECT '||V_TAB_COLUMNS||' FROM
  (SELECT A.* ,  
          ROW_NUMBER () 
           OVER (PARTITION BY WM_workspace,'||V_PKEY_COLS||'
                 ORDER BY WM_workspace,'||V_PKEY_COLS||',
                          WM_CREATETIME DESC,  
                 NVL(WM_RETIRETIME,TO_DATE(''01019900'',''DDMMYYYY'')) DESC) RW
    FROM '||TABLE||'_HIST A)
   WHERE RW=1 AND WM_WORKSPACE=''LIVE'' AND  WM_OPTYPE<>''D'' AND (:v_where)
MINUS 
SELECT '||V_TAB_COLUMNS||' FROM '||TABLE||' WHERE (:v_where)    

dove:
V_TAB_COLUMNS   sono le colonne della vista senza le colonne di prodotto
V_PKEY_COLS        sono le colonne della chiave della tabella  
v_where                    è una eventuale condizione di filtro comune ad entrambe le viste.

Per ottenere le differenze inverse basta invertire la minus.
Questa soluzione tuttavia risulta poco efficiente in quanto è valida solo per i confronti con il WS LIVE.
Quindi anche se possibile utilizzarla la scarterei a priori a favore della soluzione illustrata nell'articolo parte I.
Perchè ne abbiamo parlato? perchè potrebbe essere utile fare un confronto veloce col LIVE e poi avevo scritto la query...