Redirecionamento de Banco de Dados

Question

Pessoal,

 

Eu tenho um sistema, onde não tenho o código fonte por ser um produto fechado.O mesmo grava as informações em um Banco de dados SQL Server 2005, onde as tabelas são pré-definidas para cada módulo do sistema.o sistema não permite direcionar para mais de uma base de dados.Acontece que o volume de dados está muito grande e necessitamos criar um banco de histórico para as informações para obtermos ganho de peformance, onde seria definido o período de armazenamento dos dados no banco de produção e o restante iria para o histórico, por exemplo, somente 1 ano no banco de produção.

 

O problema é quando o sistema requisitar uma consulta e estas informações estiverem no banco de histórico, não iria retornar nada para o usuário.Existe algum recurso no SQL 2005, onde eu consiga redirecionar internamente no SQL  a consulta dependendo do periodo para o banco de histórico, ficando transparente para o sistema????

 
Obrigado,

Alvarenga

Answer 1

Bom Dia,

Infelizmente não há um recurso desse nível. Não há como dependendo da consulta decidir se a pesquisa deve ser feita em A ou em B. Se alterar a aplicação não é cogitado. Há duas formas de resolver isso:

Via Procedimento
Se algum usuário solicitar dados após uma certa data, ele deve saber que terá que consultar um outro aplicativo à parte, pois, os mesmos não estarão na base de dados

Via Infra-Estrutura
Você pode considerar particionar os seus dados. O particionamento no SQL Server 2005 permite que você separe os dados por partições além de possibilitar o backup por partição (embora torne a estratégia de backup mais complexa).

O melhor mesmo seria poder alterar a aplicação. Ainda que o fonte não possa ser alterado, se a aplicação fosse feita usando-se SPs, podería-se colocar a lógica de consultar em A ou em B dentro das SPs.

[ ]s,

Gustavo Maia Aguiar
http://gustavomaiaaguiar.spaces.live.com

Você sabe o que é divisão relacional ? Consulte
http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!360.entry

---

Classifique as respostas. O seu feedback é imprescindível

Answer 2

Olá,

Após uns dias doente voltei ao fórum. Mas, voltabdo ao assunto, concordo com Gustavo sobre o particionamento, inclusive se suas consultas, updates, etc forem realizadaas via SPs.

No entanto, o particionamento só vai gerar um bom ganho de desempenho se você usar discos diferentes para cada partição.

Abraços

---

Demétrio Silva

Answer 3

Maia e Demétrio,

Concordo que o particionamento seria uma possibilidade, mas será que não poderiamos criar uma view destes dados?

Não sei exatamente como esta modelada esta aplicação, mas me parece que existe uma ferramenta para consulta de dados, e talvez a view para ser utilizada como um motor para busca de informações?

Amigos, o que vocês acham?

---

Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA

Answer 4

Maia,

Esta seria uma boa opção, porém eu não tenho acesso as storeds do sistema, é uma caixa preta...Mas a idéia do particionamento das tabelas vai ajudar bastante...

Obrigado pela ajuda pessoal....

Answer 5

Bom Dia,

O Jr. levantou um ponto que eu ainda não tinha pensado. Realmente utilizar Views pode ser um alternativa interessante, mas ela sozinha não ajudará muito. Se você expurgar os registros para um outro local (B), uma view poderá juntar os registros atuais (A) com os históricos (os expurgados). Em todo caso, isso poderá levar a problemas de desempenho uma vez que a grande quantidade de registros permanecerá a mesma (apenas foi dividida em dois locais A e B).

A View só seria eficiente nesse caso, se for feita uma implementação do tipo View Particionada. Nesse caso, quando um SELECT for feito contra a View, a mesma será inteligente o suficiente para decidir se pesquisa em A ou em B ou em ambos. Essa é uma abordagem idêntica ao particionamento, mas enquanto o particionamento é eficaz para dados que estão no mesmo banco, a View particionada pode usar a mesma lógica para dados em bancos e até servidores diferentes. O problema é que é necessário fazer algumas alterações no modelo de dados (são muito poucas) e não sei se a aplicação irá suportá-las.

Do ponto de vista de Views, você pode também montar uma View Indexada apenas com os registros atuais. Se o seu SQL Server for o Enterprise, ele será inteligente o bastante para buscar os dados da View Indexada ao invés de pesquisar na tabela. Agora lembre-se que se houver muitos INSERTs, UPDATEs e DELETEs, a View Indexada representará um índice a mais para ser mantido.

[ ]s,

Gustavo Maia Aguiar
http://gustavomaiaaguiar.spaces.live.com/

Cálculos financeiros com SQL ? Clique abaixo:
http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!361.entry

---

Classifique as respostas. O seu feedback é imprescindível