martes, 15 de noviembre de 2011

Matar sesiones Oracle en Linux

A veces necesitamos matar sesiones de la base de datos Oracle, muchas veces estas sesiones se quedan “colgadas” e inactivas incluso por días, otras veces aunque están en estado activo se nos pide que las eliminemos.

Para matar una sesión contamos con el comando ALTER SYSTEM KILL SESSION 'sid, serial#'

Previamente debemos de conocer el sid y el serial# de la sesión que deseamos eliminar, en este caso queremos "matar" al usuario USER1:
SQL: select sid, serial#, username, status from v$session;

       SID    SERIAL# USERNAME   STATUS
---------- ---------- ---------- --------
       370        226            ACTIVE
       373        557 USER1      INACTIVE
       381         90 SYS        ACTIVE
       383          1            ACTIVE
       385          1            ACTIVE
       386          7            ACTIVE
       389          3            ACTIVE
       390          3            ACTIVE
       391          4            ACTIVE
       393          1            ACTIVE
       394          1            ACTIVE
       395          1            ACTIVE
       396          1            ACTIVE
       397          1            ACTIVE
       398          1            ACTIVE
       399          1            ACTIVE
       400          1            ACTIVE

17 rows selected.

El comando para eliminar el sid 373 es el siguiente:
SQL: alter system kill session '373,557';

System altered.

Sin embargo hay ocasiones en que ALTER SYSTEM KILL SESSION no libera los bloqueos que tenía la sesión que matamos. Esto sucede cuando una sesión no puede ser interrumpida hasta que terminie la operación que está realizando. En este caso, la sesión mantiene todos los recursos que obtuvo de nuestro servidor hasta que termina la operación. Normalmente, la sesión que ejecutó el ALTER SYSTEM KILL SESSION recibe el mensaje: “the session has been marked to be terminated”; y la sesión aparece en v$session con status “KILLED”

SQL> select sid, serial#, username, status from v$session;

       SID    SERIAL# USERNA STATUS
---------- ---------- ------ --------
       370        108        ACTIVE
       373        557 USER1  KILLED
       381         90 SYS    ACTIVE
       383          1        ACTIVE
       385          1        ACTIVE
       386          7        ACTIVE
       389          3        ACTIVE
       390          3        ACTIVE
       391          4        ACTIVE
       393          1        ACTIVE
       394          1        ACTIVE
       395          1        ACTIVE
       396          1        ACTIVE
       397          1        ACTIVE
       398          1        ACTIVE
       399          1        ACTIVE
       400          1        ACTIVE

17 rows selected.

Para poder matar el proceso del usuario en Linux, lo hacemos con un kill -9, conociendo previamente el proceso del usuario.

*** EN EL CASO QUE ESTÉN BAJO CON ORACLE BAJO WINDOWS, SUGIERO REVISAR COMANDO ORAKILL.EXE ***

Primeramente encontramos el thread con el siguiente query (debemos de conocer el thread previamente a ejecutar el comando ALTER SYSTEM KILL SESSION, de otra manera Oracle perdería la referencia al thread en cuestión):
SQL> select p.spid Thread, s.username Username, s.program
  2  from   v$process p, v$session s
  3  where  p.addr = s.paddr and s.username is not null;

THREAD       USERNAME   PROGRAM
------------ --------  -------------
364          SYS       sqlplus.exe
4524         USER1     sqlplus.exe
El comando por lo tanto sería:
kill -9 4524

A continuación en v$session vemos que ya no existe la sesión del usuario QUICK
SQL> select sid, serial#, username, status from v$session;


       SID    SERIAL# USERNAME   STATUS
---------- ---------- ---------- --------
       370        226            ACTIVE
       381         90 SYS        ACTIVE
       383          1            ACTIVE
       385          1            ACTIVE
       386          7            ACTIVE
       389          3            ACTIVE
       390          3            ACTIVE
       391          4            ACTIVE
       393          1            ACTIVE
       394          1            ACTIVE
       395          1            ACTIVE
       396          1            ACTIVE
       397          1            ACTIVE
       398          1            ACTIVE
       399          1            ACTIVE
       400          1            ACTIVE

