Archivelog mode e nu metal

In quanto appassionato di Oracle e di musica metal (soprattutto nelle sue varianti nu ed heavy), quando ho visto questo video ho pensato di riproporlo!



Il video spiega come mettere un db Oracle 10g in archivelog mode e come sottofondo sonoro propone i mitici System Of A Down.
Per completezza, vi rimando all'ottimo blog dell'autore del video ed alla sua pagina personale su Youtube con altri video interessanti su Oracle.

Buona visione e buon ascolto!

Oracle Streams

Qualche giorno fa, incuriosito dalla lettura di un post di Chen Shapira, ho iniziato a studiare e a fare qualche prova con Oracle Streams, una tecnologia che permette la propagazione e la gestione di dati, transazioni ed eventi nell'ambito di un database, oppure tra un database sorgente ed uno di destinazione.

In sostanza, Oracle Streams consente di replicare uno schema presente su un db sorgente in un db di destinazione, inoltre, ogni istruzione DDL, oppure DML eseguita nell'ambito dello schema da replicare presente sul db sorgente verrà eseguita anche sullo schema replicato presente nel db di destinazione.
Su databases OLTP, il processo di estrazione dei dati non può essere eseguito direttamente poichè interferirebbe con le normali istruzioni DDL/DML, perciò l'architettura Oracle Streams utilizza gli archivelog, decisamente mento intrusivi.
Prima di poter utilizzare uno stream Oracle, è necessario assicurarsi che siano soddisfatti alcuni prerequisiti:

1) configurare opportunamente i due db server in modo tale che sia possibile eseguire tnsping dal db server sorgente a quello di destinazione e viceversa
2) porre in ARCHIVELOG MODE entrambi i database
3) creare un utente per la gestione dello stream Oracle ad entrambi i database
4) creare un db link per la creazione iniziale, da eseguire solo la prima volta, dello schema replica sul db di destinazione mediante le utilities di data pump
5) creare un db link dal db di destinazione a quello sorgente, utile nel caso in cui la creazione iniziale dello schema replica avvenga a livello di rete senza servirsi di un file dmp intermedio (io ho creato anche questo db link in ogni caso)
6) configurazione delle utilities expdp ed impdp sia sul database sorgente sia su qyello di destinazione
7) creare una directory Oracle e una corrispondente directory sul file system del db server sorgente per ospitare lo script generato dalla procedura DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS che si occupa della replica dello schema via stream Oracle.

Supponendo, per comodità che i punti 1) e 2) siano già soddisfatti, parto direttamente dal punto 3). D'ora in poi, la sigla "PROD" identifica il database sorgente e la sigla "TEST" identifica quello di destinazione. Lo schema da replicare sarà l'onnipresente "SCOTT"!

1) OK
2) OK
3) creiamo un utente dedicato alla gestione dello stream, sia su PROD sia su TEST, connettendoci come utente SYS as SYSDBA:

CREATE TABLESPACE streams_tbs DATAFILE '/u01/app/oracle/oradata/streams_tbs.dbf' SIZE 25M;

CREATE USER strmadmin
IDENTIFIED BY strmadminpw
DEFAULT TABLESPACE streams_tbs
QUOTA UNLIMITED ON streams_tbs;

GRANT DBA TO strmadmin;

BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee => 'strmadmin',
grant_privileges => true);
END;

4) impostiamo un db link da PROD a TEST per l'importazione iniziale dello schema da replicare:

-- su PROD
connect strmadmin/strmadminpw@PROD

CREATE DATABASE LINK TEST
CONNECT TO STRMADMIN
IDENTIFIED BY STRMADMINPW
USING 'TEST';

5) ora creiamo anche un db link da TEST a PROD:

-- su TEST
connect strmadmin/strmadminpw@TEST

CREATE DATABASE LINK PROD
CONNECT TO STRMADMIN
IDENTIFIED BY STRMADMINPW
USING 'PROD';

6) configuriamo le utilities di data pump sui due db server mediante la creazione di una directory Oracle chiamata "source" sul db server che ospita PROD e di una directory Oracle chiamata "dest" sul db server che ospita TEST. Le due directories a livello di sistema operativo vanno create con gli appositi comandi del sistema operativo in uso (mkdir, per GNU/Linux):

