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).

Oracle (10g) e i backup - parte II

Finalmente dopo un (bel) pò di tempo ho ritrovato la voglia di tornare a scrivere in questo blog e di riprendere in mano l'argomento dei vari strumenti di backup messi a disposizione da Oracle.
Il primo post verteva sull'uso dei comandi exp ed imp per l'esportazione ed importazione, a caldo, ossia eseguibile anche a database attivo, di uno schema Oracle sfruttando un file binario intermedio (il cosiddetto dump).

Questo secondo post, invece, è relativo ad RMAN (Recovery MANager), un utile strumento messo a disposizione da Oracle per il restore ed il recovery di un database (compresi anche i file fisici presenti su disco fisso, come control files, datafiles, spfile, redo logs, archivelogs, necessari al suo funzionamento).
Come al solito, vorrei focalizzare l'attenzione sull'uso che faccio di RMAN al lavoro, sia per gli ambienti di test, sia per quelli in produzione, senza per questo replicare la già abbondante documentazione esistente sull'uso di questo comando. Se siete interessati ad approfondire l'argomento, come di consueto in coda a questo post ho aggiunto alcuni link (e non dimenticate il buon Google).

Il modo più semplice per invocare RMAN è tramite l'utilizzo della command line, dopo aver specificato il SID dell'istanza Oracle di cui gestire il backup/restore/recovery (per sistemi Microsoft Windows utilizzare il comando set al posto di export):

$ export ORACLE_SID=
$ rman TARGET /

