Doble dirección ip en una entrada tnsnames.ora

El tnsnames.ora es un fichero que con el tiempo se convierte en un basurero. Se añaden entradas redundantes, o usadas una vez y olvidadas, editadas a mano, mal formateadas… Un calvario si no eres especialmente ordenado.

Personalmente, prefiero nombres en las cadenas de conexión que se autodefinan, es decir que el nombre incluya una referencia a si la bbdd es de producción o desarrollo, en que máquina está y como se llama la instancia. Por ejemplo utilizo estas máscaras HOST_BBDD_PROD, CLIENTE_BBDD_PREPRO, ...

Un problema habitual suele ser intentar acceder desde tú maquina portátil a la misma bbdd desde dos puntos de red distintos, por ejemplo desde mi oficina (ip de internet) y desde la oficina del cliente (ip de su lan) cuando estoy de visita. La respuesta sencilla: dos entradas; la respuesta la inteligente: una única entrada ya que es la misma bbdd.

En el siguiente ejemplo se muestra como invocar la misma cadena de conexión desde dos puntos distintos, el sqlnet automáticamente salta a la dirección que funciona en cada caso.

HOST_BBDD_DESA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = 64.233.167.99)
(PORT = 1521)
)
(ADDRESS =
(PROTOCOL = TCP)
(HOST = 192.168.1.10)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SID = BBDD)
(SERVER = DEDICATED)
)
)

Como se puede ver las combinaciones pueden ser múltiples. No sólo se pueden marcar distintas direcciones o nombres de host sino que para cada entrada puedes determinar su puerto.

Recuperar espacio en un tablespace con datos Blob

Oracle derrocha bastante espacio de almacenamiento de disco. Al modificar o borrar registros lo lógico seria que se liberase espacio pero Oracle lo conserva para posibles futuros usos de ese mismo objeto. El principal motivo es que se prima el rendimiento, relegando la recuperación del espacio no empleado a tareas de mantenimiento.

Recuperar este espacio es sencillo para tablas normales. Probablemente la mejor manera es realiza un move tablespace de la tabla. Antiguamente estaba el par exp/imp.

El problema surge en la gestión de datos tipo BLOB que no comparten el almacenamiento en disco con el resto de los campos del registro y en caso de borrado no libera los bloques empleados pese a haber eliminado el registro. La unica solución es realizar este proceso de mantenimiento campo a campo.

Tomemos por ejemplo una tabla, T, con 3 campos y todos de tipo BLOB, (X, Y, Z). Diponemos de 2 tablespaces para realizar las tareas auxiliares LOBTEST y LOBTEST2.

Es sencillo comprobar el espacio que incialmente usado en ambos tablespaces es:

Select Sum (Bytes) / 1024 / 1024, segment_name, segment_type
From user_segments
Where tablespace_name Like 'LOBTEST%'
Group By segment_name, segment_type;
(1)

Así pues la operativa de mantenimiento es:

ALTER TABLE t MOVE LOB(x) STORE AS ( TABLESPACE lobtest2 );
ALTER TABLE t MOVE LOB(y) STORE AS ( TABLESPACE lobtest2 );
ALTER TABLE t MOVE LOB(z) STORE AS ( TABLESPACE lobtest2 );

(… suponiendo los objetos almacenados en lobtest)

Con estas instrucciones habremos recuperado el espacio libre bloqueado. Se puede comprobar el espacio consumido con la misma consulta (1). Por ultimo y dependiendo de la politica de almacenamiento quedaria devolver los objetos ya “compactados” al su tablespace original: de LOBTEST a LOBTEST2 por el mismo mecanismo descrito.

