Recientemente siguiendo el documento ID 456468.1, he realizado una verificación de la integridad del catálogo. El caso es que han aparecido un par de errores indicando un problema con un identificador de objeto:
1703982
Este objeto existe en dba_objets, la consulta:
Una vez más se vuelve a repetir la historio, se instala un PathSet con la idea de solucionar problemas y aparecen otros nuevos (esta vez sin documentas).
Esta vez ha sido al instalar el PatchSer 10.2.0.5 sobre la versión 10.2.0.1. El caso es que ahora al intentar ejecutar el SQL Access Advisor, no aparece la tarea recién creada pero si un error en el alert:
Cuando listamos los backups realizados con:
RMAN> list backup summary;Por ejemplo, podemos tener problemas para localizar un backupset. El resultado es bastante confuso y desde luego son poco elegantes las etiquetas creadas por defecto.
Es posible que una aplicación muestre en su log un error ORA-01591, que según la documentación oficial es debido a una trasacción de 2 fases que no puede completarse.
Este tipo de transacciones se usan, por ejemplo, cuando se hace un commit usando tablas obtenidas a partir de un dblink. Se verifica que se puede hacer un commit en remoto, otro en local y finalmente se hace en los 2 sitios de forma atómica.
Bueno pues cuando se pierde la conexión con un dblink durante una transacción, la transacción queda en un estado dudoso y si alguna otra sesión intenta modificar los objetos involucrados veremos el error ORA-01591.
Con la versión más reciente de Oracle Database 11g, se ha reforzado la seguridad por defecto. Esto en principio debería ser positivo, pero hay algunas situaciones en las que pueden resultar desagradables algunos comportamientos.
El caso más claro lo podemos encontrar en la moficación del perfil (PROFILE) DEFAULT, que es aplicado a cualquier usuario creado de forma predeterminada.
Recientemente para solucionar un problema en producción identificado como un bug (solventable con el Path Set 10.2.0.4) , ha sido necesario upgradear la BD Oracle de la versión 10.2.0.1 a 10.2.0.5 (ya puestos nos vamos al último Patch Set).
Después de la instalación del Path Set 10.2.0.5 para Linux 64 bits, que se realizó sin problemas y upgradear los catálogos de las bases de datos, todo parecía ir sobre ruedas.
De momento el parámetro COMPATIBLE se mantuvo con la versión original 10.2.0.1.
Los problemas surgieron aproximadamente un día más tarde cuando un report dejó de funcionar, el alert muestra:
El KVM (Kernel Based Virtual Machine) es usado por qemu para la virtualización de máquinas. La creación, modificación, arranque, parada, etc.. se puede realizar de forma visual con Virtual Machine Manager, pero la opción de trabajar por linea de comandos me parece muy potente y relativamente sencilla.
Por ejemplo si queremos crear una máquina y que nos vaya preguntando que es lo que queremos podemos hacer:
En un entorno de producción, es muy recomendable tener activado el log de consultas lentas, para irlo analizando de vez en cuando.
La activación se realiza en el fichero de parámetros usado (por ejemplo my.cnf), añadiendo dentro de la sección [mysqld]:
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 10
log-queries-not-using-indexesAl realizar una restauración de una copia vía RMAN (Oracle Database), es posible aparezcan avisos como:
datafile #NUM not processed because file is read-only
Esto se debe a que se ha usado el comando:
restore database;
En algunos casos, afortunadamente no demasiados, he tenido que buscar una cadena (normalmente algo relacionado con la configuración) en un esquema de la BD.
El asunto se complica cuando hay una cantidad de tablas ingente y además no hay forma de ponerse en contacto con el desarrollador, vamos un infierno.
Pues bueno para estos casos quiero compartir un script PL/SQL de cosecha propia (como casi todos los que pongo en el blog), que facilita el tema bastante: