Chaves fatores a serem considerados ao avaliar sistemas de cache de arquivos de terceiros com o SQL Server

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

Neste artigo

Sumário

Este artigo descreve alguns dos principais fatores clientes devem estar cientes ao avaliar um arquivo de terceiros cache de sistema.

Implementações de cache de arquivos de terceiros podem aumentar o desempenho de bancos de dados do Microsoft SQL Server quando implementada de forma adequada. Configurações desses produtos e implementações específicas, no entanto, podem deixar bancos de dados SQL Server em um alto risco de perda de dados. Os clientes completamente devem testar a configuração para garantir a integridade de dados apropriados.

As informações contidas neste documento, incluindo URL e outras referências a sites, 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 email, logotipos, pessoas, lugares e acontecimentos aqui mencionados em exemplos são fictícios. Nenhuma associação com real da empresa, organização, produto, nome de domínio, endereço de email, logotipo, pessoa, lugar ou evento é intencional ou deve ser inferida. A conformidade com todas as leis de direitos autorais aplicáveis é responsabilidade do usuário. Sem limitar os direitos autorais, nenhuma parte deste documento pode ser reproduzida, armazenada no ou introduzida em um sistema de recuperação ou transmitida de qualquer forma ou por qualquer meio (eletrônico, mecânico, fotocópia, gravação ou não) ou para qualquer propósito, sem a permissão expressa por escrito da Microsoft Corporation.

A Microsoft pode ter patentes, aplicativos patenteados, marcas comerciais, direitos autorais ou outros direitos de propriedade intelectual abordem o assunto deste documento. Exceto se expressamente fornecido em qualquer contrato de licença escrito da Microsoft, este documento não lhe concede qualquer licença para 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 registradas ou comerciais da Microsoft Corporation nos Estados Unidos e/ou outros países.

Este artigo é escrito especificamente para o SQL Server mas geralmente se aplicam aos bancos de dados Jet usados por produtos Active Directory e Exchange Server.

Mais Informações

Esta seção descreve os requisitos e fornece exemplos detalhados que devem ser abordados completamente com um fornecedor de terceiros antes de implantar 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 é mantida adequadamente.

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

Qualquer arquivo de banco de dados ou backup do SQL Server requer conceitos básicos de armazenamento oferece suporte ao protocolo write-ahead log (WAL). Esses conceitos 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
Observação O artigo também se aplica ao SQL Server 2005.
230785Algoritmos de armazenamento de dados de log do SQL Server 7.0, SQL Server 2000 e SQL Server 2005 e estendem confiabilidade de dados
A seguir está uma lista de alguns requisitos importantes:
  • Ordenação de gravação deve ser mantida.
  • Gravação dependentes consistência deve ser mantida.
  • Gravações sempre devem ser protegidas em mídia estável ou.
  • Prevenção de E/s interrompida deve ocorrer.

Certificações de produto do parceiro não são uma garantia de compatibilidade ou segurança

Um produto de terceiros ou um fornecedor específico pode receber uma certificação de logotipo do Microsoft. No entanto, parceiro certificação ou um logotipo da Microsoft específico não certificá compatibilidade ou adequação para uma finalidade específica para o SQL Server, Exchange Server ou Active Directory.

FILE_FLAG_WRITETHROUGH e FILE_FLAG_NO_BUFFERING

Produtos de banco de dados do Microsoft especificamente use write-through e não sinalizadores de armazenamento em buffer ao abrir arquivos de banco de dados para evitar a perda de dados. Qualquer solicitação de gravação a esses arquivos deve ser protegida para mídia estável. Caso contrário, pode ocorrer perda de dados. Abaixo são exemplos específicos que podem expor caches do sistema de arquivo:
  • gravar combinando e reordenação de gravação
    Para reduzir solicitações de E/s físicas, os caches de bateria não baseados em geralmente combinam e reordenar operações de gravação, quebra os requisitos de protocolo WAL imediatamente.
  • tamanho de bloco de E/s
    Semelhante da gravação combinando e reordenação são tamanho do bloco E/s. Os caches tentará concluir E/s com base no tamanho E/s caminho bloco. Novamente, isso pode fornecer um aumento de desempenho, mas abre o banco de dados para danificar e quebra os requisitos de protocolo WAL imediatamente.

