2011-07-03 16 views
42

Tengo una base de datos PostgreSQL que quiero mover a SQL Server, tanto el esquema como los datos. Soy pobre, así que no quiero pagar ningún dinero. También soy flojo, así que no quiero hacer mucho trabajo. Actualmente estoy haciendo esta tabla por tabla, y hay alrededor de 100 tablas para hacer. Esto es extremadamente tediosoLa forma más fácil de migrar una base de datos PostgreSQL a un servidor SQL

¿Hay algún truco que haga lo que yo quiero?

+2

Debo preguntar, si no tiene dinero, ¿por qué se muda a SQL Server? Si bien Express puede ser gratuito, la infraestructura necesaria para implementarlo no será ... –

+8

Estos votos a favor son tontos; es una pregunta legítima y MS SQL -> las preguntas de migración de MySQL se han actualizado aquí. Me estoy mudando a SQL Server porque ya tengo una base de datos que es MS SQL, pero una gran cantidad de datos valiosos que puedo usar solo existen en una base de datos PostgreSQL. El alojamiento de la mayoría de los servidores cuesta aproximadamente el mismo precio y me gusta ASP.NET MVC 3 ya que no incluye complementos de terceros. LINQ to SQL es flakey con PostgreSQL. – Hut8

+0

¿Qué problemas encuentra al usar el método SQL pg_dump e importar DDL/DML en SQL Server? ¿Qué quieres decir con "estoy haciendo esta tabla por tabla"? –

Respuesta

43

Creo que puede haber obtenido votos bajos debido a la increíble facilidad de generar un script SQL simple de PostgreSQL que (teóricamente) se puede ejecutar de nuevo casi cualquier DBMS. Si uno es un usuario regular de PostgreSQL, suena como una pregunta tonta.

Eso no es justo ya que resulta que este es en realidad un problema moderadamente difícil (aunque más debido a la interfaz e interfaz impar de SQL Server que a cualquier falla de PostgreSQL).

Debería poder encontrar información útil en la respuesta aceptada en esta página Serverfault: https://serverfault.com/questions/65407/best-tool-to-migrate-a-postgresql-database-to-ms-sql-2005.

Si puede obtener el esquema convertido sin los datos, es posible que pueda acortar los pasos para los datos mediante el uso de este comando:

pg_dump --data-only --column-inserts your_db_name > data_load_script.sql 

Esta carga será bastante lento, pero la opción --column-inserts genera las instrucciones INSERT más genéricas posibles para cada fila de datos y deberían ser compatibles.

EDIT: Sugerencias para convertir el esquema siguiente:

Me gustaría empezar por el vertido del esquema, pero la eliminación de cualquier cosa que tenga que ver con la propiedad o permisos. Esto debería ser suficiente:

pg_dump --schema-only --no-owner --no-privileges your_db_name > schema_create_script.sql 

Editar este archivo para agregar la línea de BEGIN TRANSACTION; al principio y ROLLBACK TRANSACTION; hasta el final. Ahora puede cargarlo y ejecutarlo en una ventana de consulta en SQL Server. Si obtiene algún error, asegúrese de ir al final del archivo, resalte la declaración ROLLBACK y ejecútela (presionando F5 mientras la instrucción está resaltada).

Básicamente, debe resolver cada error hasta que la secuencia de comandos se ejecute limpiamente. Luego puede cambiar el ROLLBACK TRANSACTION al COMMIT TRANSACTION y ejecutarlo por última vez.