-- su PROD
conn sys@PROD as sysdba
CREATE OR REPLACE DIRECTORY source AS '/u01/app/oracle/oradata/source';
GRANT READ, WRITE ON DIRECTORY source TO strmadmin;

-- su TEST
conn sys@TEST as sysdba
CREATE OR REPLACE DIRECTORY dest AS '/u01/app/oracle/oradata/dest';
GRANT READ, WRITE ON DIRECTORY dest TO strmadmin;

7) creiamo una directory Oracle e una corrispondente directory sul file system del db server che ospita il database PROD. Questa directory conterrà lo script da eseguire per la replica dello schema SCOTT da PROD a TEST via stream Oracle:

CONNECT strmadmin/strmadminpw@PROD
CREATE OR REPLACE DIRECTORY SCRIPT_DIR AS '/home/oracle/script_dir';

Una volta soddisfatti tutti i requisiti, sul db server che ospita PROD mi sono creato uno script da lanciare come utente strmadmin con il seguente contenuto:

DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'scott',
source_database => 'prod',
destination_database => 'test',
capture_name => 'capture_scott',
capture_queue_table => 'rep_capture_queue_table',
capture_queue_name => 'rep_capture_queue',
capture_queue_user => null,
apply_name => 'apply_scott',
apply_queue_table => 'rep_dest_queue_table',
apply_queue_name => 'rep_dest_queue',
apply_queue_user => null,
propagation_name => 'prop_scott',
log_file => 'exp_scott.log',
bi_directional => false,
include_ddl => true,
instantiation => dbms_streams_adm.instantiation_schema,
perform_actions => false,
script_name => 'schema_replication.sql',
script_directory_object => 'script_dir'
);
END;

Direi che è d'obbligo una spiegazione dei parametri fondamentali impostati, altrimenti non si capisce molto:

* schema_names: il nome dello schema (o degli schemi, separati da virgole) da propagare (in questo caso scott)
* source_database: il database sorgente
* destination_database: il database di destinazione
* capture_name: il nome del processo di cattura configurato per acquisire le modifiche effettuate su PROD
* capture_queue_table: il nome della tabella di accodamento per ogni coda utilizzata da un processo di cattura
* capture_queue_name: il nome di ogni coda utilizzata da un processo di cattura
* capture_queue_user: va impostato a null per indicare che la procedura non può dare il grant di alcun privilegio
* propagation_name: il nome di ciascuna propagazione configurata per propagare le modifiche
* log_file: il nome del file di log generato da expdp
* bi_directional: se impostato a 'false' indica che la propagazione dele informazioni è monodirezionale dal db di produzione a quello di test
* include_dll: impostato a 'true' indica che sia le istruzioni DDL sia quelle DML vanno replicate dal db sorgente a quello di destinazione
* instantiation: se impostato a DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA indica che l'istanziazione dello schema di destinazione verrà effettuata utilizzando le utilities expdp/impdp
* perform_action: se impostato a 'true' consente l'esecuzione dello script PL/SQL, se impostato a 'false' ne memorizza il risultato in un ulteriore script che verrà posizionato nella directory indicata dal parametro 'script_directory_object'
* script_name: impostato con la stringa 'schema_replication.sql'. Questo script verrà creato nella directory Oracle 'script_dir' (/home/oracle/script_dir) e conterrà tutti i passaggi per istanziare lo schema di replica
* script_directory_object: la directory Oracle in cui memorizzare lo script 'schema_replication.sql'

Lanciando lo script non viene avviato lo stream Oracle, quindi nemmeno il processo di replica dell'utente SCOTT sul db TEST, ma viene creato lo script schema_replication.sql nella directory /home/oracle/script_dir che andrà eseguito a parte sempre come utente strmadmin@PROD.
La creazione dello script intermedio consente di verificare se non vi sono stati errori durante l'esecuzione della procedura DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA; in alternativa, è sempre possibile saltare la creazione dello script intermedio e lanciare direttamente la procedura DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA con questi parametri:

DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'scott',
source_database => 'prod',
destination_database => 'test',
capture_name => 'capture_scott',
capture_queue_table => 'rep_capture_queue_table',
capture_queue_name => 'rep_capture_queue',
capture_queue_user => null,
apply_name => 'apply_scott',
apply_queue_table => 'rep_dest_queue_table',
apply_queue_name => 'rep_dest_queue',
apply_queue_user => null,
propagation_name => 'prop_scott',
log_file => 'exp_scott.log',
bi_directional => false,
include_ddl => true,
instantiation => dbms_streams_adm.instantiation_schema,
perform_actions => true
);
END;

Da notare che la direttiva "perform_actions" ora è impostata a true e non sono presenti le direttive "script_name" e "script_directory_object".
Se tutto funziona correttamente, sul db TEST sarà presente una replica esatta dello schema SCOTT del db PROD; ora non resta che testare se una qualsiasi istruzione DDL/DML eseguita sullo schema SCOTT@PROD viene replicata anche su SCOTT@TEST.
Buona replica!!!

Ah, lascio qualche utile link per approfondire l'argomento:
* http://www.dba-oracle.com/t_streams_schema_replication.htm
* http://ca.geocities.com/mosicr@rogers.com/OracleStreams101.htm
* http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_strm_a.htm#ARPLS305

Oracle e SQL Server

Settimana scorsa mi è stato chiesto se fosse possibile condividere l'anagrafica fornitori contenuta in una tabella su un nostro db Oracle con un software di gestione magazzino che utilizza una base dati su piattaforma SQL Server 2005.
Una breve ricerca su Google mi ha portato ai linked servers, ossia componenti di Microsoft SQL Server (io ho usato la versione 2005 Standard Edition) che consentono a questo RDBMS di poter comunicare con sorgenti dati eterogenee come Oracle, oppure AS400 e persino con fogli di calcolo Excel!
Le componenti di un linked server sono due:

* provider OLE DB (una DLL che gestisce la comunicazione con una sorgente dati)
* sorgente dati OLE DB


Cercando una guida che spiegasse come impostare un linked server da SQL Server ad Oracle mi sono imbattuto in questo post sul blog di Greg Wright, davvero chiaro e ben fatto.
Sostanzialmente, Greg suggerisce in prima istanza di installare il client Oracle (possibilmente in una versione compatibile con quella del db Oracle cui ci si deve collegare) sulla stessa macchina su cui è installato SQL Server, quindi, usando Net Manager, oppure modificando manualmente il file tnsnames.ora, si deve configurare un service name che punti al db Oracle desiderato. Nel post, segue la configurazione del linked server ed, infine, un esempio di query lanciata via SQL Server sul db Oracle a cui ci si deve collegare.
In particolare, volendo eseguire una SELECT sul db Oracle via linked server, la sintassi da utilizzare è:

select * from openquery(linked server, 'select * from dbname.tablename where clause')

La chiave dell'istruzione precedente è la funzione openquery il cui scopo è quello di restituire una tabella con il record set della query (il secondo parametro della funzione) eseguito sul db (Oracle) a cui ci si collega mediante linked server (il primo parametro della funzione).
Volendo è anche possibile eseguire join tra tabelle SQL Server e tabelle Oracle con una sintassi del tipo:

select tabellaSQLServer.campo1, X.campo2, X.campo3
from tabellaSQLServer
join openquery(nomeLinkedServer, 'select * from AltraTabella where Condizione=1') X
on tabellaSQLServer.campoSQLServer = X.campoAltraTabella

Bene, è tutto, ora continuo con i miei test di connessione SQL Server - Oracle!

L'ABC del DBA

Lavoro con Oracle da un paio d'anni e da circa uno mi sono messo in testa che da grande farò il DBA, ebbene sì! :-D

Come chiunque si avvicina per la prima volta ad un argomento nuovo, ho fin da subito cercato della documentazione che potesse chiarirmi i vari aspetti di Oracle.
Secondo la mia esperienza, le fonti principali da cui trarre informazioni sono:

* colleghi (molto utile poter chiedere direttamente a chi ne sa di più)
* libri (la vecchia carta stampata è sempre un buon punto di partenza)
* Internet
Dopo aver rotto non poco le scatole a qualche volenteroso collega con tutti i miei dubbi (perdonatemi) e vedendo che il ruolo di DBA mi appassionava sempre più, ho iniziato a sfogliare letteralmente centinaia di pagine in formato pdf sui più disparati argomenti che ruotano attorno a questo RDBMS, iscrivermi a forum, mailing list, gruppi su Facebook, ecc. Tutto ciò mi ha permesso, di volta in volta, di risolvere problemi di varia natura, ad esempio legati all'installazione di Oracle Database Server, oppure alla gestione dei backup, o ancora all'esecuzione di queries SQL per la generazione di report e così via, ma ho sempre avuto la sensazione che mi mancasse un percorso più ordinato (dal punto di vista del DBA, come sempre) del tipo:

BASI DI ORACLE --> INSTALLAZIONE DBMS --> CREAZIONE DB --> GESTIONE BACKUP --> PERFORMANCE TUNING

Purtroppo questo mi ha portato a dover riprendere in mano molte volte le stesse cose perchè magari scoprivo di non averle studiate ed approfondite a sufficienza in precedenza, oppure perchè scoprivo un documento che avrei dovuto studiare prima perdendo, di fatto, molto tempo.

Con questo post mi ripropongo di csotruire una sorta di abecedario (vedi immagine all'inizio del post) utile per approciare in modo ordinato ad Oracle ed alla sua documentazione.

1) BASI DI ORACLE: Oracle Database Concepts è il documento ufficiale Oracle che spiega proprio le fondamenta del famoso RDBMS

2) INSTALLAZIONE: in questo caso viene in soccorso un'intera sezione della documentazione Oracle (sempre versione 10.2 del dbms). Non è necessario leggere tutti i documenti proposti (sono veramente tanti), ma è sufficiente scegliere quello adatto in base alla propria piattaforma hw (32/64 bit) e sw (Microsoft Windows, FNU/Linux, Solaris, ecc)

3) CREAZIONE DB: la guida fondamentale a cui fare riferimento (e anche la più tecnica) è quella denominata Administrator's Guide

4) GESTIONE BACKUP: si può trovare la sezione relativa (Backup and Recovery) nella homepage della documentazione relativa ad Oracle Database Server 10.2 tramite il tab "Administration"

5) PERFORMANCE TUNING: argomento trattato dalla "Performance Tuning Guide" su come configurare e monitorare le prestazioni di Oracle Database Server


I punti sopra indicati costituiscono, a mio avviso, il patrimonio di conoscenze che dovrebbe essere proprio della figura del DBA e da cui partire prima di interessarsi di altri aspetti di questo potente e complesso RDBMS.
Buona lettura!

Oracle Critical Patch Update Gennaio 2009

Martedì 13 Gennaio è stata una giornata piuttosto piena in termini di patch con il rilascio in contemporanea del bollettino di sicurezza MS09-001 di Microsoft, relativo al protocollo SMB di Windows e il Critical Patch Update rilasciato da Oracle per questo primo trimestre del 2009.

Approfitto di questo doppio rilascio per creare un mio personale parallelismo tra l'attività dell'amministratore di sistema e quella dell'amministratore di database relativamente all'installazione delle patches (non ho certificazioni per nessuno dei due ruoli, ma di fatto è ciò di cui mi occupo per lavoro):

1) entrambi devono potersi documentare su eventuali patch updates anche prima che essi vengano rilasciati, allo scopo di raccogliere informazioni sulle vulnerabilità coperte dalle patches, predisporre un sistema di test su cui provarne l'installazione prima di passare in produzione, schedulare l'operazione di update ed avvertire, di conseguenza, gli utenti di un eventuale downtime dei servizi offerti dai server interessati dall'aggiornamento.
In questo senso, un buon punto di partenza lo fornisce la rete. L'amministratore di sistemi Microsoft Windows non attenderà la notifica automatica di Windows Update, ma si avvarrà di siti come il blog di Feliciano Intini, ad esempio; allo stesso modo, il dba Oracle può fare riferimento ad OTN (Oracle Technology Network).
Insomma, l'imperativo è ESSERE SEMPRE INFORMATI!

2) all'uscita di una nuova patch, sia il sysadmin sia il dba devono valutare l'impatto che l'applicazione della patch stessa avrà sui propri server possibilmente testandola, se il tempo lo consente, su una "sandbox", ossia un ambiente di prova.
La fase di testing è fondamentale per assicurarsi che l'update vada a buon fine e che non crei problemi, una volta installato, con la configurazione del server/dbms