Talking pontos e exemplos

A seção a seguir fornece exemplos de chaves e pontos de talking relativas a segurança e integridade dos dados. Ele usa falha de energia como um ponto comum de falha e a clareza, mas geralmente pode ser substituído com vários outros problemas, levando a problemas de integridade do banco de dados semelhantes.

Exemplo 1: Corrupção física ou lógica e a perda de dados

Considere o seguinte cenário:
  1. Um registro de log é gravado para a página 100 no banco de dados.
  2. Um registro de log é mantido no cache baseado em não-bateria, mas o mecanismo de banco de dados é informado que a gravação de log é concluída "protegido para estável mídia".
  3. O mecanismo de banco de dados considera o LSN protegida e problemas de gravação para a página 100.
  4. Página 100 também é mantida no cache com base não bateria.
  5. Confirmar transação é concluída sem erro.
O mecanismo de banco de dados continua o processamento como se ele confirmadas com êxito as gravações mídia estável. Uma queda de energia nesse ponto, no entanto, resultará em perda de dados imediato porque as alterações nunca fisicamente existiam fora o cache dos quais foi feito não bateria. Recuperação de falhas não indica um erro porque a recuperação de falhas não sabe sobre o registro de log perdidos e não tentar refazer o trabalho. Expanda vários cenários de modificação do objeto (chave primária por exemplo, inserções de chaves externas) em vários tipos de dano do banco de dados que podem ocorrer.

Há várias outras questões que podem surgir com pequenas alterações à forma como o cache lida com a E/s. Uma breve derivação supõe que a transação foi revertida, mas mídia página 100 feita para física. Recuperação de falhas novamente não sabe sobre o registro de log (nunca tornou a estável mídia), caso será de 100 páginas não receber desfazer operações durante a recuperação de falha, deixando o banco de dados corrompido logicamente e possivelmente fisicamente.

Exemplo 2: Banco de dados SUSPECT

Alguns fornecedores de permitem "opt-out de arquivos" e geralmente recomendam deixar o arquivo de log (.ldf para o SQL Server) do banco de dados tiver optado fora do cache. A diretiva "optar por sair" é, que o administrador tenha especificamente marcar os arquivos a ser ignorado pelo software de armazenamento em cache. Caso contrário, o arquivo é incluído automaticamente.

Isso é uma suposição ruim, como realçar os exemplos a seguir. A Microsoft recomenda todos os banco de dados e arquivos de backup ser optado por fora do como um cache.
  1. O arquivo de log é decidido, para que gravações estão obtendo mídia estável.
  2. Página 100 é modificada.
  3. O mecanismo de banco de dados executa uma operação de ponto de verificação.
  4. O mecanismo é informado de todas as páginas do banco de dados e registros de log são seguros (protegida de ponto no tempo até o ponto de verificação considerado). No entanto, as páginas de dados não são todos armazenados em ou em mídia estável.
  5. O banco de dados do SQL Server está no modo recuperação "SIMPLE", para que o ponto de verificação agora trunca os registros de log.
  6. Página 100 que foi apenas seleção apontada é modificado novamente.
Essa situação tem expostos o banco de dados a perda de dados e geralmente resulta em um banco de dados suspeito. Novamente, se acontecer uma queda de energia, recuperação de falhas não tem nenhum registro de log porque não existe devido ao truncamento. O mecanismo de banco de dados não tem nenhuma informação indicando que páginas do banco de dados estão faltando dados que devem ter sido protegidos durante a verificação. Recuperação de falhas tenta analisar a segunda modificação na página 100 mas falhará porque a página 100 não foi adequadamente protegida para mídia estável no momento do ponto de verificação.

Recuperação de falhas usa o valor LSN armazenado no cabeçalho da página para determinar necessidades de recuperação.
  • Se o LSN na página for igual a ou mais recente do que o registro de log, recuperação não nenhum trabalho adicional na página porque a página já está consistente com o registro de log com base na comparação LSN.
  • Se o LSN na página for mais antigo do que o registro de log, recuperação precisa executar as operações apropriadas para retornar a página ao estado correto. Recuperação falhará se a recuperação foi descoberta uma condição de dados ausentes e corretamente não é possível retornar a página ao seu estado correto.
