Oracle Tips en Español

Consultas útiles

2011-11-24T11:09:00.000-02:00

Aquí van algunas de esas consultas que nos podrían ser útiles en el día a día.
Copien, peguen y guarden bien a mano... Espero les sean de utilidad...

•• Consulta Oracle SQL sobre la vista que muestra el estado de la base de datos:
select * from v$instance

•• Consulta Oracle SQL que muestra si la base de datos está abierta
select status from v$instance

•• Consulta Oracle SQL sobre la vista que muestra los parámetros generales de Oracle
select * from v$system_parameter

•• Consulta Oracle SQL para conocer la Versión de Oracle
select value from v$system_parameter where name = 'compatible'

•• Consulta Oracle SQL para conocer la Ubicación y nombre del fichero spfile
select value from v$system_parameter where name = 'spfile'

•• Consulta Oracle SQL para conocer la Ubicación y número de ficheros de control
select value from v$system_parameter where name = 'control_files'

•• Consulta Oracle SQL para conocer el Nombre de la base de datos
select value from v$system_parameter where name = 'db_name'

•• Consulta Oracle SQL sobre la vista que muestra las conexiones actuales a Oracle.
Para visualizarla es necesario entrar con privilegios de administrador
select osuser, username, machine, program
from v$session
order by osuser

•• Consulta Oracle SQL que muestra el número de conexiones actuales a Oracle agrupado
por aplicación que realiza la conexión
select program Aplicacion, count(program) Numero_Sesiones
from v$session
group by program
order by Numero_Sesiones desc

•• Consulta Oracle SQL que muestra los usuarios de Oracle conectados y el número
de sesiones por usuario
select username Usuario_Oracle, count(username) Numero_Sesiones
from v$session
group by username
order by Numero_Sesiones desc

•• Consulta Oracle SQL que muestra propietarios de objetos y número de objetos por
propietario
select owner, count(owner) Numero
from dba_objects
group by owner

•• Consulta Oracle SQL sobre el Diccionario de datos (incluye todas las vistas y
tablas de la Base de Datos)
select * from dictionary

