• Author / Uploaded
• Arturo Rodriguez

Citation preview

Visión general de consultas distribuidas Los servidores de bases de datos IBM® Informix le permiten consultar más 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 características y restricciones descritas eneste capítulo para las consultas distribuidas se aplican también allamadas de funciones y a las operaciones INSERT, DELETE o UPDATE que hacen referencia a objetos o datos de más 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 están sujetas a lassiguientes restricciones sobre los tipos de datos devueltos:  

La consulta, operación DML o llamada de función puede devolver cualquier tipo de datos incorporado, incluidos los tipos opacos incorporados BLOB, BOOLEAN, CLOB y LVARCHAR. La consulta, operación DML o llamada de función no puededevolver los tipos de datos DISTINCT ni OPAQUE a menos que éstos seconviertan explícitamente en un tipo de datos incorporado, y todos lostipos de datos DISTINCT y OPAQUE y todas las conversiones explícitas 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 más instancias deDynamic Server Las operaciones distribuidas en bases de datos de dos o más instancias deIBM® Informix Dynamic Server están sujetas a lassiguientes restricciones sobre tipos de datos devueltos:  Una consulta, operación DML o llamada de función puede devolver cualquier tipo de datos incorporado no opaco, el tipo de datos BOOLEAN y el tipo de datos LVARCHAR.  Una consulta, operación DML o llamada de función puede devolver tipos de datos DISTINCT que se conviertan explícitamente 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 también 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 explícitas, funciones y tipos de datos DISTINCT en cada base de datos participante de la operación 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 sólo los tipos de datos a los que dan soporte. Una operación 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 cronológicas de transacciones compatibles, como se describe en Restricciones de tipo de registro cronológico 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 jerárquicas que constan de un coordinador y uno o más participantes. El coordinador y participante se definen del modo siguiente:  El coordinador dirige la resolución de la consulta. También decide si se debe confirmar o cancelar anormalmente la consulta.  El participante dirige la ejecución de la consulta distribuida sobre una rama. La rama es la parte de la consulta distribuida que sóloimplica 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 sesión sólo 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 están configurados para permitir las comunicaciones de servidor a servidor a través de la red. Es posible que haya que editar los siguientes archivos deconfiguración para permitir las consultas distribuidas:  El archivo sqlhosts  El archivo onconfig  /etc/hosts.equiv o .rhosts  /etc/services  /etc/hosts El archivosqlhosts contiene información 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 información 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 más información sobre cómoconfigurar el archivo sqlhosts, consulte la publicaciónIBM Informix DynamicServer Administrator's Guide.

Acceder a un servidor y una base de datos remotos El elemento básico 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 sinónimos. Los siguientes ejemplosmuestran cómo acceder a objetos remotos: empinfo@personnel:markg.emp_names empinfo@personnel:emp_names

Sentencias válidas 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, sólo puede haber una conexión 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 conexión 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 sinónimo. Tiene la opción de especificar el propietario de la tabla. Para conocer las opciones de sintaxis completas, consulte la documentación de los segmentos de base de datos y objeto de base de datos de la publicación 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 ubicación de latabla. Cuando se accede a un servidor remoto, la conexión se realizautilizando el nombre de inicio de sesión y la contraseña 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 función activa en la base de datos local actual cuando seaccede a un objeto remoto. En el servidor remoto, se utiliza la funciónpor omisión aplicada a cada base de datos remota. Si no se ha definido un rolpor omisión, 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 ningunacalificación, 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 Además 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 sinónimo para una tabla remota Puede crear un sinónimo 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 unsinónimo para rdb@srsys:rtab: CREATE SYNONYM myrtab FOR rdb@rsys:rtab;

Es posible que un sinónimo exista tanto en el servidor local como enel remoto.En el ejemplo anterior, es posible que rtab sea por sí mismosinónimo de rdb2@rsys2:rtab2. Cuando se recupera información delcatálogo, se sigue la cadena de sinónimos hasta que se encuentran la basede datos y el servidor físicos en que reside la tabla. Si, finalmente, unsinónimo se apunta a sí mismo, se devuelve un error.

Entorno de servidor y consultas distribuidas En esta sección se listan los parámetros de configuración y lasvariables de entorno que afectan al comportamiento de las consultasdistribuidas.

Variable de entorno PDQPRIORITY El valor efectivo de PDQPRIORITY para una sesiónse envía al sitio remoto cuando se establece una conexión.Los cambiosposteriores en este parámetro del coordinador no se reflejan en elsitio remoto. Sin embargo, el comportamiento exacto de esta variable de entornodepende de la función del servidor de bases de datos en la consulta distribuida(coordinador o participante). PDQPRIORITY tienesintaxis y semántica diferentes para distintas versiones de servidor. Paraobtener información sobre cómo establecerPDQPRIORITY, consulte la publicaciónIBM Informix PerformanceGuide delservidor.

Parámetro DEADLOCK_TIMEOUT Este parámetro de configuración se utiliza para especificarla cantidad de tiempo durante el que una transacción esperará un bloqueo. Sise fuerza que una transacción distribuida espere un número de segundossuperior al especificado, la hebra propietaria de la transacción supone queexiste un punto muerto de varios servidores. Se devuelve el siguiente mensajede error: -143 Error ISAM: detectado punto muerto.

Paraobtener más información sobre cómo utilizar este parámetro de configuración,consulte la publicaciónIBM Informix DynamicServer Administrator's Guide.

Restricciones de tipo de registro cronológico 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 cronológico de transacciones:  Las consultas distribuidas se pueden utilizar en una base de datos compatible con ANSI solamente si las bases de datos participantes son también 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 explícito, están permitidas si todas las demás bases de datos también utilizan registro de transaccionesexplícito. En el último caso, la utilización 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 cronológico sin almacenamiento intermedio.Consulte la publicación IBM Informix DynamicServer Administrator's Guidepara obtener más información sobre los tipos de registro cronológico de bases de datosy el DTP deX/Open.

Proceso de transacciones En esta sección 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 transacción se envía al servidorremoto al comienzo de la transacción en el sitio remoto. Si un nivel deaislamiento cambia durante una transacción, se envía 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 parámetro de configuraciónDEADLOCK_TIMEOUT como ayuda para evitar puntos muertos de servidor. Cuando se solicita la opción 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 operación y devuelve un error. El parámetro de configuración DEADLOCK_TIMEOUTespecifica el número máximo de segundos que una hebra de servidor debases de datos puede esperar para adquirir un bloqueo. Este valor es el valor por omisiónutilizado 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 transacción. Para obtener más información sobre la sentencia SET LOCK MODE, consulte la publicación IBM Informix Guideto SQL: Syntax. Paraobtener más información sobre el parámetro de configuraciónDEADLOCK_TIMEOUT, consulteParámetro DEADLOCK_TIMEOUT y el capítulo que

trata sobre los protocolosde confirmación en varias fases en la publicaciónIBM Informix DynamicServer Administrator's Guide.

Confirmación y recuperación en dos fases El protocolo de confirmación 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 automáticamente el protocolo de confirmación en dos fasespara aquellas transacciones que modifican datos en varios servidores debases de datos. Para obtener más información, consulte el capítulo que tratasobre los protocolos de confirmaciónen varias fases en la publicaciónIBM Informix DynamicServer Administrator's Guide.