MERCADOS FINANCIEROS

jueves, 21 de marzo de 2013

Oracle 11gr2 : Problemas con ASM y Cluster Synchronization Service

Seteamos nuestro ambiente para la instancia ASM
export ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=+ASM
export PATH=$PATH:/u01/app/oracle/product/11.2.0/grid/bin


Y procedemos a levantar la instancia ASM

[oracle@oracle11g ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 05:37:25 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
ORA-29701: unable to connect to Cluster Synchronization Service
SQL>




¿Cómo solucionamos este inconveniente?
Pues he acá la explicación


El demonio del Cluster Synchronization Service (cssd daemon) no queda online después del reboteo y como la instancia ASM , necesita ese demonio, pues por eso ASM no levanta
La forma de chequearlo


[oracle@oracle11g ~]$ crsctl check cssd
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon
[oracle@oracle11g ~]$ crsctl check has
CRS-4638: Oracle High Availability Services is online
[oracle@oracle11g ~]$ ps -fea | grep d.bin
oracle 6208 1 0 Apr15 ? 00:02:37 /u01/app/oracle/product/11.2.0/grid/bin/ohasd.bin reboot



Y efectivamente vemos que el servicio está abajo ... aunque el servicio ohasd este online


¿Cuál es la causa de este inconveniente?
Pues a partir de Oracle11gr2 los demonios cssd y diskmon no son levantados vía el oratab, ahora estos demonios son levantados por el HAS (High Availability Service) y registrados en un OCR local como un recurso más.
Para analizar esto, procedemos a ir al HOME de la instalación del Grid Infraestructure, que en el fondo es el HOME que soporta el ASM
Y analizamos los recursos existentes
[oracle@oracle11g ~]$ cd $ORACLE_HOME
[oracle@oracle11g grid]$ pwd
/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g grid]$ cd bin
[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE




Como vemos , ambos demonios , inscritos como recursos se encuentran OFFLINE
Para ver el origen del problema, analizamos los recursos con su configuración en detalle
Nota : Solamente vamos a mostrar los recursos que tienen problemas (CSSD y DISKMON)
[oracle@oracle11g bin]$ ./crsctl status resource -p
NAME=ora.cssd
TYPE=ora.cssd.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/cssdagent%CRS_EXE_SUFFIX%
AGENT_HB_INTERVAL=0
AGENT_HB_MISCOUNT=10
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=30
CLEAN_ARGS=abort
CSSD_PATH=%CRS_HOME%/bin/ocssd%CRS_EXE_SUFFIX%
CSS_USER=oracle
DEGREE=1
DESCRIPTION="Resource type for CSSD"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
OMON_INITRATE=1000
OMON_POLLRATE=500
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
PROCD_TIMEOUT=1000
RESTART_ATTEMPTS=5
SCRIPT_TIMEOUT=600
START_DEPENDENCIES=weak(concurrent:ora.diskmon)
START_TIMEOUT=600
STOP_DEPENDENCIES=hard(shutdown:ora.diskmon)
STOP_TIMEOUT=900
UPTIME_THRESHOLD=1m
VMON_INITLIMIT=16
VMON_INITRATE=500
VMON_POLLRATE=500
NAME=ora.diskmon
TYPE=ora.diskmon.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/orarootagent%CRS_EXE_SUFFIX%
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=20
CHECK_TIMEOUT=10
DEGREE=1
DESCRIPTION="Resource type for Diskmon"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
RESTART_ATTEMPTS=10
SCRIPT_TIMEOUT=60
START_DEPENDENCIES=weak(concurrent:ora.cssd)pullup:always(ora.cssd)
START_TIMEOUT=60
STOP_TIMEOUT=60
UPTIME_THRESHOLD=5s
USR_ORA_ENV=ORACLE_USER=oracle
VERSION=11.2.0.1.0




La propiedad AUTO_START esta seteada como NEVER o como 2 , para los demonios CDDS y DISKMON, esto implica que estos recursos no serán levantados nunca en un reincio por el HAS, y si el Cluster Synchronization Service no puede levantar, implica que la instancia ASM no puede partir.
Para solucionar el problema se debe configurar el AUTO_START para esos demonios (diskmon y cssd)
[oracle@oracle11g bin]$ ./crsctl modify resource "ora.cssd" -attr "AUTO_START=1"
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$ ./crsctl modify resource "ora.diskmon" -attr "AUTO_START=1"
[oracle@oracle11g bin]$




Una vez ejecutados esos comandos, procedemos a analizar nuevamente la configuración de los recursos
NAME=ora.cssd
TYPE=ora.cssd.type
AUTO_START=1
NAME=ora.diskmon
TYPE=ora.diskmon.type
AUTO_START=1



Verificamos los recursos y su estado actual
[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE
[oracle@oracle11g bin]$




Como podemos apreciar, ahora se encuentran con un TARGET ONLINE, lo que implica que se reiniciarán con un reboteo..
Pero se aprecia que el STATE es OFFLINE, eso implica que no están arriba los recursos, procedemos a levantarlos
[oracle@oracle11g bin]$ ./crs_start -all
Intentando iniciar `ora.cssd` en el miembro `oracle11g`
Intentando parar `ora.diskmon` en el miembro `oracle11g`
La parada de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.diskmon` en el miembro `oracle11g`
El inicio de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
El inicio de `ora.cssd` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.asm` en el miembro `oracle11g`
El inicio de `ora.asm` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.DATA.dg` en el miembro `oracle11g`
El inicio de `ora.DATA.dg` en el miembro `oracle11g` se ha realizado correctamente.



Y los volvemos a verificar
[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE oracle11g
ora.asm
ONLINE ONLINE oracle11g Started
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE ONLINE oracle11g
ora.diskmon
1 ONLINE ONLINE oracle11g




Ahora procedemos a levantar nuestra instancia ASM
Vale la pena recordar, que la instancia ASM ya no se levanta con el rol SYSDBA, existe uno nuevo llamado SYSASM , si nos conectamos con SYSDBA, aparecerá un error de privilegios
[oracle@oracle11g bin]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 06:05:11 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> startup
ORA-01031: insufficient privileges
SQL>


 Nos conectamos con el rol indicado y procedemos a subir la instancia ASM

SQL> conn / as sysasm
Connected.
SQL> startup
ASM instance started
Total System Global Area 284565504 bytes
Fixed Size 1336036 bytes
Variable Size 258063644 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted

miércoles, 20 de marzo de 2013

Buscar History

history grep | mkfs

Muestra la lista de historia de órdenes con números de línea, el fichero de historial por defecto esta contenido en el valor de la variable HISTFILE.
history n muestra las últimas n líneas
history -c borra la lista de historial (borrando todas las entradas).
history -d 625 Borra el comando que se encuentre en la posición 625 de la lista de historial
history -a añade las líneas de historia ‘‘nuevas’’ (las introducidas desde el inicio de la sesión de bash en curso) al fichero de historia.
history -r lee los contenidos del fichero de historia y los usa como la historia en curso.
Trabajando con el Historial de comandos
!find ejecuta la última orden que empieza por la cadena find
!?home? ejecuta la última orden que contenga la cadena home
ctrl+r busca la cadena en el history
comando ejecuta comando sin que este sea almacenado en el historial de comandos, esto será así dependiendo del valor de las variables de ambiente HISTCONTROL y HISTIGNORE (ver man bash, para mayor información)
kill -9 $$ sale del shell actual sin guardar el historial de comandos.

martes, 19 de marzo de 2013

UPTIME


Calcular Disponibilidad

select
   'Hostname : ' || host_name
   ,'Instance Name : ' || instance_name
   ,'Started At : ' || to_char(startup_time,'DD-MON-YYYY HH24:MI:SS') stime
   ,'Uptime : ' || floor(sysdate - startup_time) || ' days(s) ' ||
   trunc( 24*((sysdate-startup_time) -
   trunc(sysdate-startup_time))) || ' hour(s) ' ||
   mod(trunc(1440*((sysdate-startup_time) -
   trunc(sysdate-startup_time))), 60) ||' minute(s) ' ||
   mod(trunc(86400*((sysdate-startup_time) -
   trunc(sysdate-startup_time))), 60) ||' seconds' uptime
from
   sys.v_$instance;
If you assume that PMON startup time is the same as the database startup time, you can get the uptime here:select
   to_char(logon_time,'DD/MM/YYYY HH24:MI:SS')
from
   v$session
where
   sid=1;