No exemplo, o LSN anterior armazenado no registro de log para a segunda modificação da página 100 não existe no cabeçalho da página e não há nenhum presente para refazer a página de registro de log anterior. Portanto, o banco de dados está marcado como suspeito, como recuperação não pode continuar com segurança.

Exemplo 3: Backups não são válidos - quebra de cadeia de backup silencioso

Exemplo 2 é apenas uma fração desses tipos de problemas que podem ser encontrados. Neste exemplo, em vez de modo de recuperação "SIMPLE", vamos colocar o banco de dados no modo de "FULL RECOVERY" mas fazer backups regulares do log e banco de dados. A princípio, parece que isso seria melhor porque você tem uma cadeia de log intacto e pode executar apenas uma seqüência de restauração para corrigir o problema.

Isso não pode ser uma suposição válida, como algumas implementações de cache de usam a diretiva "optar por sair" para que o arquivo de backup ou partes dele podem ser armazenado em inesperadamente cache. Quando o SQL Server libera o arquivo de backup, SQL Server requer que todas as gravações na mídia de backup corretamente são armazenadas em mídia estável usando a função de API do Win32 FlushFileBuffers ou. Portanto, se o fornecedor de cache não garante a todas as gravações são liberadas corretamente, durante a chamada de função FlushFileBuffers , para estável mídia antes da operação com êxito conclusão, o banco de dados de mecanismo pode truncar o log sem um backup protegido. Novamente, uma falha de energia nesse ponto resulta em uma condição onde os registros de log adequados estão faltando e podem causar a recuperação de falhas falha. O que é mais importante é que a recuperação de falha pode não ser capaz de detectar isso devido dos registros do log ausente no banco de dados e a cadeia de backup pode estar danificada silenciosamente. Somente quando é tentada uma restauração do backup o mecanismo de banco de dados poderão indicar que o backup foi danificado.

Exemplo 4: Estados de banco de dados inválido

Arquivos de banco de dados contêm dependências entre si exigir estrito write-through e conformidade para aplicar a todas elas como um grupo de ordenação. Ponto de verificação, alterações de tamanho de arquivo, os backups diferenciais, operações não conectado e o modelo de recuperação BULK LOGGED estão entre algumas das atividades de banco de dados de chaves que exigem a gravação para ocorrer em arquivos de dados, tornando diretivas como Cancelar check-out somente do arquivo de log uma pressuposição inválida.

Exemplo 5: Perda de dados de banco de dados snapshot ? pode ser silencioso

O SQL Server 2005 introduz instantâneo bancos de dados de ponto no tempo de consultas. Isso usa tecnologia de banco de dados de cópia-na-gravação para ajudar a proteger uma cópia de uma página de dados no banco de dados de instantâneo de dados antes de uma nova modificação é feita para a página a dados no banco de dados base. Esse processo requer que a página ser protegidos no banco de dados instantâneo antes de continuar a transação. Se a página não estiver protegida em ou em mídia estável, problemas de integridade de dados serão mantidas. Banco de dados de instantâneo não contém um log de transações, por isso a gravação da página é fundamental. Se algo como uma queda de energia ocorreu, talvez seja possível que a página de banco de dados principal foi alterada mas o instantâneo não reflete a imagem anterior porque a gravação em cache foi perdida.

Como configurar

Como configurar um produto fornecendo o arquivo de cache de algo como o cache dos quais foi feito de bateria não é específico para a implementação do fornecedor. No entanto, algumas regras, podem ser aplicadas:
  • Todas as gravações devem ser concluídas em mídia estável ou antes do cache indica para o sistema operacional que a E/s é concluída.
  • Os dados podem ser armazenados em cache, desde que uma solicitação de leitura servida do cache retorna a mesma imagem como localizado em ou em mídia estável.
Essas regras essencialmente significam que o cache dos quais foi feito de bateria não pode ser eficaz para operações de leitura mas não deve ser usado para solicitações de gravação. Com a configuração adequada, isso pode fornecer um ganho de desempenho para o mecanismo de banco de dados. Isso deve, no entanto, ser testada cuidadosamente, porque a configuração reservado algo como RAM que pode ser usado pelo SQL Server pode degradar o desempenho geral. SQL Server não poderá usar a memória extra com mais precisão de um mecanismo de cache genérico.

