Archivo de la categoría: Sistema operativo

Entradas sobre sistemas operativos y entornos de virtualizacion

Detectando bloques corruptos en Oracle

Posted on por

Hoy vamos a ver como detectar que se nos ha roto en casos de problemas de bloques corruptos de Oracle.

Lo primero que tenemos que tener en mente es tener la base de datos en modo archivelog y hacer copias periódicas con RMAN, pero , ¿que ocurre si no es así y tenemos una corrupción de datos?
Seguramente habremos perdido esos bloques. Pero, lo primero va a ser el saber que objetos lógicos tenemos corruptos .

Tenemos dos maneras de detectar la corrupción de datos

RMAN

Si tenemos la base de datos en modo archivelog ejecutaremos

 rman target / nocatalog
run {
allocate channel d1 type disk;
backup check logical validate database;
release channel d1;
}

El comando validate de RMAN hará un chequeo de los bloques inválidos y nos los dejará en la vista v$database_block_corruption;

DBVERIFY

Si no tenemos la base de datos en modo archivelog, no podemos usar RMAN (a no ser que esté en modo MOUNT), asi que,usaermos dbv.

Oracle provee en todas las plataformas el comando de sistema operativo DBVERIFY (dbv) que nos permite el llevar a cabo una comprobación de la integridad física de los ficheros de la base de datos.Su gran ventaja es que no necesita corte de servicio y podemos ejecutarlo tranquilamente mientras los usuarios trabajan en la base de datos.

La sintaxis la podemos ver en http://docs.oracle.com/cd/A97630_01/server.920/a96652/ch13.htm , y su principal inconveniente es que debe lanzarse para cada uno de los datafiles de la base de datos.

Una manera rápida de automatizar el comando para toda la base de datos es mediante el siguiente script ejecutado como sys o system

spool /tmp/datafiles_corruptos.sh
set linesize 200
set heading off
set pagesize 200
select 'dbv  file=' || name || ' blocksize=' || block_size || 
       ' feedback=' || round(blocks*.10,0)||
       '  logfile=' || file# || '.log'
          from v$datafile;

Este script nos dejara un fichero /tmp/datafiles_corruptos.sh con tantas líneas como datafiles tenga la base de datos de la forma

dbv  file=/opt/oracle/oradata/pruebas/tablespace_indices001.dbf blocksize=8192 feedback=3840  logfile=2

El comando dbv nos va a generar un fichero de log de nombre DATAFILE#.log, con lo que, mi consejo es crear un subdirectorio y lanzar el script /tmp/datafiles_corruptos.sh desde este subdirectorio, asi no llenaremos el path donde nos encontremos de ficheros de log.

EL detectar lo bloques inválidos es muy sencillo, solamente tenemos que ordenar por tamaño de fichero en el subdirectorio que tenemos los logs. Los ficheros que no tienen bloques corruptos tendrás un tamaño aproximado de 1 Km y su contenido será similar a :

DBVERIFY: Release 11.2.0.3.0 - Production on Jue Jun 6 13:14:28 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - Iniciando verificación : FILE =/opt/oracle/oradata/pruebas/tablespace_indices018.dbf
DBVERIFY - Verificación terminada
Total de Páginas Examinadas     : 153600
Total de Páginas Procesadas (Datos): 91682
Total de Páginas con Fallos (Datos): 0
Total de Páginas Procesadas (Índice): 28488
Total de Páginas con Fallos (Índice): 0
Total de Páginas Procesadas (Otras): 17288
Total de Páginas Procesadas (Seg): 1
Total de Páginas con Fallos (Seg): 0
Total de Páginas Vacías         : 16142
Total de Páginas Marcadas como Corruptas: 0
Total de Páginas de Entrada     : 0
Total de Páginas Cifradas        : 0
SCN de Bloque Superior            : 1961026896 (9.1961026896)

Los datafiles con bloques corruptos tendrán un tamaño mayor, y su contenido será

DBVERIFY: Release 11.2.0.3.0 - Production on Jue Jun 6 13:16:14 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - Iniciando verificación : FILE = /opt/oracle/oradata/pruebas/SYSAUX01.DBF
La página 45847 es de entrada - probablemente el medio físico esté corrupto
Corrupt block relative dba: 0x00c0b317 (file 3, block 45847)
Fractured block found during dbv: 
Data in bad block:
 type: 6 format: 2 rdba: 0x00c0b317
 last change scn: 0x0009.5a58966b seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x00000000
 check value in block header: 0x5708
 computed block checksum: 0x48fd

La página 45849 está marcada como corrupta
Corrupt block relative dba: 0x00c0b319 (file 3, block 45849)
Completely zero block found during dbv: 

La página 45850 está marcada como corrupta
Corrupt block relative dba: 0x00c0b31a (file 3, block 45850)
Completely zero block found during dbv: 
.
.
.
.
.
.

