none
Exportação banco para um modelo diferente RRS feed

  • Pergunta

  • Pessoal,

    Tive que reformular um banco de dados inteiro e pra isso era melhor criar do zero do que qualquer outra coisa. Então foi trocado nome de tabelas,nomes de campos, adicionado FKS e em alguns casos o tipo de data(Mas foi tipo de bigInt pra int, por exemplo). Alguém sabe qual a melhor maneira de eu exportar os dados do banco 'antigo' pro novo?

    Obrigado!

    quinta-feira, 23 de outubro de 2014 13:55

Respostas

  • Rafa,

    Acho que o melhor seria através do BIDS no SQL Server 2008 que se tornou SQL Server Data Tools no SQL Server 2012.

    Estabelecer uma conexão para cada banco de dados, e através dos components de consulta aos dados, fazer o mapeamento entre cada tabela, pois como ocorreu mudanças na estrutura e nomenclatura, você vai ter que fazer este trabalho de mapear a origem para o destino e em muitos casos, utilizar por exemplo o componente DataConvert para realizes as devidas conversões. de dados.

    Outra possibilidade seria utilizar o SQL Server Import and Export Data, recurso existente dentro do Management Studio, mas que também no SQL Server 2012 e 2014 esta disponível de forma separada para ambientes 32 Bits e 64 Bits.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com


    quinta-feira, 23 de outubro de 2014 14:42
  • Rafa,

    Então existem algumas configurações que você pode fazer justamante para presenvar os valores do Identity, como também, para inserir novos valores!!!

    Neste caso, acho melhor você desabilitar a propriedade de identity nas tabelas que vão receber os dados e posteriormente após a migração faz a ativação do identity.

    Em outro cenário, você poderia ir fazendo a migração por partes, onde estaria migrando porções de dados por vez, assim você poderia ter o controle do que esta sendo migrado.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com

    sexta-feira, 24 de outubro de 2014 16:21
  • Rafa_WebDev,

    Fico feliz em saber que estamos ajudando!

    Sobre a estruturação dos tipos de dados no C#, realmente será necessário uma revisão para adequar a conversão dos valores entre os tipos do SQL Server e os referentes ao .Net Framework.

    Veja esta tabela comparativa para você adaptar seu código em C#:

    http://cbsa.com.br/post/tipos-de-dados-equivalentes-do-c-e-sql-valores-maximos-e-minimos-suportados.aspx

    http://msdn.microsoft.com/en-us/library/ms131092.aspx

    http://msdn.microsoft.com/pt-br/library/ms191530.aspx 

    A tabela acima foi indicada para VB, mas alguns tipos de dados são equivalentes (serve também para quem vier consultar este tópico futuramente).

    Sobre o Collation, se você está criando o banco de dados na mesma instância SQL do banco de dados original, então não há problema. Caso contrário, entre no SSMS, selecione seu banco de dados (origem) e clique com o botão direito em "Properties". Logo na primeira página existe a definição do Collation do seu banco. Você também poderá utilizar o script T-SQL abaixo para verificar o Collation de cada banco de dados de sua instância:

    SELECT name AS NomeBanco, 
    databasepropertyex(name, 'collation') AS Collation 
    FROM sysdatabases
    GO

    Sobre esta coluna com mais de 8000 caracteres, acredito que esta coluna originalmente deve ser datatype "text".

    De qualquer forma, esta tabela vai exigir um trabalho de análise para identificar quais são estes registros com mais de 8000 caracteres. Lembrando que as futuras versões do SQL Server não irão mais suportar o datatype "text".

    Segue abaixo um script T-SQL para auxiliar nesta análise, faça as alterações de acordo com sua necessidade:

    SELECT MAX(LEN(SuaColuna)) AS Tamanho, SuaColuna
    FROM SuaTabela
    GROUP BY SuaColuna
    HAVING MAX(LEN(SuaColuna)) > 7800
    GO

    Para estas colunas, verifique a relevância da informação. Se realmente é importante que seja importada para o banco de dados novo e se é possível ser reduzida para 8000 caracteres. Se ainda assim for necessário migrar as informações acima deste tamanho para esta coluna (poderá gerar lentidão em algumas consultas), então sugiro que você utilize o datatype "varchar" com alocação "MAX". Segue um exemplo de como converter sua informação para receber mais de 8000 caracteres:

    DECLARE @ORIGEM VARCHAR(8000) = REPLICATE('A',8000)
    DECLARE @DESTINO VARCHAR(MAX)
    SET @DESTINO = CONVERT(VARCHAR(MAX), @ORIGEM) + ' - Passou de 8000'
    
    PRINT (@DESTINO)
    PRINT datalength (@DESTINO)
    GO

    Mas para evitar problemas de performance, o ideal é recriar a tabela.

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    terça-feira, 28 de outubro de 2014 11:58
    Moderador
  • Junior, 

    Quando tento exportar os dados de uma tabela para outra recebo o erro:

     

    - Configuração de Conexão de Destino (Erro)
    Mensagens
    Erro 0xc0204016: SSIS.Pipeline: "Conversão de dados 2 - 0.Saídas[Saída de Conversão de Dados].Colunas[descricao]" tem um comprimento que não é válido. O comprimento deve ficar entre 0 e 4000.
     (Assistente de Importação e Exportação do SQL Server)

    Exceção de HRESULT: 0xC0204016 (Microsoft.SqlServer.DTSPipelineWrap)

    Acredito que seja por causa de uma coluna que tem tamanho máximo de 8000 caracteres. Outro ponto, é que estou trocando de varchar para nvarchar(pq criei o banco de dados utilizando CodeFirst) e não sei se isso impacta. Agora, o fato é que tentei trocar pra 4000 caracteres e recebi a mensagem de que eu teria q dropar a tabela pra fazer isso.

    Alguém saberia me dizer uma outra solução? Obrigado!

    Rafa_WebDev,

    Só tem sentido você alterar para o datatype "nvarchar" caso você utilize caracteres UNICODE em seu banco de dados, caso contrário você estará utilizando espaço desnecessário para armazenamento e consequentemente poderá trazer lentidão em futuras consultas (dependendo da quantidade de dados que possui).

    Verifique a quantidade total de caracteres nesta coluna, na sua tabela original para ter certeza que o tamanho de 4000 caracteres realmente atende sua necessidade. Segue abaixo um exemplo simples para realizar esta tarefa:

    SELECT MAX(LEN(SuaColuna)) FROM SuaTabela;
    GO

    Antes de iniciar a transferência dos dados, seria interessante fazer uma revisão se os novos datatypes deste novo banco vão realmente atender à sua necessidade, sem "quebra" de conteúdo.

    Como você está realizando uma migração de dados, a melhor opção mesmo é "dropar" e criar a tabela novamente. Procure evitar processos paliativos para "várias pequenas" correções, afinal você está migrando para um novo banco de dados para melhorar seu ambiente e não para criar novos problemas à serem corrigidos em curto e médio prazos.

    Outro ponto importante é rever se o Collation de seu novo banco de dados é compatível com o utilizado pelo banco de dados original. Caso ambos utilizem o mesmo Collation não haverá problema, caso contrário eu recomendo que você faça diversos testes de consulta antes de utilizar o novo banco de dados em Produção. Em alguns casos, algumas consultas deverão ser revisadas e alteradas.

    Como o Junior indicou anteriormente, utilizar o "Import Data..." ou "Export Data..." existente dentro do SSMS é uma alternativa simples e eficiente.

    Quando você possuir tabelas com colunas utilizando a propriedade "IDENTITY", basta você selecionar a tabela que utiliza a coluna IDENTITY e clicar em "Edit Mappings". Logo vai abrir a janela "Column Mappings", então selecione as opções para excluir os registros existentes no Destino e para habilitar o IDENTITY. 

    Veja na imagem abaixo:

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    segunda-feira, 27 de outubro de 2014 20:05
    Moderador

