View apontando para outro banco

Question

Galera,

tenho um banco de dados, que possui uma série de registros de auditoria, outras séries de registros de endereços e pessoas, fora as tabelas de negócio.

Estou pensando em pegar esse meu banco que hoje está grande, e dividi-lo em vários bancos e para isso tive a idéia de construir views para isso.

Exemplo:

Hoje eu tenho uma tabela de endereço que tem por exemplo 1 milhão de registros, pegaria esta tabela e criaria um banco chamado MEUSISTEMAENDERECO e neste banco eu teria somente a tabela de endereço.

No meu banco principal eu daria um DROP na table a de endereço e criaria uma view que seria um select * from  MEUSISTEMAENDERECO.dbo.ENDERECO, com isso eu teria vários bancos menores para administrar.

Pergunta que não se cala:

Eu perco perfomance com isso?

---

Marquinhos Não esqueça de qualificar a resposta.

Answer 1

Marquinhos, bom dia!

Se voce perde performance com isso? De forma alguma, mas também não ganha performance nenhuma, ou seja, em questão de melhoria técnica não a diferença porem com certeza a dificuldade de administração aumentara exponencialmente. Pense no seguinte cenário: Você tem um novo servidor e vai migrar seu sistema (Ação rotineira em muitas empresas), com as bases divididas você terá de levar todas as envolvidas ao invés de apenas uma. Não vejo motivos para realizar tal segmentação.

Colocando em N bases as tabelas você pode colocar um arquivo em cada disco ganhando performance e não concorrendo em hardware, mas isso ja pode ser feito via filegroup dentro de uma mesma base.

---

Fabrizzio A. Caputo
MCT
Certificações:
Oracle OCA 11g
MCITP SQL Server 2008 Implementation and Maintenance
MCITP SQL Server 2008 Developer
ITIL V3 Foundation
Blog Pessoal: www.fabrizziocaputo.wordpress.com
Email: [e-mail]

Answer 2

Sim essa questão de administração eu já tinha me atentado.

Porém veja esta situação eu administrar em um único arquivo 300GB de dados, ai contamos tempos de backup, compactação de base e por ai vai, o trabalho se torna árduo.

A vantagem de ter várias bases menores, a administração do volume, deixo de trabalhar com um único arquivo de 300GB, que tenho que fazer 2 backups dia 12:00 e 00:00, e trabalharia com arquivo menores, podendo em alguns casos, agendar backups menores em horários diferenciados.

Exemplo 1:

Backup críticos:

• Dados financeiros
• Este teria que fazer 12:00 e 00:00
• Dados de Endereço
• Este poderia fazer apenas 1 às 00:00
• Dados de clientes
• Este teria que fazer 13:00 e 01:00

Outro exemplo:

Montagem de um banco de homologação de sistema:

Neste banco de homologação não precisaria trazer toda a base para o servidor, apenas os dados relacionados a negócio precisariam estar na posição mais atual, ja os dados de endereço é aceitável uma defasagem.

Já com file groups não conseguiria fazer essas ações. 

correto?

---

Marquinhos Não esqueça de qualificar a resposta.

Answer 3

Marquinhos,

Até entendo seu ponto de vista, mas veja:

Quanto ao backup: Utilize estrategias de backups diferenciadas, alem da execução do backup full considere a adição de backups diferenciais e de log, dessa forma você terá backups rápidos, constantes e consistentes.

Em relação a backup de dados e não de bases: Seu sistema/Negócio funciona sem os endereços? Caso negativo, essa tabela é tão importante quanto a de dados financeiros. Seu sistema funciona sem a tabela de estado (Tabela que dificilmente muda)? Caso negativo esta tabela também é extremamente importante! A normalização dos dados e seus relacionamentos fazem com que não existe dado mais importante ou menos importante para o funcionamento do negócio uma vez que o sistema atrelado dependa de todas as informações.

Quanto ao backup de filegroup, sim, voce consegue fazer: http://msdn.microsoft.com/en-us/library/ms179401(v=sql.105).aspx

Quanto a base de homologação, o sistema funciona com apenas parte dos dados? A ideia de um ambiente de homologação é ser 100% semelhante ao de produção para não haver surpresas, caso este não seja seu cenario ainda sim recomendo a criação do script da base e a transferência dos dados conforme a necessidade via Import/Export.

---

Fabrizzio A. Caputo
MCT
Certificações:
Oracle OCA 11g
MCITP SQL Server 2008 Implementation and Maintenance
MCITP SQL Server 2008 Developer
ITIL V3 Foundation
Blog Pessoal: www.fabrizziocaputo.wordpress.com
Email: [e-mail]

Answer 4

Fabrizzio,

você está correto, os dados são correlacionados, logo não há dado mais importante que o outro, apesar de que, em ambiente homologação por exemplo não precisasse carregar uma tabela de auditora que tem mais de 1 Bilhão de registros.

Talvez eu esteja vendo de uma perspectiva errada mesmo, quanto a criação dessas views, onde minha visão está somente em trabalhar com movimentação de banco pra lá e pra cá bem como seus backups.

Eu estava seguindo a linha que ocorre no Oracle por exemplo que posso montar uma estrutura de backup/Restore de tabelas A,B e C de um banco, sem necessariamente realizar o backup/Restore Tabelas D,E e F.

---

Marquinhos Não esqueça de qualificar a resposta.

Answer 5

Marquinhos

Uma outra estrátégia seria particionar esta tabela, você pode ainda compactar as partições com dados históricos o que te pouparia espaço em disco, e dependendo de sua regra de negócio com o particionamento correto e alinhamento dos indices com o particionamento vc pode ter aumento de performance... uma vez que a massa de dados a ser pesquisada estará em particões menores. e com o particionamento vc também pode ter a estratégia de backups por FGs

estes artigos podem colaborar.

http://msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx

http://www.brentozar.com/sql/table-partitioning-resources/

---

Att.
Marcelo Fernandes

MCP, MCDBA, MCSA, MCTS, MCITP, MCT.
Se útil, classifique!!!
Me siga no twitter: @marcelodba