OpenSuSE 10.3 x86_64: gli rpm per Oracle 10g

Tra tutte le installazioni Oracle 10g che ho fatto, escludendo Red Hat 4, mi sembra che la migliore distribuzione a cui appoggiarsi sia OpenSuSE 10.3.
L'unico problema che si potrebbe avere è nella versione a 32 bit, che probabilmente richiede la ricompilazione del kernel. Con le macchine attuali x86_64 il problema non si pone.

Riporto qui la lista degli rpm da installare oltre a quelli di default da DVD OpenSuSE 10.3 a 64 bit:

gcc-32bit-4.2-24.x86_64.rpm
gcc42-32bit-4.2.1_20070724-17.x86_64.rpm
glibc-32bit-2.6.1-18.x86_64.rpm
glibc-devel-32bit-2.6.1-18.x86_64.rpm
libgcc42-32bit-4.2.1_20070724-17.x86_64.rpm
libgomp42-32bit-4.2.1_20070724-17.x86_64.rpm
libmudflap42-32bit-4.2.1_20070724-17.x86_64.rpm

Nell'installazione grafica normale, alla selezione dei pacchetti da DVD, selezionare anche il Development e C/C++ development.
I pacchetti dell'elenco di sopra sono reperibili solo da repository web, quindi o si aggiunge l'URL del repository al SuSE online update, oppure si scaricano manualmente e si installano da linea di comando.
Vedere il sito SuSE per i mirror.

RAC cluster interconnect: twisted!

Una delle "limitazioni" più famose delle implementazioni Oracle RAC a due nodi è l'impossibilità, secondo la documentazione, di utilizzare un'interconnect formata da un solo cavo diretto tra un server e l'altro.
Le FAQ di RAC riportano:

NO. CROSS OVER CABLES ARE NOT SUPPORTED.
The requirement is to use a switch:
Detailed Reasons:
1) cross-cabling limits the expansion of RAC to two nodes
2) cross-cabling is unstable:
a) Some NIC cards do not work properly with it. They are not able to negotiate the DTE/DCE clocking, and will thus not function. These NICS were made cheaper by assuming that the switch was going to have the clock. Unfortunately there is no way to know which NICs do not have that clock.
b) Media sense behaviour on various OS's (most notably Windows) will bring a NIC down when a cable is disconnected.
Either of these issues can lead to cluster instability and lead to ORA-29740 errors (node evictions).

Due to the benefits and stability provided by a switch, and their afforability ($200 for a simple 16 port GigE switch), and the expense and time related to dealing with issues when one does not exist, this is the only supported configuration.
Please see certify.us.oracle.com as well.

Vorrei però precisare quanto segue:

1. Per gli switch moderni a 1 Gb i cavi "cross" sono equivalenti a quelli normali; a me risulta che siano equivalenti anche a 100 Mb (verificato sul mio router di casa).
2. L'instabilità non è giustificata, a meno che si pensi ai SO Microsoft e ad eventuali versioni Linux che spengono la scheda di rete in caso di inattività prolungata o assenza di segnale all'altro capo in fase di avvio.
   
3. Per il funzionamento effettivo del cross-link, basta provare e vedere se funziona

Aggiungiamo che le schede di rete recenti (es. e1000) hanno tutte le migliori caratteristiche desiderabili, e soprattutto possono essere configurate in bonding.

Gli scenari da confrontare sarebbero due:

1. I 2 nodi collegati a uno switch
2. I due nodi collegati tra loro

Gli oggetti che si possono rompere, nel caso del "sistema interconnect", sono:

1. lo switch
2. i due cavi di rete
   
3. le quattro schede di rete

I cavi di rete di per sè sono molto poco propensi a rompersi, visto che strutturalmente sono molto semplici; eventualmente potrebbero essere soggetti a sollecitazioni meccaniche esterne. Sono due, quindi devono rompersi entrambi nello stesso periodo per dare problemi.
Le schede di rete hanno più o meno la stessa probabilità di rompersi di qualsiasi altro elemento attivo. Sono due per server, quindi la ridondanza abbassa di molto la probabilità di disservizio.
Lo switch è unico. Per avere una certa affidabilità e velocità bisogna acquistare qualcosa di più di "$200 for a simple 16 port GigE switch"; qualcosa di molto costoso rispetto ai server. Sta di fatto che è un elemento unico; se si vogliono due switch i costi raddoppiano.

Veniamo ora agli scenari problematici:

1. Shutdown di una delle due istanze, più o meno volontario
   
2. Reset o shutdown software di un server
3. Spegnimento togliendo la corrente

Le istanze RAC comunicano via interconnect e voting disk. Un reset o uno spegnimento di un nodo sarebbe facilmente risolto dal voting-disk, in teoria. Tra le configurazioni con e senza switch di mezzo c'è una differenza: la mancanza di alimentazione a uno dei capi dell'interconnect, ad esempio per spegnimento di un server, provoca l'errore di link down.
Consideriamo solo il caso senza switch: gli scenari peggiori quindi sono l'interruzione totale e improvvisa dell'alimentazione per un nodo, e il distacco di entrambi i cavi di rete.
La prima possibilità è realistica, e provoca il link down. La seconda possibilità è, consentitemi, praticamente irrealizzabile.

Pensiamoci un attimo: la differenza col caso switch è che in mezzo c'è un altro componente che potenzialmente può dare problemi. La cosa migliore è quindi che lo switch non sia presente! Con un solo switch in mezzo, in caso di spegnimento dello switch stesso per qualsiasi motivo, si realizzerebbe la condizione per cui i nodi non si sentono più via interconnect, hanno un link down, e le istanze sono entrambe nello stesso stato: è la situazione di gran lunga peggiore: quella del distacco dei due cavi di rete dell'interconnect. La configurazione con i cavi diretti è quindi, a mio modo di vedere, addirittura migliore di quella consigliata da Oracle senza appello.

Rimane da provare l'interruzione improvvisa dell'alimentazione per un nodo.
L'ho provata.
In questo caso le istanze non sono nello stesso stato: una non c'è più.
Ecco ciò che succede all'altra istanza:
Tue Mar 11 15:01:42 2008
ospid 1179: network interface with IP address 192.168.1.107 no longer running (check cable)
Tue Mar 11 15:01:52 2008
Reconfiguration started (old inc 2, new inc 4)
List of nodes:
0
Global Resource Directory frozen
* dead instance detected - domain 0 invalid = TRUE
...
Il link down viene rilevato. Tutto prosegue regolarmente. In caso di dubbio Clusterware avrebbe riavviato la macchina. Quindi tutto bene.
Gli indirizzi IP VIP vengono correttamente riconfigurati.

Al ripristino del nodo in failure si ottiene:
Tue Mar 11 15:12:42 2008
ospid 1179: network interface with IP address 192.168.1.107 is now running
Tue Mar 11 15:15:12 2008
Reconfiguration started (old inc 4, new inc 6)
List of nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
...
Ottimo: link up e riconfigurazione del cluster. Tutto regolare.

In sintesi, per un sistema RAC a due nodi non espandibile, a quanto sembra, è molto meglio avere un'interconnect a cavi diretti piuttosto che avere di mezzo un apparato di rete.

Restore in ambiente RAC

Per lavoro ho dovuto spostare un database RAC di test da un volume ASM ad un altro. Tralasciando i motivi, ho deciso di effettuare un restore completo della parte dati ASM a partire da un backup RMAN con catalogo.
Noto alcune cose interessanti:

• Nonostate il catalogo, bisogna sempre impostare il DBID prima di tutto
• È necessario ricreare la directory base sotto +<DISKGROUP>
• Se proprio non si ha il pfile creato a mano dall'spfile, si può usare lo startup force nomount da RMAN, per avere un minimo server process in modo da accedere ad ASM e fare il restore dell'spfile.
  
• Il restore dall'autobackup è molto comodo: si recupera sia il controlfile che l'spfile (separatamente)
  
• Il restore dell'spfile va fatto specificando il filename di destinazione nel diskgroup condiviso (TO '...')

Ho notato anche due difetti di Enterprise Manager db control una volta che il database RAC è tornato a funzionare: per prima cosa la configurazione interattiva con emca non funziona, almeno nel mio caso di ASM home separata. Bisogna per forza usare la linea di comando di emca ricavandola da uno degli script di creazione del database fatti da dbca (consiglio vivamente di far creare sempre gli script di creazione del database da dbca).
Secondo difetto: nelle pagine EM su ASM, lo spazio utilizzato dal database viene visto come "internal" (tipo archivelog) e non come spazio allocato da un database. Questo aspetto è tradizionalmente difettoso, almeno in RAC: i nomi dei database che utilizzano un dato diskgroup sono a volte solamente quelli di una delle due istanze; in questo caso, nemmeno quello.