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!

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

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.

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

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

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;

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;