Desafortunadamente, no puedo evitar los errores que puede ver, ya que nunca he pasado de PostgreSQL a SQL Server, sino al revés. Algunas cosas que yo esperaría a ser un problema, sin embargo (obviamente, no es una lista exhaustiva):

  • PostgreSQL campos de incremento automático mediante la vinculación de un campo NOT NULL INTEGER a un SEQUENCE utilizando un DEFAULT. En SQL Server, esta es una columna IDENTITY, pero no son exactamente lo mismo. No estoy seguro de si son equivalentes, pero si su esquema original está lleno de campos "id", puede que tenga problemas. No sé si SQL Server tiene CREATE SEQUENCE, por lo que es posible que deba eliminarlos.
  • Las funciones de la base de datos/Procedimientos almacenados no se traducen entre plataformas RDBMS. Tendrá que eliminar las declaraciones CREATE FUNCTION y traducir los algoritmos de forma manual.
  • Tenga cuidado con la codificación del archivo de datos.Soy una persona de Linux, así que no tengo idea de cómo verificar la codificación en Windows, pero debes asegurarte de que lo que SQL Server espera es lo mismo que el archivo que estás importando desde PostgreSQL. pg_dump tiene una opción --encoding= que le permitirá establecer una codificación específica. Me parece recordar que Windows tiende a usar una codificación UTF-16 de dos bytes para Unicode donde PostgreSQL usa UTF-8. Tuve un problema al pasar de SQL Server a PostgreSQL debido a la salida UTF-16, por lo que valdría la pena investigarlo.
  • El tipo de datos PostgreSQL TEXT es simplemente un VARCHAR sin una longitud máxima. En SQL Server, TEXT es ... complicado (y obsoleto). Cada campo en su esquema original que se declare como TEXT deberá revisarse para un tipo de datos de SQL Server apropiado.
  • SQL Server tiene tipos de datos adicionales para los datos UNICODE. No estoy lo suficientemente familiar como para hacer sugerencias. Solo estoy señalando que puede ser un problema.
+0

Información impresionante. Muchas gracias. ¿Algún consejo para convertir el esquema sin un producto comercial?Estoy perplejo aquí también. – Hut8

+0

Se agregaron más detalles. Tenga en cuenta que también he corregido la versión de datos del comando pg_dump para agregar la opción crítica: --data-only. –

1

He encontrado una forma más rápida y fácil de lograr esto.

primera copia de su tabla (o consulta) a un archivo delimitado por tabuladores, así:

COPY (SELECT siteid, searchdist, listtype, list, sitename, county, street, 
    city, state, zip, georesult, elevation, lat, lng, wkt, unlocated_bool, 
    id, status, standard_status, date_opened_or_reported, date_closed, 
    notes, list_type_description FROM mlocal) TO 'c:\SQLAzureImportFiles\data_script_mlocal.tsv' NULL E'' 

continuación, tiene que crear la tabla en SQL, esto no va a manejar cualquier esquema para usted. El esquema debe coincidir con su archivo tsv exportado en orden de campo y tipos de datos.

Finalmente se ejecuta la utilidad bcp de SQL para llevar en el archivo TSV de este modo:

bcp MyDb.dbo.mlocal in "\\NEWDBSERVER\SQLAzureImportFiles\data_script_mlocal.tsv" -S tcp:YourDBServer.database.windows.net -U YourUserName -P YourPassword -c 

Un par de cosas de la nota que me encontré. Postgres y SQL Server manejan campos booleanos de manera diferente. Su esquema de SQL Server necesita tener sus campos booleanos establecidos en varchar (1) y los datos resultantes serán 'f', 't' o null. Luego tendrá que convertir este campo a un bit. hacer algo como:

ALTER TABLE mlocal ADD unlocated bit; 
UPDATE mlocal SET unlocated=1 WHERE unlocated_bool='t'; 
UPDATE mlocal SET unlocated=0 WHERE unlocated_bool='f'; 
ALTER TABLE mlocal DROP COLUMN unlocated_bool; 

Otra cosa son los campos de geografía/geometría son muy diferentes entre las dos plataformas. Exporte los campos de geometría como WKT usando ST_AsText(geo) y conviértalo apropiadamente en el extremo de SQL Server.

Puede haber más incompatibilidades que necesitan ajustes como este.

EDITAR. Entonces, mientras que esta técnica funciona técnicamente, estoy tratando de transferir varios millones de registros de más de 100 tablas a SQL Azure y bcp a SQL Azure es bastante escamosa. Sigo recibiendo intermitentemente No se pueden abrir los errores del archivo de datos del host BCP, el servidor se interrumpe intermitentemente y por alguna razón algunos registros no se transfieren sin indicaciones de errores o problemas. Por lo tanto, esta técnica no es estable para transferir grandes cantidades de datos a Azure SQL.

Cuestiones relacionadas