•• Consulta Oracle SQL que muestra los datos de una tabla especificada (en este caso
todas las tablas que lleven la cadena "XXX"
select * from ALL_ALL_TABLES where upper(table_name) like '%XXX%'

•• Consulta Oracle SQL para conocer las tablas propiedad del usuario actual
select * from user_tables

•• Consulta Oracle SQL para conocer todos los objetos propiedad del usuario
conectado a Oracle
select * from user_catalog

•• Consulta Oracle SQL para el DBA de Oracle que muestra los tablespaces, el espacio
utilizado, el espacio libre y los ficheros de datos de los mismos:
Select t.tablespace_name "Tablespace", t.status "Estado",
ROUND(MAX(d.bytes)/1024/1024,2) "MB Tamaño",
ROUND((MAX(d.bytes)/1024/1024) -
(SUM(decode(f.bytes, NULL,0, f.bytes))/1024/1024),2) "MB Usados",
ROUND(SUM(decode(f.bytes, NULL,0, f.bytes))/1024/1024,2) "MB Libres",
t.pct_increase "% incremento",
SUBSTR(d.file_name,1,80) "Fichero de datos"
FROM DBA_FREE_SPACE f, DBA_DATA_FILES d, DBA_TABLESPACES t
WHERE t.tablespace_name = d.tablespace_name AND
f.tablespace_name(+) = d.tablespace_name
AND f.file_id(+) = d.file_id GROUP BY t.tablespace_name,
d.file_name, t.pct_increase, t.status ORDER BY 1,3 DESC

•• Consulta Oracle SQL para conocer los productos Oracle instalados y la versión:
select * from product_component_version

•• Consulta Oracle SQL para conocer los roles y privilegios por roles:
select * from role_sys_privs

•• Consulta Oracle SQL para conocer las reglas de integridad y columna a la que
afectan:
select constraint_name, column_name from sys.all_cons_columns

•• Consulta Oracle SQL para conocer las tablas de las que es propietario un usuario,
en este caso "xxx":
SELECT table_owner, table_name from sys.all_synonyms where table_owner like 'xxx'

•• Consulta Oracle SQL como la anterior, pero de otra forma más efectiva (tablas de
las que es propietario un usuario):
SELECT DISTINCT TABLE_NAME
FROM ALL_ALL_TABLES
WHERE OWNER LIKE 'HR'

•• Parámetros de Oracle, valor actual y su descripción:
SELECT v.name, v.value value, decode(ISSYS_MODIFIABLE, 'DEFERRED',
'TRUE', 'FALSE') ISSYS_MODIFIABLE, decode(v.isDefault, 'TRUE', 'YES',
'FALSE', 'NO') "DEFAULT", DECODE(ISSES_MODIFIABLE, 'IMMEDIATE',
'YES','FALSE', 'NO', 'DEFERRED', 'NO', 'YES') SES_MODIFIABLE,
DECODE(ISSYS_MODIFIABLE, 'IMMEDIATE', 'YES', 'FALSE', 'NO',
'DEFERRED', 'YES','YES') SYS_MODIFIABLE , v.description
FROM V$PARAMETER v
WHERE name not like 'nls%' ORDER BY 1

•• Consulta Oracle SQL que muestra los usuarios de Oracle y datos suyos (fecha de
creación, estado, id, nombre, tablespace temporal,...):
Select * FROM dba_users

•• Consulta Oracle SQL para conocer tablespaces y propietarios de los mismos:
select owner, decode(partition_name, null, segment_name,
segment_name || ':' || partition_name) name,
segment_type, tablespace_name,bytes,initial_extent,
next_extent, PCT_INCREASE, extents, max_extents
from dba_segments
Where 1=1 And extents > 1 order by 9 desc, 3

•• Últimas consultas SQL ejecutadas en Oracle y usuario que las ejecutó:
select distinct vs.sql_text, vs.sharable_mem,
vs.persistent_mem, vs.runtime_mem, vs.sorts,
vs.executions, vs.parse_calls, vs.module,
vs.buffer_gets, vs.disk_reads, vs.version_count,
vs.users_opening, vs.loads,
to_char(to_date(vs.first_load_time,
'YYYY-MM-DD/HH24:MI:SS'),'MM/DD HH24:MI:SS') first_load_time,
rawtohex(vs.address) address, vs.hash_value hash_value ,
rows_processed , vs.command_type, vs.parsing_user_id ,
OPTIMIZER_MODE , au.USERNAME parseuser
from v$sqlarea vs , all_users au
where (parsing_user_id != 0) AND
(au.user_id(+)=vs.parsing_user_id)
and (executions >= 1) order by buffer_gets/executions desc

•• Consulta Oracle SQL para conocer todos los tablespaces:
select * from V$TABLESPACE

•• Consulta Oracle SQL para conocer la memoria Share_Pool libre y usada
select name,to_number(value) bytes
from v$parameter where name ='shared_pool_size'
union all
select name,bytes
from v$sgastat where pool = 'shared pool' and name = 'free memory'

•• Cursores abiertos por usuario
select b.sid, a.username, b.value Cursores_Abiertos
from v$session a,
v$sesstat b,
v$statname c
where c.name in ('opened cursors current')
and b.statistic# = c.statistic#
and a.sid = b.sid
and a.username is not null
and b.value >0
order by 3

•• Consulta Oracle SQL para conocer los aciertos de la caché (no debería superar el
1 por ciento)
select sum(pins) Ejecuciones, sum(reloads) Fallos_cache,
trunc(sum(reloads)/sum(pins)*100,2) Porcentaje_aciertos
from v$librarycache
where namespace in ('TABLE/PROCEDURE','SQL AREA','BODY','TRIGGER');

•• Sentencias SQL completas ejecutadas con un texto determinado en el SQL
SELECT c.sid, d.piece, c.serial#, c.username, d.sql_text
FROM v$session c, v$sqltext d
WHERE c.sql_hash_value = d.hash_value
and upper(d.sql_text) like '%WHERE CAMPO LIKE%'
ORDER BY c.sid, d.piece

•• Una sentencia SQL concreta (filtrado por sid)
SELECT c.sid, d.piece, c.serial#, c.username, d.sql_text
FROM v$session c, v$sqltext d
WHERE c.sql_hash_value = d.hash_value
and sid = 105
ORDER BY c.sid, d.piece

•• Consulta Oracle SQL para conocer el tamaño ocupado por la base de datos
select sum(BYTES)/1024/1024 MB from DBA_EXTENTS

•• Consulta Oracle SQL para conocer el tamaño de los ficheros de datos de la base
de datos
select sum(bytes)/1024/1024 MB from dba_data_files

•• Consulta Oracle SQL para conocer el tamaño ocupado por una tabla concreta sin
incluir los índices de la misma
select sum(bytes)/1024/1024 MB from user_segments
where segment_type='TABLE' and segment_name='NOMBRETABLA'

•• Consulta Oracle SQL para conocer el tamaño ocupado por una tabla concreta
incluyendo los índices de la misma
select sum(bytes)/1024/1024 Table_Allocation_MB from user_segments
where segment_type in ('TABLE','INDEX') and
(segment_name='NOMBRETABLA' or segment_name in
(select index_name from user_indexes where table_name='NOMBRETABLA'))

•• Consulta Oracle SQL para conocer el tamaño ocupado por una columna de una tabla
select sum(vsize('NOMBRECOLUMNA'))/1024/1024 MB from NOMBRETABLA

•• Consulta Oracle SQL para conocer el espacio ocupado por usuario
SELECT owner, SUM(BYTES)/1024/1024 MB FROM DBA_EXTENTS
group by owner

•• Consulta Oracle SQL para conocer el espacio ocupado por los diferentes segmentos
(tablas, índices, undo, rollback, cluster, ...)
SELECT SEGMENT_TYPE, SUM(BYTES)/1024/1024 MB FROM DBA_EXTENTS
group by SEGMENT_TYPE

•• Consulta Oracle SQL para obtener todas las funciones de Oracle: NVL, ABS, LTRIM,...
SELECT distinct object_name
FROM all_arguments
WHERE package_name = 'STANDARD'
order by object_name

•• Consulta Oracle SQL para conocer el espacio ocupado por todos los objetos de la base de
datos, muestra los objetos que más ocupan primero
SELECT SEGMENT_NAME, SUM(BYTES)/1024/1024 MB FROM DBA_EXTENTS
group by SEGMENT_NAME
order by 2 desc

Caracter de escape

2011-11-21T17:19:00.001-02:00

Como ya bien sabemos % y _ son caracteres de escape que sirven para generar patrones.

% = equivale a O o N caracteres

_= equivale a O o 1 caracter

Nos podemos encontrar en situaciones en las que en el WHERE de una consulta queramos buscar caracteres que contengan _ o % por lo que necesitaremos un caracter de escape que le diga a Oracle que esos dos caracteres no son caracteres especiales.

Se hace de esta forma:

SELECT name FROM emp
WHERE id LIKE '%\%%' ESCAPE '\';

Matar sesiones Oracle en Linux

2011-11-15T10:11:00.001-02:00

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.

Oracle y JBoss...

2011-07-08T14:03:00.002-03:00

Oracle y JBoss.

CRS-0223: Resource 'xxx' has placement error

2011-03-16T12:33:00.003-03:00

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

JOIN eando...

2010-08-26T11:14:00.001-03:00

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.
...

Transportable Tablespaces

2009-09-23T13:43:00.000-03:00

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!

Vientos de cambio...

2009-09-22T16:08:00.000-03:00

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

2009-09-22T14:43:00.003-03:00

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)

