Parece que você precisa de uma análise básica de desempenho, para começar, para ver onde você está afundando. Os números que você obtém desse gráfico dão uma ideia realmente grosseira de onde começar a procurar seus problemas de desempenho.
Eu inicio o Monitor de Desempenho (Iniciar / perfmon), navgate até o nó "Monitor de Desempenho" e, usando o ícone "+" na barra de ferramentas, inclua os seguintes contadores no gráfico:
-
Memória - Páginas / s - Isso mostrará a atividade de paginação de memória que contribui para uma má execução (também pode mostrar atividade de paginação que também não tem nada a ver com desempenho ruim). Se você está vendo paginação alta, então pode ser um gargalo na capacidade da memória RAM. Isso também pode se manifestar como um afunilamento de disco (por causa de leituras / gravações no arquivo de paginação), portanto, seja cauteloso.
-
Disco físico - Média Comprimento da Fila de Disco - Escolha a instância que corresponde à unidade onde o arquivo de banco de dados do Access está localizado (supondo que estejam no disco local do computador servidor) - Esse número não deve ser maior do que 2 x o número de eixos no RAID volume como uma regra geral muito, muito geral. Você pode mergulhar mais fundo nos contadores de disco se parecer que está tendo um gargalo de disco.
-
Interface de rede - Total de bytes / s - Escolha a instância que corresponde à NIC pela qual os clientes estão acessando o servidor. Se o arquivo de banco de dados do Access estiver hospedado em um compartilhamento de rede, adicione uma instância para o NIC que o servidor usa para acessar esse compartilhamento de rede (supondo que não é o mesmo NIC que os clientes estão acessando o compartilhamento). - Isso vai lhe dar um número bruto de bytes / seg movendo-se na interface de rede. Você pode usar uma ferramenta de teste de carga muito, WSTTCP , para avaliar a utilização máxima de largura de banda entre o servidor e um computador cliente . Compare esse número com esse número.
Perfmon adicionará um contador "% Processor Time" para o "total" de todos os processadores na máquina automaticamente. Eu removê-lo e adicione o contador Processor -% Processor Time para cada instância do processador na máquina, individualmente. O Microsoft Access é principalmente single-threaded, e se você estiver implorando uma instância de processador único, o contador de tempo do processador% _Total "% só pode mostrar 25% (ou 12,5% se você tiver hyper-threading no seu processador).
Isso abrange os possíveis afunilamentos - disco, RAM, rede e CPU. Você pode usar esse gráfico para ter uma idéia do desempenho bruto da caixa. Então você pode começar a perfurar gargalos específicos e ter uma ideia do culpado.
Um cliente meu implantou um "pequeno aplicativo Access" que usava em seu escritório há alguns anos em um servidor de terminal que executa o Windows Server 2008 e ficou chocado com o quão ruim ele executada. Ele "correu bem" em computadores desktop, e eles esperavam que fosse o mesmo no Terminal Server. Descobrimos que eles estavam maximizando toda a RAM no Terminal Server rapidamente quando os usuários abriram o aplicativo simultaneamente. Não era grande coisa para o banco de dados abrir em uma de suas máquinas desktop com 1 ou 2 GB de RAM, mas 15 pessoas tentando compartilhá-lo no Terminal Server eram demais. (O banco de dados tinha grandes arquivos PDF armazenados como objetos OLE dentro dele, se você pode acreditar ... Inacreditável, mas verdadeiro. O arquivo MDB tinha mais de 300 MB ...)
Como um aparte: RAID 0? Em um servidor? Você está multiplicando suas chances de falha usando RAID-0, já que tem redundância "zero". Se você está procurando ou de alto desempenho, seria melhor usar o RAID-10 e sacrificar algum espaço em disco em nome da confiabilidade. Não consigo imaginar que você precise do desempenho de IO bruto do RAID-0 em uma máquina do Terminal Server executando aplicativos do tipo Microsoft Office.