MS Access (MDB) simultaneidade

Question

Para um pequeno projeto preciso utilizar um banco de dados simples com requisitos muito leves: algumas mesas, não mais do que alguns milhares de registros no total, 2 ou 3 usuários. Eu estou trabalhando em ambiente .NET.

Como um servidor de banco de dados (mesmo aquelas edições Express) parece um enorme exagero neste caso, um banco de dados MDB muito simples poderia fazer para a maioria dos requisitos. Estou, no entanto, preocupado com a concorrência. Minha idéia é colocar o arquivo .mdb em um compartilhamento de rede e permitir que os usuários acessar esse arquivo de seus clientes baseados em .NET. O db é principalmente destinado a operações somente leitura, mas os usuários vão ocasionalmente precisa registros update / delete também. Se isso não será possível no momento (devido à db que está sendo bloqueado ou qualquer outro), eu posso segurar as atualizações no cliente e processá-los em um momento posterior.

A questão em si vai junto destes pontos:

• Como são leituras simultâneas tratado em MDB?
• Como são atualizações simultâneas / exclui tratado em MDB?
• Existe um conceito de bloqueios e como posso aproveitá-lo em um aplicativo .NET?
• É colocar o arquivo MDB em uma boa partilha de rede ou uma ideia horrível?

Como eu estou trabalhando em .NET, eu também gosto de saber como posso detectar eventuais problemas de concorrência e tomar as medidas adequadas. Ou seja, qual exceção que eu deveria pegar e quais as medidas que você recomendaria a tomar?

Editar : Pode ser a minha má descrição do problema, mas a maioria das respostas parecem aconselhar indo para um servidor de DB desenvolvido. Eu entendo as diferenças e vantagens de ter uma instalação do servidor e ter de fato implementado um bom número de projetos em MSSQL e Oracle. Nesta questão, no entanto, Só estou preocupado com o Access e seus problemas de concorrência, por isso, não sugerem um servidor de banco de dados.

Obrigado por sua ajuda.

Answer 1

Esta é uma questão de idade, mas ninguém nunca realmente respondeu ele. Aqui estão as perguntas:

1. Como são leituras simultâneas tratado em MDB?
2. Como são atualizações simultâneas / exclui tratado em MDB?
3. Existe um conceito de bloqueios e como posso aproveitá-lo em um aplicativo .NET?
4. É colocar o arquivo MDB em uma boa partilha de rede ou uma ideia horrível?

As duas primeiras questões pode, basicamente, ser respondidas com uma explicação. Uma ressalva chave aqui: as respostas que eu estou dando aqui são específicas para Jet MDBs (e suas variantes) e não se aplicam completamente para o novo formato de arquivo introduziu começando com A2007, ou seja, o formato ACCDB. Eu ainda não totalmente explorado as implicações da remoção de Jet ULS da ACE e alguns dos comentários abaixo pode assumir Jet ULS abaixo do capô. Para um monte de coisas, porém, você pode substituir "file LACCDB" para "arquivo LDB" e os resultados serão os mesmos.

1-2) Concurrent lê / atualizações / exclusões

O motor de banco de dados Jet é muitas vezes referida como um banco de dados "servidor de arquivos" em que não há nenhum demônio do lado do servidor gestão de I / O com os arquivos de dados no servidor. O que isto significa é que todos os clientes usando um Jet MDB está lendo o arquivo diretamente.

Isto é, naturalmente, uma receita para o desastre se não há algum mecanismo interno para lidar com o acesso simultâneo ao arquivo.

Jet usa um arquivo de bloqueio de registro, onde se o seu MDB é "MyFile.MDB" o arquivo de bloqueio de registro será na mesma pasta e chamado de "MyFile.LDB". Os registros do arquivo LDB que os usuários Jet ULS têm o arquivo MDB aberta, o que estação de trabalho que o usuário está conectado a partir de, e todas as informações necessárias para a negociação de problemas de concorrência.

Agora, para aqueles que cortou seus dentes em bancos de dados de cliente / servidor, isto pode parecer primitivo e perigoso, mas no momento em que o motor de banco de dados Jet foi desenvolvido, o seu objectivo era para ser usado como um motor de banco de dados de área de trabalho para pequenos grupos de trabalho , e ele estava competindo com outros motores db área de trabalho como xBase e Paradox, ambos usados ??arquivos de bloqueio análogas para gerenciar o uso concomitante de arquivos de dados de vários clientes.

