none
Bases de dados com tamanhos diferentes depois de exportar para outro servidor. RRS feed

  • Pergunta

  • Olá,

    Tenho uma dúvida. Fiz uma importação (Import database) de uma base de dados que esta em outro servidor (origem) que tem quase 9,5gb. depois da operação que procedeu sem erros a base de destino estava com pouco mais de 2gb. No processo selecionei todas as tabelas. Então quero saber se pode ter acontecido algum problema de perda de dados ou se a base de origem9,5gb pode conter logs ou configuração que o aumente assim.

    Segue informações do meu ambiente

    Servidor xeon 8gb

    Windows server 2008

    sql server 2000 no servidor de destino e origem.


    Michael Jullys Suporte técnico MCP-MTA Network Foundation

    terça-feira, 19 de agosto de 2014 18:49

Respostas

  • Michael,

    Para esta situação, a última opção seria melhor. Particularmente, eu faria dois processos distintos:

    1 - Gerar o script T-SQL de todos os objetos do banco de dados, através do comando "Generate Script..." do SSMS (clique com o botão direito no seu banco de origem, selecione "Tasks" onde está a opção) e depois criar em um banco de dados vazio no Destino;

    2 - Importar todos os dados para às tabelas, do banco de dados da Origem para o Destino, através do "Import Data..." do SSMS (clique com o botão direito no seu banco de origem, selecione "Tasks" onde está a opção). Caso você tenha tabelas com campos IDENTITY, será necessário selecionar a opção "Edit Mapping" e definir a importação da tabela como indicado abaixo:

    Não esqueça de marcar como resposta todos os posts que ajudaram na sua solução!

    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"
    quarta-feira, 20 de agosto de 2014 13:19
  • Michael,

    Além da falta dos índices como o Advaldo citou, é possível que o banco de dados na origem estava com índices muito fragmentados e por este motivo a diferença de tamanho entre os bancos (origem - destino) foi tão grande.  

    Compare a quantidade de registros por tabela, se isto estiver correto entre os bancos você não deverá ter perda de dados.

    USE SeuBancoOrigem
    GO
    SELECT OBJ.name AS Tabela, IDX.[rows] AS QtdRegistro
    INTO #tmpOrigem
    FROM sysobjects AS OBJ INNER JOIN sysindexes AS IDX on OBJ.id = IDX.id
    WHERE IDX.indid < 2  AND OBJ.[type] = 'U'
    ORDER BY OBJ.name
    GO
    
    USE SeuBancoDestino
    GO
    SELECT OBJ.name AS Tabela, IDX.[rows] AS QtdRegistro
    INTO #tmpDestino
    FROM sysobjects AS OBJ INNER JOIN sysindexes AS IDX on OBJ.id = IDX.id
    WHERE IDX.indid < 2  AND OBJ.[type] = 'U'
    ORDER BY OBJ.name
    GO
    
    --Comparando Resultados
    SELECT
    	ORIGEM.TABELA,
    	ORIGEM.QtdRegistro AS QTD_ORIGEM,
    	DESTINO.QtdRegistro AS QTD_DESTINO
    FROM
    	#tmpOrigem AS ORIGEM
    INNER JOIN #tmpDestino AS DESTINO
    ON ORIGEM.TABELA = DESTINO.TABELA
    GO

    Revise também todos os objetos(VIEWs, Procedures, Functions, ...) de seu banco de dados para evitar problemas no consumo dos dados pelas aplicações.

    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, 19 de agosto de 2014 19:29