Mover columna LOB a otro tablespace

2009-09-02T14:09:00.000-03:00

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!

Eliminar registros duplicados

2009-08-13T18:17:00.003-03:00

Si por algún motivo insertaron registros duplicados de una tabla, ya sea porque han eliminado la clave primaria o ni siquiera la han creado y ahora la consideran necesaria; por aquí les dejo una sentencia que los puede ayudar a eliminar esos registros innecesarios:

delete from tabla
where rowid not in
(select min(rowid)
from tabla
group by (col_pk1, col_pk2, col_pk3...);

Donde tabla indica la tabla en cuestión y las col_pkn son las columnas que forman la primary key.

Inicio automático Oracle en Linux

2009-08-12T13:23:00.009-03:00

En este post "intentaré" explicar cómo configurar el inicio automático de Oracle 10 en un S.O. Linux (Red Hat en mi caso particular).

Luego de instalado Oracle, debemos editar el archivo /etc/oratab, donde dice algo similar a:

$ORACLE_SID:$ORACLE_HOME:N

Cambiamos la "N" por "Y" -- o sea le decimos que sí! :) --

Quedaría:

$ORACLE_SID:$ORACLE_HOME:Y

En mi caso particular quedó:

orcl10:/u01/app/oracle/product/10.2.0/db_1:Y

Luego creamos el archivo /etc/init.d/dbora con el usuario root, con el siguiente contenido:
(espero que haya quedado bien el copy & paste!)

