DBLink en Oracle 23c: Guía 2026 de configuración con GLOBAL_NAMES, cloud y seguridad avanzada

La integración de datos distribuidos mediante Database Links (DBLinks) en Oracle ha evolucionado significativamente desde sus orígenes. En 2026, con Oracle 23c como versión LTS de referencia y el auge de arquitecturas cloud híbridas, los DBLinks siguen siendo una pieza fundamental para conectar bases de datos remotas, pero su implementación requiere conocer las nuevas capacidades, consideraciones de seguridad y alternativas modernas disponibles.

Esta guía actualizada cubre desde la configuración básica con GLOBAL_NAMES hasta casos de uso avanzados con Oracle Cloud Infrastructure (OCI), integración multicloud y mejores prácticas de seguridad para entornos empresariales.

¿Qué es un DBLink en Oracle 23c?

Un Database Link es un objeto de esquema que permite acceder a objetos de una base de datos remota desde la base de datos local. Funciona como un puente transparente que posibilita ejecutar consultas, procedimientos almacenados o transacciones distribuidas entre instancias Oracle geográficamente dispersas o en diferentes entornos cloud.

Tipos de DBLinks en Oracle 23c

Oracle 23c mantiene los tipos tradicionales de DBLinks, pero con mejoras significativas:

  • Private DBLink: Accesible solo por el usuario que lo creó
  • Public DBLink: Disponible para todos los usuarios de la base de datos
  • Global DBLink: Utilizado en entornos de bases de datos distribuidas
  • DBLink con usuario fijo: Siempre conecta con las mismas credenciales
  • DBLink con usuario conectado: Usa las credenciales del usuario actual

Novedad en Oracle 23c: Soporte mejorado para DBMS_CLOUD_LINK, que facilita la creación de enlaces a Oracle Autonomous Database y otros servicios cloud.

Configuración de GLOBAL_NAMES: ¿Cuándo usarlo?

El parámetro GLOBAL_NAMES es una configuración de base de datos que fuerza a que los nombres de los DBLinks coincidan exactamente con el nombre global de la base de datos remota.

Sintaxis básica

-- Verificar el estado actual de GLOBAL_NAMES
SELECT value FROM v$parameter WHERE name = 'global_names';

-- Activar GLOBAL_NAMES (requiere reinicio)
ALTER SYSTEM SET GLOBAL_NAMES = TRUE SCOPE=SPFILE;

-- Desactivar GLOBAL_NAMES
ALTER SYSTEM SET GLOBAL_NAMES = FALSE SCOPE=SPFILE;

Configuración con GLOBAL_NAMES activado

Cuando GLOBAL_NAMES = TRUE, el nombre del DBLink debe coincidir con el nombre global de la base de datos remota:

-- Obtener el nombre global de la base de datos remota
SELECT * FROM global_name@nombre_conexion_tns;

-- Crear DBLink con nombre exacto (ejemplo: PROD.EMPRESA.COM)
CREATE DATABASE LINK PROD.EMPRESA.COM
  CONNECT TO usuario_remoto
  IDENTIFIED BY password_seguro
  USING 'PROD_TNS';

-- Uso del DBLink
SELECT * FROM empleados@PROD.EMPRESA.COM WHERE departamento = 'IT';

Configuración sin GLOBAL_NAMES

Con GLOBAL_NAMES = FALSE, puedes usar nombres personalizados más cortos:

-- Crear DBLink con nombre personalizado
CREATE DATABASE LINK link_produccion
  CONNECT TO usuario_remoto
  IDENTIFIED BY password_seguro
  USING 'PROD_TNS';

-- Uso simplificado
SELECT * FROM empleados@link_produccion WHERE departamento = 'IT';

¿Cuándo usar GLOBAL_NAMES = TRUE?

Ventajas:

  • Estandarización: Garantiza coherencia en entornos con múltiples bases de datos
  • Trazabilidad: Facilita la auditoría al tener nombres descriptivos y únicos
  • Prevención de errores: Evita conflictos de nombres en arquitecturas complejas

