Resolving Archive Gap – Detection and Resolution

DATAGUARD NOT APPLIED

Cuando trabajamos con un sitio de contingencia, tenemos que estar atentos a que en el site donde radica la base stanby se esten aplicando los logs.

Para ello podemos tener algunas herramientas desde el grid control cuando tenemos el broker configurado, donde podemos monitorear varias cosas como si hay logs encolados o si hay gaps. Tambien si nos esta faltando un archive.

Como podemos ver en este caso que ponemos de ejemplo, no se estan aplicando los logs.

Desde la linea de comandos del servidor o mediante algun cliente me logueo y tiro la siguiente query:

set line 150 
col NAME format a60 
select
 NAME,
 THREAD#,
 SEQUENCE#,
 APPLIED,
 registrar 
from v$archived_log where APPLIED='NO' order by sequence#;

Por lo que podemos observar nos devuelve logs sin aplicar.

set line 150 
col NAME format a60 
select NAME, THREAD#, SEQUENCE#, APPLIED, registrar 
from v$archived_log where APPLIED='NO' order by sequence#;  

NAME                                    THR# SEQUEN APP REG
---------------------------------------------------------------- ---- ------ --- ---

+JP_DG2/JP/archivelog/2010_04_08/thread_2_seq_1785.1680.715777227   2 1785 NO RFS
+JP_DG2/JP/archivelog/2010_04_08/thread_2_seq_1786.2313.715777322   2 1786 NO RFS
+JP_DG2/JP/archivelog/2010_04_08/thread_2_seq_1787.2459.715777120   2 1787 NO RFS
+JP_DG2/JP/archivelog/2010_04_08/thread_2_seq_1788.2588.715777831   2 1788 NO RFS

Es importante tener en cuenta los siguientes puntos para comenzar a indagar por que no se estan aplicando:

• El modo recovery no este activo.
• El parametro broker esta en false.
• Problemas en la red que puedan generar GAPs.

Nuestro articulo de hoy se baso en problemas de red , que ocasionaron GAPs.

Vamos a ver de que se trata esto.

Como el EM me avisa que estoy teniendo logs sin aplicar, y que estan faltando otros, me logueo por consola y compruebo lo dicho, estan faltando archives y tenemos un GAP.

SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
-----------  -------------  --------------
          2           1785            1785

Teniendo el numero de la secuencia, en este caso la SEQ 1785 THREAD 2, consulto si existe este archivo en el storage del dataguard.

SQL> set line 150
SQL> col NAME format a80
SQL> select NAME, THREAD#, SEQUENCE#, APPLIED, registrar 
from v$archived_log 
where SEQUENCE#='1785' and THREAD#='2' order by sequence#;  2  

NAME                    THREAD#  SEQUENCE# APP REGISTR
---------------------------------- ---------- ---------- --- -------
                              2       1785  NO  SRMN

Busco en el sitio primario, y efectivamente la pieza faltante se encuentra donde deberia estar.

SQL> select NAME, THREAD#, SEQUENCE#, APPLIED, registrar 
from v$archived_log 
where SEQUENCE#='1785' and THREAD#='2' order by sequence#;  2  3

NAME                               THR#  SEQ#    APP REGISTR
---------------------------------------------------- ------- ------- --- -------
+JP_DG2/JP/archivelog/2010_04_08
/thread_2_seq_1785.2588.715777831                          2   1785  YES  SRMN

Moviendo Objetos de ASM a Filesystem y viceversa

Como hacemos para llevar esa pieza del sitio primario al secundario. Si tenemos la base en un filesystem comun y corriente lo copiamos con un scp de un equipo a otro y bastaria. Pero como estamos trabajando con ASM, vamos a tener que emplear los recursos de RMAN.

1. Sacamos con RMAN la pieza necesaria, poniendo en el format el path donde queremos llevar la pieza correspondiente mas algún wildcard (Esto último se lo dejo a criterio de cada usuario):

RMAN> backup format '/u03/rman_database_backup/thread_2_seq1785_%s_%p.logs' archivelog sequence 1785 thread 2;

Starting backup at 08-APR-10
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting compressed archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=2 sequence=1785 recid=1261 stamp=715610322
channel ORA_DISK_1: starting piece 1 at 08-APR-10
channel ORA_DISK_1: finished piece 1 at 08-APR-10
piece handle=/u03/rman_database_backup/thread_2_seq1785_525_1.logs tag=TAG20100408T105951 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04
Finished backup at 08-APR-10