Una volta ottenuto il prompt di RMAN, se ne possono impostare i parametri di funzionamento, eseguire backup, restore (il ripristino di componenti di un db Oracle come datafile, control files, redo logs, ecc. corrotte, ad esempio in seguito alla rottura del disco fisso su cui erano memorizzate), oppure il recovery (effettuato dopo il restore, permette di riportare i dati contenuti in un database nello stato in cui si trovavano prima che si verificasse il guasto, come la rottura di un disco fisso del db server, oppure la corruzione di un file importante per il db, o ancora l'interruzione della corrente elettrica).
In alternativa, è possibile creare un file dei parametri da passare ad RMAN ogniqualvolta esso viene eseguito. Questa soluzione si rivela molto utile quando si vuole schedulare periodicamente l'esecuzione di RMAN mediante strumenti come cron per GNU/Linux, oppure Operazioni Pianificate di Microsoft Windows.

RMAN permette di creare diverse tipologie di backup (full, incrementale), di varie componenti di un db Oracle (datafiles, control file, spfile, redo logs, archivelogs, altri backup di RMAN), in diversi formati (backup pieces, image copies) e su differenti tipologie di supporto (disco fisso, nastro).
RMAN può essere configurato secondo le proprie necessità semplicemente impostando alcuni tra i numerosi parametri messi a disposizione da questo potente strumento. Prima di passare al codice degli script che utilizzo quotidianamente al lavoro vorrei delineare la politica di backup da me adottata:

* 1 backup incrementale di livello 0 una volta al giorno alle ore 20:00
* 1 backup incrementale di livello 1 alle ore 8:00, 13:00 e 18:00

Il backup incrementale delle ore 20:00 effettua il backup di tutti i blocchi dati contenuti in un datafile perciò le dimensioni del backup piece, o dell'image copy risultante, a seconda del sistema utilizzato, potranno essere anche notevoli. I backup incrementali di livello 1, invece, vengono definiti differenziali (ed è il caso di quelli che creo io con RMAN) quando vengono memorizzati i blocchi di dati a partire dal più recente backup di livello 0 o di livello 1, oppure cumulativi se vengono memorizzati i blocchi modificati a partire dal più recente backup incrementale di livello 0, come evidenziato nell'immagine sottostante.


Perchè utilizzo questa strategia? Fondamentalmente perchè le dimensioni dei backup set creati quotidianamente da RMAN per il mio database di produzione sono nell'ordine del GB, una quantità di spazio relativamente irrisoria da memorizzare su una NAS, una SAN, oppure da spostare su un file server remoto via rete (tra l'altro, i backup pieces prodotti da RMAN sono normali files che è possibile comprimere prima di un'eventuale copia in rete via ftp, rsync, scp, o altro. In questo modo diminuisce il tempo di trasferimento dei files e la loro dimensione, ma aumenta il tempo di un eventuale restore/recovery da quei files che andranno prima riportati sul db server e scompattati per poterli effettivamente utilizzare).

Quello che segue è il file dei parametri che utilizzo per RMAN:

# -------------------------------------------------
# Script per eseguire un backup incrementale a caldo
# di livello 0
#

# --------------------
# Default e Politiche
# --------------------
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE MAXSETSIZE TO UNLIMITED;

# --------------------------------
# Backup di control file + sp file
# --------------------------------
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
TO '/backup//CF_%F';

# -----------------------------------------------------
# Creazione del redundancy set costituito da:
# - backup dei datafiles
# - backup degli archive redo logs
# - backup del control file

BACKUP
DEVICE TYPE DISK
AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 0
DATABASE
FORMAT '/backup//DATAFILE_%d_%T_%t_%s_%p'
TAG 'INCREMENTAL LEV 0'
PLUS ARCHIVELOG
FORMAT '/backup//ARCH_%d_%T_%t_%s_%p'
SKIP INACCESSIBLE;

BACKUP CURRENT CONTROLFILE FORMAT
'/backup//SOLO_CF_%d_%T_%t_%s_%p'
tag='CF a parte';
# -----------------------------------------------------


# -----------------------------------------------------
# elimino i files obsoleti (compresi gli archivelogs)

DELETE force noprompt obsolete;
# -----------------------------------------------------

Ho lasciato i commenti al codice per tenermi in mente cosa combina! Come si può notare, per prima cosa vengono impostati alcuni parametri per RMAN, come la recovery window, ossia per quanto tempo mantenere un backup piece nello stato 'AVAILABLE' prima di considerarlo obsoleto (che non significa necessariamente inutile per un eventuale restore/recovery), ma anche il tipo di device su cui eseguire i backup (in questo caso su disco) e così via.

Importante è la parte relativa all'impostazione dell'autobackup che permette di creare in automatico un backup di control file + spfile da inserire in un backup piece separato rispetto a quelli dei datafiles e degli archivelogs.

Con l'istruzione BACKUP ... DATABASE PLUS ARCHIVELOG ... si avvia il backup, appunto, incrementale di livello 0 (o di livello 1 a seconda del valore impostato) dei datafiles e degli archivelogs (grazie all'istruzione 'CONFIGURE BACKUP OPTIMIZATION ON' vengono tralasciati gli archivelogs già backuppati una volta su disco riducendo, di fatto, la dimensione dei backup pieces risultanti).
Inoltre, viene creato un ulteriore backup a sè stante per il control file. Backuppo quotidianamente il control file non solo perchè si tratta di un elemento fondamentale per un database Oracle (altrimenti non se ne può nemmeno effettuare lo startup), ma soprattutto perchè RMAN memorizza al suo interno record relativi ai backup files necessari per un eventuale restore/recovery (a meno di non utilizzare un recovery catalog esterno).
L'ultima istruzione, 'DELETE force noprompt obsolete' permette di fare un pò di pulizia rimuovendo i backup considerati obsoleti, ossia che non rientrano nella recovery window impostata precedentemente (pari a 4 giorni).

Per chi volesse approfondire l'argomento backup con RMAN lascio qualche utile link:
Oracle® Database Backup and Recovery Quick Start Guide
Oracle® Database Backup and Recovery Basics
Oracle® Database Backup and Recovery Reference
Oracle® Database Backup and Recovery Advanced User's Guide

Oracle e i backup - parte I - UPDATE

Come si può notare dal titolo, questo post non è la seconda parte della serie "Oracle e i backup", bensì un update del primo post che ho pubblicato sull'argomento.

Sostanzialmente, questa mattina mi si è presentata la necessità di clonare uno schema Oracle, chiamiamolo SORGENTE in un nuovo schema che, con notevole sforzo di fantasia chiamerei DESTINAZIONE. Da notare che entrambi gli schemi si trovano sullo stesso database.
Questi sono i passaggi che ho seguito:

