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!
miércoles, 23 de septiembre de 2009
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?
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)
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!
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!
jueves, 13 de agosto de 2009
Eliminar registros duplicados
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.
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.
miércoles, 12 de agosto de 2009
Inicio automático Oracle en Linux
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!
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!
lunes, 10 de agosto de 2009
Habilitar ARCHIVELOG
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!
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!
martes, 4 de agosto de 2009
ORA-12518
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
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
viernes, 24 de julio de 2009
ORA-12519
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.
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.
jueves, 9 de julio de 2009
Explain plan
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...
A ver si me explico mejor gráficamente...
miércoles, 8 de julio de 2009
Expdp e Impdp
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
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/
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
martes, 7 de julio de 2009
Cortitas...
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;
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;
jueves, 2 de julio de 2009
Archivos redo log
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;
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;
jueves, 11 de junio de 2009
ORA-12541
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
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
martes, 9 de junio de 2009
Cambiar CHARACTER SET
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!
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!
miércoles, 3 de junio de 2009
Cuándo y cómo reconstruir un índice?
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 Nombre_índice rebuild;
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 Nombre_índice rebuild;
ORA-19734
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!!!)
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!!!)
jueves, 28 de mayo de 2009
Eliminar sesión
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;
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...
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.
Consultas, sugerencias, experiencias acerca del motor de datos más potente del mundo.
Suscribirse a:
Entradas (Atom)