Você está offline; aguardando reconexão

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

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
Este artigo foi arquivado. Este artigo é oferecido "tal como está" e deixará de ser actualizado.
Sumário
Este artigo descreve alguns dos factores chaves os clientes devem ter em consideração quando avaliar um ficheiro de outro sistema de colocação em cache.

Implementações de cache de ficheiros de outros fabricantes podem aumentar o desempenho das bases de dados do Microsoft SQL Server quando correctamente implementado. Implementações específicas, no entanto e configurações destes produtos podem deixe bases de dados do SQL Server com um elevado risco de perda de dados. Os clientes completamente devem 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 sites, estão sujeitas a alterações sem aviso prévio. Salvo disposição contrária, a empresas, organizações, produtos, nomes de domínio, endereços de correio electrónico, logótipos, pessoas, locais e eventos mencionados neste documento são fictícios. Tem por objectivo nem deve ser inferida 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. Conformes com todas as leis de direitos de autor aplicáveis é da responsabilidade do utilizador. Sem limitação dos direitos autorais, nenhuma parte deste documento pode ser reproduzida, armazenada na ou introduzida num sistema de obtenção ou transmitida sob qualquer forma ou por qualquer meio (electrónico, mecânico, fotocópia, gravação ou outro modo) ou para qualquer fim, sem a permissão escrita explícita da Microsoft Corporation.

A Microsoft pode ter patentes, candidaturas a patentes, marcas comerciais, direitos de autor ou outros direitos de propriedade intelectual que abranjam o assunto deste documento. Excepto conforme expressamente indicado em qualquer contrato de licença escrito da Microsoft, o fornecimento deste documento não lhe concede quaisquer direitos sobre essas patentes, marcas comerciais, direitos de autor ou outros direitos de propriedade intelectual.

© 2006 Microsoft Corporation. Todos os direitos reservados.

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

Este artigo se destina especificamente ao SQL Server, mas geralmente aplica-se às bases de dados Jet utilizados pelos produtos, bem como o Active Directory e Exchange Server.
Mais Informação
Esta secção descreve os requisitos e fornece exemplos detalhados que devem ser discutidos completamente com um vendedor de outros fabricantes antes de implementar qualquer solução. Os clientes devem igualmente ter especial cuidado para testar vários cenários de recuperação para se certificar de que a integridade dos dados seja correctamente mantida.

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

Qualquer ficheiro de cópia de segurança ou de base de dados do SQL Server requer Noções básicas de armazenamento suporta o protocolo de registo escrita-para-avanço (WAL). Estes princípios básicos são descritos nos seguintes artigos:
Noções básicas do SQL Server 2000 e/s
http://technet.microsoft.com/en-us/library/cc966500.aspx
Nota O artigo também se aplica para o SQL Server 2005 e versões posteriores.
230785 Registo de SQL Server 7.0, SQL Server 2000 e SQL Server 2005 e algoritmos de armazenamento de dados aumentam a fiabilidade dos dados
Segue-se uma lista de alguns requisitos importantes:
  • Deve ser mantida a ordenação de escrita.
  • Deve ser mantida coerência escrita dependentes.
  • Escreve sempre tem de ser protegido no ou no stablemedia.
  • Prevenção de e/s rasgada tem de ocorrer.

Certificação de produto do parceiro não é uma garantia de segurança ou de compatibilidade

Um produto de terceiros ou de um determinado fornecedor, pode receber uma certificação de logótipo Microsoft. No entanto, um logótipo da Microsoft específico ou um parceiro certificado não certificarem 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 utilizam a actualização simultânea e sem sinalizadores de colocação em memória intermédia ao abrir ficheiros de base de dados para evitar perda de dados. Qualquer pedido de escrita a estes ficheiros deve ser fixado a media estável. Caso contrário, poderá ocorrer perda de dados. Seguem-se exemplos específicos que poderão expor caches do sistema de ficheiro:
  • Combinação de escrita e de escrita de reaprovisionamento
    Para reduzir os pedidos de e/s físicos, as caches de com base não utilizem baterias muitas vezes combinam em reordenar operações de escrita, imediatamente quebrar os requisitos do protocolo WAL.
  • Tamanho do bloco de e/s
    Semelhante a escrita combinar e Reaprovisonamento são tamanho do bloco e/s. As caches irão tentar concluir com base no tamanho do bloco de caminho e/s e/s. Novamente, este pode fornecer um aumento de desempenho mas abre a base de dados para danificar e interrompe imediatamente os requisitos do protocolo WAL.

