Voting disk (componentes del grid)

Posted on 22 enero, 2014 por admin

Vamos a dedicar una serie de entradas a explicar los distintos componentes del Grid infraestructurae de Oracle a partir de la version 11gR2

El voting disk es usado por el demonio de sincronización de servicios (ocssd Oracle cluster sincronization services daemon) para comprobar el estado de los nodos del disco.
Cada uno de los nodos envía en intervalos predeterminados un herbeat por la red para indicar a el resto que está vivo. Si el resto determina que uno de los nodos está muerto entonces le hace un “fence” para evitar corrupción de datos o un split brain.
Cada nodo debe de enviar un hearbeat por red por segundo y escribir un herbeart por voting disk por segundo. Si un nodo no hiciera ambas cosas, el resto de nodos comenzarían un proceso de reconfiguración que, sirve para comprobar qué nodos están vivos que básicamente es que cada nodo indica cuales encuentra como vivos y cuáles no .
A los nodos que no contestan se les envía un “poison packet via network and disk” y se les saca del cluster.

En las versiones anteriores el voting file debía de ser un sistema compartido de red (NFS,OCFS.. ), pero en la versión 11gR2 ya puede ser un disco de ASM (Es aconsejable ir pasándolos a ASM ya que podrían ser de-soportados los otros tipos de voting)

Si usas OCFS para el voting file, se aconseja el uso de 3 o 5 copias del voting file, aunque el máximo es de 15. En caso de uso del ASM no puedes determinarlo ya que es transparente y dependen del tipo de redundancia del ASM (external,normal,hit). En el caso de tener redundancia interna de ASM (normal/high),oracle chequea que tengas el número de discos mencionados anteriormente, conlo que deberás de tener un mínimo de 3 failure groups en redundancia normal y 5 en high. Si no los tuvieras, recibirás un error indicándote lo :

ORA-15273: Could not create the required number of voting files
ORA-15274 ...

En la versión 11gR2, el voting file, registro local y el perfil de Grid Plug and Play (GPnP) tienen toda la información necesaria del cluster por lo que no dependen del OCR, sin embargo el OCR es necesario para administrar los recursos del cluster

El voting disk se ubica en un disco de ASM individual, esto hace que el Cluster Synchronization Services daemon (CSSD) acceda directamente al contenido de los voting disk, lo que le permite arrancarse antes que los propios discos de ASM

En la versión 11gR2 de Oracle el backup del voting disk se lleva a cabo automáticamente con el backup el OCR.

El comando con el que administraremos el voting disk es el crscrtl, la sintaxsis de las acciones mas comunes es:


[grid@rac1 oracle]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   731fe6f479734f1fbf75ed0d30b3e76b (/dev/asmdisk_sdb1) [OCRQUORUM]
Located 1 voting disk(s).

También prodríamos añadir un votedisk

[grid@rac1 oracle]$ crsctl add css votedisk /shared/vfile1

Reemplazar un votedisk

[grid@rac1 oracle]$ crsctl replace votedisk /shared/vfile1
  /shared2/vfile2

O eliminar un votedisk

[grid@rac1 oracle]$ crsctl delete votedisk  /shared2/vfile2

Como siempre, mas información en la documentación de Oracle en:
http://docs.oracle.com/cd/E11882_01/rac.112/e16794/crsref.htm#CWADD91143

Crear un diskgoup desde asmca

Posted on 29 diciembre, 2013 por admin

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:
http://dba.pamplona.name/2013/12/crear-un-diskgoup-desde-asmca.html

Vamos a ver como crear un diskgroup en nuestro grid.

Lo primero que haremos será conectarnos como el usuario propietario del grid control (grid) y cargar las variables de entorno.

[oracle@rac1 grid]$ . oraenv
ORACLE_SID = [oracle] ? +ASM1
The Oracle base has been set to /oracle/11.2.0/grid
[oracle@rac1 grid]$

Una vez tenemos cargadas las variables, ejecutaremos el comando que lanza la interfaz gráfica asmca