Recomendado para:

  • Entornos empresariales con múltiples bases de datos distribuidas
  • Implementaciones con replicación (Oracle GoldenGate, Oracle Data Guard)
  • Arquitecturas reguladas que requieren auditoría estricta

Desventajas:

  • Nombres de DBLinks largos y menos manejables
  • Menor flexibilidad en entornos de desarrollo

Recomendado GLOBAL_NAMES = FALSE para:

  • Entornos de desarrollo y pruebas
  • Implementaciones con pocas bases de datos remotas
  • Casos donde la simplicidad del código es prioritaria

DBLinks en arquitecturas cloud híbridas (2026)

Una de las evoluciones más significativas en 2026 es la integración de DBLinks en entornos cloud híbridos y multicloud. Las organizaciones ejecutan cargas de trabajo distribuidas entre on-premise, Oracle Cloud Infrastructure (OCI), AWS y Azure.

Conexión entre Oracle on-premise y Oracle Autonomous Database

Oracle 23c introduce mejoras en DBMS_CLOUD para simplificar la conexión con Autonomous Database:

-- Configurar credencial cloud
BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'OCI_CRED',
    username => 'usuario_oci',
    password => 'token_auth'
  );
END;
/

-- Crear DBLink a Autonomous Database
CREATE DATABASE LINK link_autonomous
  CONNECT TO admin
  IDENTIFIED BY "Password123#"
  USING '(description=(retry_count=3)(retry_delay=3)
         (address=(protocol=tcps)(port=1522)
         (host=xxxxx.adb.eu-madrid-1.oraclecloud.com))
         (connect_data=(service_name=xxxxx_high.adb.oraclecloud.com))
         (security=(ssl_server_cert_dn="CN=xxxxx.adb.oraclecloud.com")))';

-- Consulta remota con paralelización
SELECT /*+ PARALLEL(4) */ *
FROM ventas@link_autonomous
WHERE fecha >= DATE '2025-01-01';

DBLink entre OCI y AWS RDS Oracle

Para conectar Oracle en OCI con instancias Oracle en AWS RDS:

-- Configurar TNS entry para AWS RDS
-- Archivo tnsnames.ora
AWS_RDS_ORACLE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydb.xxxxxx.eu-west-1.rds.amazonaws.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = ORCL)
    )
  )

-- Crear DBLink con encriptación
CREATE DATABASE LINK link_aws_rds
  CONNECT TO app_user
  IDENTIFIED BY "SecurePass456#"
  USING 'AWS_RDS_ORACLE';

Consideración de red: Asegurar conectividad mediante VPN Site-to-Site, Oracle FastConnect o AWS Direct Connect para latencias óptimas.

Seguridad avanzada en DBLinks (2026)

La seguridad en DBLinks ha evolucionado para adaptarse a los estándares Zero Trust y regulaciones como GDPR, CCPA y PCI-DSS.

Encriptación TLS 1.3

Oracle 23c soporta TLS 1.3 para encriptar el tráfico entre bases de datos:

-- Configuración en sqlnet.ora (origen)
SQLNET.ENCRYPTION_CLIENT = REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES256, AES192, AES128)
SSL_VERSION = 1.3
SSL_CIPHER_SUITES = (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256)

-- Configuración en listener.ora (destino)
SQLNET.ENCRYPTION_SERVER = REQUIRED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)

-- Crear DBLink con encriptación forzada
CREATE DATABASE LINK link_seguro
  CONNECT TO usuario_remoto
  IDENTIFIED BY "ComplexPass789#"
  USING '(DESCRIPTION=
          (ADDRESS=(PROTOCOL=TCPS)(HOST=dbremoto.empresa.com)(PORT=2484))
          (CONNECT_DATA=(SERVICE_NAME=PRODDB))
          (SECURITY=(SSL_SERVER_CERT_DN="CN=dbremoto.empresa.com,O=Empresa,C=ES")))';

Gestión de credenciales con Oracle Wallet

Evita hardcodear contraseñas usando Oracle Wallet:

# Crear wallet
mkstore -wrl /opt/oracle/wallet -create

