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';
Image via Wikipedia
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>
Image by Fenng(dbanotes) via Flickr
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. Read more of this post
Juan Andres
