Chaves factores a considerar ao avaliar sistemas de cache de ficheiros de outros fabricantes com o SQL Server

Traduções de Artigos Traduções de Artigos
Artigo: 917043 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Este artigo descreve alguns dos factores chaves os clientes devem ter em atenção ao avaliar um ficheiro de outros fabricantes colocação em cache do sistema.

Implementações de cache de ficheiros de outros fabricantes podem aumentar o desempenho de bases de dados do Microsoft SQL Server quando correctamente implementado. Bases de dados do SQL Server podem deixar a configurações destes produtos e implementações específicas, no entanto, um elevado risco de perda de dados. Os clientes completamente deverão testar a configuração para assegurar a integridade de dados adequados.

As informações contidas neste documento, incluindo URLs e outras referências a Web site, estão sujeitas a alterações sem aviso prévio. Salvo indicação em contrário, empresas, organizações, produtos, nomes de domínio, endereços de correio electrónico, logótipos, pessoas, locais e eventos mencionados nos exemplos aqui mencionados são fictícios. Nenhuma associação com qualquer empresa, organização, produto, nome de domínio, endereço de correio electrónico, logótipo, pessoa, local ou evento é intencional ou deve ser inferida. Em conformidade com todas as leis de copyright aplicáveis é da responsabilidade do utilizador. Sem limitação direitos autorais, nenhuma parte deste documento pode ser reproduzida, armazenada no introduzida num sistema de obtenção ou transmitida sob qualquer forma ou por qualquer meio (electrónico, mecânico, fotocópias, gravação ou outro) ou para qualquer finalidade, sem a permissão escrita explícita da Microsoft Corporation.

Microsoft pode ter patentes, aplicações de patentes, marcas comerciais, direitos de autor ou outros direitos de propriedade intelectual que abranjam o assunto neste documento. Salvo expressamente fornecido em qualquer contrato de licença escrito da Microsoft, o facto deste documento não lhe quaisquer direitos sobre essas patentes, marcas comerciais, direitos autorais ou outra propriedade intelectual.

© 2006 Microsoft Corporation. Todos os direitos reservados.

Microsoft, Windows, Windows Server e SQL Server são marcas registadas ou marcas comerciais da Microsoft Corporation nos Estados Unidos e/ou noutros países.

Este artigo escrito especificamente para o SQL Server, mas aplica-se geralmente a bases de dados Jet utilizados pelo Active Directory e Exchange Server produtos bem.

Mais Informação

Esta secção descreve os requisitos e fornece exemplos detalhados abordados devem ser completamente com um fornecedor de terceiros antes de implementar qualquer solução. Os clientes também devem tomar cuidado especial para testar vários cenários de recuperação para garantir a integridade dos dados correctamente é mantida.

Requisitos de entrada/saída (E/s) do SQL Server

Qualquer ficheiro de base de dados ou de cópia de segurança do SQL Server requer Noções básicas de armazenamento suporta o protocolo de escrita à frente de registo (WAL). Estes princípios básicos são descritos nos seguintes artigos:
Noções básicas de E/s do SQL Server 2000
http://technet.microsoft.com/en-us/library/cc966500.aspx
Nota O artigo também se aplica ao SQL Server 2005.
230785Algoritmos de armazenamento de dados de registo de SQL Server 7.0, SQL Server 2000 e SQL Server 2005 e expandem fiabilidade dos dados
Segue-se uma lista de alguns requisitos importantes:
  • Escrita encomenda deve ser mantida.
  • Escrita dependentes consistência deve ser mantida.
  • Escreve sempre deve ser protegidos no ou no suporte estável.
  • Prevenção de E/s rasgada deve ocorrer.

Parceiro produto certificações não são uma garantia de segurança ou de compatibilidade

Um produto de terceiros ou um fornecedor específico, pode receber uma certificação de logótipo do Microsoft. No entanto, certificação parceiro ou um logótipo Microsoft específico não certificá compatibilidade ou adequação a um fim específico para o SQL Server, Exchange Server ou do Active Directory.

FILE_FLAG_WRITETHROUGH e FILE_FLAG_NO_BUFFERING

Produtos de base de dados do Microsoft especificamente utilize a actualização simultânea e sem sinalizadores de colocação na memória intermédia ao abrir ficheiros de base de dados para evitar a perda de dados. Qualquer pedido de escrita a estes ficheiros deve ser protegido para suporte estável. Caso contrário, pode ocorrer perda de dados. Listados abaixo são exemplos específicos que podem expor as caches do sistema de ficheiro:
  • escrever combinar e a reordenação de escrita
    Para reduzir a pedidos de E/s físicos, as caches baseados em bateria não frequentemente combinam e reordenar operações de escrita, interromper imediatamente os requisitos de protocolo WAL.
  • tamanho de bloco de E/s
    Semelhante à escrita combinar e reordenar são tamanho de bloco de E/s. As caches irão tentar concluir E/s baseado o tamanho de bloco de caminho de E/s. Novamente, este pode fornecer um aumento de desempenho, mas abre a base de dados para danificar e interrompe imediatamente os requisitos de protocolo WAL.