3) dopo una necessaria e fondamentale fase di testing, l'applicazione della patch va effettuata anche nell'ambiente di produzione (operazione che dovrebbe avvenire quando gli utenti non sono connessi e che non dovrebbe causare problemi, se è stato effettuato un testing sufficiente, come indicato al punto 2)


Lo scopo di questo post, innanzitutto, è quello di acquisire le competenze necessarie per eseguire l'installazione del CPU di Gennaio 2009 (punto 1), mentre la fase di installazione del patch update in un ambiente di test (punto 2) sarà l'argomento di un post che pubblicherò a breve!

Ok innanzitutto bisogna documentarsi perciò mi dirigo sulla sezione di OTN dedicata ai Critical Patch Update; il mio obiettivo è dare una risposta ad alcune domande:

* quali vulnerabilità vengono risolte dal CPU di Gennaio 2009?
* a quali prodotti (e relative versioni) Oracle si può applicare?
* conviene installarlo o ci sono controindicazioni?
* come si installa?

Il link relativo ai CPU su OTN contiene molte utili informazioni, ad esempio si apprende che i patch update vengono rilasciati su base trimestrale, infatti le prossime date di rilascio saranno:

* 14 Aprile 2009
* 14 Luglio 2009
* 13 Ottobre 2009
* 12 Gennaio 2010

Oltre a questo, OTN fornisce due utili link a risorse che indicano rispettivamente come abilitare la notifica via mail dei CPU non appena questi vengono rilasciati e un documento in formato pdf con le "Best Practices" per installare i patch updates.
In particolare, la pagina su OTN dedicata al CPU di Gennaio 2009 contiene un elenco, che riporto per comodità anche nell'immagine sottostante, con tutti i software e relative versioni di Oracle interessati all'applicazione della patch:


Supponendo, come nel mio caso, di voler applicare la patch alla componente Database Server 10g di Oracle, dalla tabella precedente si nota, ad esempio, come la versione 10.2.0.1 del DBMS non sia supportata (qualche informazione in più la si può leggere anche da questo thread sul forum di OTN), così come versioni di Oracle Database Server antecedenti alla 9.2.0.8, ecc.
Continuando nella lettura della stessa pagina su OTN, si scopre anche che i patch updates sono cumulativi per molti prodotti Oracle (non tutti però), ossia ogni CPU include tutti i fixes del CPU precedente. Fortunatamente questo caso si applica ad Oracle Database Server quindi basterà installare il patch update di Gennaio 2009 per avere anche i fixes dei patch updates precedenti!
Ancora la stessa pagina di OTN contiene una tabella, riportata anche qui di seguito, con la lista dei prodotti interessati dal CPU di Gennaio 2009, i link alle matrici dei rischi (tabelle che riportano l'elenco delle vulnerabilità con relativa descrizione per ciascuna famiglia di prodotti per cui Oracle raccomanda di installare la patch), links a Metalink, ecc.





L'immagine seguente, infine, riporta la tabella prelevata dalla nota Metalink 753340.1 relativa al CPU di Gennaio 2009 in cui viene fornito il riassunto delle note, sempre su Metalink, per accedere alla documentazione e al download del CPU JAN 2009 per varie piattaforme e versioni di Oracle Database Server:


Per questa volta è tutto, di materiale da digerire ce n'è in abbondanza. Nel prossimo post tratterò l'installazione del CPU JAN 2009 sul mio sistema di test, ossia una macchina virtuale Debian GNU/Linux con installato Oracle Database alla versione 10.2.0.4, il tutto su VMware ESXi!

Estendere le funzionalità offerte da Blogger

Ieri mi sono ritrovato con un pò di tempo libero quindi ne ho approfittato per studiare le potenzialità di Blogger, la piattaforma messa a disposizione da Google per creare in modo semplice e veloce un blog, proprio come questo.
Blogger consente, una volta messo in piedi lo scheletro del proprio blog (interfaccia grafica mediante css già pronti all'uso, gadget da inserire nel pannello laterale per arricchire le proprie pagine, ecc), di estenderne ulteriormente le funzionalità mediante l'inclusione di widget creati da terzi, purchè compatibili con la piattaforma stessa. Decisamente interessante per non fare qualche prova!

Per prima cosa ho cercato in rete qualche risorsa che trattasse bene l'argomento e sono capitato su Creareblog. Gli howto presentati da Tenebrae, l'autore del blog, sono veramente tanti e ben fatti e vi consiglio di leggerli se siete interessati all'argomento!

Le modifiche apportate al mio blog sono sia estetiche sia funzionali:

- rimossa la barra superiore aggiunta di default ai blog della piattaforma blogspot (non si incorre in nessuna bega legale facendo ciò, quindi perchè no?)

- Blogger non consente, di default, di pubblicare solo un'introduzione nella homepage per gli articoli troppo lunghi e di pubblicare i post per intero in pagine a parte (raggiungibili dall'utente cliccando su un link del tipo "Leggi tutto"). Ora invece si può! :-D Molto comodo!

- Per differenziare le righe di codice dal resto del testo, durante la composizione dei post utilizzavo i tag pre e tt. Ho quindi modificato il css aggiungendo le righe seguenti:

/* Stile del codice */
.code {
font-family:courier new;
font-size:85%;
}

blockquote.code {
background: Gainsboro;
border: 1px solid LightSlateGray;
padding: 5px 5px;
white-space: pre;
}

Il risultato lo potete vedere qui sopra.

- Ho aggiunto una nuvola di tag al pannello laterale. Sicuramente meno comoda della classica lista di tag bene ordinati, probabilmente fa anche venire il mal di mare, ma a me me piace ;-)