Dentro de um arquivo de banco de dados Jet, os bloqueios são aplicados tanto em páginas de dados (que no Jet 4 foram aumentados para 4K, enquanto que no Jet 3.xe antes, eles eram 2K), ou no nível do registro se a tabela de dados foi originalmente criado para usar o bloqueio em nível recorde. Nos primeiros dias de Jet 4, o bloqueio em nível recorde foi encontrada por muitos para ser bastante lento, especialmente quando utilizando bloqueio pessimista, então um monte de desenvolvedores de acesso nunca usei nada, mas o bloqueio em nível de página (@ David Fenton levanta a mão!).

Na verdade, quando se utiliza o bloqueio otimista, você evitar a maioria dos problemas de concorrência que viria com bloqueio pessimista.

Algumas advertências:

1. de DAO, bloqueio de nível de registo não está disponível e você só obter o bloqueio em nível de página.

2. de DAO, há uma série de opções para controlar o bloqueio otimista / pessimista, em particular o argumento LockEdits do método OpenRecordset, mas que também interage com certeza da configuração especificada no argumento Opções OpenRecordset (por exemplo, opção dbReadOnly não pode ser usado com LockEdits). Além de bloqueio, há também opções para atualizações consistentes / inconsistente, e tudo isso pode interagir com transações (por exemplo, mudanças dentro de uma transação uncomitted não vão ser visíveis a outros usuários e, portanto, não estará em conflito com eles, mas pode colocar fechaduras somente leitura nas tabelas envolvidas).

De ADO / OLEDB, estas estruturas de controle Jet concorrência vão ser mapeado sobre as funções e os argumentos relevantes encontrados em ADO / OLEDB. Desde que eu uso Jet apenas de Acesso, eu interagir com ele somente via DAO, por isso não posso aconselhar sobre como controlar estes com ADO / OLEDB, mas o ponto é que as ofertas Jet Database Engine o controle de seu bloqueio de registro ao acessá-lo programaticamente (como opposed para através da interface Access) -. É apenas mais complicado

3) Locks e .NET

Eu não posso oferecer qualquer conselho aqui, diferente do que você tinha OLEDB uso provável como sua interface de dados, mas o ponto é que a funcionalidade de bloqueio / controle está lá no próprio motor db, então não há provavelmente uma maneira de controlá-lo através de OLEDB. Pode não ser muito, embora, como parece-me que OLEDB é projetado em torno de arquiteturas cliente / servidor, e bloqueio baseado em arquivo do Jet pode não mapear para que de uma forma elegante.

4) MDB em um compartilhamento de rede

Jet é muito sensível ao menor soluço em qualquer conexão de rede. Por causa disso, as redes de baixa largura de banda pode aumentar a vulnerabilidade dos bancos de dados Jet abrir através de uma conexão lenta.

Isso ocorre porque grandes pedaços do arquivo de banco de dados tem que ser puxado através do fio para a RAM do computador local para processamento. Agora, muitas pessoas erroneamente afirmam que todo o arquivo MDB é puxado através do fio, ou que as tabelas inteiras são puxados através do fio. Isso não é verdade. Em vez disso, Jet primeiro solicita os índices (e solicitações não mais do que o necessário para cumprir a consulta) e, em seguida, a partir desse resultado determina exatamente quais são necessários páginas de dados e, em seguida, puxa apenas as páginas. Este é surpreendentemente eficiente e rápido.

Além disso, Jet faz alguns cache muito inteligente que pode significar que um primeiro pedido de dados pode demorar um pouco, mas os pedidos subsequentes para os mesmos dados acontecer quase instantaneamente por causa do cache.

Agora, se você não tiver indexado suas tabelas bem, você pode acabar puxando toda a tabela e fazer uma varredura completa da tabela. Da mesma forma, se os critérios de base sobre as funções do lado do cliente que não são parte do dialeto SQL do Jet, você pode acabar puxando uma mesa cheia (triagem, digamos, Replace (MyField, "A", "Z") é susceptível de causar uma varredura completa da tabela). Mas esse tipo de coisa vai ser ineficiente com uma arquitetura cliente / servidor, também, por isso é apenas design do esquema de senso comum para indexar as coisas corretamente e ter cuidado com o uso de UDFs ou funções não-Jet-compatíveis. Em geral, as mesmas coisas que são eficientes com o cliente / servidor vão ser eficiente com o Jet (a principal diferença é que, com Jet você é melhor fora com uma conexão persistente, a fim de evitar a sobrecarga de recriar o arquivo LDB, que é significativo).

