Migrando de MSSQL a PostgreSQL

4,610 views

Published on

Ponencia de Migración a PostgreSQL de EMACS CONSULTORES

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,610
On SlideShare
0
From Embeds
0
Number of Embeds
134
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Migrando de MSSQL a PostgreSQL

  1. 1. Migrando de MSSQL a PostgreSQL - Duración 45 minutos - Lic. Simón Castellanos EMACS CONSULTORES
  2. 2. Objetivo de ponencia● Presentar las mejores practicas para realizar un cambio de las estructuras de tablas, tipo de datos y relaciones de Microsoft SQL Server (7, 2000 y 2005) a PostgreSQL (7 y 8).● Exponer recomendaciones tecnicas y problemás frecuentes al realizar el proceso de migración.
  3. 3. Agenda Parte I – Comparación MSSQL / PGSQL (10min)1.¿Por que PostgreSQL?.2.Evaluando la capacidad.3.Arquiectura de procesos.4.Cumplimiento ACID.5. Lenguajes Procedurales.6. SGBD Objeto Relacional.7.Manejo de Concurrencia.8.Herramientas de Administración
  4. 4. Agenda Parte II – Migración MSSQL / PGSQL (20min)9. Preparativos migración10. Modificar Script de MSSQL a PGSQL11. Subir datos a PostgreSQL12.Procedimintos Almacenados13. Manejo de Cursores14. Recomendaciones para migración15. Casos de exito16. Demostración (15min)
  5. 5. PARTE ICOMPARACIÓN MSSQL VS PGSQL - Duración 10 minutos -
  6. 6. ¿Por qué PostgreSQL?● Instalación ilimitada● Ahorros considerables en costos de operación● Mejor soporte que los proveedores comerciales● Estabilidad y confiabilidad legendarias● Extensible● Multiplataforma● Diseñado para ambientes de alto volumen
  7. 7. Evaluando la capacidadCARACTERISTICA MSSQL POSTGRESQL 2005/2008 v8/v9Máximo de base de 524.272 TB ILIMITADO*datosMáximo de tamaño 16 TB 32TBde tablaMáximo de tamaño 2 TB 1.6TBde registroMáximo de tamaño 2Gb 1GBde campoMáximo de registros ILIMITADO* ILIMITADO*por TablaMáximo de campos 1000 250 a 1600por tablaMáximo de índices 999 ILIMITADO*por tabla *Limitado por el espacio de almacenamiento disponible
  8. 8. Arquitectura de procesos vs hilos (I) MSSQL PGSQL Proceso 1 Proceso 2 Proceso 3 ProcesoSubproceso Subproceso Subproceso Postgres Postgres Postgres Memory Pool
  9. 9. Arquitectura de procesos vs hilos (II) PGSQL● Postmaster ● Por cada cliente se realiza un fork() ● Cada conexión es un nuevo proceso ● No hay hebras (no subprocesos!) MSSQL● Instancia ● Por cada cliente reutiliza el proceso unico. ● Cada conexión es un nuevo subproceso sobre el proceso. ● Se mantiene un memory pool para la concurrencia multiple.
  10. 10. Cumplimiento ACID (I)● Atomicidad: asegura que la operación se ha realizad sea completada con exito sin quedar a medias.● Consistencia: aplicación de reglas y directrices de integridad de la base de datos.● Aislamiento: asegura que dos transacciones sobre la misma información nunca generará ningún tipo de error.● Durabilidad: asegura no se podrá deshacer una operación aunque falle el sistema.
  11. 11. Cumplimiento ACID (II)● A continuación comparación ACID entre MSSQL y PostgreSQL CARACTERISTICA MSSQL POSTGRESQL (A)TOMICY begin,end,rollback, begin,end,rollback, savepoint savepoint (C)ONSISTENCY Check, primary key, Not null, check, unique, foreing key, unique. primary key match, partial (I)SOLATION Block table MVCC (D)URABILITY Transaction Log WAL (write Ahead Log)
  12. 12. Lenguajes Procedurales (I)● Ambas bases de datos incluyen lenguaje procedurales (imperativos) para SQL cualquiera ya que incluye características propias de cualquier lenguaje de programación, características que nos permiten definir la lógica necesaria para el tratamiento de la información. ● Tipos de datos ● Definición de variables. ● Estructuras de control de flujo. ● Funciones predefinidas
  13. 13. Lenguaje Procedurales (II) Transact-SQL PL/pgSQL PL/Perl PL/Java PL/Ruby PL/Pythoncreate language plpgsql;
  14. 14. SGBD Objeto Relacional● La herencia de tablas permite aplicar el analisis y diseño orientado a objetivos (ADOO) y evitaria la necesidad de implementar Mapeo Objeto-Relacional (ORM). Por ejemplo propel o doctrine para PHP. create table persona ( nombre varchar (30), direccion varchar (30) ); create table estudiante ( carrera varchar(50), grupo char, grado int inherits ( persona ) );
  15. 15. Manejo de Concurrencia (I)MSSQL● Posibles soluciones: ● Bloquear la tabla completa con acceso limitado ● Bloquear sólo algunos campos● Nuevo problema: ● Rendimiento es pésimo ● Usuarios deben esperar a que el lock desaparezca ● Aún para lecturas!
  16. 16. Manejo de Concurrencia (II) PGSQL● MVCC (Multi-versioning and Locking) ● Crear “copias” dentro de una transacción ● No bloquear HASTA que sea necesario ● Las lecturas no son bloqueadas ● El bloqueo se hace en un COMMIT ● Si hay ROLLBACK el resto de las transacciones nunca “sufrieron” pérdida de rendimiento ni esperas en el acceso a los datos
  17. 17. Manejo de Concurrencia (III)EN RESUMEN● Con MVCC cada usuario obtiene una visión consistente de lo último a lo que se le hizo commit.● Esta estrategia es superior al uso de bloqueos por tabla o por filas común en otras bases, eliminando la necesidad del uso de bloqueos explícitos
  18. 18. Herramientas de Administración (I) Microsoft SQL PGADMIN3 - PostgreSQL
  19. 19. Herramientas de Administración (II) Microsoft SQL PGADMIN3 - PostgreSQL
  20. 20. Herramientas de Administración (III) WEB DATA - MSSQL PGPHPADMIN - PostgreSQL
  21. 21. Herramientas de Administración (IV) sqlcmd psql
  22. 22. PARTE IIMIGRACIÓN MSSQL VS PGSQL - Duración 20 minutos -
  23. 23. Preparativos de Migración● Generate Script con sentencias CREATE TABLE● Generar BCP o BULLCOPY bcp "pubs copy..my table" in authors.txt -c -q -Sserver_name -U"my name" -P"my pass"select "bcp " + rtrim(name) + " out " + rtrim(name) + ".bcp " + " -Usa -P -c -SLANCELOT" from sysobjects where type =U
  24. 24. Modificar Script de MSSQL a PGSQL● Aprovechar la migración realizando un ajustes de los campos de la bases de datos, selecionando tipos de datos más optimos para el rendimiento.● [DBO]● [GO]● Sustituir Datetime Date● Varchar(20) por char(20)
  25. 25. Subir datos a PostgreSQL ● Es necesario ejecutar un COPY por cada tabla creada en PGSQLCOPY FROM TableName "/ home / Homer / workdir / NombreDeTabla
  26. 26. Procedimiento Almacenados● En PGSQL no existen "Procedimientos Almacenados" como tales, sino mas bien "Funciones Almacenadas", eso quiere decir que siempre estaremos obligados a devolver algo desde nuestros "SPs".● Declaracion de variables: MSSQL: se usa la palabra DECLARE y el nombre debe empezar con el simbolo @. PGSQL: se hace el estilo de C o de java, es decir identificador seguido del tipo de dato. DECLARE @mivar INT mivar int;
  27. 27. Procedimiento Almacenados (II)● Asignaciones de valores a variables: MSSQL: se usa SET. PGSQL: se usa el simbolo := . SET mivar=10.5 mivar:=10.5;● Devolución de registros: En MSSQL se hace el select directamente y punto. create procedure consulta as select * from mitabla
  28. 28. Procedimiento Almacenados (III)● PGSQL: como dije anteriormente en PGSQL se usan "funciones Almacenadas" por lo que debemos indicar a nuestra funcion el tipo a devolver. Lo mejor es usar el tipo pg_catalog.refcursor, que creo que esta disponible recien desde la version 8.x de PGSQL. CREATE OR REPLACE FUNCTION consulta() RETURNS "pg_catalog"."refcursor" AS declare data refcursor; begin open data for ( Select * from mitabla ); return data; END;
  29. 29. Manejo de Cursores (I)● En MSSQL los cursores se manejan de la siguiente forma: declare @v_1 varchar(10) declare @v_2 varchar(10) declare cur1 cursor for select * from mitabla OPEN cur1 FETCH NEXT FROM cur1 INTO @v_1, @v_2 WHILE @@FETCH_STATUS = 0 BEGIN print Valor 1 +v_1 print Valor 2 +v_2 FETCH NEXT FROM cur1 INTO @v_1, @v_2 END CLOSE cur1
  30. 30. Manejo de Cursores (II)● En PostgreSQL los cursores se manejan de la siguiente manera: declare cur1 refcursor; v_1 varchar (10) ; v_2 varchar (10) ; begin OPEN cur1 FOR execute(select * from mitabla); loop fetch cur1 into v_1, v_2; if not found then exit ; end if; RAISE NOTICE Valor 1(%), v_1; RAISE NOTICE Valor 2(%), v_2; end loop; close cur1; end;
  31. 31. Recomendaciones (I)● 1ero. Conocer la estructura de bases de datos E/R para luego realizar la exportación del script de toda la Base de datos sin relaciones● 2do. Con el script se realiza las conversiones necesarias en tipos de datos IDENTITY, DATETIME,VARCHAR.● 3ero. Bajar la data del MSSQL a texto plano, tipo csv, es decir valores separados por comas. Utilizar BULLCOPY.● 4do. Usar el comando COPY.. FROM de PGSSQL para cargar a data desde los arhivos de texto a las tablas de PGSQL.
  32. 32. Recomendaciones (II)● 5to. Con todas las tablas y datos se pueden reconstruir las realaciones con herramientas como pgdesiner o dbvisualizer.● 6to. Para los store prucedures será necesario sobrescribir la sintaxis de Transact-SQL a PL/pgSQL● 7to. Realizar los ajustes o entonación del SGBD PostgreSQL para obtener un mejor rendimiento asi como la seguridad sobre los objetos de bases de datos.
  33. 33. Casos de exitos● Capacitación -Administración SGBD ● PL/pgSQL ● MVCC ● ACID● Evaluación Técnica Diagnostica – Diseño – Servicio SGBD – Conexion Aplicaciones
  34. 34. DemostraciónMigracion de Script Generado en Microsoft SQL Server a PostgreSQL server. Tablas y relaciones Check o Restricciones Trigger y Store Procedure - Duración 15 minutos -
  35. 35. Más Información Lic. Simón Castellanos Gerente de Operaciones Para mayor informacion puede escribirnos a emacs.computacion@gmail.com o llamar al 0416-821-06-90 / 0212-576-02-91 o visitarnos a:Av. Universidad, Edificio Centro de Parque Carabobo, Torre A, Piso 8 Oficina 812. Frente a la Estacion del Metro Parque Carabobo. Caracas - Venezuela.

×