La carga de datos en entornos Db2 con HADR requiere algunas consideraciones a tener en cuenta. El funcionamiento de la replicación con HADR está basado en el uso de los logs para replicar datos de la base de datos principal a la base de datos standby.
Las operaciones que no se registran en el log están permitidas en la base de datos primary, pero no se replican en la base de datos en standby. Es por eso que hay que tener especial cuidado con realizar acciones sin log, ya que puede causar que la replicación HADR se rompa y la información en las instancias de standby quede inaccesible o corrupta.
Una buena práctica para evitar que esto ocurra es modificar el parámetro de configuración a nivel de base de datos BLOCKNONLOGGED a YES. De esta forma, si se intenta realizar alguna acción sin log (como una load NONRECOVERABLE o con COPY NO), está fallará y no tendremos problemas con el HADR.
Comportamientos de la LOAD
En lo que respecta a la LOAD, podemos decir que se comporta de manera diferente en función de estas 3 opciones:
| Opción de LOAD | Genera Backup | Estado del tablespace después de la LOAD | Comentarios | Estado en la instancia de standby |
| COPY NO | NO | Backup pending | Necesita realizar backup para que esté accesible | La tabla no está accesible (SQL1477N) |
| COPY YES | SI | Normal | Asegúrate de que el backup está disponible durante el rollforward, de lo contrario el tablespace quedará restore pending | La instancia de standby debe poder acceder a este backup. Si no puede acceder a él, el tablespace quedará restore pending |
| NONRECOVERABLE | SI | Normal | Después del rollforward, no se puede acceder a la tabla (SQL1477N) | La tabla no está accesible (SQL1477N) |
¿Cómo hacer una LOAD en un entorno con HADR?
Solución 1
La solución fácil seria reinicializar los servidores standby de HADR restaurando un backup completo de la base de datos, una vez haya finalizado la LOAD.
A continuación se muestra la secuencia de pasos que se pueden seguir para reinicializar el HADR:
- Parar el HADR, tanto en el nodo primary como en el/los standby.
- Realizar la operación LOAD en las tablas de la base de datos primaria HADR.
- Realizar un backup online de la base de datos primaria.
- Enviar el backup al nodo/nodos standby y restaurarlo allí
- Arrancar el HADR en las bases de datos standby y posteriormente en la primary.
Solución 2
Probablemente la solución más utilizada para replicar las LOAD entre los servidores primario y de standby y en la que durante menos tiempo tendremos la tabla no disponible en el nodo/nodos standby.
Para esta solución, es necesario disponer de un sistema de archivos compartido o NFS (sistema de archivos de red) entre los servidores primario y de standby.
La idea es que todas las instancias que pertenecen al entorno con HADR tienen que poder acceder al backup que haga la LOAD en el nodo primario.
La LOAD se realizará con la opción COPY YES indicando la ruta del NFS compartido. A continuación podemos ver un ejemplo:
LOAD FROM /data/file.ixf OF IXF INTO schema.table COPY YES NONRECOVERABLE;
LOAD FROM /data/file.ixf OF IXF
INSERT INTO schema.table
COPY YES TO /shared_nfs/backupCuando la carga en el nodo primary termine, se generará un backup en la ruta en la que le hemos indicado.
Siempre que ese punto de montaje NFS tenga el mismo nombre y el propietario de la instancia Db2 tenga acceso a él, el Db2 leerá ese archivo en el nodo o nodos de standby y cargará los datos en esa base de datos.
Se puede verificar que ha funcionado consultando el db2diag en los nodos standby. Debería verse algo similar a esto:
2025-12-26-16.33.55.744401+060 I5856991E473 LEVEL: Warning
PID : 16228 TID : 47032572045632PROC : db2sysc
INSTANCE: db2inst1 NODE : 000 DB : DBNAME
APPHDL : 0-24769 APPID: *LOCAL.DB2.251209225426
EDUID : 121 EDUNAME: db2agent (DBNAME)
FUNCTION: DB2 UDB, database utilities, sqludcpy, probe:553
DATA #1 : String, 68 bytes
Starting to restore a load copy.
SCHEMA.TABNAME.20251226163341
.....
2025-12-26-16.35.47.671101+060 I5857465E430 LEVEL: Warning
PID : 16228 TID : 47032572045632PROC : db2sysc
INSTANCE: db2inst1 NODE : 000 DB : DBNAME
APPHDL : 0-24769 APPID: *LOCAL.DB2.251209225426
EDUID : 121 EDUNAME: db2agent (DBNAME)
FUNCTION: DB2 UDB, database utilities, sqludcpy, probe:1136
MESSAGE : Load copy restore completed successfully.