Juan Andres Mercado Oracle Blog
Troubleshooting daily on Oracle Systems, Linux & more !
Entre algunas alertas que podemos ver por el Enterprise Manager, podemos ver la de objetos descompilados.
13 object(s) are invalid in the PUBLIC schema.
Me logueo a la instancia y voy a ver cuales son los schemas que tienen objetos descompilados.
Para ello voy a compartirles un script que utilizo para el chequeo y para el armado de la compilacion por schema.
SELECT 'EXECUTE DBMS_UTILITY.COMPILE_SCHEMA(''' || owner || ''',FALSE) ;'
FROM dba_objects
WHERE status = 'INVALID';
Cuando cambiamos el nombre de la base despues de un restore, que generalmente sucede cuando nos solicitan rearmar un ambiente de testeo los pasos que seguimos son sencillos, usar NID y listo.
Ahora, que sucede cuando la base no se cierra ordenamente ?
No vamos a poder hacer el cambio de nombre.
Supongamos que yo bajo la base de apuro o por otro problemas con SHUTDOWN ABORT.
ORA-01013: user requested cancel of current operation SQL> shutdown abort ORACLE instance shut down. SQL> startup nomount ORACLE instance started. Total System Global Area 536870912 bytes Fixed Size 2085288 bytes Variable Size 192941656 bytes Database Buffers 335544320 bytes Redo Buffers 6299648 bytes
DG Broker: Resolviendo Inconsistencias de Configuración
En un caso de prueba que estabamos evaluando tiempos de performance de servicios, discos y por hecho la base de datos. El analisis consistia en que impacto tendría la aplicación en la base corriendo con disco rapidos y lentos. Sobre esas mismos tests, uno en particular consistia en cambiar el modo de trabajo del dataguard de MAXIMUM AVAILAVILITY a MAXIMUM PERFORMANCE.
Como pasamos de AVAILAVILITY a PERFORMANCE, aumenta el riego de DATA LOST, es por ello que configuramos el parámetro archive_lag_target en 1200 segundos para que en el momento de que haya pocas transacciones el log se cierre de todas maneras y nos asegure la menor perdidad de datos en caso de tener que pasar a contingencia.
SQL> sho parameter archive_lag NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ archive_lag_target integer 1200 SQL>
ORA-15186: ASMLIB error function = [asm_open], error = [1], mesg = [Operation not permitted]
Una tarde en un cliente estabamos realizando una tarea de mantenimiento de los server de bases de datos. La tarea por si misma requeria agregar un disco al diskgroup y el reinicio del server por una actualizacion del firmware de las placas. Agrego el disco y procedo a bajar todo prolijamente todo ya que era una base en RAC.
$ srvctl stop database -d PROJV $ srvctl stop asm -n srprod01 $ srvctl stop asm -n srprod02 $ srvctl stop nodeapps -n srprod01 $ srvctl stop nodeapps -n srprod02
Cuando finaliza el rebooteo observo que las instancias no levantaron.
La primer instancia que reviso es la de ASM para ver que ocurria y revisando el alert me encuentro con el error ORA-15186.
Una buena práctica cuando tomamos un BACKUP HOT es hacer un RESTORE VALIDATE DATABASE, que chequea la integridad y consistencia de las piezas de backup generadas por RMAN, contra los datafiles, archivelogs que se encuentran en la base de datos y nos asegura que el restore correra sin problemas al momento de recrear el ambiente.
La sintaxis de ejecución es la siguiente:
run { restore validate database; }
Bien, ahora vamos a mostrar un ejemplo, que luego de tomar un BACKUP HOT, valido las piezas.