#!/bin/bash
#
# chkconfig: 35 99 10
# description: Starts and stops Oracle processes
#
# Set ORA_HOME to be equivalent to the $ORACLE_HOME
# from which you wish to execute dbstart and dbshut;
#
# Set ORA_OWNER to the user id of the owner of the
# Oracle database in ORA_HOME.
#
ORA_HOME=/u01/app/oracle/product/10.2.0/db_1ORA_OWNER=oracle
case "$1" in
'start')
su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl start"

if [ -f $ORA_HOME/bin/oemctl ]; then
su - $ORA_OWNER -c "$ORA_HOME/bin/emctl start dbconsole"
fi

su - $ORA_OWNER -c $ORA_HOME/bin/dbstart

# Start the Intelligent Agent
#if [ -f $ORA_HOME/bin/agentctl ]; then
# su - $ORA_OWNER -c "$ORA_HOME/bin/agentctl start"
#else
# su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl dbsnmp_start"
#fi
# Start Enterprise Management Console
#if [ -f $ORA_HOME/bin/oemctl ]; then
# su - $ORA_OWNER -c "$ORA_HOME/bin/emctl start dbconsole"
#fi
# Start HTTP Server
#if [ -f $ORA_HOME/Apache/Apache/bin/apachectl ]; then
# su - $ORA_OWNER -c "$ORA_HOME/Apache/Apache/bin/apachectl start"
#fi
touch /var/lock/subsys/dbora
;;
'stop')
# Stop HTTP Server
#if [ -f $ORA_HOME/Apache/Apache/bin/apachectl ]; then
# su - $ORA_OWNER -c "$ORA_HOME/Apache/Apache/bin/apachectl stop"
#fi
# Stop Enterprise Management Console
if [ -f $ORA_HOME/bin/oemctl ]; then
su - $ORA_OWNER -c "$ORA_HOME/bin/emctl stop dbconsole"
fi
# Stop the Intelligent Agent
#if [ -f $ORA_HOME/bin/agentctl ]; then
# su - $ORA_OWNER -c "$ORA_HOME/bin/agentctl stop"
#else
# su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl dbsnmp_stop"
#fi
# Stop the TNS Listener su - $ORA_OWNER -c "$ORA_HOME/bin/lsnrctl stop"
# Stop the Oracle databases:
# The following command assumes that the oracle login
# will not prompt the user for any values
su - $ORA_OWNER -c $ORA_HOME/bin/dbshut
rm -f /var/lock/subsys/dbora
;;
esac
# End of script dbora

A continuación (seguimos con root) seteamos los privilegios sobre el archivo dbora:

chmod 750 /etc/init.d/dbora

Y asociamos al servicio con los runlevels apropiados:

chkconfig --level 345 dbora on

La instancia ahora debería iniciarse automáticamente al reinicio de nuestro servidor Oracle. Hay un bug conocido que nos puede complicar al reinicio, pero no preocuparse, porque por suerte "es conocido" y tiene solución!

Si nos encontramos con este error:

Failed to auto-start Oracle Net Listener
using /ade/vikrkuma_new/bin/tnslsnr

Se debe a un path hard-coded en el script dbstart. Para solucionarlo editamos el archivo $ORACLE_HOME/bin/dbstart y reemplazamos la siguiente línea (línea 78 aprox.):

ORACLE_HOME_LISTENER=/ade/vikrkuma_new/oracle

Con ésto:

ORACLE_HOME_LISTENER=$ORACLE_HOME

Ahora sí, con esta modificación el listener debería iniciar automáticamente sin problema alguno.

Espero que este post les sea de utilidad!

Habilitar ARCHIVELOG

2009-08-10T12:39:00.010-03:00

La mayoría de las características de Alta Disponibilidad de Oracle requieren el modo ARCHIVELOG activado. Una vez habilitada esta característica, los archivos redo logs, serán guardados antes de ser sobreescritos.

Habilitar ARCHIVELOG a partir de la versión 10, resulta más sencillo que en versiones anteriores, debido a que no debemos especificar siquiera parámetro de inicio en el spfile (como el "LOG_ARCHIVE_START=true" en la versión 9).

Como chequeamos si está habilitado el modo ARCHIVELOG?

SQL> archive log list;
Database log mode No Archive Mode
Automatica archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DES
Oldest online log sequence 42541
Current log sequence 42543

El "No Archive Mode" evidentemente nos indica que esta base no esta guardando los online archive logs, es decir, no está en modo ARCHIVELOG.

