Visin general de consultas distribuidas

Los servidores de bases de datos IBM Informix le permiten consultar ms de una base de datos del mismo servidor de bases de datos o de varios servidores de bases de datos. Este tipo de consulta se denomina consulta distribuida. Los servidores de bases de datos pueden residir en un solo sistema principal, en distintos sistemas de la misma red o en una pasarela. (Engeneral, la mayor parte de caractersticas y restricciones descritas eneste captulo para las consultas distribuidas se aplican tambin allamadas de funciones y a las operaciones INSERT, DELETE o UPDATE que hacen referencia a objetos o datos de ms de unabase de datos.)

Consultas distribuidas en bases de datos de una instancia deDynamic Server

Las operaciones distribuidas en bases de datos de la misma instancia deIBM Informix Dynamic Server estn sujetas a lassiguientes restricciones sobre los tipos de datos devueltos: La consulta, operacin DML o llamada de funcin puede devolver cualquier tipo de datos incorporado, incluidos los tipos opacos incorporados BLOB, BOOLEAN, CLOB y LVARCHAR. La consulta, operacin DML o llamada de funcin no puededevolver los tipos de datos DISTINCT ni OPAQUE a menos que stos seconviertan explcitamente en un tipo de datos incorporado, y todos lostipos de datos DISTINCT y OPAQUE y todas las conversiones explcitas sedefinan en cada una de las bases de datos participantes que almacenen oreciban los tipos de datos.

Consultas distribuidas en bases de datos de dos o ms instancias deDynamic Server

Las operaciones distribuidas en bases de datos de dos o ms instancias deIBM Informix Dynamic Server estn sujetas a lassiguientes restricciones sobre tipos de datos devueltos: Una consulta, operacin DML o llamada de funcin puede devolver cualquier tipo de datos incorporado no opaco, el tipo de datos BOOLEAN y el tipo de datos LVARCHAR. Una consulta, operacin DML o llamada de funcin puede devolver tipos de datos DISTINCT que se conviertan explcitamente en un tipo de datos incorporado, y cuyos tipos base sean tipos de datos incorporados no opacos, BOOLEAN o tipos de datos LVARCHAR. Asimismo, el tipo base puede ser tambin un tipo de datos DISTINCT cuyo tipo base sea un tipo incorporado no opaco, BOOLEAN, LVARCHAR u otro tipo de datos DISTINCT que est basado en uno de estos tipos. Debe definir estas conversiones explcitas, funciones y tipos de datos DISTINCT en cada base de datos participante de la operacin distribuida. En cualquier base de datos participante los servidores son versiones anteriores que no pueden dar soporte a estos tipos de datos en operaciones realizadas en varios servidores, dichos servidores devuelven slo los tipos de datos a los que dan soporte. Una operacin distribuida fallar si especifica un tipo de datos no soportado. Al igual que las operaciones distribuidas en las bases de datos de la misma instancia de Dynamic Server, las operaciones distribuidas en varios servidores requieren que todas las bases de datos tengan tipos de anotaciones cronolgicas de transacciones compatibles, como se describe en Restricciones de tipo de registro cronolgico en consultas distribuidas.

Coordinador y participante en una consulta distribuida

Para soportar las operaciones distribuidas entre varios servidores de bases de datos, los servidores de IBM Informix mantienen relaciones jerrquicas que constan de un coordinador y uno o ms participantes. El coordinador y participante se definen del modo siguiente: El coordinador dirige la resolucin de la consulta. Tambin decide si se debe confirmar o cancelar anormalmente la consulta. El participante dirige la ejecucin de la consulta distribuida sobre una rama. La rama es la parte de la consulta distribuida que sloimplica a ese servidor de bases de datos participante. Los siguientes ejemplos hacen referencia a un entorno devarios servidores en el que db es la base de datos local, db2 es una basede datos externa que reside en el mismo servidor y master_db es una basede datos externa del servidor remoto new_york. Los siguientes ejemplos muestran una consulta que se puede utilizarpara acceder a datos de otro servidor utilizando la base de datos db comocoordinador.
database db; select col1, col2 from db2:tab1, master_db@newyork:tab2;

