Otro error para la colección

Esta vez, Oracle Discoverer:

¿Sólo a mí me llaman la atención estas cosas?

Categorías:Oracle

La memoria no se puede “read”

Este es otro interesante error (esta vez de Windows) donde los textos de error traducidos se mezclan con mensajes crudos que parecen provenir del kernel

Para ser consistentes, también tienen la versión que dice: La memoria no se puede “write”…

Categorías:Uncategorized

N “vezces” sin éxito…

Después de auqello del “Servidor Pantalla” (interesante traducción de Forms Server), hoy encontré otro argumento para pedir el Ignatius Nobel a los traductures de la E-Business al español.

No hay caso, el español es un idioma ladino… ¿a quién se le ocurre que haya casos en que el plural no se pueda construir a partir del singular?

Categorías:E-Business Suite, Oracle

LTOM: “No comprendo su lenguaje”

Hace unos días estuve instalando LTOM, un avanzado monitor proactivo para Oracle, que se describe en la nota 352363.1 de Metalink.

Después de algunos problemas fácilmente solucionables, como instalar top para Solaris y reinstalar statspack, me encontré con un problema al utilizar LTOMg que me llevó un rato solucionar.

LTOMg es la aplicación Java que permite graficar los indicadores considerados por LTOM. Al ejecutarla, obtenía lo siguiente:

#java -jar ltomg.jar -i $TOM_HOME/recordings/profile/pro1264688828524.log
...
Starting LTOMg V1.1.2
LTOM Graph Written by Oracle Center of Expertise
Copyright (c)  2008 by Oracle Corporation

Parsing Data. Please Wait...
Timestamp Error. Expected format: May 3 16:11:12 2006.
Timestamp Error. Found format: January 28, 2010 PM

El error está claro, hay una diferencia con respecto al formato de fecha esperado.

Una llamada al comando date, verifica que el formato obtenido no es el que se espera. Decompilando las clases Java de LTOMg, me encuentro con las siguientes líneas de código:

try {
   dlist = runCommand("date", 0);
} catch(IOException ioexception5) { }
for(int i = 0; i < dlist.length; i++)
   archOut.write("\n" + dlist[i] + "                zzd");
archOut.write("\n");

Este código es el que escribe la fecha problemática en el archivo de profile, junto a la marca “zzd” (una marca que se usa para parsear el archivo).

El problema es que se llama al comando date, sin utilizar una máscara de formato. Esto permite que los formatos de fecha puedan diferir, en función de algunas variables de entorno como LANG y LC_TIME.

El workaround fue modificar la variable LC_TIME (export LC_TIME=C) para el usuario oracle.

Sin embargo, si admitimos que la gente puede tener configurado su entorno como quiera (o como necesite), la solución de fondo sería agregar una máscara de formato a la llamada al comando date:

> date +"%a %b %e %T %Z %Y"
Fri Jan 29 03:14:44 UYST 2010

Le escribí a Carl Davis para sugerirle considerar esa mejora, y como era de esperarse me mandó a pasear…

Esto refuerza mi idea de que, más allá de la moda de la localización, en el norte les preocupa muy poco lo que suceda con configuraciones no-default, y es un motivo más a favor de tener todo instalado en inglés, y siempre con la configuración “lo más default posible”.

Categorías:Java, Oracle, UNIX/Linux

Seteando el entorno en E-Business Suite R12

Muchas cosas cambiaron en el release 12 de E-Business Suite, entre ellas, la forma de setear el entorno para poder realizar consultas por fuera de la aplicación.

Sin setear el entorno, no se obtienen datos en las vistas _v:

SQL> select count(*) cuantos_veo from apps.ap_invoices_v;

CUANTOS_VEO
-----------
          0

Seteando el entorno como se hacía enR11, tampoco se obtienen datos:

SQL> select user_id my_user_id from apps.fnd_user where user_name = 'AVICENTE';

MY_USER_ID
----------
2179

SQL> select responsibility_id from apps.fnd_responsibility_tl where
     responsibility_name = 'Superusuario AP';

RESPONSIBILITY_ID
-----------------
50881
50881

SQL> select application_id from apps.fnd_application where
     application_short_name = 'SQLAP';

APPLICATION_ID
--------------
200

SQL> exec apps.fnd_global.apps_initialize(user_id => 2179, resp_id => 50881,
     resp_appl_id => 200);
PL/SQL procedure successfully completed.

SQL> select count(*) cuantos_veo from apps.ap_invoices_v;

CUANTOS_VEO
-----------
          0

Se necesita además obtener los valores de operating_unit y organization_id para la organización, y ejecutar otros dos procedimientos, para terminar de setear el entorno:

SQL> select operating_unit, organization_id
     from apps.org_organization_definitions
     where organization_name = 'HQ';
 
OPERATING_UNIT ORGANIZATION_ID
-------------- ---------------
83             85

SQL> exec apps.mo_global.set_policy_context ('S', 83);
PL/SQL procedure successfully completed.

SQL> exec apps.inv_globals.set_org_id (85);
PL/SQL procedure successfully completed.

SQL> select count(*) cuantos_veo from apps.ap_invoices_v;

CUANTOS_VEO
-----------
      15426
Categorías:E-Business Suite, Oracle

v$sga_target_advice no retorna datos

enero 19, 2010 2 comentarios

Ayer me encontré con un problema curioso, una consulta en la vista v$sga_target_advice no retornaba tuplas:

>  select * from  v$sga_target_advice; 
no rows  selected

