Post

Visualizzazione dei post da novembre, 2019

Popola LISTA tabelle target da una lista di tabelle sorgente (BULK COLLECT e FORALL)

Occorre popolare alcune una lista di tabelle dall'ambiente di produzione (sorgente) a quello di test (target). In ambiente di test creiamo un db link tra i due schema che hanno le stesse tabelle. In ambiente di test abbiamo creato l'utente " testimp"  e il database link  "dbltest" verso l'utente  prodimp di produzione. OWNER          DB_LINK        USERNAME   HOST TESTIMP         DBLTEST.WORLD        PRODIMP PROD01 In ambiente di produzione abbiamo creato l'utente "prodimp" e due tabelle A e A1. Le stesse sono state poi create poi in ambiente di test. La procedura ha come parametri in ingresso il numero di righe da fa leggere dalla istruzione fetch bulk collect, il numero di righe dopo il quale effettuare la commit e la lista delle tabelle. CREATE OR REPLACE PROCEDURE testimp.popolatabellabulk3 ( righe IN NUMBER, ncommit IN NUMBER, tabelle IN VARCHAR2) IS v_error_code NUMBER; v_error_msg VARCHAR2(512); TYPE a_rt  IS TABLE

Popola tabella target da una tabella sorgente (BULK COLLECT e FORALL)

Occorre popolare alcune tabelle dall'ambiente di produzione (sorgente) a quello di test (target). In ambiente di test creiamo un db link tra i due schema che hanno le stesse tabelle. In ambiente di test abbiamo creato l'utente " testimp"  e creato il database link  "dbltest" verso l'utente  prodimp di produzione. OWNER          DB_LINK        USERNAME   HOST TESTIMP         DBLTEST.WORLD        PRODIMP PROD01 In ambiente di produzione abbiamo creato l'utente "prodimp" e due tabelle A e A1. Le stesse sono state poi create poi in ambiente di test. La tabella da caricare in ambiente di tet contiene 10010 record. La procedura ha come parametri in ingresso il numero di righe da fa leggere dalla istruzione fetch bulk collect e ogni quante righe lette effettuare la commit. CREATE OR REPLACE PROCEDURE TESTIMP.popolatabellabulk2 ( righe IN NUMBER, ncommit IN NUMBER) IS v_error_code NUMBER; v_error_msg VARCHAR2(512); TYPE a_rt IS

Popola tabella target da una tabella sorgente

Occorre popolare alcune tabelle dall'ambiente di produzione (sorgente) a quello di test (target). In ambiente di test creiamo un db link tra i due scema che hanno le stesse tabelle. In ambiente di test abbiamo creato l'utente " testimp"  e creato il database link  "dbltest" verso l'utente  prodimp di produzione. OWNER          DB_LINK        USERNAME   HOST TESTIMP         DBLTEST.WORLD        PRODIMP PROD01 In ambiente di produzione abbiamo creato l'utente "prodimp" e due tabelle A e A1. Le stesse sono state poi create poi in ambiente di test. 1) La procedura seguente popola la tabella di target scritta nel codice e utilizza un cursore per leggere le righe della tabella sorgente e utilizza una variabile per impostare il numero di righe da leggere prima di effettuare la commit; CREATE OR REPLACE procedure testimp.Popolatabella1  IS v_error_code NUMBER; v_error_msg VARCHAR2(512); n_read number; tot_row number; BEGIN n_re

BULK COLLECT e FORALL

Prima di tutto ricordiamo che fa la fetch: FETCH <nome cursore> [(<lista di variabili>)]; Il comando fetch assegna i valori degli attributi selezionati dal cursore (e quindi una singola riga alla volta) ad una lista di variabili. Dopo un comando di fetch, il cursore avanza alla successiva tupla nell'insieme del risultato dell’istruzione select ottenuto con il comando open. Da notare che le variabili nella lista devono avere lo stesso tipo di dati dei valori delle tuple selezionate. Dopo che tutte le tuple sono state processate, si utilizza il comando close per chiudere e disabilitare il cursore. BULK COLLECTION viene usato quando si vogliono estrarre righe multiple con una sola operazione di fetch. FORALL: usato per effettuare insert, update  e delete di righe multiple contemporaneamente. In una procedura pl/sql possono esserci istruzioni pl/sql che vengono eseguite dal motore PL/SQL e istruzioni sql che vengono eseguite dal motore SQL. Lo switch tra i due m

Install Oracle Client 11 on centos 7.4

Immagine
Il cliente Oracle contiene un set di librerie e utility per connettersi ad un database Oracle. Contiene API come ODBC, OCCI, OCI, JBD e Pro*C e utility come Sql Plus. Effettuare il download dell'Instant client da Oracle. Individuare la versione linux da scaricare. [root@coslab02 ~]# uname -r 3.10.0-693.5.2.el7.x86_64 Scaricare i pacchetti: instantclient-sdk-linux.x64-11.2.0.4.0.zip instantclient-sqlplus-linux.x64-11.2.0.4.0.zip instantclient-basic-linux.x64-11.2.0.4.0.zip Creare la directory seguente dove  trasferire i suddetti file in formato zip. [root@coslab02 oracle]# mkdir -p /u01/app/oracle [root@coslab02 oracle]# ls -lrt totale 60732 -rw-r--r-- 1 root root 60704657 13 nov 11.39 instantclient-basic-linux.x64-11.2.0.4.0.zip -rw-r--r-- 1 root root   643089 13 nov 11.39 instantclient-sdk-linux.x64-11.2.0.4.0.zip -rw-r--r-- 1 root root   834491 13 nov 11.39 instantclient-sqlplus-linux.x64-11.2.0.4.0.zip Effettuare l'unzip di tutti i file

