Problema..... com banco para variar!

10 respostas
A

Seguinte:

Tem um servidor com aqui na empresa com 2 discos.
Tenho um banco que possui 2 tabelas grandes (100 mil em uma e 2 milhoes em outra) para dar uma melhorada na performance eu criei uma tabela em cada disco mas…

O que é melhor criar os indices das tabelas nos mesmos discos?
tipo

IDX1 da T1 no DISCO1
IDX2 da T2 no DISCO2

ou

IDX2 da T2 no DISCO1
IDX1 da T1 no DISCO2

tem um agravante a TABELA1(T1) e a TABELA2(T2) possui 1:N respectivamente…

Estou confuso pelo seguinte qdo eu for escrever na T1 eu tenho que acessar os dados da T2 obrigatoriamente e se o IDX2 esta no mesmo lugar da T1 eu nao faco nada em “paralelo”…entendeu?

:wink: :wink:

10 Respostas

A

poxa pessoal… so um bate papo msm… para clarear as ideias… :cry:

ninguem msm?

A

fica melhor no msm disco… msm tendo muuuuitos dados…

ps: prq ninguem responde minhas perguntas…estou me expressando mal?

Luiz_Gustavo

Eu mesmo gostaria de ajudar… mas não sei como :smiley:
Nunca passei por essa situação… e também nem sei de que banco se trata para poder pesquisar.
Talvez esses tipos de detalhe pudessem ajudar o pessoal a colaborar com você.
Mas já que deu certo, talvez possa colocar detalhes de que banco se trata e como conseguiu resolver, para ajudar pessoas que venham a precisar futuramente.

Abraços!

gcobr

:evil: Se você pelo menos explicasse de que banco de dados está falando.

lucao

Cara, normalmente um dos maiores gargalos nos bancos é por causa do IO de disco.
Como numa consulta indexada, os dados e os índices são acessados simultaneamente. O melhor é separar os dois, assim reduz pelo menos o gargalo de IO.

marciosantri

Na maioria dos casos é uma boa idéia separar os índices dos dados por causa do acesso simultâneo.
No nosso caso, utilizamos Oracle. Ao utilizar um índice o acesso à tabela é feito pelo RowId (quando é
necessário acessar a tabela). Se vc separa os discos, enquanto um lê os índices o outro lê os dados (isto
de uma maneira simplificada pois existem alguns artifícios como RAID que podem ajudar e muito na performance).
Em alguns testes feitos em clientes a performance aumenta bem utilizando este esquema, principalmente se tem discos SCSI na jogada.
Dependendo das tabelas e da forma de acesso, às vezes é melhor utilizar um disco para uma só tabela,
por exemplo.
Para o uso do Oracle, particularmente não considero 2 milhões de registros um problema. Se o acesso está
lento, verifique os índices ou estruturas da tabela. Normalmente eles são responsáveis por grande parte da lentidão do
processo. Também é interessante verificar a quantidade de registros que a maioria das consultas retorna. Se forem
poucos, deve ser rápido. Se não estiver, tente verificar o caminho que o banco está fazendo para acessar os
dados. Não sei exatamente como a maioria dos bancos mostra isso, mas no Oracle é bem tranquilo.
Existem muitos fatores que determinam velocidade de acesso a um banco. Isto é assunto pra horas e horas.

A

com toda certeza naum é o access…rsrs :wink: é o SQL SERVER

msm assim obrigado a todos pelas dicas!!! :smiley:

C

André, qual é o seu problema necessariamente?

  • Por que dois discos?
  • Por que está lento? Consulta? Acesso de muitos usuários?
  • Esses dois discos são locais?
  • Se houver lentidão, esta está ligada ao Sistema que estão usando?
  • Se for o Sistema, em qual linguagem está escrita, leia-se IDE?

Talvez respondendo essas perguntas, facilite na resolução do problema ou sane sua dúvida.

Abraços.

Eduardo_Bregaida

com toda certeza naum é o access…rsrs :wink: é o SQL SERVER

msm assim obrigado a todos pelas dicas!!! :smiley:

Access nao é BD, é um quebra galho p/ usuários :wink:

marciosantri

com toda certeza naum é o access…rsrs :wink: é o SQL SERVER

msm assim obrigado a todos pelas dicas!!! :smiley:

Access nao é BD, é um quebra galho p/ usuários :wink:

Aqui a gente tem o costume de dizer que Access não é banco de dados, é tamborete de dados.

Criado 27 de agosto de 2007
Ultima resposta 9 de set. de 2007
Respostas 10
Participantes 7