Todas as Respostas

  • Rafa,

    Acho que o melhor seria através do BIDS no SQL Server 2008 que se tornou SQL Server Data Tools no SQL Server 2012.

    Estabelecer uma conexão para cada banco de dados, e através dos components de consulta aos dados, fazer o mapeamento entre cada tabela, pois como ocorreu mudanças na estrutura e nomenclatura, você vai ter que fazer este trabalho de mapear a origem para o destino e em muitos casos, utilizar por exemplo o componente DataConvert para realizes as devidas conversões. de dados.

    Outra possibilidade seria utilizar o SQL Server Import and Export Data, recurso existente dentro do Management Studio, mas que também no SQL Server 2012 e 2014 esta disponível de forma separada para ambientes 32 Bits e 64 Bits.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com


    quinta-feira, 23 de outubro de 2014 14:42
  • Junior, 

    Muito obrigado pela resposta! Estou utilizando o export pra mapear os dados. 

    Aproveitando, só mais uma coisa, saberia me dizer se terei problemas ou terei que fazer algo para inserir por exemplo, em uma tabela que tem a primary key como identity linhas especificando a primary key como por exemplo '32'?

    Acredito que o sql server tenha que colocar a identity como OFF pra transferir os dados. Até porque essas primary keys precisam ser necessariamente os mesmos dados, já que serão foreign keys em outras tabelas.

    quinta-feira, 23 de outubro de 2014 17:21
  • Rafa,

    Então existem algumas configurações que você pode fazer justamante para presenvar os valores do Identity, como também, para inserir novos valores!!!

    Neste caso, acho melhor você desabilitar a propriedade de identity nas tabelas que vão receber os dados e posteriormente após a migração faz a ativação do identity.

    Em outro cenário, você poderia ir fazendo a migração por partes, onde estaria migrando porções de dados por vez, assim você poderia ter o controle do que esta sendo migrado.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | SoroCódigos] @JuniorGalvaoMVP | pedrogalvaojunior.wordpress.com

    sexta-feira, 24 de outubro de 2014 16:21
  • Junior, 

    Quando tento exportar os dados de uma tabela para outra recebo o erro:

     

    - Configuração de Conexão de Destino (Erro)
    Mensagens
    Erro 0xc0204016: SSIS.Pipeline: "Conversão de dados 2 - 0.Saídas[Saída de Conversão de Dados].Colunas[descricao]" tem um comprimento que não é válido. O comprimento deve ficar entre 0 e 4000.
     (Assistente de Importação e Exportação do SQL Server)

    Exceção de HRESULT: 0xC0204016 (Microsoft.SqlServer.DTSPipelineWrap)

    Acredito que seja por causa de uma coluna que tem tamanho máximo de 8000 caracteres. Outro ponto, é que estou trocando de varchar para nvarchar(pq criei o banco de dados utilizando CodeFirst) e não sei se isso impacta. Agora, o fato é que tentei trocar pra 4000 caracteres e recebi a mensagem de que eu teria q dropar a tabela pra fazer isso.

    Alguém saberia me dizer uma outra solução? Obrigado!

    segunda-feira, 27 de outubro de 2014 19:18
  • Junior, 

    Quando tento exportar os dados de uma tabela para outra recebo o erro:

     

    - Configuração de Conexão de Destino (Erro)
    Mensagens
    Erro 0xc0204016: SSIS.Pipeline: "Conversão de dados 2 - 0.Saídas[Saída de Conversão de Dados].Colunas[descricao]" tem um comprimento que não é válido. O comprimento deve ficar entre 0 e 4000.
     (Assistente de Importação e Exportação do SQL Server)

    Exceção de HRESULT: 0xC0204016 (Microsoft.SqlServer.DTSPipelineWrap)

    Acredito que seja por causa de uma coluna que tem tamanho máximo de 8000 caracteres. Outro ponto, é que estou trocando de varchar para nvarchar(pq criei o banco de dados utilizando CodeFirst) e não sei se isso impacta. Agora, o fato é que tentei trocar pra 4000 caracteres e recebi a mensagem de que eu teria q dropar a tabela pra fazer isso.

    Alguém saberia me dizer uma outra solução? Obrigado!

    Rafa_WebDev,

    Só tem sentido você alterar para o datatype "nvarchar" caso você utilize caracteres UNICODE em seu banco de dados, caso contrário você estará utilizando espaço desnecessário para armazenamento e consequentemente poderá trazer lentidão em futuras consultas (dependendo da quantidade de dados que possui).

    Verifique a quantidade total de caracteres nesta coluna, na sua tabela original para ter certeza que o tamanho de 4000 caracteres realmente atende sua necessidade. Segue abaixo um exemplo simples para realizar esta tarefa:

    SELECT MAX(LEN(SuaColuna)) FROM SuaTabela;
    GO

    Antes de iniciar a transferência dos dados, seria interessante fazer uma revisão se os novos datatypes deste novo banco vão realmente atender à sua necessidade, sem "quebra" de conteúdo.

    Como você está realizando uma migração de dados, a melhor opção mesmo é "dropar" e criar a tabela novamente. Procure evitar processos paliativos para "várias pequenas" correções, afinal você está migrando para um novo banco de dados para melhorar seu ambiente e não para criar novos problemas à serem corrigidos em curto e médio prazos.

    Outro ponto importante é rever se o Collation de seu novo banco de dados é compatível com o utilizado pelo banco de dados original. Caso ambos utilizem o mesmo Collation não haverá problema, caso contrário eu recomendo que você faça diversos testes de consulta antes de utilizar o novo banco de dados em Produção. Em alguns casos, algumas consultas deverão ser revisadas e alteradas.

    Como o Junior indicou anteriormente, utilizar o "Import Data..." ou "Export Data..." existente dentro do SSMS é uma alternativa simples e eficiente.

    Quando você possuir tabelas com colunas utilizando a propriedade "IDENTITY", basta você selecionar a tabela que utiliza a coluna IDENTITY e clicar em "Edit Mappings". Logo vai abrir a janela "Column Mappings", então selecione as opções para excluir os registros existentes no Destino e para habilitar o IDENTITY. 

    Veja na imagem abaixo:

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    segunda-feira, 27 de outubro de 2014 20:05
    Moderador
  • Durval,

    Muito obrigado pela resposta, fico surpreso com a riqueza de informação e detalhes das respostas desse fórum. Eu não sabia, por exemplo, que o nvarchar ocuparia mais espaço. Sendo assim, como eu deveria definir o tipo no C#? Porque criei todas as tabelas utilizando DataAnnotations e aí eu criei uma string com o MaxLength para definir a quantidade máxima de caracteres. Então nesse caso, as tabelas(e os tipos das colunas) foram criadas automaticamente. Seria o caso de eu trocar uma a uma?

    Também estou pesquisando quanto ao 'Collation' porque pra ser sincero, eu nem sabia o que era isso. De qualquer maneira, acredito que em relação a isso não tenha problema, já que usei a ferramenta do export data existente dentro do sql server mesmo e deu certo quando fiz um teste e selecionei só algumas tabelas. O problema está acontecendo apenas em uma tabela que tem a quantidade de caracteres acima de 8000 e o problema é que os 8000 estão no banco de dados onde os dados estão agora, ou seja, no banco que eu estarei exportando os dados e não no que receberá os dados entende? Por esse motivo, eu não poderia dropar e recriar. Essa é a grande dúvida, e estou tentando pensar alternativas de talvez tentar criar essa tabela depois(é uma tabela de mensagens). Teria alguma sugestão?

    Muito obrigado pelas dicas referentes a migração de dados. Realmente estou trocando os tipos, pois quem criou esse banco de dados fez de forma totalmente errada e então devo ter cuidados para não ter problemas lá na frente(Quem criou, criou cheio de campos bigint onde não era preciso, colunas que funcionam como foreign keys mas na verdade não são, entre outros).



    Antes de mais nada, valeu mesmo, tanto você quanto o Junior!
    segunda-feira, 27 de outubro de 2014 23:05
  • Rafa_WebDev,

    Fico feliz em saber que estamos ajudando!

    Sobre a estruturação dos tipos de dados no C#, realmente será necessário uma revisão para adequar a conversão dos valores entre os tipos do SQL Server e os referentes ao .Net Framework.

    Veja esta tabela comparativa para você adaptar seu código em C#:

    http://cbsa.com.br/post/tipos-de-dados-equivalentes-do-c-e-sql-valores-maximos-e-minimos-suportados.aspx

    http://msdn.microsoft.com/en-us/library/ms131092.aspx

    http://msdn.microsoft.com/pt-br/library/ms191530.aspx 

    A tabela acima foi indicada para VB, mas alguns tipos de dados são equivalentes (serve também para quem vier consultar este tópico futuramente).

    Sobre o Collation, se você está criando o banco de dados na mesma instância SQL do banco de dados original, então não há problema. Caso contrário, entre no SSMS, selecione seu banco de dados (origem) e clique com o botão direito em "Properties". Logo na primeira página existe a definição do Collation do seu banco. Você também poderá utilizar o script T-SQL abaixo para verificar o Collation de cada banco de dados de sua instância:

    SELECT name AS NomeBanco, 
    databasepropertyex(name, 'collation') AS Collation 
    FROM sysdatabases
    GO

    Sobre esta coluna com mais de 8000 caracteres, acredito que esta coluna originalmente deve ser datatype "text".

    De qualquer forma, esta tabela vai exigir um trabalho de análise para identificar quais são estes registros com mais de 8000 caracteres. Lembrando que as futuras versões do SQL Server não irão mais suportar o datatype "text".

    Segue abaixo um script T-SQL para auxiliar nesta análise, faça as alterações de acordo com sua necessidade:

    SELECT MAX(LEN(SuaColuna)) AS Tamanho, SuaColuna
    FROM SuaTabela
    GROUP BY SuaColuna
    HAVING MAX(LEN(SuaColuna)) > 7800
    GO

    Para estas colunas, verifique a relevância da informação. Se realmente é importante que seja importada para o banco de dados novo e se é possível ser reduzida para 8000 caracteres. Se ainda assim for necessário migrar as informações acima deste tamanho para esta coluna (poderá gerar lentidão em algumas consultas), então sugiro que você utilize o datatype "varchar" com alocação "MAX". Segue um exemplo de como converter sua informação para receber mais de 8000 caracteres:

    DECLARE @ORIGEM VARCHAR(8000) = REPLICATE('A',8000)
    DECLARE @DESTINO VARCHAR(MAX)
    SET @DESTINO = CONVERT(VARCHAR(MAX), @ORIGEM) + ' - Passou de 8000'
    
    PRINT (@DESTINO)
    PRINT datalength (@DESTINO)
    GO

    Mas para evitar problemas de performance, o ideal é recriar a tabela.

    Se ajudou na sua solução, não esqueça de marcar como resposta !

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    terça-feira, 28 de outubro de 2014 11:58
    Moderador
  • Achei interessante a visão desse cara aqui também:

    http://stackoverflow.com/questions/144283/what-is-the-difference-between-varchar-and-nvarchar

    Segundo ele, os ganhos de disco e memória não valeriam a pena se for levar em consideração os problemas de compatibilidade. Acontece que eu nunca tive problemas de compatibilidade por causa disso.

    terça-feira, 28 de outubro de 2014 12:18
  • Opss não vi que você tinha mandando uma nova mensagem e acabei mandando essa outra por cima sem querer.

    O campo é um campo de mensagem que uma pessoa enviará para outra e estou avaliando a possibilidade de colocar tamanho máximo 4000 caracteres ou se passo pra tamanho (MAX).

    Muito obrigado pelas informações!

    terça-feira, 28 de outubro de 2014 16:09