utilizar una transacciones tablas seleccionados remotas pueden ora manejo los localizadores las hacer distribuidas distribuida diseƱo datos como sql oracle distributed-transactions dblink

sql - una - ora 22992



La mejor forma de manejar LOB en bases de datos distribuidas de Oracle (6)

Si crea un Oracle dblink, no puede acceder directamente a las columnas LOB en las tablas de destino.

Por ejemplo, crea un dblink con:

create database link TEST_LINK connect to TARGETUSER IDENTIFIED BY password using ''DATABASESID'';

Después de esto, puedes hacer cosas como estas:

select column_a, column_b from data_user.sample_table@TEST_LINK

Excepto si la columna es un LOB, entonces obtiene el error:

ORA-22992: cannot use LOB locators selected from remote tables

Esta es una restricción documentada .

La misma página sugiere que busque los valores en una tabla local, pero eso es ... algo desordenado:

CREATE TABLE tmp_hello AS SELECT column_a from data_user.sample_table@TEST_LINK

¿Alguna otra idea?


¿Tienes un escenario específico en mente? Por ejemplo, si el LOB contiene archivos y usted se encuentra en una intranet de la compañía, quizás pueda escribir un procedimiento almacenado para extraer los archivos a un directorio conocido en la red y acceder a ellos desde allí.


En este caso específico, la única forma en que los dos sistemas se pueden comunicar es utilizando el dblink.

Además, la solución de la tabla no es tan terrible, es complicado tener que "almacenar en caché" los datos de mi lado del dblink.


Sí, está desordenado, no puedo pensar en una forma de evitarlo.
Podría ocultar parte del desorden del cliente colocando la creación de tabla temporal en un procedimiento almacenado (y usando "ejecutar inmediatamente" para crear la tabla)
Una cosa de la que tendrá que cuidarse es dejar tablas temporales (si algo falla a mitad de una sesión, antes de que haya tenido tiempo de limpiarlo): podría programar un trabajo de oráculo para ejecutar periódicamente y eliminar las tablas restantes .


Puede usar vistas materalizadas para manejar toda la administración de "caché". No es perfecto, pero funciona en la mayoría de los casos :)


La mejor solución al usar una consulta como la siguiente, donde column_b es un BLOB:

SELECT (select column_b from sample_table@TEST_LINK) AS column_b FROM DUAL


Para los datos de consulta, la solución de user2015502 es la más inteligente. Si desea insertar o actualizar LOB en la base de datos remota (insertar en xxx @ yyy ...) puede usar SQL dinámico para eso. Vea mi solución aquí: