none
Congelar Dados da Tabela RRS feed

  • Pergunta

  • Possuo uma procedure aonde a mesma possui dados muito antigos,de 1990 em diante.
    Em contato com meu coordenador o mesmo me informou que eu deveria "congelar" esses dados antigos, sendo assim fikei na seguinte dúvida.
    Eu teria que criar uma rotina que passa-se tudo que é do ano de 2013 por exemplo para uma outra tabela ? Pois seguindo essa solução eu teria de realizar dois select's.
    Um na tabela atual e outra na tabela congelada.
    Fiquei meio na dúvida, gostaria de saber se alguém sabe de algum processo que tenha que ser feito com dados muito antigos. 

    Se a resposta for útil marque - a como útil Atrás de conhecimento ? Acesse : http://brudesenv.wordpress.com/

    terça-feira, 12 de agosto de 2014 01:30

Respostas

  • Deleted
    terça-feira, 12 de agosto de 2014 10:36
  • Deleted
    terça-feira, 12 de agosto de 2014 13:53
  • Ninho,

    Realmente o ideal é criar uma nova tabela, preferencialmente com um nome que seja fácil de identificar que estes dados são uma "extensão" da sua tabela atual. Ex.: se a tabela original é "TB_Pessoa" então uma boa sugestão seria "TB_Pessoa_Historico".

    Lembre-se de criar os mesmo índices nesta nova tabela para manter uma boa performance nas consultas.

    Antes de exportar os dados antigos, por segurança, crie esta tabela em um novo FILEGROUP. Após exportar seus dados para a nova tabela, coloque este FILEGROUP como "somente leitura".

    Veja um exemplo abaixo:

    USE master; GO
    --CRIANDO UM NOVO FILEGROUP ALTER DATABASE SeuBanco ADD FILE ( NAME = SeuBancoHistorico, FILENAME = 'C:\Bancos\SeuBancoHistorico.ndf', SIZE = 5MB, MAXSIZE = 800MB, FILEGROWTH = 2MB ) TO FILEGROUP NOVOFILEGROUP; GO
    USE SeuBanco
    GO

    --CRIANDO SUA TABELA DE HISTORICO NO NOVO FILEGROUP CREATE TABLE TB_PESSOA_HISTORICO ( CD_PESSOA int NOT NULL PRIMARY KEY CLUSTERED, NM_PESSOA varchar(150) NOT NULL, ) ON [NOVOFILEGROUP]; GO

    --TORNANDO O NOVOFILEGROUP SOMENTE LEITURA
    ALTER DATABASE SeuBanco
    MODIFY FILEGROUP [NOVOFILEGROUP] READONLY;
    GO


    Para consultar estas tabelas, sugiro que você crie duas views: uma somente com a tabela atual (com o intuito de obter os dados mais recentes rapidamente) e outra com um UNION entre estas tabelas.

    Veja um exemplo abaixo:

    SELECT CD_PESSOA, NM_PESSOA 
    FROM TB_PESSOA
    UNION
    SELECT CD_PESSOA, NM_PESSOA 
    FROM TB_PESSOA_HISTORICO;
    GO

    Para maiores informações veja:

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

    http://technet.microsoft.com/en-us/library/ms190257(v=sql.105).aspx

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

    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, 12 de agosto de 2014 15:25
    Moderador