Una sesin slo tendr una base de datos local, pero puede abrir variasbases de datos externas. Las consultas distribuidas siempre se debenoriginar en un coordinador.

Configurar el servidor de bases de datos para utilizar consultas distribuidas

Para utilizar varios servidores IBM Informix para consultas distribuidas, debe asegurarse de que todos los servidores de bases de datos implicados estn configurados para permitir las comunicaciones de servidor a servidor a travs de la red. Es posible que haya que editar los siguientes archivos deconfiguracin para permitir las consultas distribuidas: El archivo sqlhosts El archivo onconfig /etc/hosts.equiv o .rhosts /etc/services /etc/hosts El archivosqlhosts contiene informacin de conectividad para cadaservidor de bases de datos. Si desea configurar varios servidores de bases de datospara utilizar consultas distribuidas, utilice uno de los procedimientos siguientes paraalmacenar la informacin sqlhostsparatodas las bases de datos: En un archivo sqlhosts, al que apunta INFORMIXSQLHOSTS En archivos sqlhosts independientes en cada directorio deservidor de bases de datos Para obtener ms informacin sobre cmoconfigurar el archivo sqlhosts, consulte la publicacinIBM Informix DynamicServer Administrator's Guide.

Acceder a un servidor y una base de datos remotos

El elemento bsico de cualquier sentencia de una consultadistribuida es el segmento de base de datos. Utilizando la sintaxis deestos segmentos, puede especificar un servidor de bases de datos, unabase de datos o un objeto de base de datos remotos.

Segmento Nombre de base de datos

El segmento Nombre de base de datos se utiliza para especificarel nombre de una base de datos. Los siguientes ejemplos muestrandiferentes maneras de especificar una base de datos remota:
empinfo@personnel '//personnel/empinfo'

Segmento Nombre de objeto de base de datos

El segmento Nombre de objeto de base de datos se utiliza paraespecificar el nombre de un objeto de base de datos, incluyendorestricciones, ndices, activadores y sinnimos. Los siguientes ejemplosmuestran cmo acceder a objetos remotos:
empinfo@personnel:markg.emp_names empinfo@personnel:emp_names

Sentencias vlidas para acceder a objetos remotos

Las siguientes sentencias soportan objetos remotos como parte de los segmentos de Base de datos y de Objeto de base de datos, y se pueden utilizar en una consulta distribuida. INSERT SELECT UPDATE DELETE CREATE VIEW CREATE SYNONYM CREATE DATABASE DATABASE LOAD UNLOAD LOCK UNLOCK INFO

Acceder a tablas remotas

Una tabla remota es una tabla que se encuentra en un servidor de bases de datos distinto del servidor actual. Puede conectarse del servidor actual a un servidor remoto. En cualquier momento, slo puede haber una conexin activa del servidor local a un servidor remoto. Dynamic Server no soporta varias conexiones activas entre los dos mismos servidores de bases de datos que utilizan diferentes alias de servidor. De este modo, si utiliza diferentes alias de servidor para conectarse al mismo servidor remoto, se vuelve a utilizar la conexin inicial. La sintaxis general para acceder a una tabla de otro servidor es la siguiente:
basedatos@servidor:[propietario.]tabla

Aqu, una tabla puede ser un nombre de tabla, un nombre de vista o un sinnimo. Tiene la opcin de especificar el propietario de la tabla. Para conocer las opciones de sintaxis completas, consulte la documentacin de los segmentos de base de datos y objeto de base de datos de la publicacin IBM Informix Guide to SQL: Syntax.

El siguiente ejemplo muestra una consulta que accede a una tabla remota:
DATABASE locdb; SELECT l.name, r.assignment FROM rdb@rsys:rtab r, loctab l WHERE l.empid = r.empid;

Esta consulta accede a las columnas name y empid de la tabla local loctab, y a las columnas assignment y empid de la tabla remota rtab. Los datos se enlazan utilizando empid como columna de enlace. El siguiente ejemplo muestra una consulta que accede a datos de una tabla remota y los inserta en una tabla local:
DATABASE locdb; INSERT INTO loctab SELECT * FROM rdb@rsys:rtab;

Esta consulta selecciona todos los datos de la tabla remotartab y los inserta en la tabla local loctab. El siguiente ejemplo crea una vista en la base de datos localutilizando las columnas empid y priority de la base de datos remota rdb.
DATABASE locdb; CREATE VIEW myview (empid, empprty) AS SELECT empid, priority FROM rdb@rsys:rtab;

Permisos de tabla
Los permisos para acceder a tablas de otras bases dedatos y a tablas remotas se controlan en la ubicacin de latabla. Cuando se accede a un servidor remoto, la conexin se realizautilizando el nombre de inicio de sesin y la contrasea del usuario que ejecutala consulta. Para acceder a datos remotos, el usuario debe tener lospermisos apropiados sobre la tabla remota. Cuando se procesan consultas distribuidas, el servidor de bases dedatos ignora la funcin activa en la base de datos local actual cuando seaccede a un objeto remoto. En el servidor remoto, se utiliza la funcinpor omisin aplicada a cada base de datos remota. Si no se ha definido un rolpor omisin, los privilegios del usuario definen los permisos de acceso paralos objetos de cada base de datos remota.

Calificar referencias de tabla

Las referencias a tablas se pueden calificar con la base dedatos y el nombre de servidor actuales. Si no se especifica ningunacalificacin, se impone el contexto de base de datos y servidor actuales. Porejemplo, si la base de datos actual es locdb y el servidor actual escurrsys, las siguientes referencias a loctab son equivalentes:
locdb@currsys:loctab locdb:loctabloctab

Otras operaciones remotas

Adems de consultar y actualizar datos, existen otrasoperaciones remotas que puede realizar utilizando la infraestructura deconsultas distribuidas.

Abrir una base de datos remota

Especificando un objeto remoto en la sentencia DATABASE, puedeabrir una base de datos remota, como en los siguientes ejemplos:
DATABASE nombrebd@nombreservidor; DATABASE "//nombservidor/basedatos";

Crear una base de datos remota

Puede crear una base de datos remota calificando el nombre de labase de datos con un nombre de servidor cuando utilice la sentenciaCREATE DATABASE.
CREATE DATABASE remfoo@rsys;

Crear un sinnimo para una tabla remota

Puede crear un sinnimo para una tabla remota de otra base dedatos o una tabla remota utilizando un nombre calificado en lasentencia CREATE SYNONYM. Por ejemplo, la siguiente sentencia crea unsinnimo para rdb@srsys:rtab:
CREATE SYNONYM myrtab FOR rdb@rsys:rtab;

Es posible que un sinnimo exista tanto en el servidor local como enel remoto.En el ejemplo anterior, es posible que rtab sea por s mismosinnimo de rdb2@rsys2:rtab2. Cuando se recupera informacin delcatlogo, se sigue la cadena de sinnimos hasta que se encuentran la basede datos y el servidor fsicos en que reside la tabla. Si, finalmente, unsinnimo se apunta a s mismo, se devuelve un error.

Entorno de servidor y consultas distribuidas

En esta seccin se listan los parmetros de configuracin y lasvariables de entorno que afectan al comportamiento de las consultasdistribuidas.

Variable de entorno PDQPRIORITY

El valor efectivo de PDQPRIORITY para una sesinse enva al sitio remoto cuando se establece una conexin.Los cambiosposteriores en este parmetro del coordinador no se reflejan en elsitio remoto. Sin embargo, el comportamiento exacto de esta variable de entornodepende de la funcin del servidor de bases de datos en la consulta distribuida(coordinador o participante). PDQPRIORITY tienesintaxis y semntica diferentes para distintas versiones de servidor. Paraobtener informacin sobre cmo establecerPDQPRIORITY, consulte la publicacinIBM Informix PerformanceGuide delservidor.