La página 117911 es de entrada - probablemente el medio físico esté corrupto
Corrupt block relative dba: 0x00c1cc97 (file 3, block 117911)
Fractured block found during dbv: 
Data in bad block:
 type: 0 format: 0 rdba: 0x00000000
 last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xc90c0601
 check value in block header: 0x0
 block checksum disabled

DBVERIFY - Verificación terminada
Total de Páginas Examinadas     : 141312
Total de Páginas Procesadas (Datos): 41849
Total de Páginas con Fallos (Datos): 0
Total de Páginas Procesadas (Índice): 46801
Total de Páginas con Fallos (Índice): 0
Total de Páginas Procesadas (LOB)  : 3100
Total de Páginas con Fallos (LOB)  : 0
Total de Páginas Procesadas (Otras): 27154
Total de Páginas Procesadas (Seg): 0
Total de Páginas con Fallos (Seg): 0
Total de Páginas Vacías         : 22352
Total de Páginas Marcadas como Corruptas: 56
Total de Páginas de Entrada     : 6
Total de Páginas Cifradas        : 0
SCN de Bloque Superior            : 1961026953 (9.1961026953)

Con esto tendremos también la información en la vista v$database_block_corruption;, pero ¿que objetos son los que tenemos con problemas?
Si ejecutáis la consulta :

