Crear un diskgoup desde asmca

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

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.
rac_pantalla1
En la siguiente pantalla indicaremos que queremos instalar la versión del grid infraestructure que aplica a un cluster
tac_pantalla2
Nosotros elegiremos la instalación avanzada para poder afinar mas las opciones de instalación.
rac_pantalla3
rac4
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
Captura de pantalla 2013-12-28 a la(s) 17.56.41
rac_pantalla7
rac_pantalla8
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

rac_pantalla9
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
rac_pantalla10

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
Captura de pantalla 2013-12-28 a la(s) 17.58.20

rac_pantalla12
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.
rac_pantalla13
rac_pantalla14
Indicamos los directorios que teníamos planificados
rac_pantalla16
Finalmente, vemos las opciones y el resumen

Captura de pantalla 2013-12-28 a la(s) 18.33.06
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
rac_pantalla20

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

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

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)

Introduccion a los servicios de Oracle

Uno de los elementos mas potentes que introdujo Oracle en la versión 10g fué el uso de servicios.
Los servicios de Oracle no son otra cosa que una abstracción lógica de una instancia de base de datos. Aunque los servicios tienen mas sentido en entorno RAC, hoy vamos a ver como se configuran y para que pueden servir en un entorno de «single instance».

Supongamos tenemos una base de datos produccion en la que tenemos consolidados 4 entornos distintos ( Webfotos,Cargas,Contabilidad y Desarrollo ) que acceden a nuestra instancia con el mismo esquema,y desde servidores de aplicaciones que comparten máquina entre ellos, en el momento en que la base de datos tiene problemas nos es muy difícil el saber quien es quien.
Si pudiésemos discriminar las conexiones por una agrupación lógica, sería mas fácil el verlo, y , mas aún, si el EMC fuese capaz de separar las gráficas y estadísticas por esa agrupación.

Pues esto es exactamente lo que nos proporcionan los servicios Oracle.
En nuestro caso ficticio, vamos a crear los distintos servicios:

  • Webfotos
  • Cargas
  • Contabilidad
  • Desarrollo

De esta forma, cada conexión de estos 4 entornos usara un service_name distinto en su TNS_NAMES de cliente, y , la base de datos podrá identificar ( y limitar) a cada uno de ellos de manera separada.

Lo primero que tendremos que hacer es crear los servicios. Para esto tenemos dos maneras, o bien desde el srvctl ( en caso de RAC,Grid control u Oracle restart), o mediante el paquete DBMS_SERVICES , como nuestro caso es el de una «single instance», no nos va a quedar mas remedio que usar este paquete.
Mediante la función CREATE_SERVICE crearemos los servicios de la manera:

exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'webfotos', NETWORK_NAME=>'webfotos')
exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'cargas', NETWORK_NAME=>'cargas')
exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'contabilidad', NETWORK_NAME=>'contabilidad')
exec dbms_service.CREATE_SERVICE(SERVICE_NAME=>'desarrollo', NETWORK_NAME=>'desarrollo')

Una vez creados los servicios, los arrancaremos con la función

exec dbms_service.START_SERVICE('webfotos')
exec dbms_service.START_SERVICE('cargas')
exec dbms_service.START_SERVICE('contabilidad')
exec dbms_service.START_SERVICE('desarrollo')

Para comprobar si la creación de nuestros servicios ha funcionado, podemos chequear el parámetro service_names

SQL> select value from v$parameter where NAME='service_names';
VALUE
---------------------------
produccion,webfotos,cargas,contabilidad,desarrollo

O bien el listener con lsnrctl services