Nosotros iremos a la pestaña de grupo de discos y pulsaremos en crear . Para este ejemplo crearemos el grupo DATA con los dos primeros discos con redundancia normal. tras esto, haremos lo mismo con los dos últimos (los mas pequeños) y llamaremos a el grupo INDICES

Como podemos ver, el uso de la herramienta gráfica que gestiona el ASM es bastante sencilla, en la siguiente entrada crearemos un grupo y le asignaremos discos desde la línea de comandos.

Instalacion de RAC II , instalacion de grid infraestructure

Posted on 26 diciembre, 2013 por admin

Repasando las entradas anteriores he podido comprobar como , tas la entrada de RAC I Preparativos no teníamos las siguientes entradas de instalación del RAC, así pues, vamos a hacer de nuevo la instalación para dejarla documentada.

Partimos de la base de la configuración de entorno y máquinas del post RAC I Preparativos
Como recordatorio rápido tenemos que los directorios a utilizar serán:

GI_HOME=/oracle/11.2.0/grid
ORACLE_BASE=/oracle/app/grid
grid

Y la configuración de red de los servidores será

# Direcciones para nuestros equipos
# HOST y publica  eth0
10.0.2.2  exodar.pamplona.name   exodar
10.0.2.3  rac1.pamplona.name     rac1
10.0.2.4  rac2.pamplona.name     rac2
10.0.2.5  rac3.pamplona.name     rac3
10.0.2.6  rac4.pamplona.name     rac4
10.0.2.24 plantilla.pamplona.name        plantilla


#Virtual  Eth1  direcciones de la red sobre la que se da el servicio 
192.168.1.1  exodar-vip.pamplona.name   exodar-vip
192.168.1.2  rac1-vip.pamplona.name     rac1-vip
192.168.1.3  rac2-vip.pamplona.name     rac2-vip
192.168.1.4  rac3-vip.pamplona.name     rac3-vip
192.168.1.5  rac4-vip.pamplona.name     rac4-vip
192.168.1.24 plantilla-vip.pamplona.name        plantilla-vip

#ScaN  comentadas ya que estan dada de alta en round robin dns
# estas son las verdaderas direcciones de servicio 
#192.168.1.20  ractest.pamplona.name  ractest
#192.168.1.21  ractest.pamplona.name  ractest
#192.168.1.22  ractest.pamplona.name  ractest

#Private ETH2 red privada de los nodos
192.168.2.1  exodar-priv.pamplona.name  exodar-priv
192.168.2.2  rac1-priv.pamplona.name    rac1-priv
192.168.2.3  rac2-priv.pamplona.name    rac2-priv
192.168.2.4  rac3-priv.pamplona.name    rac3-priv
192.168.2.5  rac4-priv.pamplona.name    rac4-priv
192.168.2.24 plantilla-priv.pamplona.name   plantilla-priv

Así pues, lanzamos la instalación del grid control:
En nuestro caso omitiremos la información de soporte, en el caso de una instalación real de RAC es muy recomendable el incluirla ya que facilitará mucho el uso del área de soporte así como la descarga de los últimos parches para llevar a cabo la instalación de la ultima versión disponible.

En la siguiente pantalla indicaremos que queremos instalar la versión del grid infraestructure que aplica a un cluster

Nosotros elegiremos la instalación avanzada para poder afinar mas las opciones de instalación.

En este punto comenzamos con la instalación específica del rac.
Aquí tendremos que introducir las direcciones de servicio y privadas del RAC.
Hemos de tener en cuenta que, nosotros ya teníamos comprobado y solucionado el tema de la conexión ssh entre los nodos, en caso de no estar claro ese tema, podremos comprobarlo desde la opción conectividad ssh

Si la configuración de las tarjetas con los nombres es correcta, pasamos a la pantalla en la que indicamos cual van a ser las direcciones de red.
Como las traducciones las carga el diablo,vamos a detallar unpoco que es cada cosa:

privada:van a ser las interfaces de interconexión del rac, esta debe de ser una conexión dedicada para la sincronización de las caches.
públicaEs las interfaces vip que serán sobre las que posteriormente Oracle levantará las interfaces de scan