Cómo hacemos para habilitarlo?

sqlplus sys/pass as sysdba -- nos conectamos a la consola de SQLPlus --
SQL> shutdown immediate; -- si la BD está levantada, la bajamos; de lo contrario obviamos este paso --
SQL> startup mount; -- montamos la BD --
SQL> alter database archivelog; -- activamos ARCHIVELOG --
SQL> alter database open; -- levantamos la BD --

Nuestra BD finalmente quedó en modo ARCHIVELOG!

Los archivos generados por el archivado de logs, por default, quedarán ubicados en la FRA (Flash Recovery Area).

Esta sentencia nos indicará la ubicación de los archive logs y el tamaño asignado para esta área:
select * from v$parameter where name in ('db_recovery_file_dest','db_recovery_file_dest_size');

Hasta aquí este artículo sobre ARCHIVELOG!

ORA-12518

2009-08-04T12:04:00.003-03:00

Cuando me encontré con este ORA error, que rezaba un lindo mensaje "TNS:listener could not hand off client connection", me quería volver loco!!! No sabía por donde empezar...

Las características del Server con el que estaba piloteando eran:
Intel Quad Core
4Gb RAM
Windows 2003 (32 bits)
Oracle 10.2.0.3
SGA >1.6Gb
320Mb PGA
...

Googleando en la vuelta, no encontré nada preciso que me ayudara rápidamente a solucionar el error, hasta que en metalink (metalink.oracle.com) hallé el DOC ID 556428.1 que me dió algunas sugerencias interesantes.

Un primer intento, aumentar el nro. de processes, pero los resultados no fueron los esperados; en realidad tampoco esperaba que diera resultado, pero... en fin... fue un intento no más!
Luego, viendo que la memoria que tenía asignada la SGA+PGA estaban "CASI" en los 2Gb y que mi S.O. era de 32 bits... Ups! se supone que un sistema de 32bits. no puede redireccionar más de 2Gb a un solo proceso, y yo estaba caminando por la corniza... máxime que ese día la carga de usuarios en el sistema se veía algo incrementada comparada con los demás días. Ahí lo que me quedaba era disminuir la memoria asignada a la SGA o probar con el parámetro /3GB en el boot.ini; ésto último fue lo que terminé configurando y por suerte salimos a flote.

Configurando el parámetro /3GB logramos que un sistema Win 32 bits redireccione arriba de los 2Gb de memoria por proceso.

Cómo setear este parámetro?

Contenido archivo boot.ini

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Standard" /3Gb /fastdetect /NoExecute=OptOut

ORA-12519

2009-07-24T17:06:00.003-03:00

El mensaje de este error nos dice: TNS:no appropriate service handler found

Cuando nos encontramos con este error, sugiero revisar el parámetro processes de nuestra BD:
select value from v$parameter where name='processes'

Muy probablemente, solucionemos el tema aumentando este valor (en este caso a 300):
alter system set processes=300 scope=spfile

Luego de ésto, la BD necesitará de un reinicio para adoptar este nuevo valor.

Explain plan

2009-07-09T13:48:00.008-03:00

Para obterner el plan de ejecución de una sentencia existen diferentes métodos. A mi entender, el más recomendable es el método "Explain Plan", que a contraposición del "Autotrace", no necesita ejecutar la sentencia completamente para lograr la salida buscada.

A ver si me explico mejor gráficamente...

Expdp e Impdp

2009-07-08T11:50:00.010-03:00

Datapump dejó por el camino, a partir de Oracle 10, a las viejas utilidades de exp e imp ya conocidas. Con las características de direct path y ejecuciones en paralelo datapump es mucho más veloz que sus antecesores.
Los tradicionales exp e imp corren del lado del cliente (client-side) mientras que expdp e impdp lo hacen del lado del servidor (server-side), lo que hace que sea más manejable.

Procesos involucrados en los trabajos de datapump:

Client process: este proceso es iniciado por la utilidad del cliente, llamando a la API datapump. Una vez que se inicia el datapump, este proceso no es necesario para el resto del trabajo.

Shadow process: cuando el cliente se loguea en la BD, se crea el proceso foreground que atiende las solicitudes de la API. Este proceso crea la master table y las colas utilizadas para la comunicación. Una vez que el proceso del cliente termina, shadow process también.