A outra coisa a evitar é tentar usar dados Jet através de uma conexão WiFi. Nós todos sabemos como WiFi confiável é, e está apenas pedindo para ter problemas tentando trabalhar com dados Jet através de uma conexão sem fio.

A linha inferior:

Se você estiver usando uma MDB como um armazenamento de dados para servir dados de um servidor web, você deve colocar os dados como perto de RAM do servidor web quanto possível. Isso significa que, sempre que possível, em um volume de disco que está ligado ao servidor web física. Onde isso não for possível, você quer um rápido, conexão LAN confiável. GB LANs em centros de dados são bastante comuns nos dias de hoje e eu estaria trabalhando muito confortável com dados do Jet em todo esse tipo de conexão.

Para uso compartilhado, por exemplo, várias estações de trabalho cliente executando um aplicativo de desktop VB.NET compartilhando um único Jet MDB como armazenamento de dados, é muito seguro ter o arquivo de dados em um servidor de arquivos confiável. Sempre que possível, é uma boa idéia de colocar seus arquivos Jet MDB em máquinas que não estão servindo a múltiplos propósitos (por exemplo, o controlador de domínio que está executando o Exchange, SQL Server e atuando como servidor de arquivos e servidor de impressão pode não ser a melhor localização) . Aplicativos como o Exchange mal pode interferir com a funcionalidade do servidor de arquivos, e eu geralmente recomendo nunca mais colocar os arquivos MDB em um servidor que é multi-tasking como um servidor do Exchange a menos que seja extremamente baixo volume.

Outras considerações:

1. nunca tente distribuir um MDB em um sistema de arquivos replicado, a menos que todos os usuários estão usando a mesma réplica. Ou seja, se você tiver dois servidores replicar arquivos entre eles, nem sequer pensar sobre a edição tharquivo e MDB de ambos os servidores. Esta irá corromper o arquivo quase imediatamente.

