Informe Bdlink-Vistas Materializadas

Universidad Técnica de Ambato Facultad de Ingeniería en Sistemas,

Electrónica e Industrial

CARRERA DE INGENIERÍA EN SISTEMAS Informe

Carrera Universitaria: Sistemas Computacionales e Informáticos Semestre: Sexto Semestre Alumno participante:

Juan Carlos Calvache

Módulo:

Base de Datos Distribuidos

Tema: BDLINK – VISTAS MAERIALIZADAS

UNIVERSIDAD TECNICA DE AMBATO Facultad de Ingeniería en Sistemas, Electrónica e Industrial

AUTOR: Calvache Juan Carlos [email protected]

OBJETIVO:

Utilizar bdlink para la conexión de una base de datos desde un

cliente a un servidor.

Aplicar el conocimiento anterior y obtener vistas materializadas

desde un cliente.

MARCO TEORICO:

CREATE DATABASE LINK

El CREATE DATABASE LINK es una instrucción para crear un enlace de base

de datos. Un enlace de base de datos es un objeto de esquema en una base

de datos que le permite acceder a los objetos de otra base de datos. La

otra base de datos no tiene que ser un sistema de base de datos

Oracle. Sin embargo, para acceder a los sistemas Oracle no es necesario

utilizar los servicios de Oracle heterogéneos.

Una vez que haya creado un enlace de base de datos, se puede utilizar

para hacer referencia a las tablas y vistas de la base de datos. En las

sentencias de SQL, puede hacer referencia a una tabla o vista en la base

de datos distinta añadiendo @ dblink a la tabla o nombre de vista. Puede

consultar una tabla o vista en la base de datos con

el SELECT comunicado. También puede acceder a tablas remotas y vistas

usando cualquier INSERT, ACTUALIZACIÓN, DELETE, o LOCK TABLA comunicado.



Comandos varios que se utilizan para un dlink

CREATE DATABASE LINK local

CONNECT TO nombre_usuario IDENTIFIED BY clave_usuario

USING 'local'; ==> el nombre del sid en mi caso XE

SELECT * FROM employees@local;

INSERT INTO employees@local

(employee_id, last_name, email, hire_date, job_id)

VALUES (999, 'Claus', '[email protected]', SYSDATE, 'SH_CLERK');

UPDATE jobs@local SET min_salary = 3000

WHERE job_id = 'SH_CLERK';

DELETE FROM employees@local

WHERE employee_id = 999;

drop database link local o drop public database link local

VISTAS MATERIALIZADAS

A diferencia de las vistas "normales" una vista materializada almacena

físicamente los datos resultantes de ejecutar la consulta definida en la

vista. Este tipo de vistas materializadas realizan una carga inicial de

los datos cuando se definen y posteriormente con una frecuencia

establecida se actualizan los datos de la misma.Con la utilización de

vistas materializadas logramos aumentar el rendimiento de las

consultas SQL además de ser un método de optimización a nivel físico en

modelos de datos muy complejos y/o con muchos datos.

Una vez definida una vista materializada uno de los problemas que nos

encontramos es el de la actualización de los datos. Como se ha comentado

antes, estas vistas contienen fisicamente los datos de las "tablas



base", por lo que si cambian los datos de estas tablas no se reflejarán

en la vista materializada. Para ello necesitamos establecer un mecanismo

de resfresco automático en el que tendremos que definir el tipo y

la forma de refresco.

La sentencia SQL que nos permite definir una vista materializada es

esta:

1. CREATE MATERIALIZED VIEW nombre_vista 2. [TABLESPACE nombre_ts] 3. [PARALELL (DEGREE n)] 4. [BUILD {INMEDIATE|DEFERRED}] 5. [REFRESH {FAST|COMPLETE|FORCE|NEVER}|{ON COMMIT|ON DEMAND|[START WITH fecha_inicio] NEXT interva

lo}] 6. [{ENABLE|DISABLE} QUERY REWRITE] 7. AS SELECT ... FROM ... WHERE ...

Con la palabra BUILD establecemos la forma de carga de datos en la

vista. Con la opción INMEDIATE (opción por defecto) se cargarán los

datos justo después de crear la vista, mientras que con la

opción DEFERRED se definirá la vista cuando se ejecute la

sentencia SQL sin cargar ningún dato, que se cargarán cuando se realize

el primer refresco de la vista.

Con la palabra REFRESH definimos el método y la frecuencia de refresco

de los datos.

La palabra QUERY REWRITE establece si queremos que el optimizador de

nuestra base de datos pueda reescribir las consultas. El optimizador,

sabiendo que ya existe una determinada vista materializada, puede

modificar internamente nuestra consulta sobre una determinada tabla, de

tal forma que se mejore el rendimiento de la consulta devolviendo los

mismos datos que la consulta original.

Refresco