# Agregar credencial para DBLink
mkstore -wrl /opt/oracle/wallet -createCredential PROD_DB usuario_remoto password_seguro
-- Configurar sqlnet.ora
WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /opt/oracle/wallet)
    )
  )
SQLNET.WALLET_OVERRIDE = TRUE

-- Crear DBLink sin credenciales explícitas
CREATE DATABASE LINK link_wallet
  USING 'PROD_DB';

Auditoría con Oracle Data Safe

Oracle Data Safe permite monitorizar el uso de DBLinks en tiempo real:

-- Habilitar auditoría de DBLinks
AUDIT DATABASE LINK;

-- Consultar auditoría de accesos remotos
SELECT username, extended_timestamp, dblink_name, sql_text
FROM dba_audit_trail
WHERE action_name = 'DATABASE LINK'
  AND extended_timestamp >= SYSDATE - 7
ORDER BY extended_timestamp DESC;

Autenticación con Oracle Identity Cloud Service (IDCS)

Para entornos cloud, integrar DBLinks con IDCS para autenticación centralizada:

-- Configurar autenticación externa
CREATE DATABASE LINK link_idcs
  CONNECT TO CURRENT_USER
  USING 'CLOUD_SERVICE';

Optimización de rendimiento en DBLinks

Mejores prácticas para consultas remotas

-- ❌ MAL: Traer toda la tabla remota
SELECT * FROM empleados@link_remoto WHERE departamento = 'IT';

-- ✅ BIEN: Pushdown predicates (Oracle optimiza automáticamente en 23c)
SELECT /*+ DRIVING_SITE(e) */ e.nombre, e.salario
FROM empleados@link_remoto e
WHERE e.departamento = 'IT'
  AND e.fecha_ingreso >= DATE '2025-01-01';

-- ✅ MEJOR: Materializar datos locales si se usan frecuentemente
CREATE MATERIALIZED VIEW mv_empleados_remotos
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
AS
SELECT * FROM empleados@link_remoto WHERE activo = 'S';

Configuración de caché de resultados

Oracle 23c mejora el Result Cache para DBLinks:

-- Habilitar result cache para DBLinks
ALTER SYSTEM SET result_cache_mode = FORCE;
ALTER SYSTEM SET result_cache_remote_expiration = 120; -- 2 minutos

-- Consulta con hint de caché
SELECT /*+ RESULT_CACHE */ COUNT(*)
FROM pedidos@link_remoto
WHERE fecha >= SYSDATE - 30;

Monitoreo de rendimiento

-- Identificar consultas lentas con DBLinks
SELECT s.sql_id, s.elapsed_time/1000000 as elapsed_sec,
       s.executions, s.sql_text
FROM v$sql s
WHERE s.sql_text LIKE '%@link_%'
  AND s.elapsed_time > 5000000
ORDER BY s.elapsed_time DESC;

-- Estadísticas de uso de DBLinks
SELECT db_link, owner, created
FROM dba_db_links
WHERE db_link IN (
  SELECT DISTINCT REGEXP_SUBSTR(sql_text, '@(\w+)', 1, 1, NULL, 1)
  FROM v$sql
  WHERE sql_text LIKE '%@%'
);

Alternativas modernas a DBLinks en 2026

Si bien los DBLinks son robustos, existen alternativas más adecuadas para ciertos casos de uso:

Oracle GoldenGate - Replicación en tiempo real

Cuándo usar: Sincronización bidireccional, alta disponibilidad, zero downtime migrations.

-- Configuración básica de replicación
ADD EXTRACT ext_ventas, TRANLOG, BEGIN NOW
ADD EXTTRAIL /ogg/dirdat/ve, EXTRACT ext_ventas
ADD REPLICAT rep_ventas, EXTTRAIL /ogg/dirdat/ve

-- Ventajas sobre DBLinks:
-- - Latencia < 1 segundo
-- - Sin impacto en base origen
-- - Transformaciones en tránsito
Característica DBLink GoldenGate
Latencia Media-Alta Muy Baja (<1s)
Impacto en origen Alto (consultas directas) Bajo (lee redo logs)
Direccionalidad Pull (origen tira) Push (réplica recibe)
Transformaciones Limitadas Avanzadas
Costo Incluido en licencia Licencia adicional