Todas as Respostas

  • Deleted
    terça-feira, 12 de agosto de 2014 10:36
  • Deleted
    terça-feira, 12 de agosto de 2014 13:53
  • Ninho,

    Realmente o ideal é criar uma nova tabela, preferencialmente com um nome que seja fácil de identificar que estes dados são uma "extensão" da sua tabela atual. Ex.: se a tabela original é "TB_Pessoa" então uma boa sugestão seria "TB_Pessoa_Historico".

    Lembre-se de criar os mesmo índices nesta nova tabela para manter uma boa performance nas consultas.

    Antes de exportar os dados antigos, por segurança, crie esta tabela em um novo FILEGROUP. Após exportar seus dados para a nova tabela, coloque este FILEGROUP como "somente leitura".

    Veja um exemplo abaixo:

    USE master; GO
    --CRIANDO UM NOVO FILEGROUP ALTER DATABASE SeuBanco ADD FILE ( NAME = SeuBancoHistorico, FILENAME = 'C:\Bancos\SeuBancoHistorico.ndf', SIZE = 5MB, MAXSIZE = 800MB, FILEGROWTH = 2MB ) TO FILEGROUP NOVOFILEGROUP; GO
    USE SeuBanco
    GO

    --CRIANDO SUA TABELA DE HISTORICO NO NOVO FILEGROUP CREATE TABLE TB_PESSOA_HISTORICO ( CD_PESSOA int NOT NULL PRIMARY KEY CLUSTERED, NM_PESSOA varchar(150) NOT NULL, ) ON [NOVOFILEGROUP]; GO

    --TORNANDO O NOVOFILEGROUP SOMENTE LEITURA
    ALTER DATABASE SeuBanco
    MODIFY FILEGROUP [NOVOFILEGROUP] READONLY;
    GO


    Para consultar estas tabelas, sugiro que você crie duas views: uma somente com a tabela atual (com o intuito de obter os dados mais recentes rapidamente) e outra com um UNION entre estas tabelas.

    Veja um exemplo abaixo:

    SELECT CD_PESSOA, NM_PESSOA 
    FROM TB_PESSOA
    UNION
    SELECT CD_PESSOA, NM_PESSOA 
    FROM TB_PESSOA_HISTORICO;
    GO

    Para maiores informações veja:

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

    http://technet.microsoft.com/en-us/library/ms190257(v=sql.105).aspx

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

    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, 12 de agosto de 2014 15:25
    Moderador
  • Bruno, como está a par, os dados não ficam armazenados em procedure mas sim em tabelas.

    Com relação a "congelar" os dados, uma opção é criar tabela de arquivo morto. Mas, se os dados continuariam sendo consultados, qual o objetivo de congelar dados antigos?

    Os dados congelados ficariam estáticos, sem serem atualizados? Deve-se ter em mente que se os dados congelados puderem ser atualizados, as rotinas do sistema terão que ser modificadas para tratarem essa nova tabela.

    Outro cuidado, ao desmembrar a tabela em duas, é garantir que na tabela de dados atual não seja permitido acrescentar dados do período congelado. E vice-versa. Em alguma coluna de data deve-se acrescentar a restrição (CHECK) que os dados devem ser, por exemplo, de 2013 em diante.

    Se a consulta aos dados é sempre através de procedimento armazenado, este pode tratar as tabelas de acordo com o que é solicitado: se a consulta solicita dados que estão somente na tabela ativa ou somente na tabela de dados antigos, então um único SELECT na respectiva tabela. Mas se a consulta requer dados que estão distribuídos nas duas tabelas, então serão dois comandos com a instrução SELECT. Obviamente que o procedimento deve retornar tudo como um único conjunto de dados.

    Mas verifique com o coordenador qual é o objetivo em "congelar" os dados antigos; a partir disso é possível saber qual a solução.


        José Diz     Belo Horizonte, MG - Brasil
    (Se encontrou a solução nesta resposta, ou se o conteúdo foi útil, lembre-se de marcá-la)



    José Diz,

    Concordo com a sua observação!!!


    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, 13 de agosto de 2014 19:46
  • Ninho e Amigos,

    Concordo com a sugestão de todos, inclusive já tive a necessidade de aplicar este tipo de solução em alguns cenários, dentre eles, até mesmo desenvolver uma aplicação para migrar os dados para suas respectivas tabelas.

    Em um caso especial, tinhamos uma table com 2 bilhões de linhas e como o volume era bem considerável, ao invês de fazermos a migração para uma nova tabela, optamos inicialmente em criar uma nova coluna denominada Status e para esta coluna até uma determinada data aplicamos um valor character para determiner o Status do Registro, desta forma, em nossa querys utilizamos na claúsula Where esta coluna Status justamente para filtrar os registros que apresentavam o Status de Desativado ou fora do tempo de uso.

    Prosteriormente fomos realizando a migração de forma parcial, copiando porções de registros para uma outra tabela que justamente seria a nossa posição congelada.


    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, 13 de agosto de 2014 19:53
  • Deleted
    quarta-feira, 13 de agosto de 2014 20:15
  • Pessoal conversei com meu coordenador, e ele disse que a ideia é:
    As procedures que trazem tais informações que possuem muitas tabelas temporárias, tais como muito cálculos, que deverá ser feita uma rotina para quê esses cálculos fossem realizados na carga já formatando a tabela.
    Assim quando se fosse lê a tabela não teria que realizar esse cálculos pois eles já estariam prontos, mas analisando as procedures, muitas possuem tabelas temporárias, pois como a regra está na base(coisa que eu odeio, mas respeito quem prefira claro).

    Então adotei a seguinte decisão, estou recriando as procedures, mas sem as devidas tabelas temporárias, pois quando se cria uma tabela temporária o I/O do servidor aumenta, já que quando se criar a tabela temporária ele cria a mesma no HD, mesmo sendo virtual.

    Também estou colocando o (NOLOCK), pois como são dados que dificilmente são alterados, não corro o risco de ter que aguardar algum outro registro que não seja o meu ser commitado.Já que algumas transações bloqueiam a tabela.

    E estou passando toda a lógica que está nas procedures para a aplicação, tais como if,while e etc.
    Pois acredito eu que é melhor deixar o processamento na máquina do cliente, e não tudo no servido da base.

    Estava pensando em criar indexes também, mas algumas tabelas já possuem então acho desnecessário ficar criando mais e mais, pois também pode ter um efeito contrário e causar gargalo na inserção e update dos registros.

    Pessoal essa é a solução que eu estou adotando, me corrijam se estiver errado.
    E claro estou aberto a opiniões, quanto mais eu melhorar a performance das minhas consultas melhor =D.
    Lembrando que o Sql Server que eu estou trabalhando é o SQL 2000.
    Obrigado a todos

    Se a resposta for útil marque - a como útil Atrás de conhecimento ? Acesse : http://brudesenv.wordpress.com/

    sexta-feira, 15 de agosto de 2014 12:23