Como es entendible la política de refresco de cada vista repende

altamente de nuestras necesidades y requerimientos sobre la frecuencia

de actualización de los datos de las "tablas base".

Tipos de refresco

COMPLETE: Se borrarán todos los datos de la vista y se volverá a

ejecutar la consulta definida en la vista por lo que se recargarán

físicamente los datos de las "tablas base".

FAST: Podemos decir que este tipo de refresco es una actualización

incremental, es decir, solo se refrescarán aquellos datos que se

hayan modificado desde el último refresco. Evidentemente este tipo

de refresco es mucho más fast que el complete. Pero, ¿cómo sabe la

base de datos que datos se han modificado desde el último refresco?

lo sabe gracias a que previamente hemos tenido que crear unos



determinados log de la vista (VIEWLOG) sobre cada una de las

"tablas base" de la vista materializada.

1. CREATE MATERIALIZED VIEW LOG ON tabla_base 2. WITH PRIMARY KEY 3. INCLUDING NEW VALUES;

Hay que decir que si usamos funciones sum, avg, max, min, etcétera,

no vamos a poder usar este tipo de refresco.

FORCE : si se puede realizar el refresco tipo FAST se ejecuta, y

sino se realiza el refresco COMPLETE. Es el valor por defecto del

tipo de refresco.

NEVER : nunca se realizará un refresco de la vista.

Formas de refresco

Refresco manual : mediante el paquete de PL/SQL DBMS_MVIEW podemos

forzar a realizar un refresco usando para ello la función REFRESH.

1. DBMS_MVIEW.REFRESH ('nombre_vista'); 2.

Con la función REFRESH_DEPENDENT se refrescarán todas las vistas

materializadas que tengan algunas de sus "tablas base" en la lista

de tablas pasada como parámetro de entrada.

1. DBMS_MVIEW.REFRESH_DEPENDENT ('tabla1, tabla2, tabla3, ... , tablaN'); 2.

Con la función REFRESH_ALL_MVIEWS se refrescarán todas las vistas

materializadas de nuestra base de datos.

Refresco automático: este refresco automático podemos hacerlo

usando la palabra ON COMMIT, con la que se fuerza al refresco de la

vista en el momento en el que se haga un commit sobre una de las

"tablas base" de dicha vista. Otro tipo de refresco automático es

el llamado refresco programado, en el cual podemos definir el

momento exacto en el que queremos que se refresque nuestra vista.

Para ello tenemos que definir la fecha del refresco en

formate datetime y el intervalo de este.



PRACTICA:

Para la práctica siguiente hay que aclarar que se lo realizara en dos

máquinas virtuales las cuales se encuentran en red y con un sistema

operativo Windows 7 de 32 bits.

La máquina llamada Windows 7 sp2 se tomara como servidor mientras que la

máquina Windows 7 sp1 se utilizará como cliente.

Lo primero que se debe hacer es verificar la conexión entre el servidor

Oracle y el cliente.

Servidor ip = 192.168.1.5

Cliente ip = 192.168.1.6

Configuramos el tsnames en el cliente



Luego configuramos el listener

Nos conectamos desde el cliente al servidor y comprobamos la conexión

visualizando la tabla del servidor.



Como vemos el en servidor esta creada la tabla prueba con su único campo

llamado A de tipo number.

Observamos que el cliente, se conecta correctamente y describe la tabla

del servido.

Luego procedemos a insertar datos remotamente esto quiere decir desde el

cliente.



Verificamos si los datos se han insertado correctamente en el servidor.

Esta verificación la hacemos en el servidor utilizando un select simple.

A continuación vamos a crear el bdlink desde el cliente.

Comprobamos el bdlink y hacemos un select de la tabla prueba de la

siguiente manera.



Luego procedemos a crear la vista materializada de la siguiente manera.

Comprobamos la vista materializada haciendo un select.



Probamos la vista materializada desconectándonos del servidor y conectándonos

localmente en el cliente como system, la comprobación la hacemos de la misma

manera con un select.

CONCLUSIONES:

Con la práctica realizada hemos comprobado que el bdlink sirve mucho para

hacer conexiones remotas entre cliente servidor, y así poder utilizar un select

sin la necesidad de hacer conexión al servidor.

Además con las vistas materializadas hacemos un select a una tabla en el

servidor y luego de desconectarnos los datos quedan grabados en el cliente y

podemos visualizarlos sin necesidad de conectarnos nuevamente al servidor.

BIBLIOGRAFÍA:



http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm

http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_5005.htm

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=vistasMaterializadas

http://www.oracleya.com.ar/temarios/descripcion.php?cod=248&punto=90

http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm

http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_5005.htm

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=vistasMaterializadas

http://www.oracleya.com.ar/temarios/descripcion.php?cod=248&punto=90

Documents

Informe Bdlink-Vistas Materializadas