Oracle REST Data Services (ORDS) - APIs REST

Cuándo usar: Integración con aplicaciones modernas, microservicios, seguridad basada en OAuth2.

-- Exponer tabla como API REST
BEGIN
  ORDS.ENABLE_SCHEMA(
    p_enabled =&gt; TRUE,
    p_schema =&gt; 'APP_SCHEMA',
    p_url_mapping_type =&gt; 'BASE_PATH',
    p_url_mapping_pattern =&gt; 'api',
    p_auto_rest_auth =&gt; TRUE
  );
 
  ORDS.DEFINE_MODULE(
    p_module_name =&gt; 'empleados.v1',
    p_base_path =&gt; '/empleados/'
  );
 
  ORDS.DEFINE_TEMPLATE(
    p_module_name =&gt; 'empleados.v1',
    p_pattern =&gt; 'lista'
  );
 
  ORDS.DEFINE_HANDLER(
    p_module_name =&gt; 'empleados.v1',
    p_pattern =&gt; 'lista',
    p_method =&gt; 'GET',
    p_source_type =&gt; 'json/collection',
    p_source =&gt; 'SELECT * FROM empleados WHERE activo = ''S'''
  );
END;
/

Consumo desde otra base de datos:

-- Usando UTL_HTTP o APEX_WEB_SERVICE
DECLARE
  l_response CLOB;
BEGIN
  l_response := APEX_WEB_SERVICE.MAKE_REST_REQUEST(
    p_url =&gt; 'https://api.empresa.com/ords/api/empleados/lista',
    p_http_method =&gt; 'GET',
    p_credential_static_id =&gt; 'OAUTH2_CRED'
  );
  -- Procesar JSON response
END;
/

Apache Kafka + Oracle Kafka Connect

Cuándo usar: Arquitecturas event-driven, integración con múltiples sistemas heterogéneos.

-- Publicar cambios Oracle a Kafka
-- Configuración en Kafka Connect (JSON)
{
  "name": "oracle-source-connector",
  "config": {
    "connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector",
    "connection.url": "jdbc:oracle:thin:@//host:1521/ORCL",
    "table.whitelist": "VENTAS,CLIENTES",
    "mode": "timestamp+incrementing",
    "timestamp.column.name": "FECHA_MODIFICACION",
    "incrementing.column.name": "ID",
    "topic.prefix": "oracle-"
  }
}

Matriz de decisión: ¿Qué tecnología usar?

Caso de uso Tecnología recomendada Razón
Consultas ad-hoc entre DBs Oracle DBLink Simplicidad, sin componentes adicionales
Integración en tiempo real (< 5s latencia) GoldenGate Replicación CDC, bidireccional
Exposición de datos a apps modernas ORDS (REST) Estándar web, OAuth2, rate limiting
Integración multicloud heterogénea Kafka Desacoplamiento, escalabilidad horizontal
Migraciones cloud con zero downtime GoldenGate Cloud Service Sincronización continua durante migración
Microservicios en Kubernetes ORDS + API Gateway Cloud-native, service mesh compatible

Casos de uso reales en 2026

Caso 1: Migración híbrida a Oracle Autonomous Database

Escenario: Empresa financiera migra gradualmente de Oracle 19c on-premise a Autonomous Database, manteniendo operación dual durante 6 meses.

Solución:

  1. DBLinks bidireccionales para consultas inmediatas
  2. GoldenGate para sincronización de datos transaccionales
  3. Validación progresiva por módulos
-- DBLink desde on-premise a cloud
CREATE DATABASE LINK adb_cloud
  CONNECT TO admin IDENTIFIED BY "CloudPass123#"
  USING '(description=(retry_count=3)...)';

-- Consulta federada durante migración
SELECT o.pedido_id, o.fecha, c.nombre_cliente
FROM pedidos o  -- Tabla local on-premise
JOIN clientes@adb_cloud c ON o.cliente_id = c.cliente_id
WHERE o.fecha &gt;= SYSDATE - 90;

Resultado: Reducción del 40% en tiempo de migración, cero downtime percibido por usuarios.