Master control process: este proceso controla la ejecución de los trabajos de datapump. Existe un MCP por cada trabajo de datapump. MCP divide el trabajo de datapump en varios sub-trabajos de carga y descarga de metadatos y los transfiere a los worker processes.

Worker process: MCP crea los worker process basado en el valor del parámetro PARALLEL. El worker process realiza la tarea solicitada por el MCP.

Ventajas de datapump:

* Podemos exportar en paralelo, escribiendo en múltiples archivos en diferentes discos. Por ejemplo, especificando el parámetro PARALLEL=2 y dos directorios con los nombres de archivos destino, DUMPFILE=dir1:/file1.dp, dir2:/file2.dp.

* Posibilidad de realizar attach y dettach del trabajo, monitoreando el trabajo remotamente.

* Más opciones para filtrado de metadatos (parámetros EXCLUDE e INCLUDE).

* Podemos estimar los requerimientos de espacio en disco con el parámetro ESTIMATE_ONLY, antes de ejecutar la tarea.

* Los datos pueden ser exportados desde una BD remota utilizando un DB link.

* Puede especificarse la versión de la BD y exportar solo los objetos compatibles con dicha versión.

* Durante la tarea de impdp podemos cambiar el destino de los datafiles, esquemas y tablespaces (REMAP_DATAFILES, REMAP_SCHEMA, REMAP_TABLESPACE).

* Nos permite filtrar los datos durante la ejecución de impdp.

* Puede importarse desde una BD hacia otra sin escribir a un archivo de dump, especificando el parámetro NETWORK_LINK.

* El status de los trabajos pueden ser consultados directamente desde el data dictionary. Por ejemplo, dba_datapump_jobs, dba_datapump_sessions, etc.

Ejemplos de sintaxis:
En estos ejemplos se utilizan parfiles (archivos plano de texto) para especificar los parámetros a utilizar en el expdp e impdp. Para ejecutar un expdp o impdp utilizando un parfile: expdp parfile=archivo_parfile.txt o impdp parfile=archivo_parfile.txt.

En los diferentes escenarios se muestra el contenido de cada parfile en particular.
El parámetro directory, especifica donde quedará el dmp exportado, o de donde se toma el dmp de origen para realizar una importación. La ubicación data_pump_dir, en una instalación por default, apunta a la ubicación $ORACLE_BASE/admin/dpdump.

Escenario 1:
Exportar la base ORCL completa.

userid=system/password@ORCL
dumpfile=completadp.dmp
logfile=completadp.log
full=y
directory=data_pump_dir

Escenario 2:
Exportar schema SCOTT de la base ORCL.

userid=system/password@ORCL
dumpfile=scottdp.dmp
logfile=scottdp.log
schemas=SCOTT
directory=data_pump_dir

Escenario 3:
Exportar las tablas PAISES y CIUDADES del esquema SCOTT.

userid=system/password@ORCL
dumpfile=scott_paisyciuddp.dmp
logfile=scott_paisyciuddp.log
tables=(SCOTT.PAISES,SCOTT.CIUDADES)
directory=data_pump_dir

Escenario 4:
Exportar la tabla EMPLEADOS del schema SCOTT de la base ORCL e importarla sobre la base ORCL_NEW.

*expdp parfile
userid=system/password@ORCL
dumpfile=scott_empdp.dmp
logfile=scott_empdp.log
tables=SCOTT.EMPLEADOS
directory=data_pump_dir

*impdp parfile
userid=system/password@ORCL_NEW
dumpfile=scott_empdp.dmp -- se utiliza el dmp creado en el paso anterior --
logfile=imp_scott_empdp.log
directory=data_pump_dir
table_exists_action=replace -- en caso de que la tabla exista en el destino, se reemplazará --

Escenario 5:
Exportar solamente la estructura, sin incluir datos, del esquema SCOTT.

userid=system/password@ORCL
dumpfile=scott_metadata.dmp
logfile=scott_metadata.log
content=metadata_only -- solamente la estructura --
schemas=SCOTT
directory=data_pump_dir

Escenario 6:
Exportar del esquema SCOTT, los registros de las tablas PAISES y CIUDADES cuyo nombre comience con letra A.

userid=system/password@ORCL
dumpfile=scott_soloA.dmp
logfile=scott_soloA.log
content=data_only
schemas=SCOTT
include=table:"in('PAISES','CIUDADES')"
query="where nombre like 'A%'"
directory=data_pump_dir

Cortitas...

2009-07-07T16:38:00.008-03:00

