Usando los bloques logicos en ASM

Hoy vamos a ver una entrada que nos puede causar grandes dolores de cabeza .

Uno de los problemas con los que nos podemos encontrar cuando se modifica la tecnología de los discos físicos utilizados en el ASM es el cambio del tamaño de bloque lógico.

Supongamos que nos ofrecen un nuevo disco /dev/xvdz

Nosotros intentamos añadirlo al ASM, pero recibimos un error ORA-01378

Errors in file /u01/app/oracle/diag/rdbms/test/TEST/trace/TEST_ora_40862.trc:
ORA-01378: The logical block size (512) of file +REDO is not compatible with the disk sector size 
(media sector size is 4096 and host sector size is 4096)

Veamos las características de este disco

sudo fdisk -l /dev/xvdz
Disk /dev/xvdd: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Y veamos ahora otro de los discos que tenemos

The other disks  have sector size 512
Disk /dev/xvdp: 2147.5 GB, 2147483648000 bytes
255 heads, 63 sectors/track, 261083 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Si nos fijamos, el problema que tenemos es que el sector size de nuestro nuevo disco es 8 veces mayor que el del disco viejo (521 / 4096) .

Como solucionamos ahora nuestro problema?

Tal y como indican el el blog flashdba ASM tiene un parámetro en el fichero de configuración llamado ORACLEASM_USE_LOGICAL_BLOCK_SIZE que por defecto esta a false, que era el parámetro por defecto de oracleasm-support-2.1.8.
Podemos ver su valor en el fichero /etc/sysconfig/oracleasm

# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false

Lo que vamos ha hacer es modificarlo a TRUE, de manera que el ASM sea capaz de usar los bloques de manera lógica y no se aferre a la configuración física de los mismos, esto lo hacemos con el script
oracleasm-configure.sh

  • -b|—logical-blocks sets logical blocksize usage
  • -p|—physical-blocks set physical blocksize usage

Veamos ahora cual es la información que nos dará nuestro ASM

[oracle@testserver ~]$ sysasm
 SQL> select NAME,SECTOR_SIZE,BLOCK_SIZE,DATABASE_COMPATIBILITY,COMPATIBILITY,((TOTAL_MB-FREE_MB)*100/TOTAL_MB) PERCENT_USED from v$asm_diskgroup;

NAME         SECTOR_SIZE BLOCK_SIZE DATABASE_COMPATIBILI COMPATIBILITY        PERCENT_USED
-------------------- --------- ---------- -------------------- -------------------- ------------
REDO               4096       4096 10.1.0.0.0           10.1.0.0.0             .249023438
FRA                 512       4096 10.1.0.0.0           12.1.0.0.0             44.1858724
DATA                512       4096 11.2.0.0.0           11.2.0.0.0             90.4637587

Como podeis ver, es un problema que se nos puede dar en bases de datos con ASM antiguos en los que llevemos a cabo un cambio de tecnología física.

Mas informacion en

Oracle ASMLib: Physical and Logical Blocksize

kernel.panic_on_oops : Nuevo parametro de la 12c

Hoy vamos a ver otra de estas pequeñas sorpresas de Oracle en las nuevas versiones
En los requisitos de la instalacion de la version 12c de Oracle nos encontramos con la siguiente nota

Note: 
The below Kernel Parameter "panic_on_oops=1" is being Introduced and required
 from 12.1.0.2.0 onwards.
kernel.panic_on_oops=1

Que es lo que hace este parametro del Kernel?
Este parametro simplemente controla el comportamiento del kernec cuando un oops or bug es detectado.

Los valores que puede tomar es:

  • 0: INtenta continuar la operacion
  • 1: Entra en panic , ademas de este panica, si el sysctl es distnto de cero, entonces el servidor se reiniciara

Como veis, un parametro bastante inocuo… hasta que buscamos la causa de por que el servidor se ha reiniciado

Script de arranque con el systemctl

Hoy vamos a ver (con mucho retraso) como hacer un script de arranque para el systemctl para nuestra base de datos 12c

Vamos a poner el supuesto de que tenemos una base de datos 12c, en filesystem en una OL7. Al no haber instalado el grid control, nadie arrancará nuestra base de datos.
¿Como hacemos para que arranque en el inicio ?
Simplemente hay que crearlos servicios de arranque

Scripts de arranque

Al igual que en un linux clásico, necesitaremos un script de start y stop para nuestra base de datos, nosotros crearemos :

  • listener.sh para el listener
  • cdbtest.sh para nuestra instancia cdbtest.

Por compatibilidad con los sistemas antiguos, lo dejaremos en /etc/init.d (auqnue toda la información que he visto en internet lo deja ene l propio $HOME de oracle ) y le añadiremos una guarda que compruebe que solamente pueda arrancase con el usuario oracle (y evitar asi que alguien lo use como root)

/etc/init.d/listener.sh

#!/bin/bash
##  Configuramos el nombre del usuario que arranca la BBDD
export USUARIO=oracle
if [ $UID -ne  `id -u $USUARIO`  ];then
 echo "Programa invocado con  incorrecto, debe de invocarse como $USUARIO "
 exit 1 ;