La version 11.2 del Grid nos permite tener el OCR y el Quorum en un disco en ASM, nosotros vamos a elegir este tipo de instalacion

Estamos en el momento en el que ASM nos muestra los discos disponibles, en nuestro caso lo hacemos mediante asmlib ( ver RAC I Preparativos ) , en la imagen tenemos que vamos a crear el grupo de discos OCRQUORUM y vamos a usar 1 disco de los que tenemos con la redundancia EXTERNAL.
En un entorno de producción real, será más aconsejable el uso de varios discos de 1 Gb con redundancia SUPERIOR.
Que el nombre del grupo de datos sea distinto a DATA (por defecto), llamándose OCRQUORUM no es un standard o buena práctica de Oracle, sino una modificación mía para que sirva para distinguirlo fácilmente del nombre del diskgroup que usaré en las bases de datos

El IPMI podríamos decir que es lo que tradicionalmente se ha llamado fencing , para tener mas infiormación del mismo podemos mirar en la documentación de Oracle Configuring IPMI for Failure Isolation, en nuestro caso, no lo vamos a activar.

Indicamos los directorios que teníamos planificados

Finalmente, vemos las opciones y el resumen

Y la tipica ventana de ejecución de los comandos como root.
Aquí hemos de ser pacientes y ejecutar los scripts en orden, primero siempre en el nodo en el que estamos llevando a cabo la instalacón, y, solamente cuando hallan acabado de manera correcta ejecutarlos en el otro nodo

Tras esto, continuamos con la instalación dando a «siguiente» hasta que finalice.

La instalación del Grid Infraestructure no es (desde mi punto de vista) algo muy limpio, y , tiene bastantes papeletas de fallar en algún punto, por lo que, es muy recomendable el tener a mano las notas específicas de soporte Oracle que nos ayudarán a solucionar estos problemas.
Estas notas son:

Estado del Cluster/Rac/Grid tabulado

Posted on 17 diciembre, 2013 por admin

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:
http://dba.pamplona.name/2013/12/estado-del-clusterracgrid-tabulado.html

Hoy vamos a ver una entrada de esas sencillas para hacernos la vida mas fácil.

Cuando ejecutamos el comando para ver el estado de un cluster, nos solemos encontrar con esto :

grid@rac1:/opt/oracle/10.2/CRS/bin$ crs_stat -t
Name Type Target State Host
------------------------------------------------------------
ora....SM1.asm application ONLINE ONLINE oradb1
ora....D1.lsnr application ONLINE ONLINE oradb1
ora.oradb1.gsd application ONLINE ONLINE oradb1
ora.oradb1.ons application ONLINE ONLINE oradb1
ora.oradb1.vip application ONLINE ONLINE oradb1
ora....SM2.asm application ONLINE ONLINE oradb2
ora....D2.lsnr application ONLINE ONLINE oradb2
ora.oradb2.gsd application ONLINE ONLINE oradb2
ora.oradb2.ons application ONLINE ONLINE oradb2
ora.oradb2.vip application ONLINE ONLINE oradb2
ora....robd.db application ONLINE ONLINE oradb1
ora....dmin.cs application OFFLINE OFFLINE
ora....bd1.srv application OFFLINE OFFLINE
ora....ckup.cs application OFFLINE OFFLINE
ora....bd2.srv application OFFLINE OFFLINE
ora....atch.cs application OFFLINE OFFLINE
ora....bd2.srv application OFFLINE OFFLINE
ora....oltp.cs application OFFLINE OFFLINE
ora....bd1.srv application OFFLINE OFFLINE
ora....bd2.srv application OFFLINE OFFLINE
ora....d1.inst application ONLINE ONLINE oradb1
ora....d2.inst application ONLINE ONLINE oradb2

Realmente no nos sirve de mucho ya que queda todo apiñado,y no nos permite saber que componente está arrancado y cual eta parado.
Navegando por internet vi en un par de webs (perdón pero no recuerdo el lugar) el siguiente scipt en ksh