* Creazione dell'utente DESTINAZIONE. Per comodità, ho utilizzato Enterprise Manager e, in particolare, l'opzione "Crea con copia" messa a disposizione nella pagina di gestione degli utenti, specificando l'utente SORGENTE come punto di partenza per l'operazione di clonazione, appunto. In questo modo, ho ottenuto un utente con gli stessi privilegi (tablespace a cui accedere, tipologia di operazioni DDL e DML, ecc)

* Esportazione mediante l'utility exp dello schema SORGENTE

exp SORGENTE/pwd@SID file=/path/expdata.dmp log=/path/explog.log

* Importazione del dump nello schema DESTINAZIONE precedentemente creato

imp DESTINAZIONE/pwd@SID fromuser=SORGENTE touser=DESTINAZIONE
file=/path/expdata.dmp log=/path/explog.log

Stop. Non c'è altro da fare e in questo modo DESTINAZIONE diventa un clone dello schema SORGENTE sul quale lavorare in tutta sicurezza!

Tanti link per Oracle su delicious

Da un'iniziativa di Rodolfo Baselli e Cristian Cudizio è nato poche settimane fa un gruppo su Facebook chiamato Oracle DBA Italia (se siete iscritti a Facebook e vi interessate di Oracle, lo potete trovare facilmente utilizzando la stringa "oracledbaitalia" nell'apposito motore di ricerca; l'iscrizione è aperta a tutti quindi fatevi pure avanti!)

Tra i vari thread aperti ne è stato iniziato uno relativo ai link su Oracle ed affini di cui tutti noi interessati all'argomento disponiamo e che sarebbe utile poter condividere.
Al fine di non disperdere questi collegamenti tra tanti thread, ho pensato di riunirli tutti in un'unica pagina su del.icio.us.
Di tanto in tanto, quando scopro qualche nuova risorsa, la aggiungo su delicious, ma se ne avete di nuove rispondete pure a questo post che le accodo!

Questo il link alla pagina del gruppo Oracle DBA Italia su delicious: Oracle DBA Italia

Corso Oracle @ UniFE, giorno primo

Ok, lo so che è una vita che non pubblico più un post, ma cercavo l'ispirazione giusta e questa è arrivata giovedì scorso durante la prima giornata del corso Oracle promosso dall'Università di Ferrara per cui lavoro.
Sono stati toccati i temi più svariati che voglio elencare qui per non dovermeli tenere su un txt sparpagliato in mille versioni su altrettanti pc come al solito :-)

Innanzitutto, il nostro relatore (un ragazzo simpatico che non sopporta quando un sistema operativo, oppure Oracle, viene installato in lingua italiana, hehehe) ha proposto un link molto interessante:
Oracle Free and Open Source Software un utile aggreatore di materiale FOSS creato da e per Oracle e che ho prontamente aggiunto ai miei preferiti.
Secondo punto all'ordine della giornata: una breve introduzione al concetto di backup con RMAN (e che sarà anche l'argomento di uno dei miei prossimi post).
Abbiamo dato un'occhiata agli script di backup con RMAN che utilizziamo attualmente al lavoro; tra tutti i parametri presenti negli script, PARALLELISM ha destato la mia attenzione: si tratta di un parametro che consente ad RMAN di parallelizzare, appunto, la creazione dei backup pieces su N processori/core, dove N è il valore con cui si imposta tale parametro. Per database di piccole dimensioni non si notano grandi incrementi di prestazioni impostando PARALLELISM ad un valore > 1, ma le cose cambiano per database con notevoli quantità di dati (nell'ordine delle decine o centinaia di GB).
Anche se al momento backuppo un db con solo qualche GB di dati ho impostato PARALLELISM a 2 mediante la direttiva

CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET

Altro punto relativo ai backup con RMAN riguarda le operazioni di pulizia dei backup piece e degli archivelog obsoleti: io di solito utilizzo un unico comando:

DELETE FORCE NOPROMPT OBSOLETE RECOVERY WINDOW OF 4 DAYS

Il relatore ha consigliato anche quest'altro per la rimozione esplicita degli archivelog più vecchi di due giorni e di quelli già backuppati su disco almeno una volta:

DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'sysdate -2' BACKED UP
1 TIMES TO DISK;