- Ho inserito anche un motore di ricerca che sfrutta quello di Google come base, per gli articoli presenti nel blog (anche questa componente è accessibile dalla barra laterale). Si è trattato di un'aggiunta praticamente obbligata, in quanto rimuovendo la barra superiore di Blogger (vedi punto 1), mi sono ritrovato senza un motore con cui ricercare post nel mio blog.


Nonostante l'obiettivo di questo blog sia più quello di una sorta di block notes in cui appunto esperienze quotidiane, prove, errori combinati da me e altro, purchè ruoti attorno al mondo di Oracle, il solo fatto che qualcuno possa leggere quello che scrivo è per me fonte di soddisfazione. Siccome qualche lettore in più non mi dà certamente fastidio, anzi, commenti ed eventuali proposte di collaborazione sono sempre ben accetti, ho pensato di mettere in pratica gli utili consigli di Creareblog per il posizionamento del mio blog nei principali motori di ricerca, partendo dallo stesso Google, che è quello più utilizzato a livello planetario e passando poi per Live Search di Microsoft e Yahoo.

Oltre all'indicizzazione del mio blog sui principali motori di ricerca, ho seguito anche l'articolo di Creablog relativo alla pubblicazione della sitemap di un sito su Google, Live Search, o Yahoo.
Cos'è una sitemap? Cito testualmente dal post di cui sopra:

[cut]
La Sitemap è un documento che contiene informazioni sui post e sulla struttura gerarchica di un blog. E' molto simile al feed e nel caso del feed in formato ATOM coincidono. La Sitemap del proprio blog può essere inviata ad un motore di ricerca affinchè ne vengano correttamente indicizzate tutte le pagine.

Google Webmaster Tools è il più conosciuto strumento per la segnalazione della propria sitemap e in generale per avere informazioni e statistiche sul proprio sito dal punto di vista del motore di ricerca. Contrariamente a quanto si pensi, segnalare la propria sitemap a Google non comporta un posizionamento migliore nei risultati delle ricerche, al massimo permette di far risultare il nostro blog in un contesto più coerente ai temi che contiene. Segnalare il nostro sito inoltre non accelera il processo di indicizzazione delle pagine. Questo è quanto è esplicitamente dichiarato da Google e che si riscontra effettivamente sul campo.
[/cut]

Google Webmaster Tools permette di avere importanti statistiche per il proprio sito/blog fornite direttamente da Google.

Script di creazione degli utenti

Problema: dato un utente residente sul db di produzione, creare un utente identico in tutto e per tutto al primo, ma sull'ambiente di test.

Soluzione: avviare EM (Enterprise Manager) con il comando emctl da lanciare da un prompt di DOS, oppure da una shell GNU/Linux (come nell'esempio seguente), previa impostazione del SID dell'istanza desiderata, perciò, da GNU/Linux:

$ export ORACLE_SID=SID
emctl start dbconsole

Enterprise Manager per Oracle 10.2.0.4 è accessibile via https all'url che viene riportato dal comando emctl stesso:

oracle@debiandb:~$ emctl start dbconsole
TZ set to Europe/Vatican
Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0
Copyright (c) 1996, 2007 Oracle Corporation. All rights reserved.
https://debiandb:5500/em/console/aboutApplication
Starting Oracle Enterprise Manager 10g Database Control ................. started.
------------------------------------------------------------------
Logs are generated in directory
/u01/app/oracle/product/10.2.0/db_1/debiandb_TEST/sysman/log

Una volta effettuato l'accesso come utente System, dalla pagina principale di EM, scegliendo il tab "Amministrazione", tra le molte voci presenti bisogna cliccare su "Utenti"; così facendo, si accede ad una pagina con la lista degli utenti del db di produzione.
Come si può notare dall'immagine sottostante, bisogna prima di tutto (punto 1) mettere il check sull'utente da copiare (nell'esempio, ho scelto l'utente ADMIN), quindi selezionare la voce "Genera DDL" dal menu a tendina (punto 2) ed infine, cliccare sul pulsante "Vai".


Ciò che si ottiene è un listato simile al seguente:

CREATE USER "ADMIN" PROFILE "DEFAULT" IDENTIFIED BY "*******"
DEFAULT TABLESPACE "TS_CNEXT" TEMPORARY TABLESPACE "TEMP"
QUOTA UNLIMITED ON "TS_CNEXT" ACCOUNT UNLOCK;
GRANT ALTER ANY INDEX TO "ADMIN";
GRANT ALTER ANY PROCEDURE TO "ADMIN";
GRANT ALTER ANY SEQUENCE TO "ADMIN";
GRANT ALTER ANY TABLE TO "ADMIN";
GRANT ALTER ANY TRIGGER TO "ADMIN";
GRANT CREATE ANY INDEX TO "ADMIN";
GRANT CREATE ANY PROCEDURE TO "ADMIN";
GRANT CREATE ANY SEQUENCE TO "ADMIN";
GRANT CREATE ANY TABLE TO "ADMIN";
GRANT CREATE ANY TRIGGER TO "ADMIN";
GRANT CREATE ANY VIEW TO "ADMIN";
GRANT CREATE PROCEDURE TO "ADMIN";
GRANT CREATE SEQUENCE TO "ADMIN";
GRANT CREATE TABLE TO "ADMIN";
GRANT CREATE TRIGGER TO "ADMIN";
GRANT CREATE VIEW TO "ADMIN";
GRANT EXECUTE ANY PROCEDURE TO "ADMIN";
GRANT INSERT ANY TABLE TO "ADMIN";
GRANT SELECT ANY SEQUENCE TO "ADMIN";
GRANT SELECT ANY TABLE TO "ADMIN";
GRANT UNDER ANY TABLE TO "ADMIN";
GRANT UNDER ANY VIEW TO "ADMIN";
GRANT "CONNECT" TO "ADMIN";

E' possibile copiare questo codice e salvarlo in un file di testo chiamato, ad esempio, "crea_admin_da_produzione.sql" (ricordate di impostare la password per l'utente sostituendola agli asterischi messi da EM).
Supponendo che i nomi delle tablespaces tra ambiente di produzione ed ambiente di test coincidano (altrimenti basta modificare lo script SQL di cui sopra), non ci sono altre modifiche da apportare al file!

Sul db di test si può quindi procedere alla creazione dell'utente, copia speculare dell'omonimo presente sul db di produzione, accedendo con un utente con il privilegio sysdba:

SQL> @crea_admin_da_produzione.sql

Et voilà, con un solo comando l'utente è stato creato, con tutti i privilegi replicati dalla produzione! In questo modo si dispone di uno schema vuoto in cui effettuare l'importazione del dump dell'utente di partenza esportato sempre dal db di produzione (cfr Oracle e i backup - Parte I).