!/usr/bin/ksh
#
#  $GRID_HOME debe de estar definido en el entorno 
#
RSC_KEY=$1
QSTAT=-u
AWK=/bin/awk
# Table header:echo ""
$AWK \
'BEGIN {printf "%-45s %-10s %-18s\n", "HA Resource", "Target", "State";
printf "%-45s %-10s %-18s\n", "-----------", "------", "-----";}'
# Table body:
$GRID_HOME/bin/crs_stat $QSTAT | $AWK \
'BEGIN { FS="="; state = 0; }
$1~/NAME/ && $2~/'$RSC_KEY'/ {appname = $2; state=1};
state == 0 {next;}
$1~/TARGET/ && state == 1 {apptarget = $2; state=2;}
$1~/STATE/ && state == 2 {appstate = $2; state=3;}
state == 3 {printf "%-45s %-10s %-18s\n", appname, apptarget, appstate; state=0;}'

Este script nos devuelve una salida limpia al estilo de :

grid@rac1:/opt/oracle/10.2/CRS/bin$ ./crsstat.sh
HA Resource                         Target     State
-----------                         ------     -----
ora.oradb1.ASM1.asm                ONLINE     ONLINE on oradb1
ora.oradb1.LISTENER_oradb1.lsnr    ONLINE     ONLINE on oradb1
ora.oradb1.gsd                     ONLINE     ONLINE on oradb1
ora.oradb1.ons                     ONLINE     ONLINE on oradb1
ora.oradb1.vip                     ONLINE     ONLINE on oradb1
ora.oradb2.ASM2.asm                ONLINE     ONLINE on oradb2
ora.oradb2.LISTENER_oradb2.lsnr    ONLINE     ONLINE on oradb2
ora.oradb2.gsd                     ONLINE     ONLINE on oradb2
ora.oradb2.ons                     ONLINE     ONLINE on oradb2
ora.oradb2.vip                     ONLINE     ONLINE on oradb2
ora.rac.db                         ONLINE     ONLINE on oradb1
ora.rac_admin.cs                   OFFLINE    OFFLINE
ora.rac_admin.rac1.srv             OFFLINE    OFFLINE
ora.rac_backup.cs                  OFFLINE    OFFLINE
ora.rac_backup.rac2.srv            OFFLINE    OFFLINE
ora.rac_batch.cs                   OFFLINE    OFFLINE
ora.rac_batch.rac2.srv             OFFLINE    OFFLINE
ora.rac_oltp.cs                    OFFLINE    OFFLINE
ora.rac_oltp.rac1.srv              OFFLINE    OFFLINE
ora.rac_oltp.rac2.srv              OFFLINE    OFFLINE
ora.rac.rac1.inst                   ONLINE     ONLINE on oradb1
ora.rac.rac2.inst                   ONLINE     ONLINE on oradb2

Nota posteriormente me he encontrado con que era un script documentado por Oracle en la nota 259301.1 :
CRS and 10g/11.1 Real Application Clusters (Doc ID 259301.1)

Instalación de RAC I Preparativos

Posted on 17 enero, 2013 por admin

Vamos a retomar la instalación de un RAC en una plataforma virtualizada de pruebas con Virtualbox. En este punto tenemos las máquinas creadas y con el sistema operativo instalado, con lo que vamos a utilizar esta entrada para detallar los pasos necesarios para ajustar esos sistemas operativos para la instalacion del grid

Creacion de usuarios y grupos
Lo primero que hemos de hacer es crear los grupos necesarios para nuestra instalación

/usr/sbin/groupadd -g 501 oinstall
/usr/sbin/groupadd -g 502 dba
/usr/sbin/groupadd -g 505 asmadmin
/usr/sbin/groupadd -g 506 asmdba
/usr/sbin/groupadd -g 507 asmoper

Tras los grupos, creamos los usuarios y los asignamos a los grupos correspondientes

/usr/sbin/useradd -u 501 -g oinstall -G asmadmin,asmdba,asmoper grid
/usr/sbin/useradd -u 502 -g oinstall -G dba,asmdba oracle

