Descrição do cache de controladores de disco no SQL Server

Traduções deste artigo Traduções deste artigo
ID do artigo: 86903 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Sumário

Uso de uma gravação em cache (também chamado de gravação fazer cache) controlador de disco pode melhorar o desempenho do SQL Server. Controladores de armazenamento em cache de gravação e subsistemas de disco são seguros para o SQL Server, se eles foram criados para uso em um ambiente de sistema (DBMS) de gerenciamento de banco de dados transacional crítica dados. Esses recursos de design devem preservar dados armazenados em cache se ocorrer uma falha do sistema. Usando um externo no-break (UPS) para conseguir isso geralmente não é suficiente, como modos de falha que são não relacionados a energia podem ocorrer.

Cache de controladores e subsistemas de disco pode ser seguro para uso pelo SQL Server. A maioria das novas plataformas de servidor interna que incorporam esses são seguras. No entanto, você deve verificar com seu fornecedor do hardware para certificar-se o subsistema de disco foram testado e aprovado para uso em um ambiente de RDBMS (sistema) dados crítica banco de dados relacionais transacionais gerenciamento especificamente.

Mais Informações

Instruções de modificação de dados do SQL Server geram gravações de página lógica. Este fluxo de gravações pode ser ilustrado como passar dois locais: o log e o próprio banco de dados. Por motivos de desempenho, SQL Server adia a gravações no banco de dados por meio de seu próprio sistema de buffer de cache. Grava no log de apenas momentaneamente é adiadas até COMMIT tempo. Eles não são armazenados em cache da mesma maneira como gravação de dados. Porque gravações do log para uma determinada página sempre precedem grava dados da página, às vezes, o log é chamado como um "gravação-ahead" log.

Integridade transacional é um dos conceitos fundamentais de um sistema de banco de dados relacional. As transações são consideradas unidades atômicas de trabalho que são totalmente aplicadas ou totalmente revertida. O log de transação gravação-ahead do SQL Server é um componente vital na implementação de integridade transacional.

Qualquer sistema de banco de dados relacional também deve lidar com um conceito relacionado à integridade transacional, que é a recuperação de falha do sistema não planejado. Uma variedade de não-ideal, efeitos de mundo real podem causar a falha. Em muitos sistemas de gerenciamento de banco de dados, falha do sistema pode resultar em um processo demorado direcionado humanos recuperação manual.

Por outro lado, o mecanismo de recuperação do SQL Server é totalmente automático e opera sem a intervenção humana. Por exemplo, SQL Server pode ser um aplicativo de produção de missão crítica de suporte e ocorrer uma falha do sistema devido a uma flutuação de energia momentânea. Após a restauração de energia, o hardware de servidor será reiniciado, o software de rede deve carregar e inicializar e SQL Server será reiniciado. Como o SQL Server é inicializado, ele será executado automaticamente seu processo de recuperação com base nos dados no log de transações. Todo esse processo ocorre sem intervenção humana. Sempre que as estações de trabalho cliente reiniciado, os usuários encontrar todos os seus dados presentes, até a última transação inseriram.

Integridade transacional do SQL Server e a recuperação automática constituem um recurso de salvamento de tempo e trabalho muito eficiente. Se um controlador de armazenamento em cache de gravação não foi desenvolvido corretamente para uso em um ambiente de DBMS ' dados crítico transacional, ela pode comprometer a capacidade de recuperar, do SQL Server, portanto, corrompendo o banco de dados. Isso pode ocorrer se o controlador intercepta buffers-los em um hardware de cache na placa do controlador e gravações de log de transação do SQL Server, mas não preserva esses gravadas páginas durante uma falha do sistema.

Controladores de armazenamento em cache mais executam a gravação em cache. A função de cache de gravação sempre não pode ser desativada.

Mesmo se o servidor usa um no-break, isso não garante a segurança de gravações em cache. Muitos tipos de falhas do sistema podem ocorrer que não trata um no-break. Por exemplo, um erro de paridade de memória, uma interceptação de sistema operacional ou um problema de hardware que faz com que uma reinicialização do sistema pode produzir uma interrupção do sistema não controlada. Uma falha de memória no cache de gravação de hardware também pode resultar na perda de informações de log vital.

Outro problema possível relacionado a um controlador de gravação em cache pode ocorrer no desligamento do sistema. Não é incomum para "Circular" o sistema operacional ou reinicializar o sistema durante alterações de configuração. Mesmo se um operador de cuidado segue a recomendação de sistema operacional aguardar até que toda atividade de disco tem deixou antes de reinicializar o sistema, gravações em cache ainda podem estar presentes no controlador de. Quando a combinação de teclas CTRL + ALT + DEL é pressionada ou o botão RESET é pressionado, gravações em cache podem ser descartadas, potencialmente prejudiciais o banco de dados.

É possível criar um cache de gravação de hardware que leva em conta todas as possíveis causas de descartando dados cache sujo, que, portanto, ser seguros para uso por um servidor de banco de dados. Algumas desses design recursos incluiria interceptar o barramento RST sinal evitar redefinição não controlada do controlador de armazenamento em cache, placa bateria de reserva e espelhados ou memória ERC (verificação de erros & corrigindo). Verifique com seu fornecedor de hardware para garantir que o cache de gravação inclui esses e outros recursos necessários para evitar perda de dados.

SQL Server requer sistemas para oferecer suporte a ? entrega de mídia estável garantida ? conforme descrito no programa do Microsoft SQL Server Always-On armazenamento Solution revisão. FOPara obter mais informações sobre os requisitos de entrada e saídas para o mecanismo de banco de dados do SQL Server, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
967576Requisitos do Microsoft SQL Server Database Engine entrada/saída

Propriedades

ID do artigo: 86903 - Última revisão: quarta-feira, 7 de dezembro de 2005 - Revisão: 4.3
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Palavras-chave: 
kbmt kb3rdparty kbhardware kbinfo KB86903 KbMtpt
Tradução automática
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 traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 86903

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com