Este documento presenta una comparación entre Microsoft SQL Server y PostgreSQL, y proporciona recomendaciones para realizar una migración de MSSQL a PostgreSQL. Se compara las capacidades, arquitectura, cumplimiento ACID, lenguajes procedurales y herramientas de administración. También cubre los pasos para preparar la migración, modificar scripts de MSSQL, cargar datos e implementar procedimientos almacenados y cursores en PostgreSQL. El documento concluye con casos de éxito y una demostración de 15 minutos de la migración.

1. Migrando de MSSQL a PostgreSQL
- Duración 45 minutos -
Lic. Simón Castellanos
EMACS CONSULTORES

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. 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. Agenda
Parte II – Migración MSSQL / PGSQL (20min)
9. Preparativos migración
10. Modificar Script de MSSQL a PGSQL
11. Subir datos a PostgreSQL
12.Procedimintos Almacenados
13. Manejo de Cursores
14. Recomendaciones para migración
15. Casos de exito
16. Demostración (15min)

5. PARTE I
COMPARACIÓN MSSQL VS PGSQL
- Duración 10 minutos -

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. Evaluando la capacidad
CARACTERISTICA MSSQL POSTGRESQL
2005/2008 v8/v9
Máximo de base de 524.272 TB ILIMITADO*
datos
Máximo de tamaño 16 TB 32TB
de tabla
Máximo de tamaño 2 TB 1.6TB
de registro
Máximo de tamaño 2Gb 1GB
de campo
Máximo de registros ILIMITADO* ILIMITADO*
por Tabla
Máximo de campos 1000 250 a 1600
por tabla
Máximo de índices 999 ILIMITADO*
por tabla
*Limitado por el espacio de almacenamiento disponible

8. Arquitectura de procesos vs hilos (I)
MSSQL PGSQL
Proceso 1 Proceso 2 Proceso 3
Proceso
Subproceso Subproceso Subproceso Postgres Postgres Postgres
Memory Pool

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. 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. 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. 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. Lenguaje Procedurales (II)
Transact-SQL PL/pgSQL PL/Perl
PL/Java PL/Ruby
PL/Python
create language plpgsql;

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. 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. 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. 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. Herramientas de Administración (I)
Microsoft SQL
PGADMIN3 - PostgreSQL

19. Herramientas de Administración (II)
Microsoft SQL
PGADMIN3 - PostgreSQL

20. Herramientas de Administración (III)
WEB DATA - MSSQL
PGPHPADMIN - PostgreSQL

21. Herramientas de Administración (IV)
sqlcmd
psql

22. PARTE II
MIGRACIÓN MSSQL VS PGSQL
- Duración 20 minutos -

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. 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. Subir datos a PostgreSQL
● Es necesario ejecutar un COPY por cada tabla
creada en PGSQL
COPY FROM TableName "/ home / Homer / workdir / NombreDeTabla

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. 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. 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. 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. 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. 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. 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. Casos de exitos
● Capacitación -Administración SGBD
● PL/pgSQL
● MVCC
● ACID
● Evaluación Técnica Diagnostica
– Diseño
– Servicio SGBD
– Conexion Aplicaciones

34. Demostración
Migracion 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. 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.