rac

You are currently browsing articles tagged rac.

Do you really need a RAC Database?

19 January 2010 in general | No comments

Really you need an Oracle RAC database? I’m sure this question maybe a joke, but isn’t it. I’ve seens dozens of RAC database used simply to provide a clustering or a sort of failover and high availabilty service. But this is not true, definitly not.

First if you ask for an Oracle database high availabilty solution and your DBA or your consultat answer saying “RAC” please fight him.
RAC, Real Application Cluster, as acronymous is not a normal cluster but a particular database configuration and structure that only in some case may provide an high availabilty service. Usually many RAC are configured doubling the same hardware that many times is not good for an instance at all and using a low performance storage and a not efficient interconnect network.

The big attention should be paid to the application. An application that was built for a standalone single Oracle instance does not work obviously in a RAC environment. Today I think that only few application may run on a RAC gaining performance. Too many times let a normal application run on a RAC generate only a performance problem and also expose your database to some new, and sometimes interesting, wait events. I’ve to say that to take full advantage of the particular high availability services in a RAC enviroment few special considerations are to be checked with application and the TAF (Transparent Application Failover) protocol.

RAC can solve problem only if the whole environment is Oracle RAC friendly, otherwise you will face with many problems. Don’t trust a DBA that propose without any care a RAC solutions. You will only pay more to get less.

Tags: ,

ASM…really sucks

14 July 2009 in general | No comments

I’ve always thought that ASM is a sucking unneeded part of oracle. Is really slow, is another abstraction layer between database a disk block, is not mature for production environment and simply sucks. Yesterday I made an error. Altering a diskgroup to add a new lun to ASM in a RAC environment cause an error because LUN was not visible to ASM on both cluster node

ALTER DISKGROUP ORAFRA ADD DISK '/dev/rhdisk14';
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15075: disk(s) are not visible cluster-wide

Oh my god, LUN rescan was done on both node, what’s the problem? I’ve found a permission problem, On second node LUN was not writable to oinstall group… ok. Changed. And now? Now is interesting.
First, ORAFRA diskgroup was unmounted on second node and as the diskgroup contains on control file second instance was closed in abort!
No panic. I’ve mounted diskgroup and restarted second instance. Curious, what about /dev/rhdisk14 ?
Check in ASM:

SQL> col name format a15
SQL> col path format a20
SQL> set lines 136 pages 400
SQL> select GROUP_NUMBER,DISK_NUMBER,MOUNT_STATUS,HEADER_STATUS,NAME,PATH from v$asm_disk where PATH like '%rhdisk14';

GROUP_NUMBER DISK_NUMBER MOUNT_S HEADER_STATU NAME            PATH
------------ ----------- ------- ------------ --------------- ------------------------------
           0           5 CLOSED  MEMBER                       /dev/rhdisk14

My LUN is MEMBER of nothing! Perhaps an ASM error. As this LUN was added to diskgroup ORAFRA I’ll try to remove it from this diskgroup.

SQL> alter diskgroup ORAFRA drop disk '/dev/rhdisk14' ;
alter diskgroup ORAFRA drop disk '/dev/rhdisk14'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15054: disk "/DEV/RHDISK14" does not exist in diskgroup "ORAFRA"

Damn, what I’ve to do? Metalink note: 399500.1
This problem can occurs when disk is not visible cluster-wide. For particular type of storage (of course storage I’m using) you have to change a value in LUN configuration: reserve_policy = no_reserve
Ok, this needs a reboot, bad. And to solve my problem? Metalink suggest to check and make LUN really visible and useable to both nodes. Then drop and add again the disk. Is this possible? I think not!

Tags: , , , ,

RAC su macchine virtuali

30 October 2008 in general | 1 comment

NO, questa è la mia risposta. Parto da questo concetto: la virtualizzazione e il consolidamento sono utili laddove io posso disporre di un hardware con risorse molto grandi sul quale appoggio una serie di sistemi virtualizzati che di loro non sono memory, CPU, I/O intensive. Infatti di solito si virtualizzano tante piccole cose su blade servers. Perchè però virtualizzare un database oracle o peggio ancora un database oracle in RAC quindi con più nodi che devono intanto bilanciare un servizio comune e inoltre parlare tra di loro.

L’importanza della velocità delle risorse per oracle è vitale, se su un sistema operativo la SGA viene allocata direttamente tramite il kernel in RAM, su un sistema virtualizzato abbiamo in mezzo il layer della virtualizzazione che senz’altro rallenta ulteriormente l’I/O e poi non consideriamo tutti i problemi dell’hardware virtuale. Per chi ha provato la combinazione Oracle->Windows->VMWare…o è stato fortunato o l’ha buttato. Sfatiamo poi questo mito che non capisco dove la virtualizzazione tramite sistemi come VMWare ESX Server sia una alternativa al clustering. Infatti la relocazione delle macchine virtuali avviene solo quando ci sono problemi hardware, ma se un nostro database va giù oppure cade il listener, mentre un sistema di clustering di host proverebbe prima a riavviare la risorsa e poi a switchare di nodo nel nodo peggiore dei casi… vmware? Niente, lui non è in grado di verificare lo stato dei servizi. Finchè la virtual machine è accesa per lui sta bene.

Oracle Virtual Machine si muove in modo leggermenete diverso. Questo perchè l’utilizzo del motore Xen (comprato da Citrix) permette di funzionare in modo leggermente diverso. Xen crea istanze di kernel e tipicamente virtualizza lo stesso sistema host sul guest, i.e. che se io ho una RedHat come host OS, mi troverò con Xen la stessa RedHat con lo stesso Kernel sul sistema guest. Questo riduce sensibilmente le latenze date dalla virtualizzazione ma non toglie il concetto, inutile, di virtualizzazione.

Diverso è se parliamo di ambienti di test, allora possiamo virtualizzare, fare danni, configurazioni fasulle e farlocche…ma queste sono altre mani. Alla domanda: virtualizzare un oracle in produzione la risposta secondo me deve essere sempre NO.

Tags: , , , , , ,