domingo, 18 de enero de 2015

Servidores de aplicaciones como servicios de sistema

Colocar script de arranque del servidor en el arranque del sistema 

Para que los servidores de aplicaciones se arranquen a la vez que se arranque la máquina, debemos incluir el script de arranque del Servidor de aplicaciones en el sector de arranque del Sistema Operativo. En el caso de máquinas Linux, debemos incluir enlaces simbólicos a dichos scripts en la ruta  /etc/init.d  e incluirlo en los niveles de arranque adecuados. 

Particularizamos a continuación los diferentes procedimientos a seguir para servidores de aplicaciones Tomcat y Jboss.

TOMCAT

 

Para levantar el servidor Tomcat con un usuario sin privilegios y dejarlo corriendo como servicio, se utiliza la aplicación jsvc que viene incluida dentro del propio servidor Tomcat (Tomcat 5.x), tal y como se indica en la web http://tomcat.apache.org/tomcat-5.5-doc/setup.html, siguiendo la siguiente secuencia de comandos.

cd $CATALINA_HOME/bin
tar xvfz jsvc.tar.gz
cd jsvc-src
autoconf
./configure
make
cp jsvc ..
cd ..

Se obtiene el binario jsvc y el script Tomcat5.sh en el directorio $CATALINA_HOME/bin. 

Este script, una vez modificado para indicar el usuario (ej: tomcat). Tendremos que modificar los siguientes parámetros en el script Tomcat5.sh:

JAVA_HOME = [Ruta donde hemos instalado el JDK]
CATALINA_HOME = [Ruta donde hemos instalado Tomcat]
DAEMON_HOME = [Ruta donde hemos instalado el Tomcat]
TOMCAT_USER = [Nombre del usuario que arrancará el Tomcat]

Si tenemos múltiples instancias de Tomcat, puede ser necesario modificar también los siguientes parámetros:

TMP_DIR
PID_FILE
CATALINA_BASE

El siguiente paso consistiría en crear un simbólico en la carpeta /etc/init.d con el siguiente comando y ejemplo:

ln -s /opt/pa_html/apache-tomcat-5.5.25/bin/jsvc /etc/init.d/tomcatservice

Si nos encontramos en un sistema Redhat, el siguiente paso sería colocar el script en los correspondientes niveles de arranque, mediante el comando:

chkconfig --add /etc/init.d/tomcatservice

Si estamos en un sistema Debian, el comando “chkconfig” no funcionaria correctamente, deberemos de colocar los scripts manualmente para inicio en los niveles 2 3 4 5, y de parada en los niveles 0 1 y 6. Lo haremos de la siguiente manera:

ln -s /etc/init.d/tomcatservice /etc/rc0.d/K88Tomcat
ln -s /etc/init.d/tomcatservice /etc/rc1.d/K88Tomcat
ln -s /etc/init.d/tomcatservice /etc/rc2.d/S88Tomcat
ln -s /etc/init.d/tomcatservice /etc/rc3.d/S88Tomcat
ln -s /etc/init.d/tomcatservice /etc/rc2.d/S88Tomcat
ln -s /etc/init.d/tomcatservice /etc/rc4.d/S88Tomcat
ln -s /etc/init.d/tomcatservice /etc/rc5.d/S88Tomcat
ln -s /etc/init.d/tomcatservice /etc/rc6.d/K88Tomcat

De todas formas podemos automatizar este proceso (sólo en Debian) mediante el comando “update-rc.d”, de la siguiente manera:

update-rc.d /etc/init.d/tomcatservice start 88 2 3 4 5 . stop 11 0 1 6

Se aconseja que los números de secuencia (88 y 11) sumen 99. Ya que la secuencia de inicio debe de ser inversa a la de arranque.

JBOSS

 

En la carpeta bin del servidor de aplicaciones Jboss existen una serie de scripts preparados para ponerlos en el arranque y servir como demonios. El script está optimizado para sistemas operativos Red Hat, aunque en Debian no debe haber problemas para que funcione. 

Por tanto, cogemos el script jboss_init_redhat.sh y lo editamos para definirle los siguientes parámetros:

JAVAPTH = [Ruta donde hemos instalado el JDK]
JBOSS_HOME = [Ruta donde hemos instalado el Jboss]
JBOSSUS = [Nombre del usuario que arrancará el Jboss]