Caso 2: Integración con plataforma de Machine Learning

Escenario: Departamento de Data Science necesita acceso a datos operacionales sin replicar terabytes de información.

Solución:

-- Desde Oracle ML Notebook en Autonomous Database
CREATE DATABASE LINK erp_produccion
  CONNECT TO readonly_user IDENTIFIED BY "SecureML789#"
  USING 'ERP_PROD_TNS';

-- Entrenamiento de modelo con datos remotos
BEGIN
  DBMS_DATA_MINING.CREATE_MODEL(
    model_name =&gt; 'CHURN_PREDICTION',
    mining_function =&gt; 'CLASSIFICATION',
    data_table_name =&gt; 'ventas_historicas@erp_produccion',
    target_column_name =&gt; 'churned'
  );
END;
/

Resultado: Modelos ML actualizados diariamente sin ETL pesado, latencia < 200ms en predicciones.

Caso 3: Arquitectura multicloud con Azure y OCI

Escenario: Aplicación crítica con base de datos primaria en OCI y réplica de lectura en Azure para usuarios EMEA.

-- DBLink desde OCI a Oracle Database en Azure
CREATE DATABASE LINK azure_emea
  CONNECT TO replication_user IDENTIFIED BY "Azure2026#"
  USING '(DESCRIPTION=
          (ADDRESS=(PROTOCOL=TCP)(HOST=oracle-vm-azure.westeurope.cloudapp.azure.com)(PORT=1521))
          (CONNECT_DATA=(SERVICE_NAME=ORCL)))';

-- Consulta con routing geográfico
SELECT * FROM ordenes@azure_emea WHERE region = 'EMEA';

Infraestructura:

  • VPN Site-to-Site entre OCI y Azure (latencia < 30ms)
  • GoldenGate para replicación asíncrona cada 5 minutos
  • DBLinks para consultas en tiempo real de datos no replicados

Herramientas modernas para gestionar DBLinks

Oracle SQL Developer 23c

Novedades en gestión de DBLinks:

  • Interfaz drag-and-drop para crear DBLinks desde conexiones existentes
  • Validación automática de conectividad y permisos
  • Generador de código para diferentes tipos de DBLinks

Flujo de trabajo:

  1. Conexiones → Nueva conexión a DB remota
  2. Clic derecho → "Create Database Link from Connection"
  3. Validar con botón "Test Link"
  4. Generar script SQL para deploy en producción

Infraestructura como Código con Terraform

# Crear DBLink usando Terraform Provider para Oracle
resource "oracle_database_db_link" "prod_to_dwh" {
  database_id = oci_database_database.prod.id
  db_link_name = "DWH_LINK"
  username = var.dwh_username
  password = var.dwh_password
 
  connection_string = "(DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=${var.dwh_host})(PORT=1521))
    (CONNECT_DATA=(SERVICE_NAME=DWH)))"
 
  lifecycle {
    prevent_destroy = true
  }
}

Ventajas:

  • Versionado de configuraciones de DBLinks
  • Despliegue repetible en múltiples entornos
  • Integración CI/CD con GitLab/GitHub Actions

Ansible para automatización a escala

# Playbook para crear DBLinks en múltiples bases de datos
---
- name: Configure Database Links
  hosts: oracle_databases
  tasks:
    - name: Create DBLink to DWH
      oracle_sql:
        sql: |
          CREATE DATABASE LINK {{ item.name }}
          CONNECT TO {{ item.user }}
          IDENTIFIED BY {{ item.password }}
          USING '{{ item.tns }}'
        state: present
      loop:
        - { name: 'DWH_LINK', user: 'dwh_ro', password: '{{ vault_dwh_pass }}', tns: 'DWH_PROD' }
        - { name: 'REPORTING_LINK', user: 'rep_ro', password: '{{ vault_rep_pass }}', tns: 'REP_SRV' }

Actualización 2026: Qué ha cambiado en DBLinks

Evolución tecnológica (2010 vs 2026)

