Proyecto Administración Oracle Migración Postgre Oracle Oracle Postgre

Transcripción

1 Proyecto Administración Oracle Migración Postgre Oracle Oracle Postgre Mario Carrión Claro Alejandro Salguero Oviedo

2 INDICE: Título Pág 1 PostgresSQL Diferencias entre Oracle y PostgresSQL Instalación de postgres y pgadmin en Debian Squeeze Creación de objetos en Postgres Instalación de aplicación de migración de tablas Migración de tablespace y tablas: Postgres Oracle Scripts de migración Postgres Oracle Migración de tablespace y tablas: Oracle - Postgres Scripts de migración Oracle - Postgres

3 1 PostgresSQL: Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL como administrador de bases de datos. La conexión puede ocurrir via TCP/IP ó sockets locales. Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el encargado de escuchar por un puerto/socket por conexiones entrantes de clientes. Tambien es el encargado de crear los procesos hijos que se encargaran de autentificar estas peticiones, gestionar las consultas y mandar los resultados a las aplicaciones clientes Ficheros de configuracion: Los 3 ficheros principales de configuración utilizados por PostgreSQL, postgresql.conf, pg_hba.conf y pg_ident.conf Procesos hijos postgres: Procesos hijos que se encargan de autentificar a los clientes, de gestionar las consultas y mandar los resultados a las aplicaciones clientes PostgreSQL share buffer cache: Memoria compartida usada por POstgreSQL para almacenar datos en caché. Kernel disk buffer cache: Caché de disco del sistema operativo Write-Ahead Log (WAL): Componente del sistema encargado de asegurar la integridad de los datos (recuperación de tipo REDO) Disco: Disco físico donde se almacenan los datos y toda la información necesaria para que PostgreSQL funcione Características La última serie de producción es la 9.0. Sus características técnicas la hacen una de las bases de datos más potentes y robustas del mercado. Su desarrollo comenzó hace más de 15 años, y durante este tiempo, estabilidad, potencia, robustez, facilidad de administración e implementación de estándares han sido las características que más se han tenido en cuenta durante su desarrollo. PostgreSQL funciona muy bien con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la vez a el sistema. A continuación tenéis algunas de las características más importantes y soportadas por PostgreSQL: Generales Es una base de datos 100% ACID Integridad referencial Tablespaces Nested transactions (savepoints) Replicación asincrona / Streaming replication - Hot Standby

4 Two-phase commit PITR - point in time recovery Copias de seguridad en caliente (Online/hot backups) Unicode Juegos de caracteres internacionales Multi-Version Concurrency Control (MVCC) Multiples métodos de autentificación Acceso encriptado via SSL Actualización in-situ integrada (pg_upgrade) Completa documentación Licencia BSD Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit. Programación / Desarrollo Funciones/procedimientos almacenados (stored procedures) en numerosos lenguajes de programacion, entre otros PL/pgSQL (similar al PL/SQL de oracle), PL/Perl, PL/Python y PL/Tcl Bloques anónimos de código de procedimientos (sentencias DO) Numerosos tipos de datos y posibilidad de definir nuevos tipos. Además de los tipos estándares en cualquier base de datos, tenemos disponibles, entre otros, tipos geométricos, de direcciones de red, de cadenas binarias, UUID, XML, matrices, etc Soporta el almacenamiento de objetos binarios grandes (gráficos, videos, sonido,...) APIs para programar en C/C++, Java,.Net, Perl, Python, Ruby, Tcl, ODBC, PHP, Lisp, Scheme, Qt y muchos otros. SQL SQL92,SQL99,SQL2003,SQL2008 Llaves primarias (primary keys) y ajenas (foreign keys) Check, Unique y Not null constraints Restricciones de unicidad postergables (deferrable constraints) Columnas auto-incrementales Indices compuestos, únicos, parciales y funcionales en cualquiera de los metodos de almacenamiento disponibles, B-tree, R-tree, hash ó GiST Sub-selects Consultas recursivas Funciones 'Windows' Joins Vistas (views) Disparadores (triggers) comunes, por columna, condicionales. Reglas (Rules) Herencia de tablas (Inheritance) Eventos LISTEN/NOTIFY Podeis consultar la lista completa en ingles de características disponibles en todas las versiones en la dirección Límites Algunos de los limites de PostgreSQL son: Límite Valor Máximo tamaño base de dato Ilimitado (Depende de tu sistema de almacenamiento) Máximo tamaño de tabla 32 TB Máximo tamaño de fila 1.6 TB Máximo tamaño de campo 1 GB Máximo numero de filas por tabla Ilimitado Máximo numero de columnas por tabla (dependiendo del tipo) Máximo numero de indices por tabla Ilimitado