Encontré en la nota 466412.1 de Metalink que es un bug de 10.2.0.1 hasta 10.2.0.3. Parece que al haber modificado el parámetro  sga_target_advice alguna estructura del proceso MMON queda torcida y tiene que deshabilitar el advice:

Cause: Memory broker (MMON process) disables SGA target advice internally when we cannot find any rows for component advisories. This could be due to resizes of that particular component disabling the advisory temporarily.

Siguiendo el workaround de Metalink (básicamente bajar la llave y volver a subirla) el advice vuelve a la vida:

>  show parameter  sga_target;
NAME                                  TYPE                             VALUE
------------------------------------  --------------------------------  ------------------------------
sga_target                            big integer                      1200M

> alter system set sga_target = 0 sid =  'MYDB';
System  altered.

>  alter system set sga_target = 1200M sid =  'MYDB';
System  altered.

>  select * from  v$sga_target_advice;
SGA_SIZE  SGA_SIZE_FACTOR ESTD_DB_TIME ESTD_DB_TIME_FACTOR  ESTD_PHYSICAL_READS
----------  --------------- ------------ -------------------  -------------------
1216               1      1723442                   1           1739945215
1520            1.25      1608488               .9333           1522104074
2432               2      1533174               .8896           1409529619
2128            1.75      1533174               .8896           1409529619
1824             1.5      1533174               .8896           1409529619
Categorías:Oracle

Monitoreando lock waits

En ningún RDBMS los locks son un problema. Lo que es un problema son los locks waits prolongados.

En un sistema con muchos lock waits prolongados, es importante detectar a tiempo estos waits, ya que de otra forma puede empeorar la situación con el tiempo, a medida que nuevas sesiones se encadenan en la espera por recursos.

En Oracle, este SQL muestra las sesiones que participan en un lock de más tiempo en segundos que el que se especifica como parámetro. Como se ve, en el ejemplo la salida está formateada con algunas etiquetas HTML:

#cat $HOME/local/scripts/locks.sql

set linesize 400;
set pagesize 0;
set feedback off;

select
s1.username || ‘@’ || s1.machine ||
‘ ( SID=’ || s1.sid || ‘, Module=’ || s1.module || ‘, Status=’ || s1.status ||
‘ ) ‘ || ‘<br>is blocking<br>’ ||
s2.username|| ‘@’ || s2.machine ||
‘ ( SID=’ || s2.sid || ‘, Module=’ || s2.module || ‘, Status=’ || s2.status ||
‘ ) ‘ || ‘<br>with lock in ‘ || o.object_name ||
‘ for ‘ || s2.seconds_in_wait || ‘ seconds <br><br>’ AS blocking_status
from v$session s1, v$session s2, dba_objects o
where s1.sid = s2.blocking_session
and o.object_id = s2.row_wait_obj#
and s2.seconds_in_wait > &1
order by s2.seconds_in_wait desc;

quit;

Si se ejecuta este SQL pasándole el umbral de segundos se obtienen las sesiones involucradas en los waits. En este caso incluí alguna información relevante de v$session: usuario, host, sid, módulo, status y tiempo del lock; y el nombre del objeto sobre el que se mantiene el lock.

Es fácil agendar un shell script como el siguiente (yo tengo uno cada 5 minutos) que muestra los lock waits de más de 60 segundos. El script arma el HTML con el formato para enviarlo por mail, y lo envía:

#cat $HOME/local/scripts/locks.sh
#!/bin/bash

USERID=”/ as sysdba”
SQLPLUS=”sqlplus -L -S”
TIME_THRESHOLD=60
SQLFILE=$HOME/local/scripts/locks.sql
OUT_LOCKS=/tmp/locks.txt
TO_MAIL=locks@midominio.com

echo “Subject: Locks en MyDatabase” > $OUT_LOCKS
echo “Content-Type: text/html; charset=\”us-ascii\”” >> $OUT_LOCKS
echo “<html><body><font face=\”Courier New\” color=\”#003399\” size=\”2\”>” >> $OUT_LOCKS

$SQLPLUS $USERID @$SQLFILE $TIME_THRESHOLD | egrep -v ‘^old|^new’ >> $OUT_LOCKS

echo “</font></body></html>” >> $OUT_LOCKS

# Si no hay locks, el archivo solo tiene las 4 lineas hard-coded

LINES=`wc -l $OUT_LOCKS | awk ‘{ print $1 }’`
if [ “$LINES” = “4” ]; then
echo “No hay locks de mas de $TIME_THRESHOLD segundos” >> $OUT_LOCKS
else
/usr/sbin/sendmail $TO_MAIL < $OUT_LOCKS
fi

La salida tiene el siguiente formato:

USER_A@server_A ( SID=850, Module=PROGRAM_A, Status=INACTIVE )
is blocking
USER_B@server_A ( SID=902, Module=PROGRAM_B, Status=ACTIVE )
with lock in OBJECT_A for 691 seconds

USER_B@server_A ( SID=902, Module=PROGRAM_B, Status=ACTIVE )
is blocking
USER_C@PC_5364 ( SID=937, Module=PROGRAM_C, Status=ACTIVE )
with lock in OVJECT_B for 625 seconds

Cuando se recibe un mail como el anterior, es posible hablar con los usuarios cuyas sesiones están en wait, para ver cuáles son las situaciones en que se producen. Esta información es un feedback muy valioso para los desarrolladores, que pueden rever las transacciones de los programas involucrados, sabiendo que en ellos se pueden producir lock waits, y sobre qué objetos.

Categorías:Oracle, UNIX/Linux