PROBLEMAS COM ACCESS E REDE [LENTIDAO]

USUARIO.EXCLUIDOS 17/04/2004 20:28:14
#21122 Resposta escolhida

Rafael,
A primeira coisa a fazer é abandonar o ODBC.

Muito antes do surgimento do Windows 95 acompanhei a implantação de um sistema em VB 3.0 acessando uma base Oracle 7.x com ODBC sobre Windows 3.11 (o falecido Windows for WorkGroup) e foi uma catástrofe geral, nesse época fizemos estudos sobre ODBC e chegamos a seguinte conclusão:
- Os drivers ODBC substituiam a lista de campos do comando SELECT por um asterisco (*);
- Em algumas situações o WHERE era removido da clausula SELECT e os filtros eram aplicados no cliente pelo ODBC antes de devolver os dados para a aplicação.
Resumindo seria assim: O comando SELECT Matricula, Nome, Endereco, dtNasc FROM Funcionarios WHERE Matricula=1 seria passado para o banco de dados como SELECT * FROM Funcionarios, ou seja, o recordset seria todos as tuplas da tabela Funcionarios, o ODBC ao receber o recordset ia aplicando o filtro contido no WHERE original e devolvia a aplicação somente a lista
de campos solicitados no SELECT original.

Na época como ainda não havia recursos como DAO, RDO, ADO forçamos todos os desenvolvedores a utilizarem diretamente as APIs de ODBC e o tempo de reposta melhorou drasticamente. Pode ser que as versões mais recentes de drivers ODBCs não funcionem assim, no entanto você tem em mãos tecnologias mais recentes como ADO.

Você deve levar em consideração que o Access não é e nunca será um SGBD.
Quando o tempo de resposta da aplicação vira "prazo de entrega" é um caos. Primeiramente tente isolar todas variantes envolvidas nesse processo todo (Aplicação, Servidor de banco de dados, PCs, Tráfego de rede, Velocidade das placas de rede (fixa ou hardware default), pois de nada adianta migrar seus dados para Oracle se o "gargalo" não for o banco. Leve em consideração o seguinte:
- A capacidade do servidor onde reside o banco de dados é adequada;
- Todas as placas de rede tem velocidade fixado no cliente;
- Realmente houve um aumento no trafego de dados, ou você esta servindo de Cristo para algo que estava prestes a estourar ?;
- A lentidão é devido ao trafego de rede ou incapacidade do banco em dar vazão suficiente para atender os clientes.

Nesse meus 14 anos de DBA já trabalhei muito com performance e tunning de banco e posso afirmar que tempo de resposta é 80% aplicação e 20% banco. Boas "maneiras" na programação e pequenos ajustes no design do banco pode fazer a diferença, ai vai algumas:
- Ao programar tenha em mãos o MER (Modelo Entidade Relacionamento), alem da lista de índices e campos que compoem esse índices;
- Evite seleção desnecessária de campos que você não ira utilizar. "SELECT *" deve ser considerado um pecado capital.
- A lista de campos selecionados deve obedecer a mesma sequência que esses campos tem na tabela;
- A lista de campos da clausula WHERE deve obedecer a sequência que esses campos tem em algum indice existente (quando houver indice);
- De preferência a clausula ORDER BY deve seguir a sequência de campos existentes em algum índice (quando houver indice);
- Se você costuma utilizar ordenação descendente em seus SELECTs e se existir um indice sobre esses campos, recrie esse indice em ordem descendente;
- Evite o uso de LIKEs, pois mesmo havendo um índice sobre o campo esse indice não será utilizado na recuperação das informações;
- Se o banco de dados suportar campos variáveis evite o uso de campos CHAR, de preferência aos campos VARCHAR;
- Se você tiver um baixo tempo de resposta na execução de JOINs em tabelas relacionados crie indices sobre os campos da foreign key;
- Quando montar um SELECT com JOIN sem o uso de INNER e OUTER tome cuidado na sequência das tabelas que foi fornecido na clausula FROM;
- Tome cuidado com SELECTs com JOIN sem o uso de INNER e OUTER para não provocar um produto cartesino, Processo onde: Para cada linha da tabela "A" serão retornadas todas as linhas da tabela "B";
- Deixe que o banco de dados gerencie o relacionamento entre as tabelas, evite transferir essa funcionalidade do banco para a sua aplicação;
- Evite tabelas sem índices, mais tambem evite um número excessivo de índices. Lembre-se que indices "podem" acelerar SELECTs, mais "irão" degradar INSERTs e UPDATEs;
- Dimensione (e use de forma adequada o tamanho de) suas LUWs (unidades lógicas de trabalho) através do uso de transações (BeginTrans, CommitTrans e RollbackTrans com ADO ou usando forma nativa suportado pelo banco quando for aplicável);
- Fixe a opção de LOCK desejada, não deixe que componentes decidam por você, evite os valores "default" nem sempre eles são os melhores. Se o banco de dados suportar locks explicitos e se houver a necessidade utilize SELECT FOR UPDATE ou LOCK TABLE;
- Não cometa absurdos como: Carregar tabelas imensas em "Combo Boxes" ou "ListViews";
- Evite selecionar tabelas inteiras para depois aplicar filtros, seeks, etc;
- Lembre-se que o tempo de resposta obtido na fase de desenvolvimento nunca será o mesmo obtido por seu usuário final, pois nessa fase você esta trabalhando com um banco de dados contendo um baixo volume de informações, além de estar acessando o banco sozinho (sem concorrência);
- Na fase de desenvolvimento use e abuse do comando EXPLAIN PLAN ou EXPLAIN TABLE para descobrir o plano de acesso traçado pelo banco para recuperar a informação. Isso não se aplica a todos os bancos de dados (o Access não possui isso);
- Lembre-se que LIKEs e falta de indices ocasionam "scan tables". Processo onde todos os registros data tabela são lidos de forma sequencial e carregados em memória, isso inclui leitura de espaços fisicos (do banco) de registros excluidos;
- Mantenha as estatisticas do banco de dados atualizadas (quando o banco suportar isso);
- Mantenha o seu banco de dados reorganizado ou compactado (expressão usado em Access). O processo de reorganização (compactação) consiste em desalocar areas do bancos de dados que não estão mais em uso (areas alocados por registros excluidos), reconstrução dos indices e atualização de estatisticas (quando for suportado pelo banco);
- Mesmo que a tabela contenha um indice e esse seja utilizado em sua queries ainda pode ocorrer um processo chamado "Tree walking" (passeio no indice), quando o seu banco de dados estiver muito desorganizado (necessitando de reorganização);

Nem todos os processos descritos acima são de responsabilidade do desenvolvedor, atualização de estatisticas e reorganização do banco são atribuições do DBA, no entanto, quando se fala em Access não existe o papel do DBA, logo, sempre sobra para o desenvolvedor prever esse processo em sua aplicação.

Boa sorte, espero que você consiga resolver o seu problema.