A continuación creamos en /etc/init.d/ un enlace simbólico, llamado jboss, que apunte al script que acabamos de modificar. Lo hacemos con el siguiente comando:

 ln –s  $JBOSS_HOME/bin/jboss_init_redhat.sh jboss

 Para terminar lo colocamos en los niveles de arranque. Este script está preparado para colocarlo en el nivel de arranque 3, para hacer esto, tras crear el enlace simbólico, basta con ejecutar el siguiente comando:

 chkconfig --add /etc/init.d/jboss
           
Si nos encontramos en un sistema Debian, el comando “chkconfig” no dará resultado, así que haremos lo descrito en el último punto anterior sobre Tomcat, es decir crearemos los enlaces simbólicos en los distintos niveles de arranque manualmente.

martes, 6 de enero de 2015

Cerrar sesiones en Oracle

El primer paso es identificar la sesión que queremos matar:

SET LINESIZE 100
COLUMN spid FORMAT A10
COLUMN username FORMAT A10
COLUMN program FORMAT A45

SELECT s.inst_id,
       s.sid,
       s.serial#,
       p.spid,
       s.username,
       s.program
FROM   gv$session s
       JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id
WHERE  s.type != 'BACKGROUND';

   INST_ID        SID
   SERIAL# SPID       USERNAME   PROGRAM
---------- ---------- ---------- ---------- ---------- ---------------------------------------------
         1         30         15 3859       TEST       sqlplus@oel5-11gr2.localdomain (TNS V1-V3)
         1         23        287 3834       SYS        sqlplus@oel5-11gr2.localdomain (TNS V1-V3)
         1         40        387 4663                  oracle@oel5-11gr2.localdomain (J000)
         1         38        125 4665                  oracle@oel5-11gr2.localdomain (J001)



Los valores SID y SERIAL# son los que se utilizaran en los comandos que explicamos más delante.

 ALTER SYSTEM KILL SESSION

La sintaxis básica para matar una sesión es la siguiente:

SQL> ALTER SYSTEM KILL SESSION 'sid,serial#';
En un ambiente RAC, opcionalmente se puede añadir  el identificador de la instancia INST_ID, lo obtenemos de la vista GV$SESSION view. Este permite matar una sesión desde otro de los nodos de RAC.

SQL> ALTER SYSTEM KILL SESSION 'sid,serial,#@inst_id';

El comando KILL SESSION no mata la sesión, simplemente le indica a la sesión que debe matarse ella misma. En algunas situaciones como en la espera de una respuesta de una base de datos remota o cuando se esta haciendo un roll back a una transacción, la sesión no se mata a si misma inmediatamente, espera a que termine la operación que está realizando. En estos casos la sesión adquiere el status de “marked for kill”, y se mata lo antes posible

Además de la syntaxix  descrita anteriormente, se puede añadir la clausula IMMEDIATE.

SQL> ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;

Esto no afecta al trabajo que hace el comando, pero devuelve el control a la sesión inmediatamente, en vez de esperar la confirmación de que se ha matado la sesión.

Si la sesión marcada persiste demasiado en el tiempo se puede intentar matar el proceso a nivel de sistema operativo, antes de hacer esto es conveniente comprobar que la sesión no está haciendo rollback. Podemos comprobar esto con el script (session_undo.sql), lo tenéis en la página de scripts. Si el valor de USED_UREC decrece para la sesión en cuestión es mejor dejar que termine el rollback antes de matar la sesión a nivel de sistema operativo.

ALTER SYSTEM DISCONNECT SESSION

Oracle 11g introduce la sintaxis ALTER SYSTEM DISCONNECT SESSION  un nuevo método de matar una sesion Oracle.  Lo que hace este comando es matar el proceso de servidor dedicado ( o circuito virtual cuando se utilizan los Shared Sever), lo que es equivalente a matar el proceso desde el sistema operativo. La sintaxis básica es similar a la del comando KILL SESSION más la clausula POST_TRANSACTION.

SQL> ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' POST_TRANSACTION;
SQL> ALTER SYSTEM DISCONNECT SESSION 'sid,serial#' IMMEDIATE;

La clausula POST_TRANSACTION espera a que la transacción se complete antes de desconectar la sesión.

Matar una sesión en windows

C:> orakill ORACLE_SID spid

Matar una sesión en Unix

% kill spid

Si después de unos minutos no ha muerto utilizar

% kill -9 spid

Para verificar que el spid coincide con el proceso del sistema operativo:

% ps -ef | grep ora