Terzo punto all'ordine del giorno: i database di standby. Si tratta di un ulteriore meccanismo di backup disponibile già dalla versione 8i di Oracle che consiste nel disporre di un database replica costantemente aggiornato del proprio db di produzione.


Come si può notare dall'immagine qui sopra, il database di standby rimane allineato con l'ambiente di produzione applicando gli archivelog ricevuti da quest'ultimo.
I processi LGWRn, oltre ad occuparsi della scrittura del contenuto della redo log cache (una parte della SGA) nei redo log files, inviano anche i log archiviati al database di standby. Questa procedura, a livello di carico di CPU e di bandwidth impatta veramente molto poco.
Grazie all'applicazione degli archivelog, il database di standby può mantenere il proprio SCN (System Change Number) quasi constantemente allineato con quello del database di produzione.
Va detto che un database di standby, quando si trova in tale modalità, non è fruibile in lettura/scrittura dagli utenti, tuttavia, all'occorrenza può essere posto in modalità read-only per consentire operazioni di consultazione. In questo caso, il database di standby non può ricevere nè applicare gli archivelog inviati dalla produzione finchè non viene nuovamente posto in standby mode.
Se nella propria strategia di restore/recovery si utilizzano strumenti come exp/imp, RMAN e standby database in combinata (oltre ad una ormai indispensabile ridondanza hw garantita da sistemi RAID, sistemi di mass storage come SAN, NAS, ecc) si ottiene un livello di fault tolerance molto vicini al 100%.
Aggiungo nioltre, che la tecnologia dei database di standby è stata recentemente rinominata (a partire da Oracle 10g) in Oracle Data Guard

Quarto punto all'ordine del giorno: realizzazione di un "muletto", come lo ha simpaticamente definito il relatore. In buona sostanza, il muletto è un server, possibilmente ben carrozzato a livello hardware su cui centralizzare i seguenti servizi:

* Grid Control
* Catalog per RMAN
* Ambiente di restore/recovery

Ma andiamo con ordine, Grid Control è una tecnologia Oracle nata allo scopo di monitorare altri server/servizi attraverso un unico "pannello di controllo".


La macchina che ospita il Grdi Control deve disporre di almeno 2 GB di RAM e di 40 GB di spazio disco ed è composta dai seguenti elementi:

* interfaccia web in ascolto sulla porta 7778
* il web server Apache che comunca con l'interfaccia web mediante la porta 8887 e si pone in ascolto sulla porta 4889 per ricevere informazioni dagli agent installati sui server da monitorare
* una serie di Java apps
* un database in cui vengono memorizzati i dati inviati dagli agent

Come già detto, Grid Control riceve dati ed informazioni dagli agent che consentono di monitorare non solo db server Oracle, ma anche molte altre tipologie di servizi.

Il secondo ruolo del "muletto" sarà quello di catalog per RMAN; attualmente, tutte le informazioni necessarie ad RMAN per gestire le operazioni di backup/restore/recovery per il mio db sono contenute nel controlfile, ma questa non è una situazione sicura per almeno due motivi:

* se si corrompono tutte le copie del controlfile, RMAN perde le informazioni relative ai backup disponibili e diventa di fatto inutilizzabile
* se i record di backup memorizzati nel controlfile vengono sovrascritte troppo in fretta, RMAN perde importanti informazioni relative ai backup disponibili

L'idea di base, dunque, è quella di disporre di un recovery catalog di RMAN per tutti i database sul muletto. A questo punto, si può lanciare da una qualsiasi postazione con un client Oracle installato ed opportunamente configurato, il backup di un qualsasi database Oracle collegandosi al catalog di RMAN residente sul muletto, appunto (per un howto su questo argomento mi appunto di scrivere un post apposito). Lo stesso, ovviamente, vale per le operazioni di restore/recovery.
Terzo ed ultimo ruolo del muletto sarà quello di fungere da sandbox, cioè da ambiente protetto per fare simulazioni di disastri (perdita di datafile, controlfile, ecc) e per i conseguenti test di restore/recovery.
Nei prossimi post cercherò di illustrare al meglio le operazioni di installazione e configurazione delle varie componenti del muletto.