Algoritmos de armazenamento de dados de log do SQL Server 7.0, SQL Server 2000 e SQL Server 2005 e estendem confiabilidade de dados

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

Neste artigo

Sumário

SQL Server 7.0, SQL Server 2000 e SQL Server 2005 reestruturar e recrie os algoritmos de log e dados de versões anteriores do Microsoft SQL Server para melhorar a confiabilidade dos dados e integridade.

Para saber mais sobre os conceitos subjacentes dos mecanismos de SQL Server 7.0 e SQL Server 2000, consulte "ARIES (algoritmo de recuperação e isolamento Exploiting semântica): um método de recuperação de transações suporte Fine-granularidade bloqueio e reversões parcial no log de write-ahead usando", de ACM transações em sistemas de banco de dados de. Este documento foi escrito por Chunder Mohan.

Este documento aborda as técnicas de SQL Server 7.0, SQL Server 2000 e SQL Server 2005 para estender dados confiabilidade e integridade como relacionados a falhas.

É recomendável que você leia os seguintes artigos na Base de dados de Conhecimento da Microsoft para mais esclarecimentos sobre cache e alternativos discussões de modo de falha:
86903Descrição do cache de controladores de disco no SQL Server
46091Usando cache de controlador de disco rígido com o SQL Server
234656Usando cache de disco com o SQL Server

Mais Informações

Antes de iniciar a discussão detalhada, alguns dos termos como usado neste artigo são definidos na seção a seguir.
Recolher esta tabelaExpandir esta tabela
PrazoDefinição
Backup de bateria Bateria separado e localizado backup recurso diretamente disponível e controlado pelo mecanismo de armazenamento em cache para evitar a perda de dados.
Observação Isso não é um no-break (UPS). Um no-break não garante que as atividades de gravação e pode ser desconectado do dispositivo de armazenamento em cache.
Cache Mecanismo de armazenamento intermediário usado para otimizar operações de E/s físicas e melhorar o desempenho.
Página suja Página que contém as modificações de dados que ainda precisam ser liberados para o armazenamento estável. Para obter mais informações pertencentes a buffers de página sujo, consulte a documentação SQL Server Books Online.
Falha Tudo o que pode causar uma interrupção inesperada do processo do SQL Server. Exemplos: energia interrupção, redefinição do computador, erros de memória, outros problemas de hardware, setores defeituosos, interrupções de unidade, falhas de sistema operacional e assim por diante.
Liberar Forçando uma cache de buffer para armazenamento estável.
Registrador de divisão Objeto de sincronização usado para proteger consistência física de um recurso.
Armazenamento não-volátil Qualquer meio que permanece disponível através de falhas do sistema.
Página fixada Página que permanece nos dados do cache e não pode ser liberado para o armazenamento estável até que todos os registros de log associados são protegidos em um local de armazenamento estável.
Armazenamento estável Mesmo que o armazenamento não-volátil.
Armazenamento volátil Qualquer mídia que não permanecem intactas através de falhas.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, versões anteriores do SQL Server e muitos produtos de banco de dados importantes no mercado hoje usam o protocolo write-ahead log (WAL).

Protocolo de gravação-Ahead log (WAL)

O protocolo de termo é uma excelente forma de descrever WAL. É um específico e conjunto definido de implementação etapas necessárias para assegurar que dados é armazenado e trocado corretamente e pode ser recuperado para um estado conhecido em caso de falha. Assim como uma rede contém um protocolo definido para troca de dados de maneira consistente e protegida, portanto, muito o WAL descrever o protocolo para proteger os dados.

O documento ARIES define WAL como:
O protocolo WAL declara que os registros de log que representa as alterações para alguns dados já devem estar no armazenamento estável para que os dados alterados são permitidos substituir a versão anterior dos dados de armazenamento não-volátil. Ou seja, o sistema não é permitido gravar uma página atualizada para a versão de armazenamento não-volátil da página até que pelo menos as partes de desfazer os registros de log que descrevem as atualizações para a página tem sido escritas para armazenamento estável.
Para obter mais informações sobre o log de write-ahead, consulte a documentação de MANUAIS online.

SQL Server e o WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 e versões anteriores do SQL Server usam o protocolo WAL. Para garantir committal correta de uma transação, todos os registros de log associados à transação devem ser protegidos no armazenamento estável.

Para esclarecer isso, considere o seguinte exemplo específico (para este exemplo supor que não há nenhum índice e a página afetada é página 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
agora dividir a atividade em log simples etapas:
Recolher esta tabelaExpandir esta tabela
InstruçãoAções executadas
TRANSAÇÃO INICIAL Escrito para a área de cache de log existe, mas não é necessário para liberar a armazenamento estável porque o SQL Server não foi feita qualquer alteração física.
INSERT INTO tblTest1. Dados página 150 são recuperados no cache de dados do SQL Server, se já não disponível.

2. A página é travadas , fixado e marcado como sujo e bloqueios apropriados são obtidos.

3. Um registro de log de inserir é criado e adicionado ao cache de log.

4. Uma nova linha é adicionada para a página de dados.

5. O registrador de divisão está lançada.

6. Os registros de log associado com a transação ou página não necessário ser liberados neste momento porque todas as alterações permanecem no armazenamento volátil.
CONFIRMAR TRANSAÇÃO1. Um registro de log de confirmação é formado e os registros de log associados a transação devem ser escritos para armazenamento estável. A transação não é considerada confirmadas até que os registros de log são atribuídos corretamente a armazenamento estável.

2. Dados página 150 permanecem no cache de dados SQL Server e não são liberados imediatamente para o armazenamento estável. Quando os registros de log estão corretamente recuperação segura pode refazer a operação se necessário.

3. Transacionais bloqueios são lançados.
Não se confuso com bloqueio e de log. Embora importante, log e bloqueio são separados problemas ao lidar com o WAL. No exemplo acima, SQL Server 7.0, SQL Server 2000 e SQL Server 2005 geralmente mantêm o registrador de divisão na página 150 durante o tempo necessário para executar as alterações de inserir física na página, não a toda hora da transação. O tipo de bloqueio apropriado é estabelecido para proteger a linha, intervalo, página ou tabela conforme necessário. Consulte as seções de bloqueio MANUAIS online para obter mais detalhes sobre tipos de bloqueio.

Observando o exemplo em mais detalhes, você pode perguntar o que acontece quando executar os processos LazyWriter ou ponto de verificação. SQL Server 7.0, SQL Server 2000 e SQL Server 2005 emitem todas as liberações apropriadas para armazenamento para registros de log transacional associado à página suja e fixada estável. Isso garante que o protocolo WAL que uma página de dados pode nunca ser gravada em estável armazenamento até que os registros de log transacional associado foram liberados.

Armazenamento do SQL Server e estável

SQL Server 7.0, SQL Server 2000 e SQL Server 2005 melhoram operações de página de log e dados, incluindo o conhecimento de tamanhos de setor de disco (normalmente de 512 bytes).

Para manter as propriedades ACID de uma transação, o SQL Server deve conta para pontos de falha. Durante uma falha de diversas especificações de unidade de disco garantem apenas uma quantidade limitada de setor de operações de gravação. A maioria das especificações garantem a conclusão de uma gravação de setor único quando ocorre uma falha.

SQL Server 7.0, SQL Server 2000 e SQL Server 2005 usam páginas de dados de 8 KB e o log (se liberados) em múltiplos do tamanho de setor. (A maioria das unidades de disco use 512 bytes como o tamanho de setor padrão.) No caso de falha, SQL Server pode conta para as operações de gravação maior do que um setor empregando paridade de log e técnicas de gravação interrompida.

Detecção de página interrompida

A seção a seguir vêm o SQL Server 7.0 Books Online que descreve a detecção de página interrompida:
Esta opção permite que o SQL Server detectar operações de E/s incompletas causadas por falhas de energia ou outras interrupções no sistema. Quando true, ele faz com que um pouco ser invertidas para cada setor de 512 bytes em uma página de banco de dados 8 kilobytes (KB) sempre que a página é gravada no disco. Se um pouco está no estado incorreto quando a página for posterior ler pelo SQL Server, em seguida, a página foi escrita incorretamente; uma página interrompida for detectada. Páginas rasgadas geralmente são detectadas durante a recuperação porque provavelmente ser lido por recuperação qualquer página que foi escrita incorretamente.

Embora as páginas de banco de dados do SQL Server tem 8 KB, discos executam operações de E/s usando um setor de 512 bytes. Portanto, 16 setores são gravados por página de banco de dados. Uma página interrompida pode ocorrer se o sistema falhar (por exemplo, devido a falha de energia) entre a hora que do sistema operacional grava o primeiro setor de 512 bytes para disco e a conclusão da operação E/s de 8 KB. Se o primeiro setor de uma página de banco de dados é gravado com êxito antes da falha, a página de banco de dados no disco será exibida como atualizado, embora ele não pode ter êxito.

Usando caches de controlador de disco de backup de bateria pode garantir que os dados com êxito são gravados em disco ou não gravados em todos os. Nesse caso, fazer conjunto interrompida detecção de página não como true, para que ele não é necessário.
Observação A detecção de página interrompida não é ativada por padrão no SQL Server 7.0. Consulte sp_dboption sobre como ativar a detecção no seu sistema.

Paridade de log

Verificação de paridade de log é muito semelhante a detecção de página interrompida. Cada setor de 512 bytes contém bits de paridade. Esses bits de paridade sempre são escritos com o registro de log e avaliados quando o registro de log é recuperado. Forçando o log grava em um limite de 512 bytes, SQL Server 7.0, SQL Server 2000 e SQL Server 2005 podem garantir que committal operações são gravadas completamente os setores de disco físico.

As alterações fornecem consistência de dados maior, até mesmo sobre as versões anteriores do SQL Server.

Versões do SQL Server anterior à 7.0

Versões anteriores do SQL Server que 7.0 não forneceu log paridade ou bits rasgado detecção instalações. Na verdade, essas versões podem escrever a mesma página de log várias vezes até que os registros de log preencham a página 2 KB log. Isso pode expor as transações que têm confirmada com êxito. Se a página de log está sendo reconfigurada durante uma falha, um setor com a transação confirmada não pode obter reescrito corretamente.

Impacto de desempenho

Todas as versões do SQL Server abrir os arquivos de log e dados usando a função Win32 CreateFile . O membro dwFlagsAndAttributes inclui a opção FILE_FLAG_WRITE_THROUGH quando aberto pelo SQL Server.
FILE_FLAG_WRITE_THROUGH
Instrui o sistema para gravar por meio de qualquer cache intermediário e ir diretamente para disco. O sistema ainda pode cache operações de gravação, mas não é possível liberar ociosamente-los.

A opção FILE_FLAG_WRITE_THROUGH garante que quando uma gravação operação retorna conclusão com êxito que os dados corretamente são armazenados no armazenamento estável. Isso se alinha com o protocolo WAL assegurar os dados.
Muitas unidades de disco (SCSI e IDE) conter integrados caches de 512 KB, 1 MB ou maior. No entanto, os caches de unidade geralmente dependem um capacitor e não uma solução de backup de bateria. Esses mecanismos de cache não é possível garantir gravações em uma potência ciclo ou ponto de falha semelhante. Eles apenas garantem a conclusão das operações de gravação setor. Isso é especificamente por que a gravação interrompida e detecção de paridade de log criados no SQL Server 7.0, SQL Server 2000 e SQL Server 2005. Como as unidades de disco continuarem a crescer em tamanho, os caches ficar maiores e eles podem expor grandes quantidades de dados durante uma falha.

Muitos fornecedores de hardware fornecem soluções de controlador de disco de backup de bateria. Esses caches controlador podem manter os dados no cache por vários dias e ainda permitir que o hardware de armazenamento em cache para ser colocado em um segundo computador. Quando a alimentação é restaurada corretamente, os dados unwritten completamente for liberados antes seja permitido o acesso a dados mais. Muitas delas permitem que uma porcentagem de leitura versus cache de gravação sejam estabelecidas para desempenho ideal. Alguns contêm grande quantidade de memória áreas de armazenamento. Na verdade, para um segmento bastante específico do mercado, alguns fornecedores de hardware high-end feito bateria disco cache de sistemas de controlador com 6 GB de cache de fornecer. Esses podem melhorar significativamente o desempenho de banco de dados.

Implementações de cache avançados será recursos no caso de uma reinicialização do sistema, falha de energia ou outro ponto de falha reescrever de identificador FILE_FLAG_WRITE_THROUGH solicitar desativando o cache do controlador não porque pode fornecem true.

Transferências de E/s sem o uso de um cache podem ser muito mais devido ao tempo mecânico necessário para mover as cabeças de unidade, taxas de rotação e outros fatores de limitação.

Classificação de setor

Uma técnica comum usada para aumentar o desempenho de E/s é o setor de ordenação. Para evitar o movimento de cabeça mecânico as solicitações de leitura/gravação são classificadas, permitindo que uma animação mais consistente do cabeçote de para recuperar ou armazenar dados.

O cache pode Mantenha vários log e solicitações de gravação de dados ao mesmo tempo. O protocolo WAL e implementação do protocolo WAL SQL Server exigem a liberação do log grava estável armazenamento antes da gravação de página pode ser emitida. No entanto, o uso do cache pode retornar êxito de uma solicitação de gravação de log sem os dados sendo gravados para a unidade real (que é, gravada em armazenamento estável). Isso pode levar para emitir a solicitação de gravação de página de dados do SQL Server.

Com o envolvimento de cache de gravação, os dados ainda são considerados como sendo no armazenamento volátil. No entanto, de chamada Win32 API WriteFile , exatamente como o SQL Server vê a atividade, um código de retorno bem-sucedido foi obtido. SQL Server ou qualquer processo usando o API WriteFile chamada só poderá deduzir os dados corretamente obteve armazenamento estável.

Para fins de discussão, suponha que todos os setores da página de dados são classificados para gravar antes dos setores dos registros de log correspondente. Isso viola o protocolo WAL imediatamente. O cache está escrevendo uma página de dados antes dos registros de log. A menos que o cache seja feito totalmente bateria, uma falha pode causar resultados catastróficos.

Ao avaliar os fatores de desempenho ideal para um servidor de banco de dados, há muitos fatores a considerar. É o principal dessas considerações "Meu sistema permitir recursos FILE_FLAG_WRITE_THROUGH válidos?"

Observação Qualquer cache que você estiver usando deve totalmente oferece suporte a uma solução de backup de bateria. Todos os outros mecanismos de cache são suspeito a corrupção e perda de dados. SQL Server faz com que todos os esforços para garantir o WAL habilitando FILE_FLAG_WRITE_THROUGH.

Os testes mostraram que muitas configurações de unidade de disco podem conter a gravação em cache sem bateria adequado de backup. Unidades EIDE, SCSI e IDE se beneficiar de caches de gravação.

Em muitas configurações, a única maneira para desativar corretamente o cache de gravação de uma unidade IDE ou EIDE é com um utilitário fabricante específico ou usando jumpers localizados na unidade própria. Para garantir que o cache de gravação está desabilitado para a unidade própria, contate o fabricante da unidade.

Unidades SCSI também possuem caches de gravação, mas esses caches normalmente podem ser desabilitados pelo sistema operacional. Se houver qualquer questão, contate o fabricante unidade para utilitários apropriados.

Empilhamento de cache de gravação

Gravação de que empilhamento de cache é semelhante à classificação de setor. A seguinte definição foi extraída diretamente um fabricante de unidade IDE à esquerda Web site:
Normalmente, esse modo está ativo. Escreva um modo de cache aceita que o host gravar dados no buffer até que o buffer estiver cheio ou a transferência de host seja concluída.

Inicia uma tarefa de gravação de disco armazenar dados do host para o disco. Comandos de gravação de host continuem a ser aceita e dados transferidos para o buffer até que a pilha de comando de gravação está cheia ou o buffer de dados estiver cheio. A unidade pode reordenar os comandos de gravação para otimizar a taxa de transferência de unidade.

Realocação de gravação automática (AWR)

Outra técnica comum usada para proteger os dados é detectar setores defeituosos durante a manipulação de dados. A seguinte explicação vem do mesmo à esquerda IDE unidade fabricante site da Web:
Esse recurso faz parte o cache de gravação e reduz o risco de perda de dados durante operações de gravação retardada. Se ocorrer um erro de disco durante o processo de gravação de disco, as paradas de tarefa de disco e o setor suspeito é realocada para um pool de setores alternativos localizado no final da unidade. Seguindo a realocação, a tarefa de gravação de disco continuará até que ela for concluída.
Isso pode ser um recurso muito eficiente se a bateria de reserva é fornecida para o cache, permitindo que a modificação adequada durante a reinicialização. É preferível para detectar os erros de disco, mas a segurança de dados de protocolo WAL novamente exigiria isso ser feito a tempo real e não de uma maneira adiada. Dentro de parâmetros WAL, a técnica AWR não é possível conta para uma situação em que uma gravação de log falha devido a um erro de setor mas a unidade está cheia. O mecanismo de banco de dados imediatamente deve saber sobre a falha para a transação pode ser anulada corretamente, o administrador pode ser alertado e as etapas adequadas tomadas para proteger os dados e corrigir a situação de falha de mídia.

Segurança de dados

Há várias precauções que um administrador de banco de dados deve tomar para garantir a segurança dos dados.
  • Sempre é uma boa idéia para garantir que sua estratégia de backup seja suficiente para recuperar de uma falha catastrófica. Armazenamento externos e outras precauções são apropriadas.
  • Teste a operação de restauração de banco de dados em um secundário ou banco de dados em uma base freqüente de teste.
  • Certifique-se que os dispositivos de armazenamento em cache podem manipular todas as situações de falha (queda de energia, setores defeituosos, unidades incorretas, interrupção do sistema, lockups, pico de energia e assim por diante).
  • Verifique se o dispositivo de armazenamento em cache:
    • Integrou a bateria de reserva.
    • Pode reedição grava em energia de.
    • Pode ser totalmente desativado se necessário.
    • Manipula o setor defeituoso remapeamento em tempo real.
  • Ativar detecção de página interrompida; ele tem pouco impacto de desempenho.
  • Configure unidades RAID possibilita uma troca automática de uma unidade de disco incorreta, se possível.
  • Use controladores de armazenamento em cache mais recentes que permitem a adição de mais espaço em disco sem reiniciar o sistema operacional. Isso pode ser uma solução ideal.

Unidades de testes

Para proteger totalmente seus dados, você deve garantir que todos os dados de cache é tratado corretamente. Em muitas situações, isso significa que você deve desativar o cache de gravação da unidade de disco.

Observação Certifique-se que um mecanismo de cache alternativo corretamente pode manipular vários tipos de falha.

Microsoft realizou testes em várias unidades SCSI e IDE usando o utilitário SQLIOStress . Esse utilitário simula a atividade de leitura/gravação assíncrona pesado para um dispositivo de dados simulados e o dispositivo de log. Estatísticas de desempenho de teste mostram as operações de gravação média por segundo entre 50 e 70 para uma unidade com cache de gravação desativada e um intervalo de RPM entre 5,200 e 7,200.

Para obter mais informações e detalhes sobre o utilitário SQLIOStress , consulte o seguinte 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
Muitos fabricantes de computador (por exemplo, Compaq, Dell, gateway, HP e assim por diante) as unidades da ordem com o cache de gravação desabilitado. No entanto, teste mostra que isso pode não ser o caso, portanto, sempre teste completamente.

Dispositivos de dados

Em situações de tudo, mas não-conectado, o SQL Server exigirá apenas os registros de log para ser liberado. Ao fazer operações não conectado, as páginas de dados também precisam ser liberadas para o armazenamento estável; há não registros de logs individuais para gerar novamente as ações em caso de falha.

As páginas de dados podem permanecer no cache até que o processo de ponto de verificação ou LazyWriter libera-los para o armazenamento estável. Usar o protocolo WAL para garantir que os registros de log são armazenados corretamente garante que a recuperação pode recuperar uma página de dados para um estado conhecido.

Isso não significa que é aconselhável colocar arquivos de dados em uma unidade em cache. Quando o SQL Server libera as páginas de dados para armazenamento estável, os registros de log podem ser truncados do log de transação. Se as páginas de dados são armazenadas em cache volátil, é possível truncar registros de log que poderiam ser usados para recuperar uma página no caso de falha. Certifique-se que os dados e log dispositivos acomodar armazenamento estável corretamente.

Aumentando o desempenho

A pergunta inicial que surge é: "Tenho uma unidade IDE que foi cache, mas quando eu desativado-lo, meu desempenho ficou significativamente menor do que esperado--por que?"

Muitos das unidades IDE testadas pela Microsoft executada em uma taxa de RPM de 5,200 e o SCSI unidades em um RPM do 7,200. Quando você desativa a gravação de cache de unidade IDE desempenho mecânico pode se tornar um fator.

Há uma área muito clara para abordar a diferença de desempenho: "A taxa de transação de endereços."

Há muitas transações online (OLTP) sistemas que requerem uma taxa alta de transação de processamento. Para esses sistemas, considere usar um controlador de armazenamento em cache que pode oferecer suporte a um cache de gravação e fornecer melhora a desempenho ao garantir a integridade dos dados corretamente.

Para encontrar significativamente alterações de desempenho com o SQL Server em uma unidade de armazenamento em cache, a taxa de transação foi aumentada usando transações pequenas.

Teste mostra que a gravação alta atividade de buffers menores que 512 KB ou acima de 2 MB pode causar desempenho lento.
Considere o exemplo a seguir:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
a seguir é resultados de teste de exemplo para o SQL Server:
84 SCSI(7200 RPM) segundos
SCSI(7200 RPM) 15 segundos (controlador de cache)

14 IDE(5200 RPM) segundos (unidade de cache habilitado)
IDE(5200 RPM) 160 segundos
Quebra automática de toda a série de operações INSERT em uma única transação é executado em aproximadamente 4 segundos em todas as configurações.

O motivo é o número de liberações de log necessários. Sem a transação, cada INSERT é uma transação na e de si mesmo e cada vez que os registros de log para a transação devem ser liberados. Cada liberação é 512 bytes em tamanho, que requer intervenção unidade mecânico significativo.

Quando uma única transação é usada, os registros de log para a transação podem ser agrupados e uma gravação única, maior pode ser usada para liberar os registros de log obtidas. Intervenção mecânica é reduzida significativamente.

Aviso Não é recomendável que você aumentar o escopo da transação. Transações de longa execução podem levar a excesso e indesejado bloqueio, bem como maior sobrecarga. Use o SQL Server 7.0, SQL Server 2000 e contadores de desempenho do SQL Server 2005 Bancos de dados do SQL Server: para exibir os contadores de baseado em log de transação. Especificamente, Flushed de bytes de log por segundo pode indicar muitas transações pequenas levando a atividade do disco mecânico alta.

Examine as instruções associadas com o log de liberação e determinar se o número de liberações de log pode ser reduzido. No exemplo acima, uma única transação foi implementada. No entanto, em muitos cenários isso pode levar a um comportamento de bloqueio indesejado. Examinar o design de transação. Talvez algo como a seguir para executar lotes para reduzir o log de pequeno e freqüente liberar atividade:
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6. x talvez não veja o mesmo impacto no desempenho de freqüentes e log de transações pequeno grava. SQL Server 6. x regrava a mesma página de 2 KB log como transações são confirmadas. Isso pode reduzir o tamanho do log significativamente em comparação comparado as liberações de limite de setor de 512 bytes no SQL Server 7.0, SQL Server 2000 e SQL Server 2005. Reduzir o tamanho do log de diretamente se relaciona com a quantidade de atividade de unidade mecânico. No entanto, como explicado acima, o SQL Server 6. x algoritmo pode expor transações confirmadas.
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: 230785 - Última revisão: quinta-feira, 9 de fevereiro de 2006 - Revisão: 5.3
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Palavras-chave: 
kbmt kbhowto kbinfo KB230785 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: 230785

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