5 2 Diferencias entre Oracle y PostgresSQL: Antes de realizar las migraciones entre estos dos SGBD vamos a realizar una pequeña comparativa entre ellos, en la que trataremos los siguientes puntos: Sintaxis. Elementos. Rendimiento. SINTAXIS: En este primer punto veremos algunas diferencias que nos hemos encontrado entre la sintaxis de Postgres y Oracle. También os dejamos link de las diapositivas del tema de Administración de Oracle que hemos utilizado en clase, y otro link a una web en la que encontramos la sintaxis utilizada en Postgres para su administración, por si quisiéramos comparar las diferencias existentes. Un punto que caracteriza a Postgres, es que puede ser administrado desde el sistema operativo (mediante línea de comandos al más puro estilo Linux) o desde un cliente SQL, y existen diferencias en la sintaxis de las órdenes. Solo mostraremos la administración a través de un cliente SQL, pero podemos ver la administración desde el sistema operativo (y muchísima más información sobre PostgresSQL) aquí. 1- La primera diferencia que nos encontramos son algunos tipos de datos, en concreto nosotros hemos tratado los siguientes: ORACLE varchar2() number POSTGRES varchar() int(para enteros),float(para decimales) 2- En la creación de usuarios, para especificar la contraseña del usuario tenemos que poner WITH PASSWORD en lugar de IDENTIFIED BY como hacíamos en Oracle. 3- Nos encontramos con una característica de Postgres, que no encontramos en Oracle, y es la posibilidad de crear reglas, las cuales sirven para poner condiciones a los updates, inserts o deletes en tablas o clases, y en Oracle tenemos que utilizar triggers para ello (en postgres también existen los triggers). Creación de Reglas: CREATE RULE name AS ON event TO object [ WHERE condition ] DO [ INSTEAD ] [ action NOTHING ] 4- En Postgres no existen los procedimientos, aunque existen AGGREGATE que son funciones de agregado de datos 5- En Postgres tenemos la posibilidad de realizar funciones y triggers en varios lenguajes de programación, y también tenemos la posibilidad de definir el lenguaje que queramos, como por ejemplo Pl-sql, lo cual nos serviría para migraciones, o para realizar funciones compatibles con Oracle. En general, no existen grandes diferencias entre la sintaxis de Postgres y Oracle en lo que respecta a la creación de tablas, vistas, etc. aunque si algunos parámetros que se llaman de forma distinta o bien no existen en uno u otro. ELEMENTOS: La ausencia de comparativas (en internet) entre estos SGBD, ha dificultado la tarea de realizar este análisis de similitudes y diferencias. Resulta curioso pero Oracle en su licencia prohíbe las comparativas sin su consentimiento: - disclose results of any program benchmark tests without our prior consent;

6 En las siguientes tablas podemos ver una información sobre Oracle y Postgres, además de comparar las principales características de estos dos SGBD: Información general: Soporte del sistema operativo Características fundamentales Información acerca de que características fundamentales de las RDBMS son implementados nativamente. Tablas y vistas Información acerca de que tablas y vistas (unas más básicos que otras) son soportados nativamente. Nota (4): La vista materializada puede ser emulada con PL/PgSQL Índices Información acerca de que índices (otros como los índices básicos B-/B+) son soportados nativamente. Otros objetos Información acerca de que otros objetos son soportados nativamente. Particionamiento Información acerca de que métodos de particionamiento son soportados nativamente. RENDIMIENTO: En este link encontramos una comparativa de rendimiento entre distintos SGBD, en concreto SQL Server, Oracle y PostgreSQL, pero nosotros obviaremos el producto de Microsoft ya que nuestro proyecto se centra en los otros dos sistemas mencionados. El estudio se basa en la medición del tiempo de ejecución de consultas de distinta complejidad, las cuales tienen los siguientes elementos:

7 Para esta comparativa se usaron las versiones ORACLE 10g XE y PostgreSQL 8.2.5, que no son las últimas versiones de ambos sistemas, por lo que los resultados pueden variar en la actualidad. Otro factor a tener en cuenta es el Pc en el que son llevadas a cabo las pruebas, el cual es bastante cortito por decirlo de algún modo: Y bien es conocido Oracle por consumir bastantes recursos, con lo cual sale perjudicado, pero no obstante mostraremos los resultados para comprobar empíricamente como se comportan en igualdad de condiciones estos dos sistemas. Según los resultados obtenidos en este análisis de rendimiento en consultas de complejidad baja PostgreSQL es 1.6 veces más rápido que Oracle, en consultas de complejidad media esta diferencia se reduce a 1.1, y en consultas de complejidad alta Oracle es 1.6 veces más rápido que PostgreSQL.