Tópicos e exemplos

A secção seguinte fornece exemplos de chaves e tópicos relativos à integridade dos dados e segurança. Falha de energia que utiliza como um ponto comum de falha e de clareza, mas muitas vezes podem ser substituído com vários outros problemas que conduzam a 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 destina-se a página 100 na base de dados.
  2. Um registro de log é mantido em cache não baseados em bateria, mas o motor de base de dados é informado que a escrita de registo é concluída "segura estável media".
  3. O motor de base de dados considera o LSN temperado e problemas de escrita para a página 100.
  4. Página 100 também é mantida em cache de base de não utilizem baterias.
  5. Consolidar transacção é concluída sem erros.
O motor de base de dados continua o processamento, como se foi consolidada com êxito o escreve para suportes de dados estáveis. Uma falha de energia neste momento, no entanto, irá resultar na perda de dados de imediato porque as alterações nunca fisicamente existiam fora da cache com cópia de segurança não utilizem baterias. Recuperação de falhas não indica um erro porque a recuperação de falhas não conhecer o registro de log perdidas e não tentará repetir o trabalho. Expandir vários cenários de modificação de objecto (chave primária por exemplo, inserções de chaves externas) sobre os vários tipos de danos da base de dados que podem ocorrer.

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

Exemplo 2: Base de dados de suspeita

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

Este é um pressuposto fraco, realce os seguintes exemplos. A Microsoft recomenda que todos os ficheiros de cópia de segurança e de base de dados ser optado tais uma cache.
  1. O ficheiro de registo é consentido, para que operações de escrita estão a obter suporte de dados estáveis.
  2. Página 100 é modificado.
  3. O motor de base de dados é executada uma operação de ponto de verificação.
  4. O motor é informado de todas as páginas de base de dados e registos são seguros (ponto no tempo até ao ponto de verificação considerado temperado). No entanto, as páginas de dados não são todos armazenados num ou em meios estáveis.
  5. A base de dados do SQL Server está no modo de recuperação "Simples", para que o ponto de verificação agora trunca os registros de log.
  6. 100 de página que foi apenas verificação apontada é modificado novamente.
Esta situação tenha exposto a base de dados a perda de dados e resulta geralmente numa base de dados suspeito. Novamente, se a uma falha de energia for efectuada, recuperação de falhas não tem registo registos porque já não existem devido a truncagem. O motor de base de dados não tem informações indicando que as páginas de base de dados são dados que devem ter sido protegidos durante o ponto de verificação em falta. Recuperação de falhas tenta analisar a segunda alteração na página 100 mas falha porque a página 100 não estava devidamente protegida para suportes de dados estáveis no momento do ponto de verificação.

Recuperação de falhas utiliza o valor LSN armazenado no cabeçalho da página para determinar as necessidades de recuperação.
  • Se o LSN na página for igual ou mais recente do que do Registro de log, recuperação não nenhum trabalho adicional na página, porque a página já está consistente com o registo com base na comparação LSN.
  • Se for anterior do Registro de log a LSN na página, tem de recuperação efectuar as operações adequadas para a página voltar para o bom estado. Recuperação falha se recuperação tenha descobertos uma condição de dados em falta e correctamente não é possível devolver a página para o respectivo estado legítimo.
No exemplo, o LSN anterior armazenado no registo do registo para a segunda alteraçã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 a recuperação não é possível continuar com segurança.

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