fi
export ORAENV_ASK=no
export export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1
case $1 in 
start)
	$ORACLE_HOME/bin/lsnrctl start 
;;
stop)
        $ORACLE_HOME/bin/lsnrctl stop
;;
status)
        $ORACLE_HOME/bin/lsnrctl status
;;
*)
  echo "Usage $0 start|stop|status "
  ;;
esac

/etc/init.d/cdbtest.sh

#!/bin/bash
##  Configuramos el nombre del usuario que arranca la BBDD
export USUARIO=oracle
if [ $UID -ne  `id -u $USUARIO`  ];then
 echo "Programa invocado con  incorrecto, debe de invocarse como $USUARIO "
 exit 1 ;
fi
export ORACLE_SID=cdbtest
export ORAENV_ASK=NO
. oraenv
case $1 in 
start)
$ORACLE_HOME/bin/sqlplus "/as sysdba" << EOF
	startup;
	exit;
EOF
;;
stop)
$ORACLE_HOME/bin/sqlplus "/as sysdba" << EOF
	shutdown immediate;
	exit;
EOF
;;
*)
  echo "Usage $0 start|stop "
  ;;

Creamos los servicios de systemctl

Ahora que tenemos ya los scripts que arrancaran y pararan el listener y la base de datos, crearemos nuestros servicios de arranque.
Crearemos uno especifico para el listener y otro para nuestra instancia cdbtest.
Para identificar cuales son nuestros servicios , los llamaremos dbora-XXX . Esto no es una convención genérica ni una best practice , sino que es simplemente un patrón propio para facilitarme su futura identificación.

Servicio dbora-listener.service

Crearemos un fichero llamado /lib/systemd/system/dbora-listener.service

[Unit]
Description=The Oracle Listener
After=syslog.target network.target