8 3 Instalación de postgres y pgadmin en Debian Squeeze: Para instalar PostgresSQL solamente tenemos que hacer lo siguiente: # aptitude install postgresql Ya tenemos corriendo PostgresSQL, y para comprobarlo miramos los puertos que ha abierto el servidor: root@usuario:/home/usuario# netstat -putan grep postgres tcp : :* LISTEN 18271/postgres tcp6 0 0 ::1:5432 :::* LISTEN 18271/postgres udp6 0 0 ::1:51681 ::1:51681 ESTABLISHED 18271/postgres Ahora instalaremos una aplicación gráfica que nos hará más sencillo el manejo de PostgresSQL: # aptitude install pgadmin3 Conexiones remotas: Por motivos de seguridad postgres no tiene activo el aceptar conexiones remotas. Para activar esta característica realizaremos los siguientes pasos: 1- Editaremos el fichero /etc/postgresql/8.4/main/pg_hba.conf y permitiremos conexiones con autenticación MD5. remotas pero # nano /etc/postgresql/8.4/main/pg_hba.conf # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all ident Cambiamos el método ident por md5 para que sea este el método de autenticación: # TYPE DATABASE USER CIDR-ADDRESS METHOD # "local" is for Unix domain socket connections only local all all md5 2- Editamos el archivo /etc/postgresql/8.4/main/postgresql.conf: Buscamos la siguiente línea: #listen_addresses = localhost La descomentamos y modificamos lo siguiente: listen_addresses = * Luego buscamos la siguiente línea y la descomentamos: #password_encryption = on 3- Cambiaremos la contraseña que nos trae por defecto postgres, para ello: # passwd postgres Nos pide la nueva contraseña en este caso postgres (ya que se trata de un proyecto esa por sencillez). 4- Cambiaremos la contraseña al administrador de la BD postgres: #sudo su postgres -c psql Con el siguiente comando SQL cambiamos la contraseña del administrador. académico, elegimos

9 postgres=#alter USER postgres WITH PASSWORD 'postgres'; Saldremos de la linea de comando de postgres con \q. Ya podemos acceder a administrar nuestro servidor PostgresSQL a través de pgadmin, al cual accederemos a través del menú Aplicaciones Programación pgadmin III. Ahora debemos realizar una conexión de pgadmin a nuestro sistema gestor de bases de datos, para ello tenemos que pulsar en el botón realizar una nueva conexión : Nos aparecerá la siguiente ventana, la cual rellenaremos indicándole el nombre de nuestra conexión, como Servidor localhost y lo demás lo dejamos por defecto. Como podemos ver en la siguiente captura ya esta creada nuestra conexión con la BD. *Observando el explorador de objetos de pgadmin podemos ver una pestaña catalogo. En ella podemos encontrar las tablas que son el equivalente al diccionario de datos de Oracle, también podemos encontrar triggers, funciones...

10 4 Creación de objetos en Postgres: Para crear tablas en postgressql desplegaremos en el menú el esquema public y pulsamos botón derecho del ratón encima del icono Tablas, y escogemos la opción Nueva tabla en el menú desplegable: Nos aparecerá una ventana en la que podemos crear la tabla mediante esta interfaz gráfica, en la cual a través de las diferentes pestañas que tenemos arriba podemos asignarle todas las propiedades de tabla:

11 O también podemos hacerlo utilizando un editor de SQL, que es el método que vamos a utilizar. Para ello pulsaremos en el icono y se abrirá un editor SQL en el que crearemos la tabla: Ejecutamos la sentencia y comprobamos que se ha creado correctamente: Antes de seguir añadiremos a Postgres el lenguaje plpgsql para procedimientos, ya que por defecto no viene activo. Para ello ejecutamos en el editor SQL la siguiente sentencia: CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER plpgsql_call_handler VALIDATOR plpgsql_validator; Crearemos una serie de elementos que serán los que luego migremos. Esos elementos son los siguientes: Usuarios: CREATE USER administrador WITH PASSWORD 'administrador'; CREATE USER jefe WITH PASSWORD 'jefe'; CREATE USER pringui WITH PASSWORD 'pringui'; Tablas: CREATE TABLE DEPARTAMENTOS ( deptno varchar(4) PRIMARY KEY, dname varchar(30) NOT NULL, loc varchar(20) ); CREATE TABLE EMPLEADOS ( empno varchar(5) PRIMARY KEY, ename varchar(30) NOT NULL, sal float(7,2) CONSTRAINT sal_minimo CHECK( sal > 600), hiredate date, deptno varchar(4) REFERENCES DEPARTAMENTOS (deptno) ); Establecemos los permisos para que el usuario jefe pueda consultar las dos tablas y el usuario pringui solo la tabla EMPLEADOS: GRANT SELECT ON DEPARTAMENTOS TO jefe; GRANT SELECT ON EMPLEADOS TO jefe; GRANT SELECT ON EMPLEADOS TO pringui; Por último introducimos datos en las tablas. Esto lo haremos del mismo modo que con Oracle: INSERT INTO nombre_tabla ( campo1, campo2, campo3,...) VALUES( valor1, valor2, valor3,...);

12 5 Instalación de aplicación de migración de tablas: Navicat: Nos descargamos Navicat, programa que sirve para la administración de varios SGBD y permite la conexión a varios de ellos simultáneamente. Lo hemos instalado en Windows, y no hay ningún paso a resaltar de la instalación ya que es el típico siguiente, siguiente. Nota*: Para poder realizar la conexión con Oracle necesitamos tener instalados unos paquetes, los cuales podemos descargar de la página de descargas de Oracle. Una vez allí nos descargamos el paquete instantclient-basic-win zip y instantclient-sqlplus-win zip. Para poder descargar el paquete debemos estar registrados. Una vez que los descarguemos los descomprimimos en un directorio cualquiera. Configuramos Navicat para poder realizar la conexión con Oracle, para ello nos vamos al menú Tools Options y elegimos OCI del menú de la izquierda, y veremos lo siguiente: Seleccionamos los ficheros y pulsamos Ok. Crear conexiones con Oracle y Postgres Pulsamos en el botón y seleccionamos en primer lugar Oracle de la lista desplegable. Introducimos los datos para crear la conexión:

13 Abrimos de nuevo el asistente para conexiones y esta vez elegimos Postgres:

14 Y ya tenemos creadas las conexiones con ambas bases de datos:

15 6 Migracion de tablespace y tablas: Postgres Oracle: Una vez realizada la conexión con las bases de datos nos disponemos a realizar la migración de tablas y datos: Hacemos click derecho sobre el icono de la conexión de Postgres, y seleccionamos Data Transfer en el menú desplegable: Veremos la siguiente pantalla:

16 En la izquierda nos encontramos el menú Source, donde podremos especificar los elementos a migrar. - Elegimos la base de datos y el esquema en los que están las tablas que queremos migrar. - Seleccionamos las tablas que queremos incluir en la migración. En la derecha vemos el menú Target en el que elegiremos el SGBD destino de las tablas. Pulsamos Start. Como podemos ver ha finalizado con éxito. *Nota: Al comprobar vemos que las tablas han sido migradas con todos sus registros, pero ni constraints ni de los índices, por lo que habría que migrarlos a mano. rastro de las

17 7 Scripts de migración Postgres Oracle: Migración de usuarios: La migración de usuarios debemos hacerla mediante la utilización de scripts. Primero nos vamos al editor SQL de Postgres y ejecutamos el siguiente script: SELECT 'CREATE USER ' usename ' IDENTIFIED BY ' usename ' PASSWORD EXPIRE' FROM pg_shadow; Nos devolverá como resultado el listado de todos los usuarios del sistema. Vamos al menú Archivo Exportar y elegimos no entrecomillado y desmarcamos Nombres de columnas. Por último seleccionamos el fichero al que queremos que vaya el resultado en nuestro caso script_usuarios. El contenido del fichero es el siguiente: Lo editamos para crear solo los usuarios que queramos: CREATE USER jefe IDENTIFIED BY jefe PASSWORD EXPIRE; CREATE USER pringui IDENTIFIED BY pringui PASSWORD EXPIRE; CREATE USER administrador IDENTIFIED BY administrador PASSWORD EXPIRE; Ahora nos vamos a un cliente SQL de Oracle, ejecutamos el script y obtenemos como resultado:

