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 of
ORA-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 because
that
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.
4 comentarios:
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!
Publicar un comentario