v$sqlarea v$sqltetx v$sql_monitor select SQL_TEXT  from v$sqlarea  where address in (select sql_address from v$session where sid=&sid); select SQL_TEXT  from v$sqlarea  where address in  (select sql_address  from v$session where sid in (select s.sid from v$process p, v$session s where s.paddr=p.addr and p.spid =&spid));

 Se il db è lento e ci accorgiamo dal comando TOP che esite un processo oracle che occupa la CPU quasi al 90 - 100% possiamo capire chi è la sessione oracle legata al processo del sistema operativo. SQL> Select s.sid from v$session s,v$process p where p.spid=PID  and s.paddr=p.addr dove PID è recuperato dalla colonna PID del comando TOP Una volta recuperato il sid si può risalire alla username , machine , stato SQL> select username, machine, status, sql_id from v$session where sid= Risalgo al tipo di statement in corso SQL> select * from v$sql where sq_id= SQL> select * from v$sql_ext where sql_id=

Cosa è UTL_HTTP? E' un package oracle usato in query SQL o in PL/SQL che permette di accedere a dati in internet tramite protocollo http. Da Oracle 9i Release 2, il pacchetto UTL_HTTP può accedere alle risorse di rete anche su HTTPS oltre che HTTP.  Per abilitare l'accesso HTTPS dal pacchetto UTL_HTTP occorre installare un WALLET che permette di gestire i certificati. Riferimento: https://oracle-base.com/articles/misc/utl_http-and-ssl https://doyensys.com/blogs/how-to-access-https-ssl-url-via-utl-http-using-the-orapki-wallet-command/ Installazione WALLET 1) Creare la directory contente il wallet mkdir -p /u01/app/oracle/admin/SISV/wallet 2) Scaricare in locale i certificati. Ho scaricato per comodità sotto una cartella CRT. mkdir -p /u01/app/oracle/admin/SISV/wallet/CRT I certificati di Google sono due GTS Root R1.crt e GTS CA 1C3.crt da scaricare separatamete come singolo certificato e non come catena di certificato. 3) Creare il wallet usando una password (esempio svilAnag

  Datapump Import generates the following error messages: ORA-31655: no data or metadata objects selected for job ORA-39039: Schema expression " IN ('<schema name>')" contains no valid schemas Originally the Export was performed on Table Mode as follows: DUMPFILE= EXCLUDE= CONTENT= LOGFILE= TABLES=            ====> notice that export is on Table mode. While Import is performed on Schema Mode as follows: DUMPFILE= TABLE_EXISTS_ACTION= CONTENT= LOGFILE= SCHEMAS=          ====> notice that we are trying to import on Schema level.  CAUSA: ORA-39039<Schema expression " IN ('<schema name>')" contains no valid schemas, which points to the fact that the dump file contains no data regarding the schema. Datapump export was performed on table mode, so the import should also be performed on table mode as there is no valid information in the dump file about the schema. SOLUZIONE: 1. Remove Schemas parameter from the import parameters. - OR -

  Il Doc ID 1927827.1 indica come disabilitare la funzionalità del partner agent così da evitare che gli alert di agenti non raggiungibili che vengono generati dai partner agent in caso di latenza di rete nell'ambiente.  Ad esempio un partner agent (kudb) è un agent che è assegnato ad un altro agent (orapp1) come il  "partner" or "Buddy" con lo scopo di monitorare da remoto la disponibilità dell’agent e il suo host (orapp1). Durante l'installazione non è possibile selezionare alcuna opzione di questo tipo per fornire un agente partner. Questo agente partner viene selezionato automaticamente nella network più vicina,  ad esempio nella stessa subnet dell’agent che deve essere monitorato. In genere, se si dispone di 2 nodi, un agent del nodo sceglie l'agent dell'altro nodo come agent partner. Se gli agenti sono autonomi, il calcolo si basa sulla prossimità. Un agent può essere un partner (remote monitor) di multiple agents. Ad un agent può essere assegn

L'errore è comparso durante la creazione di una tabella TAB2 dalla TAB1 che ha una colonna di tipo LONG RAW e a cui è applicata la funzione TO_LOB. SQL>  Create Table <TAB2>  as     Select   col_a , TO_LOB(col_b)     From <TAB1>; TO_LOB converte una colonna di tipo LONG o LONG RAW in LOB. La versione del db in cui si è verificato l'errore è 11.2.0.4 ed è stato risolto agendo sulla definizione della sequence IDGEN1$ che era impostata ad un valore incrementare troppo basso rispetto al valore di default 50. SQL> alter sequence IDGEN1$  increment by 50;

  Per aggiornare il valore della sequence ad un valore differente, si può operare in due modi: 1) aggiornare l'incemento come descritto nel post SEQUENCE: aggiornare una sequence ad un valore 2) oppure occorre droppare e ricreare la sequence. DROP SEQUENCE schema_name.sequence_name; CREATE SEQUENCE schema_name.sequence_name START WITH new_value; Oppure eseguire la seguente query: select 'CREATE SEQUENCE '|| sequence_owner ||'.'|| SEQUENCE_NAME || ' START WITH ' || LAST_NUMBER || ';' from dba_sequences where sequence_owner = <schema_name> nd last_number <> 1

L'errore "ORA-01591: blocco trattenuto da transazione distribuita in dubbio", significa che nel database sono presenti alcune transazioni non committate. C'è stato un tentativo di accesso a una risorsa bloccata da una transazione di commit a due fasi (two-phase commit trnsaction) morta che è in stato "prepared". È necessario eseguire il "rollback force" o il "commit force" per le transazioni non committate per risolvere questo problema. Query per individuare le transazioni non committate o pending (in sospeso) con il seguente script che genera anche il comando di forza di rollback SQL> select 'rollback force '''||local_tran_id||''';' from DBA_2PC_PENDING where state='prepared'; SQL> select 'commit force '''||local_tran_id||''';' from DBA_2PC_PENDING where state='prepared'; Che cos'è una in-doubt distributed transaction ? Le transazioni distribuite po

 Mettere sotto trace un instanza. 1) Accedere come sys ed avviare la trace. SQL>  EXEC DBMS_System.Set_Ev(304, 30209, 10046, 12, ''); 2) Lanciare la sessione da monitorare che in questo caso potrebbe essere anche una procedura lanciata via web dall'applicazione:  3) Al termine della procedura chiudere la trace  SQL>  EXEC DBMS_System.Set_Ev(304, 30209, 10046, 0, ''); 4) Creare il report con il seguente comando: tkprof <trace_file_nm>.trc <output_rpt_nm>.txt

Rientra nelle tecnince di SQL Tuning, E' vantaggioso perchè individua tutte le sql statements eseguite tra lo start e la fine del trace. E' un tool free ma occorre avere le grant di dba. Il file TKPROF contiene queste info call     count       cpu    elapsed       disk      query    current        rows ------- ------  -------- ---------- ---------- ---------- ----------  ----------------------------------------- Parse        1      0.01       0.00          0          0          0           0 Execute      1      0.00       0.00          0          0          0           0 Fetch        6      0.38       0.38          0       8133          0          66 ------- ------  -------- ---------- ---------- ---------- ----------  ----------------------------------------- total        8      0.39       0.39          0       8133          0          66 count    = number of times OCI procedure was executed - parse time  --> se molto alto suggerisce di controllare il sistema piuttosto che

To View the pending transactions: SELECT LOCAL_TRAN_ID, GLOBAL_TRAN_ID, STATE, MIXED, COMMIT# FROM DBA_2PC_PENDING; SQL> select 'rollback force '''||local_tran_id||''';' from DBA_2PC_PENDING where state='prepared'; SQL> rollback force '10.26.7211'; The actual transaction entry view is X$KTUXE  ([K]ernel [T]ransaction [U]ndo Transa[X]tion [E]ntry) where the columns correspond to the following sections of the transaction id: select ktuxeusn, ktuxeslt, ktuxesqn, /* transaction id */ ktuxesta status, ktuxecfl flags from x$ktuxe where ktuxeusn= 10 and ktuxeslt= 26;--- and ktuxesqn=7211; Solution 1 to Condition 1: se una riga della DBA_2PC_PENDING non è in x$ktuxe e lo state of the transaction (in DBA_2PC_PENDING) è committed, rollback forced or commit forced then it can be cleaned by: SQL>  select 'EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY( ''' ||local_tran_id||''');'   from DBA_2PC_PENDING ; SQL

Il seguente comando forza l'Optimizer ha utilizzare l'indice PK_SERVIZIO  della tabella servizi. L'HINT quindi forza l'optimizer ad usare un altro piano di esecuzione. Non è detto che se è presente un HINT l'Optimizer lo usa perchè valuta se Hint ha senso. SELECT /* + INDEX  (ser PK_SERVIZIO) */ ut.id_utente, ser.id_servizio ................................ FROM servizi ser, utenti ut, ................... Questo è un esempio di come l'uso di PARALLEL migliora le performance di una query, e abbassa i costi /* Another example with multiple joins, groups etc. But with no hint*/ SELECT customers.cust_first_name, customers.cust_last_name,    MAX(QUANTITY_SOLD), AVG(QUANTITY_SOLD) FROM sales, customers WHERE sales.cust_id=customers.cust_id GROUP BY customers.cust_first_name, customers.cust_last_name;   /* Performance increase when performing parallel execution hint*/ SELECT /*+ PARALLEL(4) */ customers.cust_first_name, customers.cust_last_name,    MAX(QUANTITY_SOLD

ORA-12518/TNS-12518 indica un problema mentre il listener trasferisce la connessione client al processo del server o al processo del dispatcher. TNS-12518 viene registrato nel registro del listener. Il client potrebbe ricevere ORA-12518 o altri errori di disconnessione come ORA-12537.  Come vengono effettivamente effettuate le connessioni al database? Dedicated mode, il client contatta il listener e fornisce il SERVICE NAME del database. Quindi il listener genera un server process dedicato e trasferisce la connessione client a questo processo server dedicato. TNS-12518 indica un problema durante il trasferimento della connessione client al processo server. Shared Server mode,  il client del database contatta il listener e fornisce il  SERVICE NAME del database. Quindi il listener trasferisce la connessione client a uno dei dispatcher configurati per quel servizio. TNS-12518 indica un problema durante il trasferimento della connessione client al processo del server di distribuzione. S

Oracle Database relase è individuato dal valore version_full della tabella  V$INSTANCE. La versione è indicata nella seguente forma:  major release numeral.0.0.0.0 - 1 - major release numeral è l'anno di rilascio del database software -2- release update version (RU)  trimestrale -3- release updates revision (RUR) trimestrale -4- oracle Database increment version. Questa nomenclatura può essere applicata agli aggiornamenti nelle versioni future e si applica a tutte le versioni precedenti alla 18c. Ad esempio: 12.1.0.1, 12.2.0.1 -5- questo numero è riservato per scopi futui Ad esempio 18.2.1 Indica un database 18 release 2, update revision 1

Il package DBMS_NETWORK_ACL_ADMIN fornisce un interfaccia per amministrare network access control lists (ACL). ACLs sono usati per controllare l'accesso degli utenti a servizi e risorse di rete esterna  dal database attravero delle utility package PL/SQL di rete che includono UTL_TCP , UTL_HTTP , UTL_SMTP and UTL_INADDR .   Oracle recommanda di non usare sottoprogrammi deprecati in nuove applicazioni. Il support per deprecated features è soltanto disponibile per backward compatibility. I seguenti sottoprogrammi pacchetto DBMS_NETWORK_ACL_ADMIN PL/SQL sono deprecati dalla release Oracle Database 12c: CREATE_ACL Procedure ADD_PRIVILEGE Procedure DELETE_PRIVILEGE Procedure ASSIGN_ACL Procedure DROP_ACL Procedure ASSIGN_WALLET_ACL Procedure CHECK_PRIVILEGE Function CHECK_PRIVILEGE_ACLID Function UNASSIGN_ACL Procedure UNASSIGN_WALLET_ACL Procedure Sono stati sostituite con nuovi equivalenti.  Quando viene effettuato un upgrade da 11g a version 12c o più alte gli ACLs mancano Gli ACLs d

Per individuare le fk associate ad una tabella: select c.owner , c.table_name, c.constraint_name from ALL_CONSTRAINTS c where r_constraint_name in ( select constraint_name from all_constraints where owner ='<schema>' --and constraint_type <> 'R' and table_name='<nometabella>' ) and c.constraint_type ='R';

ORA-24247 - network access denied by access control list (ACL) ACL = Access Control List è la lista degli utenti che possono accedere ad host esterni tramite risorse di rete UTL_TCP , UTL_SMTP , UTL_MAIL and UTL_HTTP usando diverse PL/SQL APIs. Attraverso le seguenti procedure viene caricato la lista nel XML DB repository. Creare il file acl. BEGIN DBMS_NETWORK_ACL_ADMIN.create_acl (   acl          => '/sys/acls/<nome_acl>.xml',   description  => 'ACL /sys/acls/ <nome_acl>. xml',   principal    => 'SYS',   is_grant     => true,   privilege    => 'connect'); COMMIT; END; acl : è il nome del file ACL XML e la directory dove viene generato description : è la descrizione dell’acl principal : indica il primo user o ruolo che ha i privilegi is_grant : indica se quell’utente può avere i privilegi o meno privilege : connect è il privilegio dell’utente sys può accedere ai servizi di rete UTL_TCP , UTL_SMTP , UTL_MAIL and UTL_HTTP usa

 Per effettuare la sottoscrizione e scaricare i pacchetti ufficiali dal sito Redhat occorre registrarsi a quest'ultimo. # subscription-manager register inserire login e pwd #  subscription-manager list --available Per esercitazioni su server locali cercare  Subscription Name: Red Hat Developer Subscription for Individuals Copiare il codice Pool Id da mettere nel seguente comando #  subscription-manager attach --pool <Pool Id> Verificare che sia popolato il file "redhat.repo" sotto /etc/yum.repo.d/