16 rows selected.

Y con ésto, finalmente nos liberamos de esas molestas sesiones en estado KILLED que ocupan recursos en nuestra Base de Datos Oracle.

miércoles, 16 de marzo de 2011

CRS-0223: Resource 'xxx' has placement error

Me encontré con este error luego de instalar DG4ODBC y reiniciar el RAC... y lo peor era un RAC que estaba en Producción!!! He aquí el primer consejo, y que está en la tapa del libro... no tocar algo que está funcionando y menos aún hacer pruebas sobre eso... :)

Luego de algunos minutos y con los latidos a 200 por minuto, y viendo que el status de las instancias no era ONLINE... las mostraba como unknown, y obviamente no podía conectarme...

crs_stat -t

Name Type Target State Host
------------------------------------------------------------
ora.prod.db application ONLINE ONLINE
ora....d1.inst application ONLINE UNKNOWN
ora....d2.inst application ONLINE UNKNOWN
ora....SM1.asm application ONLINE ONLINE racdb1
ora....B1.lsnr application ONLINE ONLINE racdb1
ora.racdb1.gsd application ONLINE ONLINE racdb1
ora.racdb1.ons application ONLINE ONLINE racdb1
ora.racdb1.vip application ONLINE ONLINE racdb1
ora....SM2.asm application ONLINE ONLINE racdb2
ora....B2.lsnr application ONLINE ONLINE racdb2
ora.racdb2.gsd application ONLINE ONLINE racdb2
ora.racdb2.ons application ONLINE ONLINE racdb2
ora.racdb2.vip application ONLINE ONLINE racdb2

Intenté levantarlas nuevamente... con crs_start, con srvctl...
y nooo, no había caso... error!

PRKP-1001 : Error starting instance prod1 on node racdb1
CRS-1028: Dependency analysis failed because of:
CRS-0223: Resource 'ora.prod1.racdb1.inst' has placement error.

Se me complicó... dónde está la salida?!?!
Intenté levantarlas como si fueran BDs stanalone primero prod1 y luego prod2...

> export ORACLE_SID=prod1
> sqlplus /nolog
>> connect / as sysdba
>> startup;

y levantaron !!! la instancia 1 y la 2...

Bueh... salimos del paso... no se ven una a otra como un RAC pero al menos accedo a los datos... simplemente cambio las propiedades de las aplicaciones que hacen uso del RAC, y que empiecen a apuntar a una de las instancias, sin necesidad de FAILOVER ni BALANCEO... por lo menos para empezar...

Luego de un par de días de darle vueltas al asunto, encontré googleando, alguien que recomendaba matar los procesos crsd y probar levantar las instancias nuevamente... y fue lo que hice, y funcionó!

> kill - 9 --> en ambos nodos
> srvctl start instance -i prod1 -d prod --> luego con prod2

y listo!!! todo ONLINE nuevamente...

crs_stat -t

Name Type Target State Host
------------------------------------------------------------
ora.prod.db application ONLINE ONLINE racdb1
ora....d1.inst application ONLINE ONLINE racdb1
ora....d2.inst application ONLINE ONLINE racdb2
ora....SM1.asm application ONLINE ONLINE racdb1
ora....B1.lsnr application ONLINE ONLINE racdb1
ora.racdb1.gsd application ONLINE ONLINE racdb1
ora.racdb1.ons application ONLINE ONLINE racdb1
ora.racdb1.vip application ONLINE ONLINE racdb1
ora....SM2.asm application ONLINE ONLINE racdb2
ora....B2.lsnr application ONLINE ONLINE racdb2
ora.racdb2.gsd application ONLINE ONLINE racdb2
ora.racdb2.ons application ONLINE ONLINE racdb2
ora.racdb2.vip application ONLINE ONLINE racdb2

jueves, 26 de agosto de 2010

JOIN eando...

Hace casi un año que no agregaba ningún post... hoy quizás sea la excepción... o no...

Estaba pensando de que podía hablar (escribir en realidad). Se me cruzó por la mente describir los diferentes tipos de joins que podemos utilizar en una sentencia sql, y eso es lo que intentaré hacer...

Los diferentes tipos de joins y sus aplicaciones:

INNER JOIN
Es el join "mas común", por decirlo de alguna forma. Se utiliza cuando se quiere matchear dos tablas que tienen valores en común en una o más columnnas.
Se podría utilizar para matchear el id_pais de la tabla CLIENTES, con el id_pais de la tabla PAISES; eso nos traería los clientes que tengan asociado algún id_pais existente en la tabla PAISES.

OUTER JOIN

Se utiliza si se desea que el resultado no solo contenga los registros que cumplen con la condición del join, sino también cualquier registro que no cumpla de una tabla o de las demás.
Por ejemplo, se puede usar para obtener todos los clientes de la tabla CLIENES con su país asociado de la tabla PAISES, incluyendo aquellos clientes que no tienen un país asociado.

CROSS JOIN
Utilizado cuando se quiere matchear todos los registros de una tabla con cada registro de otra tabla. Este tipo de join se lo conoce como producto cartesiano.

SELF JOIN
Se aplica para matchear una tabla consigo misma. Se puede usar self join cuando una columna de una tabla debe referenciar una columna diferente en la misma tabla.
...

miércoles, 23 de septiembre de 2009

Transportable Tablespaces

Con esta utilidad, lo que buscamos básicamente es bajar los tiempos de pasaje de datos, más específicamente al transferir un tablespace de una BD a otra, o al recuperarlo de un estado anterior (recover).

Para poder transportar un tablespace, éste debe ser self-contained (auto-contenido), es decir, no debe contener objetos que referencien a otros objetos en diferentes tablespaces.

Cómo chequeamos si el tablespace es self-contained?

EXEC DBMS_TTS.TRANSPORT_SET_CHECK(ts_list => 'nombre_tablespace', incl_constraints => TRUE);

Luego chequeamos la vista transport_set_violations para ver si existe alguna violación...

SELECT * FROM transport_set_violations


RESPALDANDO EL TABLESPACE A TRANSPORTAR:

Como primer paso, luego de estos chequeos, debemos crear el "respaldo" del tablespace a transportar.

Seteamos el tablespace en cuestión en modo READ ONLY:

ALTER TABLESPACE nombre_tablespace READ ONLY;

Ejecutamos el siguiente export:

exp parfile=export_parfile.txt

-- contenido archivo export_parfile.txt
userid="sys/pass as sysdba"
transport_tablespace=y
tablespaces=(nombre_tablespace)
file=plug_in_nombre_tablespace_ts.dmp
log=plug_in_nombre_tablespace_ts.log
statistics=NONE

Respaldamos los datafiles que componen el tablespace, ésto lo podemos hacer simplemente con el comando de copia del sistema operativo (xcopy para Win o cp para Linux) o como más cómodo nos quede.

-- ejemplo respaldo bajo Linux
cp tablespace_datafile*.dbf /Respaldo

Ya con ésto tenemos todo lo necesario para poder levantar el mismo tablespace en otra BD o simplemente para utilizarlo como respaldo.

Ahora deberíamos llevar nuevamente el tablespace a modo READ WRITE para retornar a la "normalidad":

ALTER TABLESPACE nombre_tablespace READ WRITE;


RESTAURANDO EL TRANSPORTABLE TABLESPACE:

Ahora intentaremos describir cómo hacer para levantar el respaldo que realizamos en el capítulo anterior.

Si el tablespace que vamos a restaurar ya existe en nuestra BD destino, debemos eliminarlo:

DROP TABLESPACE nombre_tablespace INCLUDING CONTENTS AND DATAFILES;

Restauramos los datafiles del "respaldo", que tan cuidadosamente habíamos guardado...

-- ejemplo copia desde respaldo, supongamos orcl es la BD
cp /Respaldo/tablespace_datafile*.dbf  $ORACLE_BASE/oradata/orcl