[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535

RemainAfterExit=yes
User=oracle
Group=oinstall
ExecStart=/etc/init.d/listener.sh start 
ExecStop=/etc/init.d/listener.sh stop 
Type=idle
RemainAfterExit=yes
User=oracle
Group=oinstall
[Install]
WantedBy=multi-user.target

Servcio dbora-cdbtets.service

Ahora crearemos un servicio de arranque para nuestra instancia /lib/systemd/system/dbora-cdbtets.service

[Unit]
Description=Base de datos cdbtest
After=syslog.target network.target dbora-listener.service

[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535
RemainAfterExit=yes
User=oracle
Group=dba
ExecStart=/etc/init.d/cdbtest.sh start  >> /tmp/startup_cdbtestlog 2>&1 &
ExecStop=/etc/init.d/cdbtest.sh stop  >> /tmp/shutdown_cdbtestlog 2>&1 &
Type=idle
[Install]
WantedBy=multi-user.target

Configuramos los servicios

Ya tenemos los scripts de arranque y los scripts de los servicios. Ahora simplemente nos quedará el habilitarlos para su funcionamiento.
Para ello, primero haremos un reload para refrescar los servicios

# systemctl daemon-reload
Y luego los cargaremos y habilitaremos
systemctl start dbora-listener.service
systemctl enable dbora-listener.service
systemctl start dbora-cdbtest.service
systemctl enable dbora-cdbtest.service

Así pues, si queremos ver el estado del service, podremos ver como :

[root@alone ~]# systemctl status dbora-cdbtest.service
● dbora-cdbtest.service - Base de datos cdbtest
   Loaded: loaded (/usr/lib/systemd/system/dbora-cdbtest.service; enabled; vendor preset: disabled)
   Active: active (exited) since mar 2017-02-21 13:16:19 CET; 9min ago
  Process: 1039 ExecStart=/etc/init.d/cdbtest.sh start >> /tmp/startup_cdbtestlog 2>&1 & (code=exited, status=0/SUCCESS)
 Main PID: 1039 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/dbora-cdbtest.service
           ├─2303 ora_pmon_cdbtest
           ├─2305 ora_psp0_cdbtest
           ├─2307 ora_vktm_cdbtest
           ├─2311 ora_gen0_cdbtest
           ├─2315 ora_mman_cdbtest
           ├─2317 ora_diag_cdbtest
           ├─2319 ora_dbrm_cdbtest
           ├─2321 ora_vkrm_cdbtest
           ├─2323 ora_dia0_cdbtest
           ├─2325 ora_dbw0_cdbtest
           ├─2327 ora_lgwr_cdbtest
           ├─2329 ora_ckpt_cdbtest
           ├─2331 ora_smon_cdbtest
           ├─2333 ora_reco_cdbtest
           ├─2335 ora_lreg_cdbtest
           ├─2337 ora_pxmn_cdbtest
           ├─2339 ora_mmon_cdbtest
           ├─2341 ora_mmnl_cdbtest
           ├─2343 ora_d000_cdbtest
           ├─2345 ora_s000_cdbtest
           ├─2357 ora_tmon_cdbtest
           ├─2359 ora_tt00_cdbtest
           ├─2361 ora_smco_cdbtest
           ├─2363 ora_w000_cdbtest
           ├─2365 ora_w001_cdbtest
           ├─2369 ora_aqpc_cdbtest
           ├─2373 ora_p000_cdbtest
           ├─2375 ora_p001_cdbtest
           ├─2377 ora_p002_cdbtest
           ├─2379 ora_p003_cdbtest
           ├─2381 ora_qm02_cdbtest
           ├─2385 ora_q002_cdbtest
           ├─2387 ora_q003_cdbtest
           └─2452 ora_cjq0_cdbtest

feb 21 13:16:33 alone.pamplona.name cdbtest.sh[1039]: Copyright (c) 1982, 2014, Oracle.  All rights reserved.
feb 21 13:16:51 alone.pamplona.name cdbtest.sh[1039]: Connected to an idle instance.
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: SQL> ORACLE instance started.
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Total System Global Area 6291456000 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Fixed Size                    2938352 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Variable Size                 3372222992 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Database Buffers         2902458368 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Redo Buffers                   13836288 bytes
feb 21 13:17:05 alone.pamplona.name cdbtest.sh[1039]: Database mounted.
feb 21 13:17:30 alone.pamplona.name cdbtest.sh[1039]: Database opened.

Alarmas ioctl 2285 en Linux

Hoy vamos a ver una entrada rápida para tranquilizarnos ante algunos errores.
Tras las Entradas anteriores en las que usabamos una particion y ASMlib para los discos ASM, he recibido preguntas de administradores que se encuentran en el dmesg o en el messajes con erroers del tipo

oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!
oracle: sending ioctl 2285 to a partition!

Estos mensajes que en un principio pueden asustar un poco, pueden ser ignorados con tranquilidad.
Parece ser que son errores específicos si usamos la version UEK del kernel Enterprise Kernel for Oracle Linux y que están solventados en el 2.6.39-400.100.0.el6uek

Más información

Manejo de ASM , Multipath y ASMLIB

Hoy vamos a ver la manera de crear discos con ASM en equipos linux con el multipath y ASMLIB.
La primera pregunta es ¿por que ASMLIB?

Al igual que en las versiones anteriores de Redhat o Oracle Linux donde mi opinión era usar el rawdevices de la manera clásica accediendo al dispositivo en crudo, con la llegada del systemd no me la jugaría en las secuencias de arranque y usaría siempre las librerías que nos proporcionan de manera soportada para ayudarnos con esto, y esa librería es el asmlinb

Multpath en Linux

Lo primero que tenemos que ver es como funciona el multipath en linux.
El «device Mapper Multipath» es una herramienta nativa de Linux para el manejo de múltiples caminos en los accesos a disco.
Resumiendo mucho, el multipath nos va a crear 3 devices:

  • /dev/dmX Dispositivo real
  • /dev/multipath/multipahX Alias del dispositivo para la facilitar la localizacion (formato humano)
  • /dev/mapper/multipathX Dispositivo de acceso al que deberemos apuntar nuestro ASM

Gran parte de los problemas que se tienen con el multipath es el uso de estos tres devices, ya que, es muy común el crear el disco en el dispositivo que no es correcto.

Primer paso, preparar el disco

El primer paso como siempre será la detección del disco. Este paso probablemente lo lleve a cabo el administrador del sistema operativo. Vamos a suponer que el dispositivo sobre el que queremos actuar es el /dev/mapper/mpath10

Lo primero que tendremos que hacer es crear una partición ( Oracle recomienda crear en raw sobre una particion)
para ello

fdisk /dev/mapper/mpath10
Command (m for help): n   
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1017, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-31455238, default 31455238):
Using default value 31455238
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.

Si os habeis fijado, hemos utilizado el dispositivo bajo /dev/mapper y no ninguno de los otros dos.
Con esto hemos creado la partición, pero no se ha grabado en la tabla de particiones del disco ya que hemos actuado sobre el multipath no sobre los discos físicos, para lo que tendremos que llamar el kpartx, y actualizar el kernel con partprobe.
Aquí es donde tenemos que tener mucho cuidado, ya que debemos de usar de nuevo el /dev/mapper

kpartx -a /dev/mapper/mpath10
partprobe

Estas acciones nos habrán creado un nuevo device en el /dev/mapper que se corresponderá con la primera partición de nuestro dispositivo multipath, es decir el /dev/mapper/mpath10p1

Segundo paso, mostrarlo al ASM

Una vez tenemos la partición creada, ya tendremos nuestro disco para añadir a ASM, esta partición se llamará DISKp1, por lo que para nuestro mpath10 será la mpath10p1
Así pues, llamamos al ASMLIB con

/etc/init.d/oracleasm createdisk DATAXX /dev/mapper/mpath10p1

ASMLIB nos habrá creado el dispositivo DATAXX en /dev/oracleasm/disks que será la ruta que usaremos en nuestra variable ASM_DISKSTRING del ASM y que ya tratará de manera indistinta el disco independientemente del camino por el que llegue.

Como siempre , mas información en

  • How To Setup ASM & ASMLIB On Native Linux Multipath Mapper disks? (Doc ID 602952.1)
  • How to Partition DM-Multipath Pseudo Devices (Doc ID 470913.1)