Talking pontos e exemplos

A secção seguinte fornece exemplos de chaves e pontos de talking relativas a integridade dos dados e segurança. Utiliza falha de energia como um ponto de falha e a clareza comuns, mas muitas vezes, pode ser substituído com vários outros problemas à esquerda para problemas de integridade da base de dados semelhantes.

Exemplo 1: Perda de dados e danos físicos ou lógicos

Considere o seguinte cenário:
  1. Um registo é escrito para a página 100 na base de dados.
  2. Um registo é mantido na cache não baseados em bateria, mas o motor de base de dados é indicado que a escrita de registo é concluída "segura para estável suportes de dados".
  3. O motor de base de dados considera o LSN hardened e problemas de escrita para a página 100.
  4. Página 100 também é mantida na bateria não baseados em cache.
  5. Consolidar transacção é concluída sem erros.
O motor de base de dados continua o processamento como se consolidada com êxito o escreve suporte estável. Uma falha de energia nesta altura, no entanto, resultará numa perda de dados imediata porque as alterações nunca fisicamente existiam fora da cache dos quais efectuou cópia de segurança sem bateria. Recuperação de falhas não indica um erro porque a recuperação de falhas não tem conhecimento sobre o registo perdidos e não irá tentar repetir o trabalho. Expandir vários cenários de modificação de objecto (chave primária por exemplo, inserções de chaves externas) em vários tipos de danos da base de dados que podem ocorrer.

Existem vários problemas que podem surgir com pequenas alterações à forma como a cache processa a E/s. Uma derivação breve assume que a transacção foi anulada, mas página 100 efectuada físico para suportes de dados. Recuperação de falhas novamente não saberá sobre o registro de log (nunca efectuado que estável suportes de dados), caso será de 100 de página não receber anular operações durante a recuperação de falhas, deixando a base de dados lógica e possivelmente fisicamente danificado.

Exemplo 2: Base de dados suspeitos

Alguns fabricantes permitem "opt de ficheiros" e recomendam, muitas vezes, deixar o ficheiro de registo da base de dados (.ldf para o SQL Server) consentido da cache. A política "opt" é que o administrador tem especificamente a marca os ficheiros sejam ignoradas pelo software de colocação em cache. Caso contrário, o ficheiro é automaticamente incluído.

É pressupostos fraca, realce os seguintes exemplos. A Microsoft recomenda todas as base de dados e ficheiros de cópia de segurança ser consentido esgotada tal uma cache.
  1. O ficheiro de registo é consentido, modo escritas estão a obter suporte de dados estáveis.
  2. Página 100 é modificada.
  3. O motor de base de dados é executada uma operação de ponto de verificação.
  4. É indicado o motor da base de todos os dados páginas e registos são seguros (ponto no tempo até ao ponto de verificação considerado hardened). No entanto, as páginas de dados não são todos armazenados num ou em suportes estáveis.
  5. Está a base de dados do SQL Server no modo de recuperação "SIMPLES", para que o ponto de verificação agora trunca os registos.
  6. 100 De página que foi apenas verificação apontada é modificado novamente.
Esta situação tem expostos a base de dados a perda de dados e normalmente resulta numa base de dados suspeito. Novamente, se ocorrer uma falha de energia, recuperação de falhas tem sem registos porque já não existe devido a truncagem. O motor de base de dados não tem informações indicando que faltam dados que devem ter sido protegidos durante o ponto de verificação páginas de base de dados. Recuperação de falhas tenta analisar a segunda modificação na página 100 mas falha porque página 100 não estava correctamente protegida estável suporte de dados na altura do ponto de verificação.

Recuperação de falhas utiliza o valor LSN armazenado no cabeçalho da página para determinar necessidades de recuperação.
  • Se o LSN na página for igual ou mais recente do que o registo, recuperação funciona sem mais na página porque a página já está consistente com o registo com base na comparação LSN.
  • Se LSN na página for mais antigo do que o registo, recuperação terá de efectuar as operações correctas para devolver a página para o estado correcto. Recuperação falha se recuperação tem uncovered uma condição de dados em falta e correctamente não é possível devolver a página ao respectivo estado legítimo.