Connesione da client 12 a database 9i [ORA-03134]

Immagine
La connessione da un client 12c a un database 9i restituisce il seguente messaggio di errore: SQL> conn B00/B00@RIVS ERROR: ORA-03134: Connections to this server version are no longer supported. Il problema persiste anche se si modifica sul client il file sqlnet.ora inserendo i parametri seguenti SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8 SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 Soluzione: creare un dblink tra un istanza ponte in versione 11gr2 e il database oracle 9i. Sull'istanza ponte 11gr2 (LST) creiamo un db link privato così da accedere alla istanza 11gr2 non con utenza sys. Verificare che l'istanza 11gr2 raggiunga il server 9i oracle@serverdb01:/u01/app/oracle/product/11gR24/network/admin> tnsping RIVS TNS Ping Utility for Linux: Version 11.2.0.4.0 - Production on 12-NOV-2019 17:05:53 Copyright (c) 1997, 2013, Oracle.  All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_

ORA-04031: Unable To Allocate 32 Bytes Of Shared Memory ("shared pool","select tablespace_id, rfno, ...","SQLA","tmp")

La SGA è frammentata vuol dire che il db non trova un’area di memoria contigua. Da quanto tempo sta su il database ps -ef | grep pmon oracle    5307     1  0  2018 ?        00:00:25 ora_pmon_TEST01 -->  attivo dal 2018 ma non si sa il mese oracle   32301     1  0 Mar04 ?        00:50:09 ora_pmon_RILP11  --> attivo da aprile 2019 Workaround:  riavviare il database. Questo equivale ad effettuare anche un "Alter system flush shared_pool;" Dopo questo flush o riavvio del db, tutte le istruzioni memorizzare nella Shared pool sono cancellate e quindi una sql statement, già eseguita precedentemente al flush, ora ci impiegherà più tempo rispetto all'ultima esecuzione perché l’istruzione non è più in memoria.

ORA-01658: unable to create INITIAL extent for segment in tablespace

ORA-01658: unable to create INITIAL extent for segment in tablespace TS_PEPT_DATA Vuol dire che non c'è sufficiente spazio contiguo per allocare INITIAL extent per la creazione di un segment. Soluzione: aggiungere un datafile. Vedere post seguente  Add Datafile

EXPDP e IMPDP eseguito da un utente non sysdba

Test eseguito su Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 Creare una direcotry di dump e dare le grant di lettura e scrittura all'utente. SQL> conn /as sysdba SQL> create or replace directory DIR_EXP as '/u01/app/oracle/export'  -- verifica select * from dba_directories SQL>  grant READ, WRITE ON DIRECTORY dir_exp to BIBI  La seguente grant concede all'utente i privilegi di esportare i dati con l'utility datapump. Questa grant concede inoltre all'utente l'accesso a tutti i dati di tutti gli schema del database. Concedere con cautela!!!! SQL>  grant DATAPUMP_EXP_FULL_DATABASE  to BIBI Eseguiamo la export di due tabelle. [oracle@ab03 export]$ /expdp bibi/bibi  directory= DIR_EXP   tables=BIBI.CONTRATTI,BIBI.EMP dumpfile=exp_BIBI_tables.dmp logfile=exp_BIBI_tables.log Per effettuare l'import invece assegnare all'utente le seguenti grant, SQL> grant DATAPUMP_IMP_FULL_DATABASE  to BIBI

UDE-00018: Data Pump client is incompatible with database version 11.2.0.4.0

L'export di due tabelle di uno schema  eseguito con l'utility DataPump ha restituito il seguente messaggio di errore: [oracle@lab03 dpdump]$ expdp bibi/bibi@S11TEST1 tables=CONTRATTI,EMP dumpfile=exp_BIBI_tables.dmp logfile=exp_BIBI_tables.log UDE-00018: Data Pump client is incompatible with database version 11.2.0.4.0 La causa è legata alla versione di datapump che si usa. Infatti eseguendo il comando seguente si evince che stiamo usando il datapump versione 12 installata sullo stesso server. [oracle@lab03 dpdump]$ which expdp /u01/app/oracle/product/ 12.2.0 /dbhome_1/bin/expdp La versione del datapump utility non può essere maggiore della versione del database. Lanciare il datatpump usando dal path della versione 11. [oracle@lab03 dpdump]$ cd /u01/app/oracle/product/11.2.0.4/dbhome_1/bin [oracle@coslab03 bin]$ / u01/app/oracle/product/11.2.0.4/dbhome_1/bin/expdp tables=CONTRATTI,EMP dumpfile=exp_BIBI_tables.dmp logfile=exp_BIBI_t