Manter a integridade transaccional com OPLOCKS

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 224992
Este artigo foi arquivado. Este artigo é oferecido "tal como está" e deixará de ser actualizado.
Sintomas
Em circunstâncias extremas, algumas aplicações de base de dados multi-utilizadores que utilizam um arquivo de dados comuns através de uma ligação de rede num servidor de ficheiros poderão ocorrer problemas de integridade transaccional ou corrupção dos ficheiros de base de dados e/ou índices guardados no servidor. Isto normalmente se aplica a alguns denominado "ISAM estilo" ou "registo orientado" base de dados multi-utilizadores aplicações, não para um sistema de relacional de cliente/servidor como o SQL Server.
Causa
Se uma aplicação de base de dados de utilizador único ou vários utilizadores aceder a um arquivo de dados comuns num servidor de ficheiros do Windows NT com bloqueios oportunistas (ou OPLOCKS), é possível que um determinado utilizador às transacções parcial de cache no disco rígido sistemas cliente. Este é um melhoramento de desempenho para o redireccionador de cliente do Windows para reduzir a E/s de ficheiro rede entre o cliente e o servidor. Os dados colocada em cache no redireccionador do cliente é mais tarde escritos novamente para o servidor. No entanto, em alguns casos, um sistema cliente poderá deixar de responder (não reagir), efectue um reinício do disco rígido, perder a ligação de rede para o servidor ou detectar qualquer número de outras dificuldades técnicas. Nesses casos, o conteúdo da cache local que ainda não tiver sido escrito para o servidor pode ser perdido. Como resultado, a integridade da transacção das estruturas de base de dados no servidor está comprometida e os dados no servidor de ficheiros podem ficar danificados.
Resolução
Para contornar este problema, programadores que escrevam aplicações de base de dados que acedem a um arquivo de dados de rede devem esvaziar memórias intermédias do ficheiro sempre que representa delineation de uma transacção; por exemplo, depois de uma operação em massa ou anterior para fechar um identificador de ficheiro ou sempre que um registo de transacções é escrito. Pode fazê-lo através da chamada a chamada a API do Win32 FlushFileBuffers.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 224992 - Última Revisão: 12/05/2015 13:50:05 - Revisão: 1.1

Microsoft Windows NT Server 4.0 Standard Edition, Microsoft Windows NT Server 4.0 Enterprise Edition

  • kbnosurvey kbarchive kbmt kbprb KB224992 KbMtpt
Comentários