Otra situacion seria si tenemos un grupo de logs, por ejemplo del 33045 al 33059 del thread 2.

RMAN> BACKUP ARCHIVELOG  FROM SEQUENCE 33045 UNTIL SEQUENCE 33059 THREAD 2;

Lo pasamos del sitio primario al secundario via scp u otro mecanismo.

Teniendo la pieza la catalogamos con el RMAN.

RMAN> catalog backuppiece '/u03/rman_database_backup/thread_2_seq1785_525_1.logs';

using target database control file instead of recovery catalog
cataloged backuppiece
backup piece handle=/u03/rman_database_backup/thread_2_seq1785_525_1.logs recid=439 stamp=715777801

Restoreamos el archive que necesitamos.

RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 1785 THREAD 2;

Starting restore at 08-APR-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=307 instance=JPDG1 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=287 instance=JPDG1 devtype=DISK

archive log thread 2 sequence 1786 is already on disk as file
+JPDG_DG2/JP/archivelog/2010_04_06/thread_2_seq_1786.3764.715610751
archive log thread 2 sequence 1787 is already on disk as file
+JPDG_DG2/JP/archivelog/2010_04_06/thread_2_seq_1787.2909.715610787
archive log thread 2 sequence 1788 is already on disk as file
+JPDG_DG2/JP/archivelog/2010_04_06/thread_2_seq_1788.2125.715610813
archive log thread 2 sequence 1789 is already on disk as file
+JPDG_DG2/JP/archivelog/2010_04_06/thread_2_seq_1789.2620.715610849
archive log thread 2 sequence 1790 is already on disk as file
+JPDG_DG2/JP/archivelog/2010_04_06/thread_2_seq_1790.636.715643317
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=2 sequence=1785
channel ORA_DISK_1: reading from backup piece
/u03/rman_database_backup/thread_2_seq1785_525_1.logs
channel ORA_DISK_1: restored backup piece 1
piece handle=/u03/rman_database_backup/thread_2_seq1785_525_1.logs tag=TAG20100408T105951
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
Finished restore at 08-APR-10

RMAN>

Debemos recordar que al buscar la pieza dentro del ASM el rman la restorea al dia de la fecha y si no ponemos la sentencia de destino, la incorporara al path del dia de hoy.

Lo vemos con mas detalle ingresando al ASM y verificando que el log exista en el filesystem.

ASMCMD> cd 2010_04_08/
ASMCMD> ls
thread_1_seq_1864.791.715755691
thread_1_seq_1865.3747.715772623
thread_1_seq_1866.3007.715774079
thread_1_seq_1867.3722.715774109
thread_1_seq_1868.2712.715774259
thread_1_seq_1869.3680.715774289
thread_1_seq_1870.645.715774325
thread_1_seq_1871.3511.715774353
thread_1_seq_1872.974.715774407
thread_1_seq_1873.3343.715774433
thread_1_seq_1874.2724.715774565
thread_1_seq_1875.628.715774643
thread_2_seq_1785.2588.715777831
thread_2_seq_1813.2260.715772625

Al encontrarse el archive restoreado donde corresponde, procedemos a detener el recovery y a registrar la pieza.

ALTER DATABASE REGISTER LOGFILE 'PATH/FILE.logs';

Es importante saber que si tenemos el configurado dataguard broker, este trabajo lo hace de manera automatica, y que al intentar registrar el REDO faltante no arrojara el error ORA-16089:

SQL> ALTER DATABASE REGISTER LOGFILE '+JPDG_DG2/JP/ARCHIVELOG/2010_04_08/thread_2_seq_1785.2588.715777831'; 2ALTER DATABASE REGISTER LOGFILE '+JPDG_DG2/JP/ARCHIVELOG/2010_04_08/thread_2_seq_1785.2588.715777831'
*
ERROR at line 1:
ORA-16089: archive log has already been registered

Una vez que comienza el aplicado de logs podemos verlo el alert.log de la base.

Tiramos la consulta para ver si comenzo el aplicación, esto decrementaria la cantidad de logs encolados.

También verificamos que el GAP desaparecio.

SQL> select * from v$archive_gap;
no rows selected