Bancos de dados somente leitura

Bancos de dados somente leitura podem ser um bom exemplo onde esses tipos de produtos do excel. Se o banco de dados primeiro foi criado e armazenado em ou em mídia estável para garantir a integridade dos dados, a instrução ALTER DATABASE usada para marcar o banco de dados somente leitura e o banco de dados posteriormente atribuídos ao mecanismo de cache, ganhos de desempenho podem ser encontrados. Algumas implementações manter imagens compactadas das páginas de banco de dados no cache, permitindo que mais físicos dados a serem recuperados do cache e reduzindo E/s física.

cuidado O banco de dados nunca deve ser feito leitura gravação quando atribuído a um cache que não Defender o protocolo WAL.

Segurança

Apresentar um cache, como o cache do sistema arquivo baseado em RAM, introduz outro local "na memória" de dados. Produtos, como um mecanismo de banco de dados podem assumir dados críticos foi armazenados em mídia estável ou e mantêm corretamente as proteções de ACL (lista) de controle de acesso. O cache de RAM pode expor os dados para um conjunto de problemas de segurança que são exclusivos em comparação com mídia estável. Por exemplo, se o aplicativo é projetado para usar algo como a função SecureZeroMemory toda vez que ele terminou de usar informações críticas, o aplicativo tem uma expectativa que os dados não existem mais na RAM. No entanto, se uma forma dos dados pode permanecer em cache quando o aplicativo espera que ele seja em mídia estável ou, pode alterar as considerações de segurança.

Verificações de integridade de dados

A Microsoft sempre recomenda uma estratégia de integridade de dados de alta segurança e limpar. Isso deve incluir, mas não está limitado a, restaurando de backups e as operações normais DBCC CHECKDB no banco de dados restaurado e a produção.

A Microsoft também recomenda aumentar a freqüência desses testes de segurança ao avaliar e implementar alterações no ambiente ou se surgirem qualquer preocupações relativas a estabilidade do ambiente de.

Para obter mais informações sobre como usar o SQLIOStress utilitário, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
231619Como usar o utilitário SQLIOStress para enfatizar um subsistema de disco, como o SQL Server

O banco de dados TEMPDB

É possível localizar o banco de dados TEMPDB em determinados sistemas de armazenamento em cache. Vários fatores devem ser cuidadosamente considerados e testados ao avaliar o local de armazenamento do banco de dados TEMPDB nessa configuração. O seguinte artigo descreve os requisitos de E/s, limites de suporte associada e ganhos de desempenho possível.
917047Requisitos de subsistema de E/s do Microsoft SQL Server para o banco de dados TEMPDB

Suporte

Suporte do Microsoft SQL Server ajudará os clientes, usando técnicas de recuperação de dados padrão. Se o produto instalado no computador desenho integridade dos dados em questão, Microsoft SQL Server, Active Directory e suporte do Exchange pode solicitar que o produto ser desinstalado e será não participar análise da causa raiz até esse momento o problema pode ser reproduzido sem produto citado.

Microsoft não certifica ou validar se os produtos de terceiros funcionam corretamente com o SQL Server. Além disso, a Microsoft não fornece qualquer garantia, garantia ou declaração de adequação do produto de terceiros para uso com o SQL Server.

Referências

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

826433Diagnóstico de SQL Server adicional ao detectar problemas de E/s unreported
828339Mensagem de erro 823 pode indicar problemas de hardware ou problemas do sistema no SQL Server
234656Usando cache de disco com o SQL Server
110352Otimizar o desempenho do Microsoft SQL Server
304261Descrição do suporte para arquivos de banco de dados de rede no SQL Server
910716Suporte para soluções de espelhamento remoto de terceiros usado com SQL Server 2000 e 2005 usuário bancos de dados
913945Microsoft não certificar que os produtos de terceiros irão funcionar com Microsoft SQL Server
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: 917043 - Última revisão: sexta-feira, 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 Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • 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 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: 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