No exemplo, o LSN anterior armazenado no registo para a segunda modificação da página 100 não existe no cabeçalho da página e não existe nenhum registo anterior registo presente para refazer a página. Por conseguinte, a base de dados está marcado como sendo suspeito, como recuperação de segurança não pode continuar.

Exemplo 3: Cópias de segurança não são válidas - cadeia de cópia de segurança silencioso quebra

Exemplo 2 é apenas uma fracção destes tipos de problemas que podem ser detectados. Neste exemplo, em vez do modo de recuperação "SIMPLE", deixe-nos colocar a base de dados em "FULL RECOVERY" modo mas efectuar regularmente cópias de segurança do registo e base de dados. Primeiro, parece que poderá ser melhor porque tem uma cadeia de registo intacto e apenas é possível executar uma sequência de restauro para corrigir o problema.

Isto poderá não ser pressupostos válido, à medida que algumas implementações de cache utilizam a política "opt" para que o ficheiro de cópia de segurança ou partes do mesmo podem ser colocada em inesperadamente cache. Quando do SQL Server esvazia o ficheiro de cópia de segurança, o SQL Server requer que todas as escritas para o suporte de cópia de segurança são correctamente armazenadas no ou no suporte de dados estáveis utilizando a função de API do Win32 FlushFileBuffers . Assim, se o fornecedor de cache não garante a todas as escritas correctamente são limpas, durante a chamada de função FlushFileBuffers , para estável suportes de dados antes de concluída a operação com êxito, a base de dados de motor pode truncar o registo sem uma cópia de segurança protegida. Novamente, uma falha de energia neste momento provoca uma condição onde os registos adequados estão em falta e podem causar a recuperação de falhas falha. O que é mais importante é que recuperação de falhas poderá não ser capaz de detectar isto devido dos registos de registo em falta na base de dados e a cadeia de cópia de segurança pode estar danificada silenciosamente. Quando um restauro da cópia de segurança é tentado o motor de base de dados será possível indicar que a cópia de segurança foi danificada.

Exemplo 4: Estados de base de dados inválido

Ficheiros de base de dados contêm dependências entre si requerer estrita actualização simultânea e conformidade para aplicar a todos os como um grupo de ordenação. Ponto de verificação, tamanho do ficheiro é alterado, diferencial, operações não registados e o modelo de recuperação BULK REGISTADOS são entre alguns as actividades de chave da base de dados que requerem escrita completa para ocorrer em ficheiros de dados, efectuar políticas como activando saída apenas do ficheiro de registo pressuposto inválido.

Exemplo 5: Perda de dados da base de dados de Snapshot ? poderá ser silenciosa

SQL Server 2005 introduz instantâneo bases de dados para o ponto no tempo consultas. Este utiliza a base de dados cópia na escrita tecnologia para ajudar a proteger uma cópia de uma página de dados na base de dados de instantâneo de dados antes de uma modificação nova é efectuada à página de dados na base de dados base. Este processo requer que a página ser protegida na base de dados instantâneo antes da transacção pode continuar. Se a página não estiver protegida no ou no suporte estável, persistirá problemas de integridade de dados. A base de dados snapshot não contém um registo de transacções, pelo que a escrita da página é crítica. Se tiver ocorrido semelhante uma falha de energia, poderá ser possível que a página de base de dados principal foi alterada mas o snapshot não reflecte a imagem anterior porque se perdeu a escrita em cache.

Como configurar

Como configurar um produto fornecendo cache de ficheiros a partir de algo como cache dos quais efectuou cópia de segurança da bateria não é específico para a implementação de fornecedor. No entanto, algumas regras, podem ser aplicadas:
  • Todas as escritas devem ser preenchidas no ou no suporte estável antes da cache indica ao sistema operativo que a E/s foi concluída.
  • Dados podem ser colocada em cache, desde que um pedido de leitura servido a partir da cache devolve a mesma imagem como localizado no ou no suporte estável.
Estas regras essencialmente significam que a cache de cópia de segurança de bateria não pode ser eficaz para as operações de leitura mas não deve ser utilizada para pedidos de escrita. Com a configuração correcta, este poderá fornecer um ganho em desempenho para o motor de base de dados. Isto deve, no entanto, ser testada cuidadosamente, porque a definição reservar algo como RAM que pode ser utilizado pelo SQL Server pode degradar o desempenho global. SQL Server poderá utilizar a memória adicional com precisão mais do que um mecanismo de cache genérico.

Bases de dados só de leitura