set linesize 200
set pagesize 200
SELECT e.owner, e.segment_type, e.segment_name, e.partition_name, c.file#
, greatest(e.block_id, c.block#) corr_start_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1)
- greatest(e.block_id, c.block#) + 1 blocks_corrupted
, null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id <= c.block# + c.blocks - 1
AND e.block_id + e.blocks - 1 >= c.block#
UNION
SELECT s.owner, s.segment_type, s.segment_name, s.partition_name, c.file#
, header_block corr_start_block#
, header_block corr_end_block#
, 1 blocks_corrupted
, 'Segment Header' description
FROM dba_segments s, v$database_block_corruption c
WHERE s.header_file = c.file#
AND s.header_block between c.block# and c.block# + c.blocks - 1
UNION
SELECT null owner, null segment_type, null segment_name, null partition_name, c.file#
, greatest(f.block_id, c.block#) corr_start_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1)
- greatest(f.block_id, c.block#) + 1 blocks_corrupted
, 'Free Block' description
FROM dba_free_space f, v$database_block_corruption c
WHERE f.file_id = c.file#
AND f.block_id <= c.block# + c.blocks - 1
AND f.block_id + f.blocks - 1 >= c.block#
order by file#, corr_start_block#;

Obtendréis un resultado similar a este


OWNER        SEGMENT_TYPE       SEGMENT_NAME                   PARTITION_NAME   CORR_START_BLOCK# CORR_END_BLOCK# BLOCKS_CORRUPTED DESCRIPTION
----------- ------------------ ------------------------------------------------- ---------- ----------------- ---
SYS           TABLE              WRH$_PGASTAT                       3             45847         45847                1
SYSMAN        TABLE              MGMT_TARGET_ASSOC_ERROR            3             45851          45851             1 Segment Header

Como siempre, tenemos mas información y mas precisa en soporte oracle en :

  • OERR: ORA-1578 «ORACLE data block corrupted (file # %s, block # %s)» Master Note [ID 1578.1]
  • Note 28814.1 Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g
  • Note 556733.1 DBMS_REPAIR script y Note 68013.1 DBMS_REPAIR example
  • Physical and Logical Block Corruptions. All you wanted to know about it. [ID 840978.1]

Problemas con glibc-devel instalando OEM 12c (crt1.o)

Posted on por

Hoy vamos a ver la solución a un problema en la instalación de OEM 12c bajo Oracle linux 6.4

Si miramos la documentación de la instalación en el apartado de paquetes tenemos que necesitamos los paquetes:

  • glibc-devel-2.5-49-i686 (This is a 32-bit package)
  • glibc-devel-2.5-49-x86_64 (This is a 64-bit package)

Sin embargo, si miramos lo que tenemos en la distribución, 

[root@emc ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n" | grep glibc-dev
glibc-devel-2.12-1.107.el6(x86_64)

Y a la hora de instalar otro glibc-devel nos dice que ya está instalado

[root@emc ~]# yum install glibc-devel-2.12-1.80.el6
Loaded plugins: security
Setting up Install Process
Package matching glibc-devel-2.12-1.80.el6.x86_64 already installed. Checking for update.
Nothing to do

Si intentamos instalar , llega aun punto en que nos da un error de linkado, y es que no encuentra la librería crt1.o


INFO: Salida final del proceso iniciado.
INFO: ----------------------------------
INFO: Excepción devuelta de la acción: make
Nombre de la Excepción: MakefileException
Cadena de la Excepción: Error al llamar al destino 'install' del archivo make '/oem/oem12c/oms/sqlplus/lib/ins_sqlplus.mk'. 
Consulte '/oraInventory/logs/installActions-XX.log' para obtener más información.
Gravedad de la Excepción: 1
INFO: POPUP WARNING:Error al llamar al destino 'install' del archivo make '/oem/oem12c/oms/sqlplus/lib/ins_sqlplus.mk'. Consulte '/oraInventory/logs/installActions-XX.log' para obtener más información.

Haga clic en  "Reintentar" para volver a intentarlo.
Haga clic en "Ignorar" para ignorar este error y continuar.
Haga clic en "Cancelar" para parar esta instalación.

Este error estaba en el proceso de linkado delsqlplus, con el error

/usr/bin/ld: crt1.o: No suxh file or directory

La solución es tremendamente sencilla, y pasa un poco por la comprension del Oracle Linux, y es que,debemos instalar una librería del formato i396 (i696 para Oracle Linux), el problema , es que, cuando ejecutamos el yum este no instala las librerias de i686 debido a que nuestro sistema es x64.

Así pues, hay que forzarle a que instale el paquete de i386 (i686) con el comando


yum install glibc-devel.i686

Con este comando, tendremos los dos paquetes instalados

[root@emc ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n" 
 | grep glibc-dev

glibc-devel-2.12-1.107.el6(x86_64)
glibc-devel-2.12-1.107.el6(i686)

Y la instalación continuará sin problemas

Encontrar el proceso que se come la CPU en windows

Posted on por

Una de las principales diferencias de oracle para Unix y Windows radica en que, debido a el tipo de sistema operativo, en Windows tenemos un proceso monolítico oracle.exe, y no la multitud de procesos que nos encontramos en los sistemas Unix. Así pues, cuando queremos saber cual es el proceso que se nos come la CPU, siempre vamos a tener una misma respuesta oracle.exe y, además de eso, probablemente no podamos enlazarlo con los procesos de sistema operativo.

¿Como solucionamos este problema?

Para empezar, mi recomendación es tener en el servidor uno de estos dos programas

  • Pprocess explorer
  • QSlice

Los dos programas son gratuitos y se pueden descargar desde soporte de microsoft, y nos permitirán ver con mayor facilidad el origen de nuestro problema.

Si abrimos el process explorer , veremos algo similar a esto:
process explorer

Aquí podemos ver como uno de los procesos oracle se esta comiendo el 100% de la CPU , si hacemos boton derecho «propiedades», el process explorer nos indicará en una ventana independiente la informacion de este proceso, si vamos a la pestaña «threads» y ordenamos por CPU, tendremos:
proceso oralce.exe

Aqui vemos como los treads que mas CPU están consumiendo son

  • 3076 con el 23%
  • 4976 con el 19,95%

Ahora, teniendo estos dos número de thread, si que podremos ir a nuestra ventana de sql y enlazar este numero de thread con el proceso/sesion de Oracle que está causando la carga


select proc.spid ThreadNO,  
sess.username Usuario,  
sess.osuser OSUser,
sess.machine Maquina,  
sess.status Estado,  
sess.sid SessionID,  
sess.program Program  
from v$process proc, v$session sess, v$bgprocess bg  
where sess.paddr = proc.addr  
and bg.paddr(+) = proc.addr  
and proc.spid in (3076)

Esta informacion tambien puede obtenerse con qslice.exe, solamente que la información del thread está en exadecimal, y habremos de pasarla a decimal, por otra parte, la ventaja del qslice.exe es que es más ligero que el process explorer, con lo que, como decía al principio, mi recomendación es tener los dos en el servidor

Instalación de RAC I Preparativos

Posted on por

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

Clonación de maquinas virtuales con VirtualBox

Posted on por

Esta entrada es una pequeña prolongacion de la entrada , donde partimos de la base de que tenemos un servidor Linux en un entorno VirtualBox con los interfaces de red y los discos necesarios para llevar a cabo una instalación de Oracle RAC

El proceso de clonación de este servidor a uno que llamaremos dataguard sería:

  • Clonado de disco

    Una vez hayamos levantado esta nueva máquina copiada tendremos que llevar a cabo las siguientes modificaciones:

    • Fichero /etc/sysconfig/networ: En este fichero tendremos que poner el nombre del servidor
    • Fichero /etc/sysconfig/network-scripts/ifcfg-eth1 en este fichero habremos de modificar la IP de la eth1
    • Fichero /etc/sysconfig/network-scripts/ifcfg-eth2 en este fichero habremos de modificar la IP de la eth2
    • Fichero /etc/sysconfig/network-scripts/ifcfg-eth2 en este fichero habremos de modificar la IP de la eth2
    • Fichero /etc/udev/rules.d/70-persistent-net.rules: En este fichero el udev tendrá informacion de las interfaces de red de la máquina original, con lo que, deberemos de vaciar todas las líneas para que nuestros interfaces de red funcionen correctamente.

Con todo esto, tendremos ya nuestra infraestuctura virtual para poder hacer pruebas con el RAC