Parmetro DEADLOCK_TIMEOUT
Este parmetro de configuracin se utiliza para especificarla cantidad de tiempo durante el que una transaccin esperar un bloqueo. Sise fuerza que una transaccin distribuida espere un nmero de segundossuperior al especificado, la hebra propietaria de la transaccin supone queexiste un punto muerto de varios servidores. Se devuelve el siguiente mensajede error:
-143 Error ISAM: detectado punto muerto.

Paraobtener ms informacin sobre cmo utilizar este parmetro de configuracin,consulte la publicacinIBM Informix DynamicServer Administrator's Guide.

Restricciones de tipo de registro cronolgico en consultas distribuidas

Para ejecutar consultas distribuidas en un entorno de servidor de bases de datos IBM Informix, todas las bases de datos participantes debe ser de tipos compatibles de registro cronolgico de transacciones: Las consultas distribuidas se pueden utilizar en una base de datos compatible con ANSI solamente si las bases de datos participantes son tambin compatibles con ANSI. Las consultas distribuidas realizadas en una base de datos que no es compatible con el registro de transacciones solamente se pueden ejecutar si todas las bases de datos participantes tampoco utilizan el registro de transacciones. Las consultas distribuidas realizadas en una base de datos que no es compatible con ANSI, pero que utiliza registro de transacciones explcito, estn permitidas si todas las dems bases de datos tambin utilizan registro de transaccionesexplcito. En el ltimo caso, la utilizacin de un registro detransacciones con o sin almacenamiento intermedio por parte deuna base de datos participante no afecta a su capacidad parapermitir operaciones distribuidas. En el entorno de proceso de transaccionesdistribuidas (DTP) deX/Open, todas lasbases de datos deben utilizar el registro cronolgico sin almacenamiento intermedio.Consulte la publicacin IBM Informix DynamicServer Administrator's Guide para obtener ms informacin sobre los tipos de registro cronolgico de bases de datosy el DTP deX/Open.

Proceso de transacciones
En esta seccin se describen algunas de las consideracionesimplicadas cuando se utilizan consultas distribuidas en un entorno deproceso de transacciones.

Niveles de aislamiento
El nivel de aislamiento de una transaccin se enva al servidorremoto al comienzo de la transaccin en el sitio remoto. Si un nivel deaislamiento cambia durante una transaccin, se enva el nuevo valor alsitio remoto.

DEADLOCK_TIMEOUT y SET LOCK MODE

Cuando utilice consultas distribuidas, puede usar la sentencia SET LOCK MODE junto con el parmetro de configuracinDEADLOCK_TIMEOUT como ayuda para evitar puntos muertos de servidor. Cuando se solicita la opcin WAIT de SET LOCK MODE, el servidor de bases de datos se protege frente a la posibilidad de un punto muerto. Sin embargo, si el servidor de bases de datos descubre que se puedeproducir un punto muerto, termina la operacin y devuelve un error. El parmetro de configuracin DEADLOCK_TIMEOUTespecifica el nmero mximo de segundos que una hebra de servidor debases de datos puede esperar para adquirir un bloqueo. Este valor es el valor por omisinutilizado por la sentencia SET LOCK MODE WAIT. nicamente se aplica este valor si se adquieren bloqueos sobre losservidores de bases de datos actual y remoto en la misma transaccin. Para obtener ms informacin sobre la sentencia SET LOCK MODE, consulte la publicacin IBM Informix Guideto SQL: Syntax. Paraobtener ms informacin sobre el parmetro de configuracinDEADLOCK_TIMEOUT, consulteParmetro DEADLOCK_TIMEOUT y el captulo que

trata sobre los protocolosde confirmacin en varias fases en la publicacin IBM Informix DynamicServer Administrator's Guide.

Confirmacin y recuperacin en dos fases

El protocolo de confirmacin en dos fases se utiliza paraasegurarse que las consultas distribuidas se confirman o retrotraenuniformemente en varios servidores de bases de datos. Un servidor de basesde datos utiliza automticamente el protocolo de confirmacin en dos fasespara aquellas transacciones que modifican datos en varios servidores debases de datos. Para obtener ms informacin, consulte el captulo que tratasobre los protocolos de confirmacinen varias fases en la publicacinIBM Informix DynamicServer Administrator's Guide.