Confuguración del fichero hosts

Dado que los equipos van a referenciarse entre ellos constantemente, deberemos de configurar la resolución de nombres entre ellos, la forma mas rápida y sencilla es la de incluir sus nombres en el /etc/hosts de todos los nodos del rac

# Direcciones para nuestros equipos
# HOST y publica  eth0
10.0.2.2  exodar.pamplona.name   exodar
10.0.2.3  rac1.pamplona.name     rac1
10.0.2.4  rac2.pamplona.name     rac2
10.0.2.5  rac3.pamplona.name     rac3
10.0.2.6  rac4.pamplona.name     rac4
10.0.2.24 plantilla.pamplona.name        plantilla


#Virtual  Eth1  direcciones de la red sobre la que se da el servicio 
192.168.1.1  exodar-vip.pamplona.name   exodar-vip
192.168.1.2  rac1-vip.pamplona.name     rac1-vip
192.168.1.3  rac2-vip.pamplona.name     rac2-vip
192.168.1.4  rac3-vip.pamplona.name     rac3-vip
192.168.1.5  rac4-vip.pamplona.name     rac4-vip
192.168.1.24 plantilla-vip.pamplona.name        plantilla-vip

#ScaN  comentadas ya que estan dada de alta en round robin dns
# estas son las verdaderas direcciones de servicio 
#192.168.1.20  ractest.pamplona.name  ractest
#192.168.1.21  ractest.pamplona.name  ractest
#192.168.1.22  ractest.pamplona.name  ractest

#Private ETH2 red privada de los nodos
192.168.2.1  exodar-conn.pamplona.name  exodar-priv
192.168.2.2  rac1-conn.pamplona.name    rac1-conn
192.168.2.3  rac2-conn.pamplona.name    rac2-conn
192.168.2.4  rac3-conn.pamplona.name    rac3-conn
192.168.2.5  rac4-conn.pamplona.name    rac4-conn
192.168.2.24 plantilla-conn.pamplona.name   plantilla-conn

Consideraciones sobre la configuracion de la red

El orden de las interfaces de red en todos los nodos ha de ser el mismo
La direccion de SCAN (Single Cliente Access Name) es la direccion a la que vamos a aceeder desde los clientes ( IPs de servicio),Grid Infraestructure iniciará el local listener LISTENER sobre todos los nodos para escuchar sobre la local VIP, y SCAN listener LISTENER_SCAN1 para escuchar sobre las SCAN VIPs. Aunque podríamos seguir entrando a las local VIPS del nodo, Oracle recomienda que se acceda siempre a las direcciones de SCAN.
La direccion de SCAN debe de ser un nombre del dominio con almenos una direccion y un máximo de tres direcciones,el nombre de la direccion de scan (ractest en nuestro caso) debe de ser global y único y será utilizado por defecto como nombre del cluster
Oracle recomienda no configurar SCAN VIP address en el archivo host ya que si se usa en archivo host para resolver el nombre del SCAN, se puede tener una sola SCAN VIP address. Oracle recomienda configurar el SCAN para utilizar DNS Round Robin resolution a con direcciones.

Servidor de NTP
Debemos de estar seguros que la hora de todos nuestros equipos del RAC es idéntica.
Oracle cuenta con el CTSSD(Cluster Time Syncronization Server Daemon) que se encarga de esto, con lo que podemos parar el servicio del sistema operativo NTPD.
Si por el contrario queremos tener el servicio activo, habremos de configurarlo con la opción -x

Creamos accesos por ssh entre los nodos.
Deberemos permitir conexiones y ejecuciones remotas entre los nodos para el usuario grid.
Para ello haremos en uno de los dos nodos:

mkdir .ssh
chmod 700 .ssh
[grid@rac1 ~]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/grid/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/grid/.ssh/id_dsa.
Your public key has been saved in /home/grid/.ssh/id_dsa.pub.

Ahora copiaremos

scp id_dsa.pub rac1-vip:/home/grid/.ssh/authorized_keys

y haremos lo mismo con rac1

scp id_dsa.pub rac2-vip:/home/grid/.ssh/authorized_keys

para ver si ha funcionado deberemos de poder hacer libremente ssh desde el usuario grid de rac1 a rac2 y viceversa.

preparamos los parámetros del kernel

Editaremos el fichero /etc/sysctl.cnf y pondremos los siguientes valores para el kernel

# Para Oracle
fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 1054504960
kernel.shmmni = 4096
# semaphores: semmsl, semmns, semopm, semmni
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default=262144
net.core.rmem_max=4194304
net.core.wmem_default=262144
net.core.wmem_max=1048586

para que el kernel adopte estos valores sintener que reiniciar ejecutaremos el comando

sysctl -p

ademas de esto, tendremos que añadir las siguientes líneas en el fichero /etc/security/limits.conf

# Para Oracle
grid soft nproc 2047
grid hard nproc 16384
grid soft nofile 1024
grid hard nofile 65536

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

comprobamos que en el fichero /etc/pam.d/login este la línea

session required pam_limits.so

Directorios para la instalación
Ahora crearemos los directorios de instalacion.
Habitualmente los elementos de oracle son creados bajo /u01/app /u02 ….
En nuestro caso tratándose de una plataforma de test sobre maquinas virtuales no tenemos un alto número de unidades de disco que montar y donde separar los elementos, con lo que toda nuestra instlacion será llevada a cabo bajo el directorio /oracle aún así y por motivos de compatibilidad, vamos ha hacer un enlace simólico desde /u01 hasta /oracle
así pues, nuestros datos para la instalacion del grid serán
GI_HOME=/oracle/11.2.0/grid
ORACLE_BASE=/oracle/app/grid

Hemos de tener en cuenta que el GI_HOME no debe de estar bajo ningún directorio de oracle_base .
Durante la instalación el GI_HOME será cambiado a root lo que podría causar errores de alguna otra instalación que esté sobre esos discos.

mkdir /oracle
ln -s /oracle /u01
chown -R grid:oinstall /oracle
mkdir -p /oracle/11.2.0/grid
chown -R grid:oinstall /oracle/11.2.0/grid
chmod 775 /oracle/11.2.0/grid

mkdir -p /oracle/app/grid
chown -R grid:oinstall /oracle/app/grid
chmod -R 775 /oracle/app/grid

Configuramos el asmlib

[root@rac2 etc]# /etc/init.d/oracleasm configure -i
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver. The following questions will determine whether the driver is
loaded on boot and what permissions it will have. The current values
will be shown in brackets ('[]'). Hitting without typing an
answer will keep that current value. Ctrl-C will abort.

Default user to own the driver interface []: grid
Default group to own the driver interface []: asmadmin
Start Oracle ASM library driver on boot (y/n) [y]:
Scan for Oracle ASM disks on boot (y/n) [y]:
Writing Oracle ASM library driver configuration: done
Initializing the Oracle ASMLib driver: [ OK ]
Scanning the system for Oracle ASMLib disks: [ OK ]

Aseguramos permisos con UDEV
En linux una de las formas que podemos asegurar que los dispositivos de los discos tendrán los permisos deseados es mediante la creacion de una regla de udev.
Así pues, con el comando blkid comprobaremos que discos tenemos en nuestro sistema.

[root@rac1 /]# blkid
/dev/sda1: UUID="b8327abf-baf7-48c5-baac-b39dc98d6b6e" TYPE="swap"
/dev/sda2: UUID="67748b98-ffde-4dbc-9b14-5da7dae13d65" TYPE="ext4"
/dev/sdb1: LABEL="DISK1" TYPE="oracleasm"
/dev/sdc1: LABEL="DISK2" TYPE="oracleasm"
/dev/sdd1: LABEL="DISK3" TYPE="oracleasm"
/dev/sde1: LABEL="DISK4" TYPE="oracleasm"
/dev/sdf1: LABEL="DISK5" TYPE="oracleasm"
/dev/sdg1: LABEL="OCRVOTING" TYPE="oracleasm"