Intersante:

  • Si se dispone de suficiente espacio en el tablespace es posible reconstruir el objeto utilizando el mismo tablespaces
  • Como se puede observar, dado este consumo desmesurado de espacio es recomendable almacenarlo en tablespaces separados.
  • Desde la versión 10 existen mejores metodos de monitorización y recuperación de espacio como el “consejero de almacenamiento”. En cualquier caso estas técnicas siguen siendo operativas.
  • No se tiene en cuenta la gestión del almacenamiento con ASM
  • Matando sesiones con seguridad

    El método más seguro de matar una sesión es desde una sesión del administrador de la bbdd. Con alguna referencia sobre el proceso a matar se realiza una búsqueda con la consulta:

    SELECT s.sid, s.serial#, s.osuser, s.program
    FROM v$session s;

    Con el sid y serial# se lanza la instrucción:

    ALTER SYSTEM KILL SESSION 'sid,serial#';

    Es posible que el proceso no termine con facilidad, por lo que conviene lanzar esta misma llamada con el modificador IMMEDIATE. De este modo el proceso fuerza también, de un modo seguro, la finalización del proceso del sistema operativo.

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

    Este es el único método seguro ya que si se opta por matar directamente la sesión del sistema operativo es posible que se vea afectada la integridad de los datos.

    No obstante en situaciones de autentica necesidad se podrá también matar los procesos del sistema operativo.

    Para sistemas Unix el clásico KILL -9 {spid} o desde windows orakill {sid} {spid}, donde {spid} se deduce del cruce de v$session y v$process y el {sid} es el identificador de la bbdd.

    Moviendo un datafile para resolver un filesystem lleno

    El método más sencillo de hacer espacio en un filesystem lleno es mover uno de los datafiles afectados a un nuevo filesystem. Si se disponde de hueco no habrá que esperar más tiempo que el que tarde en realizarse el cp del datafile a su nueva ubicación. Existen dos maneras de mover estos datafile en funcion de lo bloqueada que este la bbdd.

    ALTER DATABASE
    (datafiles tipo sistema)

    Si la cosa está muy complicada es posible que Oracle ni siquiera pueda permanecer abierta por tratarse de alguno de los ficheros o tablespace de los vitales.

    1. Con la bbdd parada, movemos el fichero (o uno de los ficheros) a su nueva ubicación, tan sencillo como un cp del sistema operativo. La intención es hacer hueco en el filesystem para que sistema pueda seguir funcionando.
    2. Nos conectamos como sys y montamos la bbdd.
    3. Realizamos el alter del datafile
      alter database rename file '/system/oradata/XXX/undotbspc01.dbf' to '/datos/oradata/XXX/undotbspc01.dbf';
    4. Por ultmo abrimos al servicio la bbdd
      alter database open;

    ALTER TABLESPACE
    (cualquier otro tipo de datafile)

    Para tablespaces de los no vitales el siguiente método tiene un impacto menor ya que el sistema no necesita ser parado.

    1. Conectarse como sys a una instancia abierta.
    2. Poner offline el tablespace afectado con la instrucción
      alter tablespace datos offline;
    3. Realizar el alter de tablespace con el modificador rename.
      alter tablespace datos rename datafile '/datos01/oradata/XXX/datos01.dbf' to '/datos02/oradata/XXX/datos01.dbf';
    4. Volver a abrir el tablespace con la instrucción:
      alter tablespace datos online;

    Perdiendo la conexión al servidor Oracle

    De un tiempo a esta parte he tenido problemas de conexión a Oracle y cualquier tipo de servidores: era capaz de conectar con el servicio pero inexplicablemente, e incluso en mitad de una instrucción, perdía la conexión. En la ultima semana se había vuelto insoportable ya que debía reconectarme cada pocos minutos.

    Estuve chequeando una serie de posibles causas y soluciones y todo hacia indicar que era un problema de mi tarjeta de red. Hice pruebas con varias pcmcia y todo parecía seguir igual.

    Sin descartar del todo el problema de hard intente limpiar el ordenador buscando algún spyware que lei provocaban el mismo efecto. El resultado: nada de nada.

    De casualidad y sobre el tema de los spyware leí sobre el reset del winsock y encontré esta herramienta, XP TCP/IP Repair. ¡¡¡Cuidado con lanzar a ciegas!!!

    Según parece, si se juega como es mi caso con la configuración de red o debido a algunos tipos de software de no se sabe que propósito tienen, se puede corromper la configuración Winsock y/o Layered Service Providers (LSP) del sistema Operativo, degradando o bloqueando la conexión de red. Esta aplicación en cuestión no deja de ser una interfaz a un par de instrucciones, requiere reiniciar la máquina para ver los cambios aplicados.

    En mi caso funcionó. Debo advertir que debe de ser una práctica con cierto riesgo ya que elimina posibles configuraciones correctas que en teoría dejarán de funcionar pero es esto o nada.

    Actualización: Después de varios días funcionando sin problemas, volvieron a dar varios timeout en una conexión a Oracle. Esta vez el problema estaba limitado a este tipo de cliente con lo que realicé una traza de SQL*NET y descubrí problemas de timeout. Según Metalink  estos problemas pueden ser debidos a algún tipo de congestión de red y pueden solucionarse ampliado el valor de un parametro del registro TcpMaxDataRetransmissions. Lo subí hasta 10, el doble del valor por defecto. A ver cuanto dura.

    Poner Oracle9i en modo archivelog

    Los pasos son muy básicos, en primer lugar abrir una sesión con el usuario SYS y modificar estos parámetros del xfile.

    ALTER SYSTEM SET log_archive_start=TRUE SCOPE=spfile;

    ALTER SYSTEM SET log_archive_dest_1='location=/u01/oradata/<MiSID>/archive/' SCOPE=spfile;

    ALTER SYSTEM SET log_archive_format='arch_%t_%s.arc' SCOPE=spfile;

    Su función es activar el proceso de archivado y establecer el destino y formato de los ficheros. Con los parámetros modificados debemos reiniciar la base de datos. Antes de la apertura es necesario reactivar el proceso de archivado.

    SHUTDOWN IMMEDIATE;

    STARTUP MOUNT;

    ARCHIVE LOG START;

    ALTER DATABASE ARCHIVELOG;

    ALTER DATABASE OPEN;

    La base de datos ya está activada, en este ultimo paso comprobamos el estado del archiver.

    ARCHIVE LOG LIST;

    Reconfigurando el Enterprise Manager Console en la Oracle10g

    Cambiar el nombre de una máquina después de una instalación
    correcta debería de estar prohibido.

    Si bien, instalar un servidor oracle10g en una máquina de pruebas ya no es especialmente complicado. Los problemas saltan cuando se debe manipular la configuración manualmente.

    Caso típico, alguien decide que la máquina recién instalada debe cambiar de nombre para que quede bien con la nomenclatura del resto de los equipos. ¡Gran problema!

    Configurar el Listener y el propio servidor no es difícil, el método es el mismo desde casi el principio de los tiempos. Adivinar como se puede cambiar la configuración del nuevo Enterprise Manager Console tipo web es otro cantar.

    En encontrado esta referencia en la web que explica como realizar todo el proceso como antes de que existiesen los instaladores.

    En mi particular caso, debo obviar el repositorio que ya fue creado, pasamos directamente al punto

    emca-config dbcontrol db

    Antes de empezar, por favor, confirmar que tenemos todas las contraseñas y parametros de configuracion.

    Buena caza