error "missing form factor" en archivo "ons.log" del Oracle HTTP Server

En cierta ocasión, en una reciente instalación de un Oracle Application Server 10g, se detectó que el oracle home estaba ocupado al 100%.

Después de borrar algunos archivos que ya no era necesario tener, se detectó que el espacio rápidamente se llenó de nuevo, por lo que se hizo una búsqueda de los directorios con más espacio ocupado, de manera sucesiva, hasta encontrar que el path

/u00/app/oracle/product/infra_10.1.2/opmn/logs

contenía dos archivos de 1.5 Gb cada uno, llamados ons.log.[fecha y hora], los cuales se hicieron nulos ( > ons.log.[ ] ), con lo que se liberó el espacio.

Después de esto se observó que el archivo ons.log crecía muy rápido, a razón de unos 2 Mb por minuto, y también se observó que dentro aparecía solo una línea repetida infinitamente, como la siguiente:

05/07/27 09:38:19 [4] Local connection 0,127.0.0.1,6113 missing form factor

Se buscó el error y en metalink se halló la nota 284602.1 (10g Listener: High CPU Utilization - Listener May Hang), en la cual se presenta la siguiente solución:

Se dieron de baja los listeners de la Base de Datos instalada y del OAS

lsnrctl stop

En el software de la Base de Datos se renombró el archivo:

/u00/app/oracle/product/10.1.0/opmn/conf/ons.config

y se le llamó:

/u00/app/oracle/product/10.1.0/opmn/conf/ons.config.orig

Se levantaron de nuevo los listeners, tanto de la BD como del OAS

lsnrctl start

cómo verificar objetos bloqueados en una Base de Datos Oracle

Existen dos vistas que registran los bloqueos de objetos en una base de datos oracle 10g:

1. DBA_DDL_LOCKS
2. DBA_DML_LOCKS

La primera registra los bloqueos por compilaciones, comandos alter ..., etc. La segunda registra los bloqueos por update, delete, insert, select.

La vista DBA_DML_LOCKS tiene un campo llamado BLOCKING_OTHERS, el cual registra si hay otros objetos "esperando" a que se desbloquee el objeto registrado como bloqueado.

Ambas vistas están accesibles para el usuario sys o system, y son útiles para detectar si algún objeto está bloqueado en modo "Exclusive" cuando ocurre un error como este:

ORA-04021: timeout occurred while waiting to lock object schema_user.object

Este error salió cuando se intentó compilar un package y dicho package estaba entretenido ejecutando un cliclo infinito. :) La solución fue reiniciar la aplicación (OAS) para poder volver a compilar el package. Quizá hubiera sido mejor identificar la sesión o sesiones bloqueadas y "matarlas", pero como no era un proceso crítico y no había mucho tiempo, se decidió reiniciar todo.

firefox auto-connect - deshabilitar

A mí me parece muy engorroso o molesto que cada vez que se va la red o cuando quiero trabajar desconectado, el firefox se intente conectar y abra la ventana de "dial up" para conectarse por teléfono, ya que esta ventana aparece encima de todas las demás, y si estoy trabajando, me interrumpe.

Para deshabilitar esta opción, encontré en el FAQ de Mozilla lo siguiente:

(http://www.mozilla.org/start/1.5/faq/browser.html#auto-dial)

If you want to turn on auto-connect for other Internet clients but turn it off for Mozilla, enter about:config in the Location Bar. Find the item network.autodial-helper.enabled and set its value to false.

Así pués, puse "about:config" en la barra de direcciones y me apareció una página con una lista interminable de parámetros, cuyo encabezado dice: "Preference name", "Status", "Type" y "Value". En "filter" use el texto "network.dial" para llegar más rápido al parámetro mencionado. Luego di clic con el botón derecho del ratón sobre la preferencia que quería cambiar y seleccioné del menú que apareció "Modify", y le cambié a "false". Asunto arreglado.

No le he echado un vistazo a los demás parámetros, pero estuvo interesante esta configuración. Ahora buscaré cómo hacer lo mismo pero en el Thunderbird, el cliente de email de Mozilla.

error en JDev al crear web service que utiliza "table of"

Cuando intenté crear un web service a partir de un package de PL/SQL que utilizaba como parámetro de entrada un tipo de dato TABLE OF CHAR, en el JDeveloper simplemente no aparecía como opción a seleccionar para ser convertido. Al dar click en el botón de ayuda "Why not?", salía un mensaje como este:

The following types used by the program unit do not have an XML Schema mapping

Entonces, buscando en internet, como siempre, me encontré en un foro lo siguiente:

It works ("VARRAY" and "TABLE OF"; in JDev 1013) if the types are defined globally and NOT inside a package specification.

Acto seguido, puse entre comentarios el código que declaraba el TYPE dentro del package, me llevé dicho código al sqlplus, y lo compilé directamente con el mismo usuario dueño del package, de manera que quedara declarado en su mismo esquema (para comprobarlo, revisar que la instrucción SELECT * FROM ALL_OBJECTS WHERE OBJECT_TYPE = 'TYPE' AND OWNER = '[schema owner]'; regrese un registro correspondiente al aludido TYPE)

That's it! Después de hacer esto, ya pude crear el web service derivado de este package con el JDeveloper (que por cierto, era el 10.1.2).

proceso "ocssd" se queda corriendo al bajar Oracle Database

Cuando bajo la base de datos Oracle 10gR2 hay un par de procesos que se quedan corriendo, como sigue:

/bin/su -l oracle -c exec /u00/app/oracle
/u00/app/oracle/product/10.1.0/bin/ocssd.

resulta que ese proceso llamado OCSSD es útil cuando se tiene un RAC, y sirve para ASM (Automatic Storage Management). Este proceso lo arranca el sistema operativo, y no oracle, por lo que para desctivarlo hay que quitar una línea en un archivo de inicio del operativo. Según la discusión llevada a cabo en el siguiente sitio:

http://forums.oracle.com/forums/message.jspa?messageID=818352

El script que arranca el proceso es:

/etc/init.d/init.cssd,

y para deshabilitarlo se puede comentar la línea que llama al "init.cssd" en el arachivo:

/etc/inittab

o bien, modificar el "init.cssd" y agregarle "exit", como sugieren en esta otra discusión:

http://forums.oracle.com/forums/thread.jspa?messageID=787244󀌬

Si se requiere simplemente detener el proceso, el siguiente procedimiento es útil:

1. Shut down the Oracle Cluster Synchronization Services (CSS) daemon as the root user:

   # /etc/init.d/init.cssd stop
   

libro de Korn Shell online

He aquí una referencia muy útil para quienes usa el korn shell:

http://www.sm.luth.se/~alapaa/file_fetch/unixcdbookshelf/korn/

Esta liga dejó de funcionar. La dejo como historia ...

disco lleno, a causa del flash recovery area [file system full]

En una ocasion el OAS dejó de responder, y me di cuenta de que el file system donde estaba el software de oracle se había llenado, esto lo supe mediante el comando: df -h . y observando que decía que estaba usado el 100%

A continuación seguí los pasos del siguiente algoritmo:

INICIO
Entrar al servidor con el usuario dueño del software de oracle
REPETIR hasta llegar al último directorio en la ruta
ejecutar comando: du -hs ./*
ir al directorio que ocupa mayor espacio en disco: cd [directorio]
FIN REPETIR
FIN

Ahí me di cuenta de que el flash Recovery Area era el que más espacio ocupaba. Esta área se utiliza para generar los respaldos mediante el RMAN. En el caso de nuestro servidor, no teníamos configurado ningún respaldo, por lo que investigué cómo depurarlo. Aquí está lo que hice:

$ORACLE_HOME/bin/rman
connect target
LIST COPY OF DATABASE ARCHIVELOG ALL;
delete archivelog from sequence XXXX;

donde XXXX es la secuencia a partir de la cual se desea borrar los archivos. Si eso no lo borra, intentar lo siguiente:

crosscheck archivelog sequence=4107;
delete archivelog sequence=4107;

- - - - - - -
En otra ocasión que me sucedió lo mismo y no encontraba mis apuntes anteriores, funcionó esto:

BORRADO MANUAL DE archivelogs

Con la Base de Datos abajo (shutdown immediate):

cd $ORACLE_HOME/flash_recovery_area/$ORACLE_SID/archivelog
find . -name "*.arc" -exec rm {} \;

Despues de hacer el borrado, ejecutar comandos siguientes (RMAN):

$ORACLE_HOME/bin/rman
startup mount
connect target
delete force noprompt archivelog all;
shutdown immediate
startup
exit

Listo. Revisar que el file system ya tiene espacio libre: df -h $ORACLE_HOME

Si la Base de Datos está levantada, se pueden correr los comandos del rman directamente sin tener que borrar los archivos del flash_recovery_area a mano.

Luego de esto, procedí a deshabilitar el flash recovery area del sistema mediante este comando:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST=''

y al final, puse ese mismo parámetro en el archivo de init para que al arrancar la BD de nuevo no se fuera a crear otra vez el flash recovery area.

OCS - no aparece el botón "create oc4j" en el EM

En la Consola de Administración (EM, o Enterprise Manager) del Oracle Collaboration Suite no aparece la opción de crear un contendor de java (como sí aparece en la consola del OAS). Por lo tanto tuve que crear el contenedor desde la línea de comandos.

Para crear un nuevo contenedor OC4J en el OAS:

dcmctl createComponent -ct oc4j -co OC4J_myapps

Después me encontré esta nota en la documentación:

- - - - - - -

The admin Account

Whenever you create a new OC4J instance, that instance is given an administrator account admin with password welcome. You should change this password immediately using Oracle Enterprise Manager 10g Application Server Control Console.

Here are the steps to change the password:

1. From the Application Server Home page, select the OC4J instance.
2. From the home page of the OC4J instance, choose Administration.
3. From the OC4J Administration page, choose Security.
4. From the Security page, choose jazn.com/admin (under Users) to edit the administrative user properties.

- - - - - - -

JDev, OAS - deploy failure, y otras cosas raras

El día de hoy, Edgar (no el que se cae, sino otro) me reportó que en el JDeveloper desde donde estaba intentando hacer un deploy hacia el Oracle Application Server de pruebas (OAS 10gR2) estaba recibiendo errores como los siguientes:

#### DCM command did not complete
successfully (-1) #### HTTP return code was -1 Exit
status of DCM servlet client: -1
Elapsed time for deployment: 41 seconds ####
Deployment incomplete. #### 6/10/2006 11:44:02 AM

y en los logs marca:

MOD_OC4J_0015: recv() returns 0. There has no message
available to be received and oc4j has gracefully
(orderly) closed the connection.
MOD_OC4J_0054: Failed to call network
routine to receive an ajp13 message from oc4j.
MOD_OC4J_0033: Failed to receive an
ajp13 message from oc4j.
MOD_OC4J_0078: Network connection errors
happened to host: prod05ws.itesm.mx and port: 12502
while receiving the first response from oc4j. This
request is recoverable.

Pues resulta que el servidor donde se aloja el susodicho OAS sufrió un ataque de pánico el día de ayer y se reinició (el sistema operativo indicaba "panic"), por lo que supuse que algo quedó inconsistente al cerrarse abruptamente la aplicación. Entonces recordé que ayer yo había tenido problemas con otro OAS de laboratorio y había encontrado un comando "resyncInstance", por lo que se me ocurrió que éste podía ayudar. Antes de correr dicho comando, verificamos algunos logs (Oc4jDcmServlet.log), encontrando algunos errores como:

The configuration files for this Oracle Application Server instance are
inconsistent with the configuration stored in the repository. In order to
protect the repository, no further configuration or deployment operations are
allowed until the problem with the configuration on the filesystem is resol
ved. This condition arises when a prior operation was unsuccessful.

igualmente, checamos el estatus de la instancia con otro comando:

[PATH-TO-ORACLE-HOME]/dcm/bin/dcmctl getState

y encontramos lo siguiente:

Current State for Instance:infra.prod05ws.itesm.mx

Component Type Up Status
In Sync Status
======================================================
1 HTTP_Server HTTP_Server Up True
2 OC4J_SECURITY OC4J Up True
3 home OC4J Down True(Disabled)
4 oca OC4J Up True

Entonces procedimos a correr el comando que mencioné anteriormente,

[PATH-TO-ORACLE-HOME]/dcm/bin/dcmctl resyncInstance -force

Después de eso hubo que reiniciar desde la consola (EM), todo lo que marcaba como estatus "down", como los contenedores (OC4J).

Y voilà! Al intentar de nuevo hacer un deploy, ya funcionó bien. Sin embargo, notamos otro problema, y es que se borraron unas clases que estaban puestas bajo el directorio del OC4J_SECURITY y se eliminaron unas modificaciones hechas al web.xml del mismo contenedor. Supuse entonces que, como dichas clases y modificaciones se hicieron directamente en el file system, en lugar de hacerlo a través de un "deploy" desde la consola o desde el JDeveloper, pues los cambios no estaban registrados en el repositorio, y el resyncInstance obviamente los eliminó. Tengo que verificar esto, y lo haré el lunes, junto con Edgar (que a veces también se cae), nomás pa'estar seguros. Así que, amiguitos y amiguitas, aquí tenemos una muestra del por qué no hay que modificar los archivos a patín, o directamente, sino que hay que hacerlo a través de las herramientas que Oracle proporcione, aunque a veces este procedimiento sea más tardado y/o tedioso :S Dicen que no hay lonche gratis!

Por cierto, en el servidor de OAS de laboratorio también corrí el "resyncInstance" y al parecer sí le ayudó, pero sigo teniendo algunos problemas con él. Me había estado marcando errores extraños y no me dejaba modificar los archivos httpd.conf e incluidos (a través de la consola, por supuesto), desaparecía los nombres de los DADs, etc. Ahora se perdieron los cambios que había hecho en httpd.conf y me desapareció un archivo que inclui (dat.conf), así que estoy dudando lo que realmente hace el "resyncInstance"... el lunes nos daremos cuenta. :)