Exemplo 2 é apenas uma fracção destes tipos de problemas que poderiam ocorrer. Para este exemplo, em vez do modo de recuperação "Simples", deixe-nos colocar a base de dados no modo de "Recuperação completo" mas tirar cópias de segurança regulares do registo e base de dados. Primeiro, afigura-se que tal seria 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 um pressuposto válido, como algumas implementações de cache utilizam a política "opt out" de modo que o ficheiro de cópia de segurança ou partes dele podem ser inesperadamente em cache. Quando o SQL Server esvazia o ficheiro de cópia de segurança, o SQL Server requer que todas as operações de escrita no suporte de dados de cópia de segurança são correctamente armazenadas no ou no suporte de dados estáveis, utilizando a função de Win32 API FlushFileBuffers . Assim, se o fornecedor de cache não garante a todas as escritas correctamente são descarregadas, durante a chamada de função de FlushFileBuffers , estável media antes de concluída a operação com êxito, a base de dados motor pode truncar o registo sem uma cópia de segurança segura. Novamente, uma falha de energia neste momento resulta numa condição onde os registos adequados estão em falta e podem fazer com que a recuperação de falhas falha. O que é mais importante é que a recuperação de falhas pode não ser capaz de detectar isto devido os registos de registo em falta na base de dados e a cadeia de cópia de segurança pode estar danificada silenciosamente. Apenas quando uma operação de restauro da cópia de segurança é tentada o motor de base de dados será possível indicar que a cópia de segurança está danificada.

Exemplo 4: Estados de base de dados inválido

Ficheiros de base de dados contêm dependências entre si requerendo simultânea estrita e conformidade a aplicar a todos eles como um grupo de ordenação. Ponto de verificação, as alterações de tamanho de ficheiro, cópias de segurança diferenciais, -logged operações e o modelo de recuperação BULK LOGGED estão entre algumas das actividades da base de dados de chave que necessitam de escrita através de ocorrer em ficheiros de dados, tornar políticas como optam saída apenas do ficheiro de registo um pressuposto inválido.

Exemplo 5: Perda de dados do instantâneo da base de dados – poderá ser silenciosa

SQL Server 2005 introduz bases de dados do instantâneo para o ponto em consultas de tempo. Esta opção utiliza tecnologia de base de dados de cópia ao escrever para ajudar a proteger uma cópia de uma página de dados da base de dados de dados de instantâneo antes de é efectuada uma alteração de nova para a página de dados na base de dados base. Este processo requer que a página ser protegida da base de dados do instantâneo antes da transacção pode continuar. Se a página não está protegida no ou nos suportes estáveis, persistirá problemas de integridade de dados. A base de dados do instantâneo não contém um registo de transacções, pelo que a escrita da página é crítica. Se algo como uma falha de energia ocorreu, é possível que a página de base de dados principal foi alterada, mas o instantâneo não reflecte a imagem anterior porque se perdeu a escrita em cache.

Como configurar

Como configurar um produto fornecendo a cache de ficheiros de algo como cache com cópia de segurança de bateria não é específico para a execução de fornecedor. No entanto, podem ser aplicadas algumas regras:
  • Todas as operações de escrita devem ser preenchidas no ou no media estável, antes da cache indica ao sistema operativo que a e/s foi concluída.
  • Dados podem ser colocadas em cache, enquanto que um pedido de leitura processado a partir da cache devolve a mesma imagem, tal como localizados no ou no suporte de dados estáveis.
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, isto pode fornecer um ganho de desempenho para o motor de base de dados. Isto deve, no entanto, ser testado cuidadosamente, porque a definição retiradas da produção algo como RAM que pode ser utilizado pelo SQL Server pode degradar o desempenho global. SQL Server poderá conseguir utilizar a memória adicional com uma precisão mais que um mecanismo de cache genérico.

Bases de dados só de leitura

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

Atenção A base de dados nunca deve ser feita ler escrever quando atribuído a uma cache que não manter o protocolo WAL.

Segurança

