En esta semana me han ofrecido un proyecto en Elance basado en preparar unas 300 preguntas para candidatos a puestos de DBA de Oracle, incluyendo la respuesta y las explicaciones. Las reglas no permitían preguntas de si/no/verdadero/falso, ni multi opción, y debían basarse en escenarios de trabajo reales.
Finalmente el proyecto no saldrá adelante con mi participación, y quiero compartir con vosotros la pregunta que lancé como ejemplo: (la solución y explicación está en los comentarios)
QUESTION:
Database is stuck. No more connections are allowed because ofORA-00257: archiver error. Connect internal only, until freed.You check the following:
– db_recovery_file_dest_size is set to 20GB
– db_recovery_file_dest filesystem/folder has 30GB of free space available
– v$flash_recovery_area_usage shows a 99% of occupation.
What would you do first to set the database available with minimum impact as fast as possible?
POSSIBLE ANSWERS:
A:Delete archivelogs from Flash Recovery Area with OS commands becausethat would free the archiver area.
B:Launch an archivelogs backup with RMAN using the “delete input” clause because that would free the archiver area.
C:Change the parameter db_recovery_file_dest_size to 50G.
D: Change the database mode to NOARCHIVELOG, delete archivelogs from Flash Recovery Area and set back the database to ARCHIVELOG mode.
SOLUTION:
C
EXPLANATION:
A is incorrect because Oracle archiver is managed by Flash Recovery Area usage control. Even if the filesystem is completely empty, the database would still consider the occupation is at 99% until the archivelogs are being backed up and deleted with RMAN.
B is incorrect because launching a backup with RMAN takes time. The backup would only delete the files when they’re securely backed up and during this frame of time the database is still stuck and not allowing incoming connections.
D is incorrect because changing the ARCHIVELOG mode of the database implies a shutdown and has a great impact on recovery policies. All current transacions would be lost.
C is correct because it would instantly set the Flash Recovery Area occupation to 40% and the database would get immediately available. The next action to perform is perform an RMAN backup of archivelogs deleting the input as described in answer B.
¡Con esta no habría fallado! Sobre todo por ser un escenario muy muy típico (eso de recibir llamado tras a guardia de madrugada por errores de archivado…)
Hola javier: antes que nada te felicito por el blog y por el libro. Realmente me resulta interesante este esquema de escenarios que planteas es muy productivo (ijala algun dia puedas publicar las 300 preguntas). Bueno yendo al punto de esta pregunta: puede ser que yo tenga como destino de el archivado de mi base una ubicacion en un disco X, y el Flash Recovery Area en otro disco diferente, y que si el % de utilizacion de mi Flash Recovery Area este en un 99% no provoca que la base se detenga solamente que fallen los trabajos de rman, pero sin embargo si el disco que tiene como destino los archive log si se llena, entonces si provocaria la para ad de la base, y usando la opcion A, la base se recuperaria, aunque preferiria la B, para no perder info.
Saludos.
Hola Raul!
Sí! Qué fallo! Debía haber descrito en el escenario un “archive log list” indicando que el destino de los archivados era la FRA. Muy hábil! :)))
Con esta variación, la mejor opción sería la A, como bien planteas, y lanzar un backup de todo cuanto antes (por evitar esperar al backup de archivados).
Es una pena, el proyecto no salió. Como imaginas, cada pregunta implica darle algunas “vueltas de tuerca” y el proyecto no contemplaba el tiempo necesario para hacerlas como debería.
Gracias por tu comentario !! Un abrazo!