Quizás este tipo de comentario tendrían que haber estado al inicio (cronológicamente) del blog, pero bueh, las disculpas del caso, se me ocurrió ahora!!!

Cómo creo un usuario?
create user usuario identified by password
default tablespace USERS
temporary tablespace TEMP
profile default;

Cómo cambio el password de un usuario existente?
alter user usuario identified by password;

Cómo creo un tablespace de 1Gb, autoextensible, tamaño máximo 10Gb?
create tablespace nombre_ts datafile
'c:\oracle\oradata\nombre_datafile.dbf' size 1024m autoextend on next 128m maxsize 10240m
logging
permanent
extent management local autoallocate
blocksize 8k
segment space management auto
flashback on;

Espacio disponible en Tablespaces?
select tablespace_name as "TABLESPACE",
sum(round(f.bytes/1024/1024)) "TAMAÑO ACTUAL (Mb)",
sum(round((((f.bytes / f.blocks) * x.maxextend) / 1024 /1024))) "TAMAÑO MAXIMO (Mb)"
, sum(round(((((f.bytes / f.blocks) * x.maxextend) / 1024 /1024) - (f.bytes/1024/1024)),0)) "ESPACIO DISPONIBLE (Mb)"
from sys.dba_data_files f,sys.filext$ x
where x.file# (+)= f.file_id
group by tablespace_name
order by "ESPACIO DISPONIBLE (Mb)";

Cómo eliminar columna de una tabla?
alter table nombre_tabla drop column nombre_columna;

Archivos redo log

2009-07-02T17:19:00.010-03:00

Los archivos de redo log registran cambios a la base de datos como resultado de transacciones o acciones internas del servidor Oracle.

Los archivos de redo log nos protegen la base de datos de la pérdida de integridad en casos de fallos causados por suministro eléctrico, errores en discos duros, y demás causas.

Es recomendable que los archivos de redo log sean multiplexados para asegurar que la información almacenada en ellos no se pierda en caso de un fallo en disco.

Consiste en grupos de archivos de redo log y cada grupo esta integrado por un archivo de redo log y sus copias multiplexadas. Se dice que cada copia idéntica es miembro de un grupo, y cada grupo es identificado por un número.

El proceso de escritura en logs (LGWR) escribe los registros de redo del buffer de redo log a todos los miembros del grupo actual de redo logs, hasta que el archivo se llena o se solicita una operación de cambio de archivo de log. Entonces, cambia el grupo activo y comienza a escribir en los archivos del siguiente grupo. Los grupos de redo log son usados de una forma circular.

Cómo obtenemos la info de los grupos de redo log de nuestra BD?

Consultando estas dos vistas, tenemos los datos que nos pueden interesar de los redo log files, ubicación, estado, tamaño, etc.
select * from v$logfile;
select * from v$log;

Cómo cambiamos el redo log group activo?
alter system switch logfile;

Cómo eliminamos un redo log group? (en este caso en particular en group 1)
alter database drop logfile group 1;

Ahora bien, cómo haríamos para agregar un nuevo redo log group? (agregamos el group 1, conteniendo un redo log file de 200mb)
alter database add logfile group 1 ('/u01/app/oracle/oradata/orcl/redo01.log') size 200m reuse;

Y si quisieramos agregar un redo log group redundante con dos redo log files members?
(agregamos el group 1, con dos redo log files en distintas ubicaciones con un tamaño de 200mb cada uno)
alter database add logfile group 1 ('/u01/app/oracle/oradata/orcl/redo01.log','/u02/app/oracle/oradata/orcl/redo01b.log') size 200m reuse;

ORA-12541

2009-06-11T11:51:00.004-03:00

El error completo: ORA-12541: TNS:no listener (DBD ERROR: OCIServerAttach).
Con ésto nos podemos encontrar en la pantalla de inicio del EM de nuestra BD. En mi caso, me daba problemas cuando la instancia se quería conectar con el agente para realizar tareas de respaldo, entre otras.
La solución... recrear el repositorio del EM desde línea de comandos:

emca -config dbcontrol db -repos recreate

Cambiar CHARACTER SET

2009-06-09T18:29:00.003-03:00

Aquí van los pasos para cambiar el character set de una base de datos.

Desde la consola de SQLPLUS:

1) shutdown immediate;
2) startup mount;
3) alter system enable restricted session;
4) alter system set job_queue_processes=0;
5) alter database open;
6) alter database character set WE8ISO8859P1; (en esta línea, va el juego de caracteres al que queremos pasar nuestra BD)
7) shutdown immediate;
8) startup;