Introdução de uma cache, tais como a cache do sistema de ficheiros baseados em RAM, introduz outra localização de "de memória" para os dados. Produtos como um motor de base de dados podem assumir dados críticos foi armazenados no ou no suporte de dados estáveis e mantém correctamente protecções de (ACL lista) de controlo de acesso. A cache baseada em RAM poderá expor os dados a um conjunto de problemas de segurança que são exclusivos em comparação com o media estável. Por exemplo, se a aplicação foi concebida para utilizar algo como a função SecureZeroMemory de cada vez que tenha terminado de usar informações críticas, a aplicação tem uma expectativa de que os dados já não existem na RAM. No entanto, se um formulário de dados pode permanecer em cache quando a aplicação esperado no ou no suporte de dados estáveis, 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 forte e clara. Isto deve incluir, mas não está limitado a, restaurar cópias de segurança e de operações de DBCC CHECKDB regulares sobre a produção e a base de dados restaurada.

A Microsoft recomenda também a aumentar a frequência destes testes de segurança quando avalia e alterações no ambiente de execução ou se quaisquer questões que se ocorrerem relativos a estabilidade do ambiente.

Para mais informações sobre como utilizar o utilitário de SQLIOStress, clique no número de artigo seguinte para visualizar o artigo na Microsoft Knowledge Base:
231619 Como utilizar o utilitário de SQLIOStress sob tensão um subsistema de disco como o SQL Server

Base de dados TEMPDB

É possível localizar a base de dados TEMPDB em determinados sistemas de colocação em cache. Vários factores deverão ser considerados cuidadosamente e testou ao avaliar a localização de armazenamento da base de dados TEMPDB nesta configuração. O seguinte artigo na Microsoft Knowledge Base descreve os requisitos e/s, limites de suporte associado e ganhos de desempenho possível.
917047 Requisitos do sub-sistema de e/s do Microsoft SQL Server para a base de dados TEMPDB

Suporte

Suporte do Microsoft SQL Server ajudará os clientes, utilizando técnicas de recuperação de dados padrão. Se os produtos instalados na integridade dos dados em causa, o Microsoft SQL Server, Active Directory e suporte do Exchange pode solicitar que o produto seja desinstalado de desenho de computador e será não exercem na análise de causa raiz até o problema pode ser reproduzido sem referido produto.

A Microsoft não certifica ou validar que os produtos de outros fabricantes funcionem correctamente com o SQL Server. Além disso, a Microsoft não fornece qualquer garantia, a garantia ou a 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 a melhoria do desempenho do SQL Server:

826433 Diagnóstico de SQL Server adicional adicionado para detectar problemas de e/s não reportados
828339 Mensagem de erro 823 poderá indicar problemas de hardware ou problemas do sistema no SQL Server
234656 Utilizar a cache da unidade de disco com o SQL Server
304261 Descrição do suporte para ficheiros de base de dados de rede no SQL Server
910716 Suporte para soluções de espelhamento remoto de terceiros utilizados com o SQL Server 2000 e bases de dados de utilizador de 2005
913945Microsoft não atesta que os produtos de outros fabricantes funcione com o Microsoft SQL Server
Optimizar a consulta planos estimador de cardinalidade de 2014 com o SQL Server

Desempenho das consultas

Sistemas para suportar o «entrega garantida para suportes de dados estáveis» conforme descrito em M requer o SQL ServerRequisitos do programa de fiabilidade do SQL Server e/s.Para 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 seguinte para visualizar o artigo na Microsoft Knowledge Base:
967576 Requisitos de entrada/saída do motor de base de dados do Microsoft SQL servidor

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 917043 - Última Revisão: 12/09/2015 05:15:12 - Revisão: 3.0

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, Microsoft SQL Server 2008 R2 Analysis Services, Microsoft SQL Server 2008 R2 Datacenter, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Express with Advanced Services, Microsoft SQL Server 2008 R2 Parallel Data Warehouse, Microsoft SQL Server 2008 R2 Reporting Services, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Standard Edition for Small Business, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2012 Analysis Services, Microsoft SQL Server 2012 Business Intelligence, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, SQL Server 2012 Enterprise Core, SQL Server 2012 Reporting Services, Microsoft SQL Server 2014 Business Intelligence, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Enterprise Core, Microsoft SQL Server 2014 Express, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Web, SQL Server 2014 Reporting Services

  • kbnosurvey kbarchive kbexpertiseadvanced kbinfo kbmt KB917043 KbMtpt
Comentários