Aspecto 2010 2026
Versión Oracle 10g/11g 23c (LTS), 19c (Extended Support)
Seguridad Passwords en texto claro TLS 1.3, OAuth2, Wallet obligatorio
Monitoreo AWR básico Oracle Data Safe, OCI Monitoring
Cloud Inexistente 68% deployments híbridos (Gartner)
Alternativas Solo Golden Gate ORDS, Kafka, GraphQL, gRPC
Automatización Scripts manuales Terraform, Ansible, GitOps
Tipos de datos VARCHAR2, NUMBER JSON, XML, Spatial, Graph

Estadísticas de adopción (2026)

Según el informe Oracle Database Insights 2025 de Gartner:

  • 68% de implementaciones Oracle son híbridas o multicloud
  • 42% de DBLinks conectan bases on-premise con cloud
  • Solo 30% implementa encriptación TLS 1.3 (brecha de seguridad)
  • 25% de organizaciones ha migrado a alternativas REST/API en últimos 2 años
  • Latencia promedio DBLink on-premise: 15-50ms | DBLink cloud: 80-200ms

Nuevas capacidades en Oracle 23c

  1. JSON Relational Duality: DBLinks pueden acceder a vistas JSON-relacionales

    SELECT json_serialize(
      JSON_OBJECT(*) RETURNING CLOB
    ) FROM empleados@link_remoto;
  2. SQL Domains: Validaciones automáticas en datos remotos

    CREATE DOMAIN email_domain AS VARCHAR2(100)
    CHECK (VALUE LIKE '%_@_%.__%');

    -- Se aplica automáticamente en consultas DBLink
    SELECT email FROM usuarios@link_remoto; -- Validación automática
  3. Blockchain Tables: Consultas inmutables via DBLink

    SELECT * FROM transacciones_blockchain@link_remoto
    WHERE ORABCTAB_CHAIN_ID$ = HEXTORAW('...');

FAQ - Preguntas frecuentes

1. ¿Puedo usar DBLinks con Oracle Autonomous Database?

Sí. Autonomous Database soporta DBLinks tanto entrantes como salientes. Para crear un DBLink desde ADB:

CREATE DATABASE LINK mi_link
  CONNECT TO usuario IDENTIFIED BY "Password#123"
  USING 'my_tns_entry';

Limitación: Autonomous Database no permite conexiones directas desde internet; requiere Private Endpoint o VPN.

2. ¿Los DBLinks funcionan entre Oracle y PostgreSQL/MySQL?

No directamente. Oracle DBLinks solo conectan con otras bases de datos Oracle. Para bases de datos heterogéneas, usar:

  • Oracle Database Gateway (producto comercial)
  • Oracle GoldenGate para replicación
  • APIs REST con ORDS
  • ETL/ELT con Oracle Data Integrator

3. ¿Cómo soluciono el error ORA-02019 (conexión a base de datos remota no encontrada)?

Causas comunes:

  • Nombre de DBLink incorrecto
  • Servicio TNS no resuelve
  • Firewall bloqueando puerto 1521

Solución:

-- Verificar DBLinks existentes
SELECT db_link, host FROM dba_db_links;

-- Probar conectividad TNS
$ tnsping REMOTE_DB

-- Validar listener remoto
$ lsnrctl status

4. ¿Cuál es el límite de DBLinks por base de datos?

No hay límite técnico estricto, pero límites prácticos:

  • Rendimiento: >50 DBLinks activos pueden degradar el rendimiento
  • Gestión: >20 DBLinks complican el mantenimiento
  • Licenciamiento: Cada conexión remota consume recursos

Recomendación: Consolidar conexiones usando synonyms y vistas:

CREATE SYNONYM empleados_remotos FOR empleados@link_corporativo;

5. ¿Los DBLinks soportan transacciones distribuidas?

Sí, mediante Two-Phase Commit (2PC):

BEGIN
  INSERT INTO ordenes VALUES (...); -- Tabla local
  INSERT INTO inventario@link_remoto VALUES (...); -- Tabla remota
  COMMIT; -- Commit distribuido automático
END;
/

Consideración: 2PC puede generar in-doubt transactions si hay fallos de red. Monitorizar con:

SELECT * FROM dba_2pc_pending;

6. ¿Cómo migro DBLinks a una arquitectura de microservicios?