[oracle@blog] [$lsnrctl services

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 17-MAY-2013 13:31:06

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0
         LOCAL SERVER
Service "produccion" has 1 instance(s).
  Instance "XE", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:34 refused:0 state:ready
         LOCAL SERVER
Service "webfotos" has 1 instance(s).
  Instance "XE", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:34 refused:0 state:ready
         LOCAL SERVER
Service "contabilidad" has 1 instance(s).
  Instance "XE", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:34 refused:0 state:ready
         LOCAL SERVER
Service "desarrollo" has 1 instance(s).
  Instance "XE", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:34 refused:0 state:ready
         LOCAL SERVER
Service "cargas" has 1 instance(s).
  Instance "XE", status READY, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:34 refused:0 state:ready
         LOCAL SERVER
The command completed successfully

Ahora, solamente tendremos que modificar los respectivos TNSNAMES de los distntos entornos para que se conecten mediante SERVICE_NAME y no mediante SID y tendremos identificados cada una de la sesiones de oracle con el servicio.

¿que beneficios nos aporta todo esto?

  • Trazabilidad: Nos va a ser sencillísimo encontrar quien es el que esta haciendo algo ya que en un primer vistazo encontraremos al culpable «logico» del problema, una vez tenemos el origen del problema es mas sencillo abordarlo.
  • Accounting: Vamos a poder ser capaces de ver los consumos de cada aplicacion/grupo lógico en la base de datos, lo que nos puede ser muy bueno a la hora de derivar costes o limitar recursos
  • control de accesos: Si en un momento específico queremos asegurarnos de que un elemento lógico no acceda a la aplicacion, podemos detener el servicio y el resto funcionaría correctamente.Esto puede ser muy útil por ejemplo, para evitar cargas en horario diurno, o para controlar los equipos de desarrollo

Hasta ahora lo hemos visto todo muy fácil, pero .. ¿que ocurre cuando reinicias la base de datos?.
Para que la instancia levante los servicios al arrancar deberán de estar en el init.ora con la sintaxsis:


service_names='produccion','webfotos','cargas','desarrollo'

Si no es así , cuando se levante nuestra base de datos no se levantan los servicios, y esto hace que no funcione nada de lo que apunta a ellos.
La solución como os decía la principio es hacerlo desde el srvctl, pero …
¿como lo hacemos si no tenemos RAC,Grid u Oracle restart?
La respuesta es brutalmente sencilla.

[oracle@blog] [$sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.2.0 Production on Vie May 17 13:09:11 2013
Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
SQL> alter system set service_names='produccion,webfotos,cargas,contabilidad,desarrollo';
System altered.

Tan sencillo como acabáis de ver, simplemente hemos de conectarnos desde el sqlplus y hacer un ALTER SYSTEM para el parámetro service_names poniendo nuestros servicios separados por comas.

Como siempre, para mas información, tenemos la documentación de Oracle del paqueteDBMS_SERVICES

Monitorizar el alert.log desde una sql remota

El fichero de alertas de oracle alert.log es uno de los ficheros que tradicionalmente revisamos en busca de errores de la base de datos.
Hasta la versión 11g esta monitorización se hacía por medio del scripts que interactuaban con ficheros del sistema operativo, lo que nos llevaba a tener que mantener estos scripts para las distintas versiones de shells de sistema, o tener que instalar algún tipo de interprete en el sistema que nos lo gestionara de manera multiplataforma.

Una de las grandes ventajas de la 11g es que Oracle nos ha obsequiado con una tabla de base de datos que mapea esta información del alert.log dentro de la base de datos . Estamos hablando de la tabla x$dbgalertext;

Mediante la tabla x$dbgalertext podemos obtener toda la informacion que está en el alert.log, su contenido es:

SQL> desc X$DBGALERTEXT

           Name                            Null?    Type
           ------------------------------- -------- -------------------------
    1      ADDR                                     RAW(4)
    2      INDX                                     NUMBER
    3      INST_ID                                  NUMBER
    4      ORIGINATING_TIMESTAMP                    TIMESTAMP(3) WITH TIME ZONE
    5      NORMALIZED_TIMESTAMP                     TIMESTAMP(3) WITH TIME ZONE
    6      ORGANIZATION_ID                          VARCHAR2(64)
    7      COMPONENT_ID                             VARCHAR2(64)
    8      HOST_ID                                  VARCHAR2(64)
    9      HOST_ADDRESS                             VARCHAR2(16)
   10      MESSAGE_TYPE                             NUMBER
   11      MESSAGE_LEVEL                            NUMBER
   12      MESSAGE_ID                               VARCHAR2(64)
   13      MESSAGE_GROUP                            VARCHAR2(64)
   14      CLIENT_ID                                VARCHAR2(64)
   15      MODULE_ID                                VARCHAR2(64)
   16      PROCESS_ID                               VARCHAR2(32)
   17      THREAD_ID                                VARCHAR2(64)
   18      USER_ID                                  VARCHAR2(64)
   19      INSTANCE_ID                              VARCHAR2(64)
   20      DETAILED_LOCATION                        VARCHAR2(160)
   21      PROBLEM_KEY                              VARCHAR2(64)
   22      UPSTREAM_COMP_ID                         VARCHAR2(100)
   23      DOWNSTREAM_COMP_ID                       VARCHAR2(100)
   24      EXECUTION_CONTEXT_ID                     VARCHAR2(100)
   25      EXECUTION_CONTEXT_SEQUENCE               NUMBER
   26      ERROR_INSTANCE_ID                        NUMBER
   27      ERROR_INSTANCE_SEQUENCE                  NUMBER
   28      VERSION                                  NUMBER
   29      MESSAGE_TEXT                             VARCHAR2(2048)
   30      MESSAGE_ARGUMENTS                        VARCHAR2(128)
   31      SUPPLEMENTAL_ATTRIBUTES                  VARCHAR2(128)
   32      SUPPLEMENTAL_DETAILS                     VARCHAR2(128)
   33      PARTITION                                NUMBER
   34      RECORD_ID                                NUMBER

Ahora bien, ¿como accedemos a ella?

La tabla no puede ser accedida directamente desde un usuario que no sea sys, así que, lo que haremos será el crear una vista sobre esta tabla (a la que llamaremos por ejemplo ficheroalert ) y permitirle que lo vea a nuestro usuario de monitorizacion.


create view ficheroalert as select  * from sys.x$dbgalertext;
grant select on sys.ficheroalert to MONITORIZACION;

A partir de aquí, solamente tenemos que jugar con los campos descritos arriba y podremos obtener la informacion que deseemos.
En mi caso , por ejemplo, me gustaría saber si ha habido algún mensaje ORA- o ERROR en los ultimos 5 munitos.

La consulta que ejecutaré para obtenerlo es:


select to_char(ORIGINATING_TIMESTAMP, 'dd-mon-yyyy hh24:mi:ss'),
      substr(MESSAGE_TEXT, 1, 300) message_text
    from sys.ficheroalert
    where (MESSAGE_TEXT like '%ORA-%'
            or upper(MESSAGE_TEXT) like '%ERROR%')
     and 
           cast(ORIGINATING_TIMESTAMP as DATE) > sysdate - 5/1440;
            - X/1440 es la X en minutos 

Entrada en ingles en Monitoring the alert.log from a remote sql