Y con eso es todo!

Cuándo y cómo reconstruir un índice?

2009-06-03T16:38:00.009-03:00

A veces nos preguntamos... en qué basarnos para justificar (o no) la reconstrucción de algún índice de nuestro motor?

Muchas veces (al menos por mi parte) reconstruimos el índice solamente si nuestra aplicación nos dice "Ups! index or partition of such index is in unusuable state (ORA-01502)"... pero sino, no nos acordamos de su existencia!

He aquí una sugerencia...
select index_name, blevel from dba_indexes where table_owner='Propietario'

Si esta sentencia nos devuelve en blevel un valor > 4, es recomendable recontruir el índice en cuestión. Blevel (branch level) indica el número de veces que Oracle ha tenido que reducir la búsqueda en ese índice.

Para reconstruirlo...
alter index rebuild Nombre_índice;

ORA-19734

2009-06-03T13:04:00.008-03:00

Me encontré con este amigable error en una instancia en la que estaba intentando hacer un transporte de tablespace... y resulta que por la mitad del procedimiento me canceló (todavía no me explico por qué!!!)

ORA-19734: wrong creation SCN - control file expects converted plugged-in datafile

Haciendo referencia a un datafile involucrado en el transporte, en mi caso era TEST.DBF...

Qué hacer?!

Sospeché que el problema podría estar dado por el lado del controlfile, y que en caso de recrearlo sin la referencia a ese datafile, iba a poder repetir el procedmiento.

En principio no tenía respaldo del controlfile... así que procedí a crear un backup del mismo...
Inicié la instancia en modo MOUNT:
STARTUP MOUNT;

Luego ejecuté el backup:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/tmp/ctrlfile.bak';

Edité el trace generado con las sentencias para recrear mi controlfile, eliminando la referencia al datafile TEST.DBF, quedó algo de este estilo...

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORA10CCU" RESETLOGS NOARCHIVELOG MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 2336
LOGFILE
GROUP 1 '/home/oracle/oracle/product/10.2.0/oradata/ora10ccu/redo01.log' SIZE 100M, GROUP 2 '/home/oracle/oracle/product/10.2.0/oradata/ora10ccu/redo02.log' SIZE 100M, GROUP 3 '/home/oracle/oracle/product/10.2.0/oradata/ora10ccu/redo03.log' SIZE 100M-- STANDBY LOGFILE
DATAFILE
'/home/oracle/oracle/product/10.2.0/oradata/ora10/system01.dbf', '/home/oracle/oracle/product/10.2.0/oradata/ora10/undotbs01.dbf', '/home/oracle/oracle/product/10.2.0/oradata/ora10/sysaux01.dbf', '/home/oracle/oracle/product/10.2.0/oradata/ora10/users01.dbf', '/home/oracle/oracle/product/10.2.0/oradata/ora10/example01.dbf', '/home/oracle/oracle/product/10.2.0/oradata/ora10/TEST.DBF', (eliminando esta línea)
CHARACTER SET WE8MSWIN1252;

Copié y pegué en la consola de SQLPlus y listo! Nuevo CONTROLFILE generado!

Luego desde la consola:
RECOVER DATABASE;

ALTER DATABASE OPEN;

En mi caso, había omitido la creación del TEMPORARY TABLESPACE, así que lo generé nuevamente:
ALTER TABLESPACE TEMP ADD TEMPFILE '/home/oracle/oracle/product/10.2.0/oradata/ora10/temp01.dbf' REUSE;

Ahora sí!!! Repetí el transporte del tablespace y quedó solucionado... (por suerte!!!)

Eliminar sesión

2009-05-28T13:17:00.008-03:00

Muchas veces, cuando la salud de nuestro motor Oracle está en juego a causa de bloqueos, la solución es sacar del camino la sesión que nos está trancando el trabajo de otras sesiones, en este caso debemos eliminar a la sesión bloqueante...

Como la identificamos?

select * from v$session;

Luego con el dato sid y serial# de la sesión en cuestión, ejecutamos:

alter system kill session 'sid,serial#' immediate;

Comenzando...

2009-05-28T13:09:00.001-03:00

Se me ocurrió abrir un blog para compartir experiencias en el mundo Oracle...

Consultas, sugerencias, experiencias acerca del motor de datos más potente del mundo.