18 Haremos un script que tome los usuarios que tengan el permiso rolcanlogic en Postgres: SELECT 'GRANT CONNECT TO ' rolname ';' FROM pg_roles WHERE rolcanlogin='true' AND rolname IN (SELECT usename FROM pg_user); Hacemos lo mismo que con el anterior script, lo ejecutamos en Postgres y de nuevo lo exportamos a un fichero y el resultado lo editamos para dejar los usuarios a los que migramos anteriormente: GRANT CONNECT TO jefe; GRANT CONNECT TO pringui; GRANT CONNECT TO administrador; Y por último lo ejecutamos en SQL Plus de Oracle: *Nota: El permiso rolcanlogin es el equivalente a create session pero hemos decidido hacer el script con rol connect para que los usuarios puedan hacer consultas a los objetos de su esquema. Por último asignaremos al usuario administrador como propietario de las tablas (más tarde deberíamos asignarle los permisos a jefe y pringui sobre las mismas):

19 8 Migracion de tablespace y tablas: Oracle - Postgres: En este punto de nuevo utilizaremos Navicat, repitiendo los mismos pasos que en el punto 6 pero eligiendo esta vez como Source nuestro servidor Oracle y como Target nuestro servidor Postgres. Para poder migrar las tablas debemos desmarcar la opción del recuadro rojo: Si no lo desmarcamos intentará borrar las tablas en el servidor Postgres antes de migrarlas, y como no existen nos arroja un fallo.

20 Comprobamos que se ha completado correctamente: Con Navicat no podemos migrar vistas, procedimientos, triggers, etc, sin embargo podemos utilizar la opción de exportar a un fichero esos objetos, y una vez tengamos ese fichero hacer las modificaciones de sintaxis para adaptarlos al otro SGBD y por último ejecutarlos. Esto se puede hacer tanto en un sentido como en el otro. Por ejemplo, tenemos la vista NOMBRE_DEPTOS, la cual exportamos a un fichero llamado dname.sql:

21 El contenido de ese fichero es el siguiente: /* Navicat Oracle Data Transfer Oracle Client Version : Source Server : ORACLE Source Server Version : Source Host : :1521 Source Schema : SCOTT Target Server Type : ORACLE Target Server Version : File Encoding : Date: :40:33 */ View structure for "NOMBRE_DEPTOS" CREATE VIEW "NOMBRE_DEPTOS" AS SELECT dname FROM dept; Nos vamos a Postgres y hacemos los cambios pertinentes en la sintaxis, en este caso solo tenemos que poner dname y dept en mayúsculas puesto que en Oracle todo se guarda en mayúsculas, y al pasar las tablas a Postgres se pasa todo en mayúsculas también. Ejecutamos en Postgres: Y ya tenemos la vista migrada. Como dijimos anteriormente podemos hacer este mismo proceso para todos los objetos que no hemos conseguido migrar con Navicat o con scripts, tanto en un sentido como en otro.

22 9 Scripts de migración Oracle - Postgres: Migración de usuarios: El script para migración de usuarios de Oracle a Postgres es el siguiente: SELECT 'CREATE USER ' username ' WITH PASSWORD ''' username ';' FROM dba_users; Lo ejecutamos en SQL Developer y nos devuelve un listado con los usuarios del sistema, pero dejaremos solo dos para migrar: CREATE USER SCOTT WITH PASSWORD 'SCOTT'; CREATE USER MARIO WITH PASSWORD 'MARIO'; Por último ejecutamos estas dos sentencias en Postgres. Nota*: Hemos intentado encontrar un parámetro para hacer que la contraseña expirara al iniciar sesión el usuario y encontramos el parámetro VALID UNTIL, este parámetro funciona con una fecha, y no al inicio de sesión. Por otra parte no hace falta asignarle permisos de crear sesión puesto que en Postgres los usuarios pueden conectarse por defecto.

23 CONCLUSIÓN: Este proyecto nos ha servido para darnos cuenta de la minuciosidad y de la dificultad para llevar a cabo una migración completa y correcta entre estos SGBD, tanto en un sentido como en otro, ya que hay que salvar importantes diferencias en su arquitectura interna y su funcionamiento en general. Concretamente las mayores diferencias que nos hemos encontrado son el sistema de permisos, el cual se almacena de manera muy distinta en ambos SGBD, los distintos lenguajes de programación utilizados para funciones, triggers, etc., que fuerzan a que se tengan que migrar a mano. Así que podemos determinar que en caso de tenernos que enfrentar a una migración debemos ser muy organizados y sobre todo armarnos de paciencia.