Bases de dados só de leitura podem ser um bom exemplo onde estes tipos de produtos do excel. Se a base de dados primeiro criado e armazenado numa ou em suportes estáveis para garantir a integridade dos dados, a instrução ALTER DATABASE utilizado para marcar READ ONLY a base de dados e a base de dados atribuído posteriormente o mecanismo de colocação em cache, ganhos de desempenho podem ser encontrados. Algumas implementações manter comprimidas imagens das páginas de base de dados na cache, permitindo físicos mais dados a serem obtidos a partir da cache e reduzir E/s física.

atenção A base de dados nunca deverá ser feita leitura escrita quando atribuído a uma cache não manter o protocolo WAL.

Segurança

Introdução à cache, tais como cache do sistema de ficheiros baseados em RAM, introduz outra localização de "na memória" para dados. Produtos como um motor de base de dados podem assumir dados críticos foi armazenados no ou no suporte estável e correctamente retêm protecções de lista (ACL, Access Control List) do controlo de acesso. A cache de RAM poderá expor os dados para um conjunto de problemas de segurança que são exclusivos quando comparados com suportes de dados estáveis. Por exemplo, se a aplicação é concebida para utilizar algo parecido com a função SecureZeroMemory sempre que tiver terminado de utilizar informações críticas, a aplicação tem uma expectativa que os dados já não existem na memória RAM. No entanto, se um formulário de dados pode permanecer em cache quando a aplicação era esperado que seja no ou no suporte estável, pode alterar as considerações de segurança.

Verificações de integridade de dados

A Microsoft recomenda sempre uma estratégia de integridade de dados segura e simples. Deve incluir, mas não está limitado a, o restauro de cópias de segurança e normais DBCC CHECKDB operações na produção e base de dados restaurada.

A Microsoft recomenda também a aumentar a frequência destes testes de segurança quando avaliar e implementar as alterações de ambiente ou se ocorrerem quaisquer questões relativas a estabilidade do ambiente de.

Para mais informações sobre como utilizar o SQLIOStress utilitário, clique no número de artigo que se segue para visualizar o artigo na base de dados de conhecimento da Microsoft:
231619Como utilizar o utilitário SQLIOStress para salientar um subsistema de disco como, por exemplo, o SQL Server

Base de dados TEMPDB

É possível localizar a base de dados TEMPDB em determinados sistemas colocação em cache. Vários factores devem ser cuidadosamente considerados e testados quando avaliar a localização de armazenamento da base de dados TEMPDB nesta configuração. O artigo da base de dados de conhecimento da Microsoft seguinte descreve os requisitos de E/s, limites de suporte associado e ganhos de desempenho possível.
917047Requisitos de subsistema de E/s do Microsoft SQL Server para base de dados TEMPDB

Suporte

Suporte do Microsoft SQL Server vai ajudar os clientes, utilizar técnicas de recuperação de dados padrão. Se produtos instalados no computador desenho integridade de dados em questão, o Microsoft SQL Server, do Active Directory e suporte do Exchange poderá solicitar que o produto ser desinstalado e irá participar não na análise de causa raiz até esse momento o problema pode ser reproduzido desses produtos.

Microsoft não certificá ou validar a que os produtos de outros fabricantes funcionam correctamente com o SQL Server. Além disso, a Microsoft não fornece qualquer garantia, garantia ou instrução de adequação de qualquer produto de terceiros para utilização com o SQL Server.

Referências

Considere cuidadosamente as informações adicionais fornecidas pelas seguintes referências para avaliar o melhoramento do desempenho do SQL Server:

826433Diagnósticos de SQL Server adicionais ao detectar problemas de E/s não reportados
828339Mensagem de erro 823 poderá indicar problemas de hardware ou problemas do sistema no SQL Server
234656Utilizar unidade de disco em cache com o SQL Server
110352Optimizar o desempenho do Microsoft SQL Server
304261Descrição do suporte para ficheiros de base de dados de rede no SQL Server
910716Suporte para soluções de mirror remoto de terceiros utilizado com o SQL Server 2000 e bases de dados de utilizador de 2005
913945Microsoft não certificar de que os produtos de outros fabricantes funcione com o Microsoft SQL Server
SQL Server requer sistemas para suportar ? garantida a entrega de multimédia estável ? conforme descrito no programa do Microsoft SQL Server Always-On armazenamento solução de revisão. FOPara obter mais informações sobre os requisitos de entrada e saídas para o motor de base de dados do SQL Server, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:
967576Requisitos de motor de entrada/saída do Microsoft SQL da base de dados do servidor

Propriedades

Artigo: 917043 - Última revisão: 2 de novembro de 2007 - Revisão: 1.5
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Palavras-chave: 
kbmt kbexpertiseadvanced kbinfo KB917043 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 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: 917043

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