Visto quanto ho penato per mettere insieme la procedura corretta per l’installazione di Oracle 10G in Cluster di tipo Fail Safe su Windows Server 2003 x64 ho pensato bene di non far soffrire altri come me.

Ovviamente do per scontati due requisiti di base perché le istruzioni che sto per scrivere abbiano qualche valore aggiunto: dovete conoscere i rudimenti del cluster Microsoft e conoscere Oracle 10g ed in particolare quel diabolico cappello che fa girare il database server in modalità cluster su Windows senza usare il famoso, fortissimo e bellissimo ma costosissimo RAC (Real Application Cluster)

Se, come il sottoscritto, venite da anni (o decenni…) di conoscenza (anche molto di dettaglio) e lavoro sulle piattaforme Microsoft è giusto avvisarvi che l’installazione di Oracle 10g (ma anche l’11g è così) assomiglierà drammaticamente alla draconiana installazione che bisognava fare per far funzionare SQL Server 7 in cluster.

Innanzitutto è necessario installare, a regola d’arte, il cluster di Windows Server 2003 seguendo la checklist presente già nell’help di Windows o le varie guide che Microsoft ha sul TechNet.

Se il vostro cluster group fa failover (e failback) correttamente tra i nodi, è raggiungibile tramite DNS senza problemi e la rete è configurata correttamente (occhio all’ordine delle schede di rete!) bhé, complimenti avete un cluster Windows Server x64!

Da questo momento in poi dimenticatevi dell’ìnstallazione cluster-aware di SQL Server 2005 (o già 2000) e iniziate il ping pong dell’installazioni su entrambi i nodi.

Infatti sul disco locale di ogni nodo del cluster andranno installati:

1. Oracle 10g v. 10.2.0.1 (per la x64 non sono riuscito a trovare una versione più recente anche se la 32bit mi risulta alla 10.2.0.4..)
2. Oracle Fail Safe 3.3.4
3. Oracle Enterprise Manager Agent (non vorrete mica amministrare il cluster da SQLPLUS…) ci vuole il Grid Control per andare con l’interfaccia grafica dell’ enterprise manager

L’installazione di Oracle 10g

L’installazione di 10g è piuttosto standard e simile a quella che fareste su un normale server stand-alone con l’accortenza di non lanciare la creazione di nessun db e, se avete già disponibili i dischi clusterizzati sul nodo, facendo attenzione a dove l’installer mette la oracle home. Almeno per quanto mi riguarda ha avuto un comportamento abbastanza bizzarro visto che, stranamente, voleva mettere la ORACLE_HOME su uno dei dischi shared del cluster…

L’installazione su entrambi i nodi deve essere speculare senza alcuna differnza sia nei percorsi che nei componenti installati. Insomma, a voler essere maligni, si tratta di fare gli stessi passi necessari anni fa per l’installazione di SQL Server 7 in cluster.

Alla fine dell’installazione è necessario controllare che i PATH della oracle_home siano correttamente aggiunti a quelli di sistema.

Non avendo creato nessun database l’installazione di Oracle non è particolarmente complessa e priva di qualunque sfida tecnica legata all’installazione clusterizzata tranne quella di inserire l’utente con cui gira il servizio cluster services nel gruppo locale di ogni nodo Ora_dba.

Se la versione che state installando non è già l’ultima disponibile oppure dovete applicare un patchset è questo il momento migliore per farlo.

Purtroppo una volta clusterizzate le istanze di Oracle non possono essere patchate senza de-clusterizzare (e non mi dite che non è robba da SQL Server 7.0…)

L’installazione di Oracle Fail Safe 3.3.4

In realtà OFS è l’unico software Cluster Aware ed è solo grazie a lui che, senza spendere la vagonata di soldi necessari per un RAC, riusciamo ad avere un minimo di alta disponibilità su Oracle.

L’installazione è abbastanza banale se il sistema su cui volete creare il cluster è un normale 32bit. Se invece avete intenzione di superare il limite di 4GB (si, è diventato un limite..) e volete usare sistema operativo e software a 64bit le cose si complicano un pochino.

Infatti è necessario installare il Fail Safe Manager  su una macchina a 32 bit ed installare invece OFS su entrambi i nodi del cluster Windows. Con questa azione si registra la resource DLL che si occupa di clusterizzare i database StandAlone che sono il punto di partenza per creare un’istanza clusterizzata di Oracle.

A questo punto parte quella che, secondo me, è l’installazione volutamente peggio realizzata di tutti i software su Cluster Microsoft che abbia visto in 12 anni di attività del mondo enterprise.

Non tanto per la procedura, che non è poi così’ male rispetto al panorama della clusterizzazione, ma per la totale assenza di pulizia architetturale che traspare da quello che sto per dirvi.

La creazione di una istanza clusterizzata si basa sull’utilizzo di un template di database appositamente aggiunto dall’installazione di OFS in DBCA ovvero Oracle Failsafe Sample Database, Oracle_Fail_Safe_Sample_102.dbc.

Tutto fila liscio se non volete aggiornare Oracle ad un patchset più recente….

.. nel caso, quasi inevitabile, di applicazione di una patchset, come ad esempio l’upgrade alla 10.2.0.4, l’accrocco si mostra in tutta la sua approssimazione e astrusità.

Infatti, per installare il patchset è necessario de-clusterizzare, e per patchare è necessario lanciare una procedura di aggiornamento del Database che, in alcuni casi, è preferibile non far passare i propri dati nel “tricarne” di una procedura simile.

Dunque scegliete di effettuare l’export del db e mettere i vostri dati da qualche parte anche per sfruttare l’occasione di ricompattare le tabelle.

Quello che vi rimane sono quindi due DB Oracle completamente vuoti su cui l’aggiornamento sarà una passeggiata.

Così’ è per la quanto riguarda l’applicazione del patchset, peccato che il database usato come template dal failsafe non viene aggiornato e la conseguenza di questo è l’impossibilità di procedere alla creazione di una nuova risorsa stand-alone da inserire successivamente in una istanza clusterizzata.

Il database Oracle Failsafe Sample Database, “Oracle_Fail_Safe_Sample_102.dbc” non viene aggiornato e per questo qualunque tentativo di utilizzarlo come base per un nuovo database failsafe.

Non trovando nulla sul Metalink e avendo un sistema di produzione down ho iniziato a cercare nei files una qualche indicazione che dicesse a dbca che quel db non era aggiornato.

In realtà cambiamndo alcuni file di configurazione dei template di creazione ed in particolare sostituendo

<initParam name="compatible" value="10.2.0.3.0"/>

<Location>C:\oracle\product\10.2.0\db_1\assistants\dbca\templates\Seed_Database.dfb</Location>

In modo da usare il Seed_Database.dfb (che è l’originale di Oracle_Fail_Safe_Sample_102.dfb).

Con questi piccoli trucchi il wizard crea il maledetto sample database con cui è possibile terminare la clusterizzazione di una istanza oracle senza ricorrere a script o procedure manuali da anni 70.

(sono quasi commosso visto che ho impiegato quasi 6 mesi per completare questo post… forse è uscito oracle 12 nel frattempo..)