Luego, debemos "enchufar" (no se me ocurrió otro término para traducir plug-in) el tablespace:

imp parfile=plug_in_nombre_tablespace_ts.txt

-- contenido archivo plug_in_nombre_tablespace_ts.txt
userid="sys/pass as sysdba"
transport_tablespace=y
file=plug_in_nombre_tablespace_ts.dmp               -- dmp generado en el respaldo
log=plug_in_nombre_tablespace_ts.log
tablespaces=(nombre_tablespace)
tts_owners=schema_origen
fromuser=schema_origen
touser=schema_destino
datafiles=(
'$ORACLE_BASE/oradata/orcl/tablespace_datafile1.dbf ',      -- declaramos todos los datafiles del ts
$ORACLE_BASE/oradata/orcl/tablespace_datafile2.dbf '       -- en su ubicación correspondiente
...
)

Luego de terminado el import, colocamos el tablespace en modo READ WRITE:

ALTER TABLESPACE nombre_tablespace READ WRITE;

Si seguimos los pasos al pie de la letra, deberíamos poder realizar los transportes de tablespaces sin mayores problemas. Espero que haya sido de utilidad!

martes, 22 de septiembre de 2009

Vientos de cambio...

Qué mes difícil este setiembre!!!
Vaivenes, complicaciones, interrogantes, dudas...
Ahora soplan vientos de cambio... a enfrentarlos!!!
Disculpen, nada tiene ésto que ver con Oracle... o si?

Ubicación de archivos

Veamos en este post, donde se encuentran por default, algunos archivos y utilitarios que podemos llegar a necesitar:

alert.log ($ORACLE_HOME/admin/orcl/bdump) donde orcl es el nombre de la instancia

orcl_ora_xxxx.trc - archivos trace de usuario - ($ORACLE_HOME/admin/orcl/udump)

sqlplus ($ORACLE_HOME/bin)

dbca ($ORACLE_HOME/bin)

dbua ($ORACLE_HOME/bin)

spfile.ora ($ORACLE_HOME/dbs)

expdp / impdp / exp / imp ($ORACLE_HOME/bin)

miércoles, 2 de septiembre de 2009

Mover columna LOB a otro tablespace

Mover una tabla de un tablespace a otro puede resultar tan sencillo como ejecutar la sentencia:

alter table TABLA_SIMPLE move tablespace TS_DESTINO;

Pero... qué sucede si esta tabla contiene un atributo de tipo CLOB?
Cuando se crea una tabla con un atributo de tipo CLOB, Oracle implícitamente crea un segmento LOB y un índice LOB para dicha columna. Los nombres que asigna Oracle para estos objetos son, SYS_LOBxxxx para los segmentos y SYS_ILxxxx para los índices.
Aquí va la receta para mover la tabla conjuntamente con ese índice y segmento LOB...

Supongamos que la tabla en cuestión se llama TABLA_LOB.

Ahora, verificamos el segmento, el índice y la columna asociada al campo lob de dicha dicha tabla:

select segment_name, index_name, column_name from user_lobs where table_name='TABLA_LOB';

SEGMENT_NAME   INDEX_NAME   COLUMN_NAME
--------------------------   ---------------------   ------------------------
SYS_LOB0000760032C00019$$   SYS_IL0000760032C00019$$   COLUMN_LOB

Movemos la tabla TABLA_LOB al tablespace que deseamos:

alter table TABLA_LOB move tablespace TS_LOB;

Con ésto hemos logrado, como ya sabíamos, mover la tabla TABLA_LOB al tablespace requerido, pero el segmento LOB aún permanece en el tablespace de origen.

Para mover el segmento debemos ejecutar el siguiente sql:

alter table TABLA_LOB move lob (COLUMN_NAME) store as (tablespace TS_LOB);

Verificamos:

select index_name, tablespace_name from user_indexes where table_name = ‘TABLA_LOB’;

INDEX_NAME   TABLESPACE_NAME              
---------------------   -------------------------------
SYS_IL0000760032C00019$$   TS_LOB


Está listo, conseguimos mover el dichoso segmento!