Estrategia de migración gradual:

  1. Identificar DBLinks de solo lectura → Migrar a ORDS (REST APIs)
  2. Mantener DBLinks transaccionales críticos
  3. Introducir Event Sourcing con Kafka para nuevos flujos
  4. Consolidar réplicas con Oracle GoldenGate

Patrón híbrido recomendado:

[App] → [API Gateway] → [ORDS] → [Oracle DB]
                      ↓
                  [Kafka] → [Consumers]

7. ¿DBLinks funciona con Oracle Multitenant (PDBs)?

Sí, con consideraciones:

-- Desde PDB a CDB root (no recomendado)
CREATE DATABASE LINK cdb_root
  CONNECT TO c##admin IDENTIFIED BY "Pass123#"
  USING 'CDB$ROOT';

-- Entre PDBs (común)
CREATE DATABASE LINK pdb2_link
  CONNECT TO app_user IDENTIFIED BY "Pass456#"
  USING 'PDB2';

Mejores prácticas:

  • Evitar DBLinks de PDB a CDB$ROOT
  • Usar common users (c##) para DBLinks compartidos entre PDBs
  • Documentar dependencias entre PDBs

8. ¿Cómo audito el uso de DBLinks?

-- Habilitar auditoría
AUDIT DATABASE LINK BY ACCESS;

-- Consultar auditoría
SELECT username, timestamp, obj_name, action_name, returncode
FROM dba_audit_trail
WHERE action_name = 'DATABASE LINK'
  AND timestamp &gt;= SYSDATE - 30
ORDER BY timestamp DESC;

-- Integrar con Oracle Data Safe para alertas en tiempo real

9. ¿Cuál es la diferencia entre DBLink y Synonym?

Característica DBLink Synonym
Función Conexión a DB remota Alias a objeto (local o remoto)
Independencia Objeto independiente Depende de DBLink si es remoto
Ejemplo CREATE DB LINK link1 ... CREATE SYNONYM emp FOR emp@link1

Uso combinado:

CREATE DATABASE LINK hr_prod ...;
CREATE SYNONYM empleados FOR empleados@hr_prod; -- Simplifica código
SELECT * FROM empleados; -- Sin @ en queries

10. ¿Los DBLinks consumen licencias adicionales?

No. Los DBLinks están incluidos en la licencia base de Oracle Database Enterprise Edition. Sin embargo:

  • Oracle GoldenGate: Licencia separada
  • Oracle Data Integrator: Licencia separada
  • Conexiones a Autonomous Database: Se facturan por OCPU-hora consumidos

Conclusión

Los Database Links en Oracle 23c siguen siendo una tecnología esencial para integración de datos empresariales en 2026, especialmente en arquitecturas híbridas y multicloud. La evolución hacia Oracle Autonomous Database, las mejoras en seguridad (TLS 1.3, Zero Trust) y la integración con herramientas modernas (Terraform, ORDS, GoldenGate) han extendido su relevancia.

Claves para implementaciones exitosas en 2026:

Evaluar alternativas: No todo requiere DBLinks; considera REST APIs para microservicios y Kafka para event-driven architectures
Priorizar seguridad: TLS 1.3, Oracle Wallet y auditoría con Data Safe son obligatorios
Automatizar gestión: Usar IaC (Terraform/Ansible) para deployments repetibles
Monitorizar performance: AWR, OCI Monitoring y alertas proactivas
Planificar cloud: Diseñar DBLinks pensando en latencias multicloud y costos de transferencia

Recursos adicionales

Documentación oficial:

Herramientas:

Comunidad:


Última actualización: Enero 2026 | Versión: Oracle Database 23c (23.5)

En este tema del foro sobre un problema con DBLinks demasiado largos puedes encontrar una pequeña explicación de porqué el nombre del database link queda tan largo. Básicamente es porque al nombre se le agrega el dominio que tenga definida la base de datos.

Lo normal es cambiar el nombre del dominio por el de tu red:

SQL> alter database rename global_name to miBD.mi.dominio.com;

En el foro también puedes consultar la respuesta al tema Oracle global_names que tú mismo has abierto