Oracle Error Troubleshooting (11g r2 tested) – part 01

/, Oracle Troubleshooting, RMAN, Uncategorized/Oracle Error Troubleshooting (11g r2 tested) – part 01

Oracle Error Troubleshooting (11g r2 tested) – part 01

Continuamos con la seria de posts sobre: Oracle  Error Troubleshooting, y como solucionarlos:

02 – https://itegram.com/2017/01/30/oracle-troubleshooting-11g-r2-tested-part-02/

03 – https://itegram.com/2017/01/30/oracle-troubleshooting-11g-r2-tested-part-03/

04 – http://itegram.com/2017/03/10/oracle-troubleshooting-11g-r2-tested-part-04/

05 – http://itegram.com/2017/04/27/oracle-error-troubleshooting-11g-r2-tested-part-05/

06 – http://itegram.com/2017/04/29/oracle-error-troubleshooting-11g-r2-tested-part-06/

07 – http://itegram.com/2017/04/29/oracle-error-troubleshooting-11g-r2-tested-part-07/

08 – http://itegram.com/2017/04/29/oracle-error-troubleshooting-11g-r2-tested-part-08/

Y links a diversos posts sobre Oracle:

https://itegram.wordpress.com/2017/01/13/indice-posts-sobre-oracle/

Errores encontrados en este documento

ORA-39002 , ORA-06512 while importing

RMAN-06207, RMAN-06208

Gap en secuencia de archivelogs – oracle replica manual (standby)

 

ORA-39002 , ORA-06512 while importing

Durante la instalacion, configuré que el directorio donde se vuelca el EXPORT de la base sea /o1/backups/export

Cuando hice el import con el parámetro directory=EXPORT, me dió el siguiente error:

 

DATA_PUMP_DIR

/o/app/oracle/admin/UAACLDB/dpdump/

Y yo le había puesto que sea el EXPORT (/o1/backups/export)


RMAN-06207, RMAN-06208

Cuando miramos el log de nuestro script de limpieza de logs (/o/app/oracle/scripts/bk-clean.log) , o cuando borramos backups obsoletos, podemos ver esos dos errores:

SOLUCIÓN:

Según la política de nuestro backup, puede ser que pasen a estar obsoletos y limpiados por oracle mismo.

Intento 1) Asi que el primer paso es esperar y ver si se borraron o no.

Intento 2)

Si en el próximo backup no se borran:

ó

Podemos hacer crosscheck de un archivo en particular


Gap en secuencia de archivelogs – oracle replica manual (standby)

Si encontramos un gap en la secuencia de los archivelogs, no podremos aplicar el recover de la base standby.

En producción deberemos recuperar el archivelog faltante.

  • Si no fue borrado, copiarlo directamente a nivel de S.O (con scp  o ftp por ejemplo)
  • Si fue borrado, recuperarlo de backup.

Si el archivelog se perdió porque fue borrado el backup que lo contenía, deberemos realizar el proceso de réplica completo nuevamente.

(Antes probar con el backup incremental, siguiendo este tutorial: https://taliphakanozturken.wordpress.com/2012/04/11/how-to-resolve-primarystandby-log-gap-in-case-of-deleting-archivelogs-from-primary/)

  1. Recuperacion de archivo desde bk, en servidor de producción

Si no funciona, probar con:

Si necesitamos recuperar mas archivos, cambiamos el numero del until hasta la secueancia que queramos.

  1.  Luego de realizar este recupero del archivelog (supongamos que es el de secuencia 701 solamente), lo copiamos dentro del directorio donde están los archivelogs.

En produccion deberemos hacer algo como :

3.  Hacemos el recover en la replica o standby

By |2017-04-30T00:17:24+00:00enero 16th, 2017|Categories: Oracle, Oracle Troubleshooting, RMAN, Uncategorized|Tags: |5 Comments

About the Author:

5 Comments

  1. Image edit julio 25, 2018 at 3:40 am - Reply

    fantastic post, very informative. I’m wondering why the
    other experts of this sector do not notice this.
    You should continue your writing. I am sure, you’ve a great readers’ base already!

  2. […] Parte 01 – https://itegram.wordpress.com/2017/01/16/oracle-troubleshooting-11g-r2-tested-part-01/ […]

  3. […] Parte 01 – https://itegram.wordpress.com/2017/01/16/oracle-troubleshooting-11g-r2-tested-part-01/ […]

  4. […] Parte 01 – https://itegram.wordpress.com/2017/01/16/oracle-troubleshooting-11g-r2-tested-part-01/ […]

Leave A Comment