2. Eu recomendaria contra armazenar qualquer MDB em outra coisa senão um sistema de arquivos Windows nativo servidos via rede nativa Microsoft SMB. Isto significa que não Novell, não Linux, não SAMBA. A principal razão para isso é que há, aparentemente, ganchos de baixo nível de Jet para algumas funcionalidades de bloqueio de baixo nível no sistema de arquivos do Windows que não são 100% replicado em outras systsm arquivo. Agora, eu sou muito conservador sobre isso, e muitos desenvolvedores de Acesso competentes têm relatado excelentes resultados com servidores de arquivos Novell devidamente configurados (muitas vezes é necessário que haja alguns ajustes de bloqueio de registro, no entanto, que pode ser menos relevantes nos dias de hoje - I don 't mesmo sei se Novell existe mais!), e um desempenho incrivelmente com servidores de arquivos baseados em Linux em execução SAMBA. Eu sou cauteloso sobre isso e gostaria de recomendar qualquer cliente contra ela (isso inclui vários dispositivos SAN, assim, uma vez que não um monte deles são baseados em Windows).

3. Eu nunca iria executá-los em qualquer sistema de arquivos virtualizados pelas mesmas razões. No entanto, eu tenho um cliente que tem funcionado seu aplicativo acesso de usuário único sob Parallels em um Mac Air há vários anos sem um único problema. Mas é um único usuário, de modo que os problemas de bloqueio vão ser relativamente menor.

Eu não sei se isso responde às suas perguntas ou não. É tudo baseado em meus 13 anos de uso regular de Jet como um desenvolvedor de acesso e estudo do único livro publicado em Jet, Guia de programadores do motor do Jet banco de dados (para Jet apenas 3,5). Eu não forneceram quaisquer citações reais, mas se alguém precisa de alguns detalhes sobre qualquer coisa que eu disse, eu vou fazer a pesquisa se eu puder.

Answer 2

Eu construí uma dúzia ou aplicativos de modo de pequenas empresas no acesso ao longo dos anos. A maioria tem um máximo de 10-20 usuários sobre eles ao mesmo tempo. As bases de dados são divididos entre um "app" e um banco de dados "dados". Desempenho é decente e sem problemas com concurrancy. Também a corrupção tem sido basicamente inexistente desde Access 2000 SP2.

Há um monte de gente dizendo "não nunca usar o Access" - bem se for feito direito (ou seja, por um desenvolvedor profissional) Acesso é bastante um pacote de desenvolvimento bem e eu ter feito uma boa vida com isso. Meus clientes estão muito satisfeitos com o que eu construí.

Answer 3

Eu escrevi dois produtos comerciais que usam um banco de dados Access, correndo de um compartilhamento de rede, para tipicamente até 10 usuários. Se você não abusar dela, não há realmente nenhum problema; mas como você pode ver muitos desenvolvedores não nunca chegar lá - e por causa de seu fim natureza de baixo, há um monte de hacks ruins construídas sobre ele. No caso de um produto, eu tive que reformular o aplicativo por causa de todos os problemas descritos em detalhe por outros; mas depois que eu limpa-lo, eu nunca tive um problema de integridade de dados em centenas de instalações.

Seu uma grande vantagem é o banco de dados único arquivo, que é fácil de fazer backup, restaurar e copiar para o seu computador portátil para dissecar. Praticamente todas as alternativas, incluindo sqlite (embora alguns não vão admitir isso), exigem alguma forma de atenção DBA agora e depois.

Na maioria dos casos, Access fornece bloqueios de registo e bloqueios de arquivos para alguns DDL (por exemplo, alterações de esquema) por padrão.

Mas a Microsoft é basicamente obsoleting-lo, e alguns de seus colegas irão pilha desprezo em cima de você para usá-lo.

(Nesse ponto, eu normalmente pato para a tampa e gritar "ENTRADA !!!".)

Answer 4

O acesso é realmente um desktop, solução de usuário único. Na prática, isso tem um limite de usuário superior "um".

É também um motor local. Ou seja, quando você executa uma consulta, os dados são puxados através da rede para o motor JET local para processamento. Um arquivo .ldb é colocado no compartilhamento de rede para fechaduras de controle.

Se você usar um motor do lado do servidor (MSSQL, MySQL, Sybase, 'Orable etc), então você enviar uma consulta para um motor que processa e retorna os resultados para você. Bloqueios são mantidos internamente.

Isso tem enormes implicações para a performance, estabilidade e integridade dos dados.

Se o usuário decide pressionar o botão de reset, o databse Access tem uma oportunidade justa de ser corrompido e você terá que excluir o .ldb.

Com um motor de banco de dados apropriado (MSSQL, Sybase, 'Orable: eu não gosto de backups do MySQL), então você também um recurso de backup adequada. A menos que você tenha algum software whizzy fazer backup inuse arquivos, é possível que você não terá backups de vocês dados no Access DB.

mencionei fechaduras especificamente porque um motor db pode lidar com simultaneidade e transação muito mais eficiente e elegante do que qualquer sistema baseado em arquivo.

Eu posso ver usando um projeto do Access como um front-end para um motor de banco de dados, mas não investir em um aplicativo cliente completo com um backend Access.

Answer 5

Eu tenho usado o Access, ou mais corretamente, Jet como um back-end em uma pequena local, privada que nunca pode crescer à medida que ele é limitado pelo tamanho de uma profissão neste pequeno país. Em três anos eu não tive quaisquer problemas. Há menos de 100 usuários, com cerca de trinta a quarenta usá-lo todos os dias. As mesas têm alguns milhares de registros.

Answer 6

Eu não tenho muita experiência com Access, mas este link pode ser útil para você:

http://office.microsoft.com/en-us/access /HP052408601033.aspx

"Você pode colocar todo o banco de dados Access em um servidor de rede ou em uma pasta compartilhada. Este é o método mais fácil de implementar. Ações Todos os dados e usa os mesmos formulários, relatórios, consultas, macros e módulos. Use esta estratégia se você quiser que todos possam usar o banco de dados Access da mesma forma ou se você não pode suportar usuários criando seus próprios objetos. "

"Quando você abre um arquivo de banco de dados Access (.mdb) no modo compartilhado, o Microsoft Access também cria um arquivo de informações de bloqueio (.ldb) com o mesmo nome do arquivo (por exemplo, Northwind.ldb) e na mesma pasta o arquivo de banco de dados. este arquivo armazena informações o nome do computador de bloqueio (como MyPC) eo nome segurança (como admin) de cada usuário compartilhada do banco de dados. Microsoft Access usa essa informação para a simultaneidade de controle. na maioria dos casos, o Microsoft Access apaga automaticamente o bloqueio de arquivo de informações quando o último usuário fecha o arquivo de banco de dados. "

Answer 7

O acesso é suposto ser multi-usuário - Acho que a Microsoft recomendo para até 4 ou 5 usuários, mas na prática eu recomendo que você nunca usa um banco de dados onde existe mais do que um único usuário, embora se você realmente não tem a escolha é aceitável para dois ou três, dadas certas ressalvas.

Eu tive experiência de quatro ou cinco sistemas usando um back-end banco de dados Access - todos adquiridos de outros desenvolvedores "- e em todos os casos que eu mudei-los para SQL Server como o como uma prioridade após quaisquer atualizações imediatas e correções necessárias quando se toma o contrato - geralmente assim que eu poderia falar o chefe de pagar a conta para ele. intervalo de tempo para que é geralmente vários meses, então eu o vi correndo em simultâneo por um período razoável de tempo, sob diversas aplicações diferentes.

Na verdade, ele geralmente funciona razoavelmente bem se o sistema não tiver um monte de inserções concorrentes / atualização e não é muito utilizada. Os problemas práticos principais em minha experiência são ..

1. É passível de corrupção - ele só faz. Geralmente isso não é muito de um problema como abrir o arquivo e executar compacto e reparação irá resolver os problemas, mas um regime bom backup é absolutamente essencial.

2. É lento. Toda vez que eu tiver atualizado um sistema para SQL Server Recebi um monte de elogios para acelerar o sistema dos usuários.

3. Os incha de arquivo de banco de dados por causa da maneira que os registros de marcas Access como atualizado ou excluído. Isso ainda retarda o sistema como o arquivo tem de ser carregado através da rede. Consequentemente algum regime que comprime os dados, geralmente em uma base diária, é essencial.

Todos os itens acima são muito menos de um problema com os sistemas de um único usuário como os problemas subjacentes que alerta Estes são muito menos proeminente.

Apesar de tudo, devemos enfatizar que eu nunca recomendaria acesso para qualquer sistema multi-usuário. No entanto, se realmente tem muito você provavelmente vai fugir com ele, desde que ele é uma aplicação pouco usado e você faz instituir os procedimentos de backup e manutenção.

Answer 8

É já foi dito várias vezes para usar um verdadeiro multi-usuário, a plataforma de banco de dados livre. Mas uma das razões por que não foi dito. Esta razão é, quantos existentes, desarrumado, problemático, grandes bases de dados Access ter começado como "alguns registros, um ou dois usuários max"? Eu arriscaria dizer que todos eles.

A menos que haja apenas dois ou três funcionários em toda a empresa, as chances são de que se você desenvolver uma peça útil de software, que vai, eventualmente, ser utilizado por mais do que os originais dois ou três usuários, ter mais do que o original alguns milhares de registros, e se expandirá ao longo dos anos para incluir muitas formas, muitas mais tabelas, e muito mais dados. Você não pode refazer a fundação de uma casa uma vez que a casa é construída. Construir uma base forte hoje, e você pode expandir a casa para o conteúdo do seu coração. Mesmo para software.

Answer 9

Quando vai com um compartilhamento de rede eu iria com uma rede de banco de dados habilitado (mysql / firebird / mssql) em vez de acesso.

Para a situação a sua descrição usando o Access não seria um problema.

Não

Eu usei Acesso em mais um desafio situações, em seguida, isso principalmente quando se trabalha com sites quando Access não é abusado além da medida é realmente tão ruim de um motor de banco de dados. (Não falando de formas e coisas assim apenas tabelas e registros)

Quando você está fazendo inserções / atualizações / exclusões de vários usuários ao mesmo tempo, em seguida, ele fica um pouco peludo. Este é o ponto onde você começa a pensar sobre os motores de banco de dados reais.

Além disso, quando você quer um banco de dados de baixa sobrecarga que é o segmento de seguros você pode ter um olhar para VistaDB (acesso, em seguida, mais lento, nem sempre livre, 100% NET)

Eu acho fechaduras nível de tabela usos de acesso com algum tipo de queeing mecanismo as coisas devem funcionar ok. Se o seu preocupado com isso você pode sempre jogar um teste de estresse simulado para ele.

Answer 10

Eu acho que você pode defini-lo em sua seqüência de conexão aplicativo .net. Eu pesquisei para JET, acesso e bloqueio de registro

aqui está uma href="http://support.microsoft.com/kb/306435" rel="nofollow ligação que ajuda poder.

Por favor, veja a resposta aceita para detalhes reais sobre como os dados de acesso e obter JET.

Answer 11

Por favor, não usar o Access para um cenário multi-utilizador.

Eu acabado de passar por duas semanas de dor porque meu predeccessor em um projeto escolheu Access como um back-end.

razões concretas:

• Não existe tal coisa como Linq-to-Access
• Acesso tem inúmeras peculiaridades como dependências da ordem de adição de parâmetros para comandos que irá levá-lo idades a depuração
• Acesso não escalar
• atualizações de banco de dados é uma tarefa árdua quando comparado ao uso do SQL Server