con lo que sabemos que tenemos los discos sdb,sdc,sdd,sde,sdf, y sdg para asegurar los permisos crearemos el fichero /etc/udev/rules.d/99.oracle.rules con el contenido

# Damos permisos grid:asmadmin a los discos de asm

KERNEL=="sd[b-g]1", OWNER="grid",GROUP="asmadmin", MODE="660" NAME="asmdisk_%k"

comprobamos los permisos

root@rac1 /]# ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 dic 30 16:56 /dev/sda
brw-rw---- 1 root disk 8, 1 dic 30 16:56 /dev/sda1
brw-rw---- 1 root disk 8, 2 dic 30 16:56 /dev/sda2
brw-rw---- 1 root disk 8, 16 dic 30 16:56 /dev/sdb
brw-rw---- 1 root disk 8, 17 dic 30 16:56 /dev/sdb1
brw-rw---- 1 root disk 8, 32 dic 30 16:56 /dev/sdc
brw-rw---- 1 root disk 8, 33 dic 30 16:56 /dev/sdc1
brw-rw---- 1 root disk 8, 48 dic 30 16:56 /dev/sdd
brw-rw---- 1 root disk 8, 49 dic 30 16:56 /dev/sdd1
brw-rw---- 1 root disk 8, 64 dic 30 16:56 /dev/sde
brw-rw---- 1 root disk 8, 65 dic 30 16:56 /dev/sde1
brw-rw---- 1 root disk 8, 80 dic 30 16:56 /dev/sdf
brw-rw---- 1 root disk 8, 81 dic 30 16:56 /dev/sdf1
brw-rw---- 1 root disk 8, 96 dic 30 16:56 /dev/sdg
brw-rw---- 1 root disk 8, 97 dic 30 16:56 /dev/sdg1

ejecutamos

udevadm control --reload-rules
/sbin/start_udev

Y comprobamos los permisos, tenemos que:

[root@rac1 rules.d]# ls -l /dev/sd*
brw-rw---- 1 root disk 8, 0 dic 30 15:01 /dev/sda
brw-rw---- 1 root disk 8, 1 dic 30 15:01 /dev/sda1
brw-rw---- 1 root disk 8, 2 dic 30 15:01 /dev/sda2
brw-rw---- 1 root disk 8, 16 dic 30 15:01 /dev/sdb
brw-rw---- 1 grid asmadmin 8, 17 dic 30 15:01 /dev/sdb1
brw-rw---- 1 root disk 8, 32 dic 30 15:01 /dev/sdc
brw-rw---- 1 grid asmadmin 8, 33 dic 30 15:01 /dev/sdc1
brw-rw---- 1 root disk 8, 48 dic 30 15:01 /dev/sdd
brw-rw---- 1 grid asmadmin 8, 49 dic 30 15:01 /dev/sdd1
brw-rw---- 1 root disk 8, 64 dic 30 15:01 /dev/sde
brw-rw---- 1 grid asmadmin 8, 65 dic 30 15:01 /dev/sde1
brw-rw---- 1 root disk 8, 80 dic 30 15:01 /dev/sdf
brw-rw---- 1 grid asmadmin 8, 81 dic 30 15:01 /dev/sdf1
brw-rw---- 1 root disk 8, 96 dic 30 15:01 /dev/sdg
brw-rw---- 1 grid asmadmin 8, 97 dic 30 15:01 /dev/sdg1

Comprobacion de prerequisitos

Ahora podremos comprobar que esta todo correcto con el comando


./runcluvfy.sh stage -pre crsinst -n rac1,rac2 -r 11gR2

El siguiente paso será la instalación del Grid Infraestructure

Dba stuff

Un cajon desastre para el día a día

Archivo de la categoría: grid

Voting disk (componentes del grid)

Crear un diskgoup desde asmca

Instalacion de RAC II , instalacion de grid infraestructure

Estado del Cluster/Rac/Grid tabulado

Instalación de RAC I Preparativos