Todas as Respostas

  • Verifique se a quantidade de registros nas duas bases são as mesmas e se todos os objetos foram migrados.

    Não sei como migrou, mas pode ser que os indices nao foram criados.

    if OBJECT_ID('tempdb..#temp') IS NOT NULL
    DROP TABLE #temp
    
    create table #temp ([name] varchar(1000), [rows] bigint, [reserved] varchar(1000), 
    [data] varchar(1000), 
    [index_size] varchar(1000), [unsed] varchar(1000))
    
    insert into #temp
    
    EXEC sp_MSforeachtable 
    	@command1="print '>>>Tabela: ?' ", 
    		@command2="sp_spaceused '?' "
    
    SELECT * 
    FROM #temp 
    WHERE rows > 0 
    ORDER BY rows DESC
    
    []´s 

    terça-feira, 19 de agosto de 2014 19:10
  • Michael,

    Além da falta dos índices como o Advaldo citou, é possível que o banco de dados na origem estava com índices muito fragmentados e por este motivo a diferença de tamanho entre os bancos (origem - destino) foi tão grande.  

    Compare a quantidade de registros por tabela, se isto estiver correto entre os bancos você não deverá ter perda de dados.

    USE SeuBancoOrigem
    GO
    SELECT OBJ.name AS Tabela, IDX.[rows] AS QtdRegistro
    INTO #tmpOrigem
    FROM sysobjects AS OBJ INNER JOIN sysindexes AS IDX on OBJ.id = IDX.id
    WHERE IDX.indid < 2  AND OBJ.[type] = 'U'
    ORDER BY OBJ.name
    GO
    
    USE SeuBancoDestino
    GO
    SELECT OBJ.name AS Tabela, IDX.[rows] AS QtdRegistro
    INTO #tmpDestino
    FROM sysobjects AS OBJ INNER JOIN sysindexes AS IDX on OBJ.id = IDX.id
    WHERE IDX.indid < 2  AND OBJ.[type] = 'U'
    ORDER BY OBJ.name
    GO
    
    --Comparando Resultados
    SELECT
    	ORIGEM.TABELA,
    	ORIGEM.QtdRegistro AS QTD_ORIGEM,
    	DESTINO.QtdRegistro AS QTD_DESTINO
    FROM
    	#tmpOrigem AS ORIGEM
    INNER JOIN #tmpDestino AS DESTINO
    ON ORIGEM.TABELA = DESTINO.TABELA
    GO

    Revise também todos os objetos(VIEWs, Procedures, Functions, ...) de seu banco de dados para evitar problemas no consumo dos dados pelas aplicações.

    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, 19 de agosto de 2014 19:29
  • Durval Obrigado,

    no processo de transferencia da base de um servidor para o outro escolhi a primeira opção, porque eu precisei transferir toda a base de dados (completa) veja.

    a melhor opção para o meu caso seria a primeira ou a ultima?


    Michael Jullys Suporte técnico MCP-MTA Network Foundation


    terça-feira, 19 de agosto de 2014 20:39
  • Michael,

    Para esta situação, a última opção seria melhor. Particularmente, eu faria dois processos distintos:

    1 - Gerar o script T-SQL de todos os objetos do banco de dados, através do comando "Generate Script..." do SSMS (clique com o botão direito no seu banco de origem, selecione "Tasks" onde está a opção) e depois criar em um banco de dados vazio no Destino;

    2 - Importar todos os dados para às tabelas, do banco de dados da Origem para o Destino, através do "Import Data..." do SSMS (clique com o botão direito no seu banco de origem, selecione "Tasks" onde está a opção). Caso você tenha tabelas com campos IDENTITY, será necessário selecionar a opção "Edit Mapping" e definir a importação da tabela como indicado abaixo:

    Não esqueça de marcar como resposta todos os posts que ajudaram na sua solução!

    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"
    quarta-feira, 20 de agosto de 2014 13:19
  • Michael,

    Uma curiosidade, quando você se refere á 9GBs do tamanho do banco de dados, esta se referindo ao arquivo .mdf?

    Se por acaso você esta se referindo a este tamanho com base nas informações que a tela de propriedades do banco de dados apresentada pelo SQL Server, esse valor pode estar sendo considerado se levarmos em consideração o tamanho do arquivo de log.

    Como você obteve esta valor de 9GBs?


    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

    quarta-feira, 20 de agosto de 2014 14:57
    Moderador
  • Olá Júnior 

    Para obter o tamanho da base de dados usei propriedades do banco do sistema pelo management studio.

    Eu não medi o tamanho pelo mdf do banco. Será que por esse motivo não obtive informações concretas? O log da base e informações de backup podem mesmo diferir. Obrigado.


    Michael Jullys Suporte técnico MCP-MTA Network Foundation

    quarta-feira, 20 de agosto de 2014 18:33