Algoritmos de armazenamento de dados de registo de SQL Server 7.0, SQL Server 2000 e SQL Server 2005 e expandem fiabilidade dos dados

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

Nesta página

Sumário

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

Para obter mais informações sobre conceitos subjacentes dos motores 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 transacções suportar fino-granularidade bloqueio e anuladas parciais utilizar registo escrita à frente", de transacções de ACM em sistemas de base de dados. 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 aumentar a fiabilidade dos dados e integridade no que respeita a falhas.

Recomenda-se que leia os seguintes artigos na Microsoft Knowledge Base para clarificação adicional no cache e alternar falha no modo de debates:
86903Descrição da cache de controladores de disco no SQL Server
46091Utilizar a cache de controlador de disco rígido com o SQL Server
234656Utilizar unidade de disco em cache com o SQL Server

Mais Informação

Antes de iniciar a aprofundada, alguns dos termos utilizados neste artigo são definidos na secção seguinte.
Reduzir esta tabelaExpandir esta tabela
TermoDefinição
Segurança de bateria Bateria separadas e localizadas cópia de segurança funcionalidade directamente disponível e controlada pelo mecanismo de colocação em cache para evitar a perda de dados.
Nota Não se trata de uma fonte de alimentação ininterrupta (UPS, supply). Uma UPS não garante qualquer actividades de escrita e pode ser desligada proveniente do cache.
Cache Mecanismo de armazenamento intermediário utilizado para optimizar as operações de E/s físicas e melhorar o desempenho.
Página adicional Página que contém modificações de dados que têm ainda de ser descarregada para armazenamento estável. Para mais informações relativas a memórias intermédias de página adicional, consulte a documentação do SQL Server Books Online.
Falha Tudo o que poderá provocar uma falha inesperada do processo de SQL Server. Exemplos: energia falha, reposição do computador, erros de memória, outros problemas de hardware, sectores danificados, falhas de unidade, falhas de sistema operativo e por aí em diante.
Limpar Forçar uma memória intermédia de cache para armazenamento estável.
Enganchado Objecto de sincronização utilizado para proteger consistência física de um recurso.
Armazenamento nonvolatile Qualquer meio que permanece disponível através de falhas do sistema.
Página associada Página permanece nos dados em cache e não pode ser descarregada para armazenamento estável até que todos os registos associados estão protegidos numa localização de armazenamento estável.
Armazenamento estável Mesmo que o armazenamento nonvolatile.
Armazenamento volátil Qualquer suporte de dados que não permanecem intactos através de falhas.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, versões anteriores do SQL Server e muitos produtos da base de dados principal no mercado utilizam actualmente o protocolo de escrita à frente de registo (WAL).

Protocolo de escrita à frente de registo (WAL)

O protocolo de termo é uma excelente forma de descrever WAL. É um específico e conjunto definido de implementação passos necessários para assegurar que dados está armazenado e trocado correctamente e pode ser recuperada para um estado conhecido em caso de falha. Tal como uma rede contém um protocolo definido para trocar dados de uma forma consistente e protegida, por isso demasiado faz o WAL descrevem o protocolo para proteger os dados.

O documento ARIES define WAL como:
O protocolo WAL assegura que os registos que representa as alterações para alguns dados já devem estar em armazenamento estável antes dos dados alterados estão autorizados a substituir a versão anterior dos dados de armazenamento nonvolatile. Ou seja, o sistema não está autorizado a escrever uma página actualizada para a versão armazenamento nonvolatile da página até, pelo menos, as partes de anulação dos registos que descrevem as actualizações para a página tem sido escritas para armazenamento estável.
Para mais informações sobre registo escrita antecipada, consulte a documentação do SQL Server Books Online.

SQL Server e o WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 e anteriores versões do SQL Server utilizam o protocolo WAL. Para assegurar committal adequada de uma transacção, todos os registos associados à transacção devem ser protegidos em armazenamento estável.

Para clarificar este, considere o seguinte exemplo específico (para este exemplo partem do princípio que não existe nenhum índice e a página afectada é página 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
agora divida a actividade em registo simplistic passos:
Reduzir esta tabelaExpandir esta tabela
InstruçãoAcções executadas
INÍCIO TRANSACÇÃO Escritas para a área de cache de registo existe mas não é necessário esvaziar para armazenamento estável, porque o SQL Server não efectuou quaisquer alterações físicas.
INSERT INTO tblTest1. Página 150 obtém dados em cache de dados do SQL Server, se já não disponível.

2. A página é latched fixada e marcado com problemas e bloqueios adequados são obtidos.

3. Um registo de inserir registo é criado e adicionado a cache de registo.

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

5. O enganchado é editado.

6. Os registos associados à transacção ou página não tenha de ser limpa neste momento porque todas as alterações permanecem no armazenamento volátil.
CONFIRMAR TRANSACÇÃO1. Um registo do registo de transacções está formado e os registos associados à transacção devem ser escritos para armazenamento estável. A transacção não é considerada consolidada até que os registos são correctamente atribuídos para o armazenamento estável.

2. Dados página 150 permanecem na cache de dados do SQL Server e não são esvaziados imediatamente para o armazenamento estável. Quando os registos estão correctamente recuperação segura possível repetir a operação se necessário.

3. Transaccionais bloqueios são libertados.
Não se confundidas com bloquear e iniciar sessão. Apesar de importante, bloqueio e o registo são problemas separados ao lidar com o WAL. No exemplo acima, SQL Server 7.0, SQL Server 2000 e SQL Server 2005 geralmente mantenha o enganchado na página 150 para o tempo necessário para efectuar as alterações físicas inserir na página, não todo o tempo da transacção. O tipo de bloqueio adequado é estabelecido para proteger a linha, intervalo, página ou tabela conforme necessário. Consulte as secções bloqueio SQL Server Books Online para obter mais detalhes sobre tipos de bloqueio.

Observar o exemplo mais detalhadamente, poderá 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 todos os alinhamentos adequados para estável relativas registos transaccionais associados à página adicional e associada. Isto garante o protocolo WAL que nunca pode ser escrita uma página de dados no estável armazenamento até tem sido limpa os registos de transacções associado.

Armazenamento de SQL Server e estável

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

Para manter as propriedades ACID de uma transacção, o SQL Server devem ter pontos de falha. Durante uma falha de especificações de unidade de disco muitos garantem apenas uma quantidade limitada de sector operações de escrita. A maior parte das especificações garantem a conclusão de uma único sector escrita quando ocorre uma falha.

SQL Server 7.0, SQL Server 2000 e SQL Server 2005 utilizam páginas de dados de 8 KB e o registo (se abatida) em múltiplos do tamanho do sector. (A maior parte das unidades de disco utilizar 512 bytes como o tamanho de sector predefinido.) No caso de falha, SQL Server pode conta para operações de escrita maior do que um sector utilizando paridade de registo e técnicas de escrita rasgado.

Detecção página rasgado

A secção seguinte provém o SQL Server 7.0 Books Online descrevendo Detecção página rasgado:
Esta opção permite que o SQL Server detectar operações de E/s incompletas causadas por falhas de energia ou outras falhas de sistema. Quando verdadeiro, faz com que um bit de invertidas para cada sector de byte 512 numa página 8 quilobytes (KB) da base de dados sempre que a página é escrita no disco. Se um pouco está no estado errado quando a página é posterior ler pelo SQL Server, em seguida, a página foi escrita incorrectamente, uma página rasgada é detectada. Páginas rasgadas normalmente são detectadas durante a recuperação porque poderão ser lidos por recuperação qualquer página que foi escrita incorrectamente.

Apesar de páginas de base de dados do SQL Server 8 KB, discos efectuam operações de E/s utilizando um sector de byte 512. Por conseguinte, 16 sectores são escritos por página de base de dados. Uma página rasgada pode ocorrer se o sistema falhar (por exemplo, devido a falha de energia) entre a hora que do sistema operativo escreve o primeiro sector de byte 512 no disco e a conclusão da operação de E/s de 8 KB. Se o primeiro sector de uma página de base de dados for escrito com êxito antes da falha, a página de base de dados no disco aparecerá como actualizado, apesar de pode não ter êxito.

Utilizar caches de controlador de disco bateria pode garantir que os dados com êxito são escritos no disco ou não escritos de todo. Neste caso, não conjunto incompleta detecção de página como true, para não é necessário.
Nota Detecção página rasgado não está activada por predefinição no SQL Server 7.0. Consulte sp_dboption para saber como activar a detecção no sistema.

Paridade de registo

Verificação de paridade de registo é muito semelhante a detecção página rasgado. Cada sector de byte 512 contém bits de paridade. Estes bits de paridade sempre são escritas com o registo e avaliadas quando o registo é obtido. Forçando registo escreve num limite de 512 bytes, SQL Server 7.0, SQL Server 2000 e SQL Server 2005 podem garantir que as operações committal completamente são escritas os sectores de disco físico.

As alterações fornecem consistência de dados maiores, mesmo através de versões anteriores do SQL Server.

Versões anteriores ao 7.0 do SQL Server

Versões anteriores do SQL Server que 7.0 não fornecem registo paridade ou bits rasgado detecção instalações. De facto, essas versões podem escrever a mesma página de registo várias vezes até que os registos de preencher a página de registo 2 KB. Isto pode expor transacções com êxito tem consolidada. Se a página de registo está a ser escritas de novo durante uma falha, um sector com transacção consolidada não pode obter rescrito correctamente.

Impactos de desempenho

Todas as versões do SQL Server abrir os ficheiros de registo e dados utilizando a função de Win32 CreateFile . O membro dwFlagsAndAttributes inclui a opção FILE_FLAG_WRITE_THROUGH quando aberto pelo SQL Server.
FILE_FLAG_WRITE_THROUGH
Indica ao sistema para escrever através de qualquer cache intermédio e ir directamente para o disco. O sistema pode ainda em cache as operações de escrita, mas lazily não é possível esvaziá-los.

A opção FILE_FLAG_WRITE_THROUGH garante que quando um escrita operação devolve concluído com êxito que os dados são correctamente guardados em armazenamento estável. Isto alinha com o protocolo WAL certificando-se os dados.
Muitas unidades de disco (SCSI e IDE) contêm incorporadas caches de 512 KB, 1 MB, ou maior. No entanto, as caches de unidade normalmente dependem de um condensador e não uma solução bateria. Estes mecanismos de cache não garante escritas por uma potência de ciclo ou ponto de falha semelhante. Apenas garantem a conclusão de operações de escrita sector. Trata-se especificamente porque a escrita rasgada e detecção de paridade de registo foram incorporadas no SQL Server 7.0, SQL Server 2000 e SQL Server 2005. À medida que as unidades continuam a aumentar de tamanho, aumentar as caches e estes podem expor maiores quantidades de dados durante uma falha.

Muitos fornecedores de hardware fornecem soluções de controlador de disco de bateria. Estes caches de controlador podem manter os dados na cache durante vários dias e ainda permitir que o hardware cache seja colocada num segundo computador. Quando energia for restaurada correctamente, os dados unwritten completamente são esvaziados antes do acesso a dados mais é permitido. Muitos deles permitem uma percentagem de leitura em cache de escrita seja estabelecida para um óptimo desempenho. Contém algumas áreas de armazenamento de memória de grandes dimensões. Na realidade, para um segmento do mercado muito específico, alguns fornecedores de hardware fornecem disco topo de gama bateria cache controlador sistemas com 6 GB de cache. Estes podem melhorar significativamente o desempenho da base de dados.

Avançadas implementações cache irá capacidades em caso de uma reposição do sistema, falha de energia ou outro ponto de falha rescrever de identificador FILE_FLAG_WRITE_THROUGH pedir desactivando não a cache do controlador porque fornecem VERDADEIRO.

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

Sector de ordenação

Uma técnica comum utilizada para aumentar o desempenho de E/s é o sector de ordenação. Para evitar mecânico movimento da cabeça de impressão são ordenados os pedidos de leitura/escrita, permitindo um movimento da cabeça obtenha ou armazene dados mais consistente.

A cache pode conter vários registo e pedidos de escrita de dados ao mesmo tempo. O protocolo WAL e a implementação de SQL Server do protocolo WAL requerem abate do registo escreve estável armazenamento antes da escrita de página pode ser emitida. No entanto, utilização da cache poderá devolver êxito a partir de um pedido de escrita de registo sem os dados a ser escritos para a unidade actual (que é, escrita estável armazenamento). Isto pode conduzir a emitir o pedido de escrita de página de dados do SQL Server.

Com o envolvimento de cache de escrita, os dados é ainda considerados no armazenamento volátil. No entanto, de chamada de API do Win32 WriteFile , exactamente como o SQL Server vê a actividade, um código de retorno com êxito foi obtido. SQL Server ou qualquer processo que utiliza apenas o pode de chamada de API WriteFile decifrar os dados correctamente obteve armazenamento estável.

Para fins de debate, partem do princípio que todos os sectores da página de dados são ordenados para escrever antes dos sectores dos registos correspondentes. O protocolo WAL Isto viola imediatamente. A cache está a escrever uma página de dados antes dos registos. A menos que a cache seja totalmente bateria, uma falha pode causar resultados grave.

Ao avaliar os factores de desempenho ideal para um servidor de base de dados, existem muitos factores a considerar. É de conta estas considerações foremost "Meu sistema permitir capacidades FILE_FLAG_WRITE_THROUGH válidas?"

Nota Qualquer cache estiver a utilizar tem totalmente suporta uma solução de bateria. Todos os outros mecanismos de colocação em cache forem suspeitas danos nos dados e perda de dados. SQL Server faz com que cada esforço para garantir a WAL activando FILE_FLAG_WRITE_THROUGH.

Testes demonstraram que podem conter várias configurações de unidade de disco escrita em cache sem cópia de segurança adequadas da bateria. Unidades SCSI, IDE e EIDE tirar partido das caches de escrita.

Em muitas configurações, a única forma para desactivar correctamente a escrita em cache de uma unidade IDE ou EIDE é com um utilitário de fabricante específico ou utilizando os jumpers localizados na unidade própria. Para se certificar que a cache de escrita está desactivada para a unidade propriamente dito, contacte o fabricante da unidade.

Unidades SCSI têm também caches de escrita mas estes caches normalmente podem ser desactivadas pelo sistema operativo. Se existir qualquer pergunta, contacte o fabricante unidade para utilitários adequados.

Empilhamento de cache de escrita

Escreva que empilhamento de cache é semelhante ao sector de encomenda. A seguinte definição foi retirada directamente de um fabricante de Web site da unidade IDE à esquerda:
Normalmente, este modo está activo. Escreva o modo cache aceita que o anfitrião escreve dados na memória intermédia até que a memória intermédia estiver cheia ou a transferência de anfitrião está concluída.

Inicia uma tarefa de escrita do disco armazenar os dados de anfitrião para o disco. Comandos de escrita de anfitrião continuam a ser aceites e dados transferidos para a memória intermédia até que a pilha de comando de escrita está cheia ou a memória intermédia de dados está cheia. A unidade poderá reordenar comandos de escrita para optimizar débito de unidade.

Realocação automático de escrita (AWR)

Outra técnica comum utilizada para proteger dados deve detectar sectores danificados durante a manipulação de dados. A explicação seguinte é fornecido a partir do mesmo à esquerda IDE unidade fabricante Web site:
Esta funcionalidade faz parte da cache de escrita e reduz o risco de perda de dados durante operações de escrita adiada. Novamente se ocorrer um erro no disco durante o processo de escrita de disco, o disco poderá deixar de tarefa e o sector suspeito é atribuída a um conjunto de sectores alternativas se encontram no fim da unidade. Após a reatribuição a tarefa de escrita de disco continua até estar concluída.
Isto pode ser uma funcionalidade muito poderosa se cópia de segurança da bateria é fornecida para a cache, permitindo modificações adequadas ao reiniciar. É preferível para detectar os erros de disco, mas a segurança de dados do protocolo WAL necessitaria novamente esta opção para fazer o tempo real e não de uma forma adiada. Dentro de parâmetros WAL, a técnica AWR não é possível conta para uma situação em que uma escrita de registo falha devido a um erro de sector mas a unidade estiver cheia. O motor de base de dados imediatamente tem de saber sobre a falha para a transacção pode ser correctamente interrompida, o administrador pode ser alertado e adequados passos seguidos para proteger os dados e corrigir a situação de falha de suportes de dados.

Segurança dos dados

Existem várias precauções que deve tomar um administrador de base de dados para garantir a segurança dos dados.
  • É sempre uma boa ideia para garantir que a estratégia de cópia de segurança é suficiente para recuperar de uma falha grave. Armazenamento noutro local e outras precauções são adequadas.
  • Teste a operação de restauro da base de dados de uma reserva ou base de dados numa base frequente teste.
  • Certifique-se que todos os dispositivos colocação em cache podem processar todas as situações de falha (falha de energia, sectores danificados, unidades incorrectas, falha de sistema, lockups, colector de energia e por aí em diante).
  • Garantir que o dispositivo de colocação em cache:
    • Integrou cópia de segurança da bateria.
    • Pode relançamento escreve com energia de.
    • Pode ser totalmente desactivado se necessário.
    • Processa o sector danificado remapeamento em tempo real.
  • Activar a detecção página rasgado; tem algum impacto no desempenho.
  • Configure unidades RAID, permitindo uma comutação quente de uma unidade de disco danificada, se possível.
  • Utilize controladores de colocação em cache mais recentes que permitem a adição de mais espaço em disco sem reiniciar o sistema operativo. Isto pode ser uma solução ideal.

Testes de unidades

Para proteger totalmente os dados, deve garantir que todos os dados caches correctamente é processado. Em muitos casos, isto significa que terá de desactivar a escrita em cache da unidade de disco.

Nota Certifique-se de que um mecanismo de colocação em cache alternativo pode processar correctamente vários tipos de falha.

Microsoft efectuou testes em várias unidades SCSI e IDE utilizando o utilitário SQLIOStress . Este utilitário simula a actividade de leitura/escrita assíncrona grossa para um dispositivo de simulada dados e o dispositivo de registo. Estatísticas de desempenho teste mostram as operações de escrita médio por segundo entre 50 e 70 para uma unidade com desactivado escrita em cache e um intervalo RPM entre 5,200 e 7,200.

Para mais informações e detalhes sobre o utilitário SQLIOStress , consulte o seguinte 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
Muitos fabricantes (por exemplo, Compaq, Dell, gateway, HP e assim sucessivamente) encomendar as unidades com a cache de escrita desactivada. No entanto, teste mostra que este poderá não sempre ser o caso, sempre testar completamente.

Dispositivos de dados

Situações tudo mas não-registados, SQL Server vai requerer apenas os registos para ser esvaziada. Ao efectuar operações não registados, as páginas de dados também devem ser descarregadas para armazenamento estável; não existem registos de registo individuais para gerar as acções em caso de falha.

As páginas de dados podem permanecer na cache até o processo LazyWriter ou ponto de verificação esvazia para armazenamento estável. A utilização de protocolo WAL para garantir que os registos são correctamente armazenados assegura que a recuperação pode recuperar uma página de dados um estado conhecido.

Isto não significa que é aconselhável colocar ficheiros de dados numa unidade em cache. Quando o SQL Server esvazia as páginas de dados para armazenamento estável, os registos podem ser truncados do registo de transacções. Se as páginas de dados estiverem armazenadas no cache voláteis, é possível truncar registos que seriam utilizados para recuperar uma página em caso de falha. Certifique-se de que dispositivos os dados e registo acomodar armazenamento estável correctamente.

Aumentar o desempenho

A pergunta inicial que resulta é: "tiver uma unidade IDE foi colocação em cache mas quando é desactivada, o desempenho ficou significativamente inferior esperado--porquê?"

Muitas das unidades IDE testadas pela Microsoft execute a uma velocidade RPM de 5,200 e o SCSI unidades a um RPM do 7,200. Quando desactiva a escrita colocar em cache da unidade IDE desempenho mecânico pode ficar um factor.

Existe uma área muito simples para resolver a diferença de desempenho: "A taxa de transacção de endereços".

Existem muitos processamento sistemas (OLTP) que requerem uma taxa alta transacção de transacções online. Nestes sistemas, considere utilizar um controlador de colocação em cache que correctamente pode suportar uma cache de escrita e fornecer o aumento do desempenho ao assegurar a integridade dos dados.

Para encontrar significativamente alterações de desempenho com o SQL Server numa unidade de colocação em cache, a taxa de transacção foi aumentada utilizar transacções pequenas.

Testar mostra que escrita elevada actividade de memórias intermédias mais pequenas do que 512 KB ou acima dos 2 MB pode provocar um desempenho lento.
Considere o seguinte exemplo:
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')
				
seguem os resultados do teste exemplo para o SQL Server:
Segundos SCSI(7200 RPM) 84
SCSI(7200 RPM) 15 segundos (controlador de colocação em cache)

14 De IDE(5200 RPM) segundos (unidade de cache activada)
IDE(5200 RPM) 160 segundos
Moldagem toda a série de operações de INSERT numa única transacção é executado em todas as configurações de cerca de 4 segundos.

A razão é o número de esvaziamentos de registo necessárias. Sem a transacção, cada INSERT é uma transacção na e de si próprio e sempre que os registos para a transacção devem ser esvaziados. Cada limpeza é 512 bytes de tamanho, o que requer intervenção unidade mecânico significativa do.

Quando é utilizada uma única transacção, os registos para a transacção podem ser Unidos e uma escrita única, maior pode ser utilizada para limpar os registos recolhidas. A intervenção mecânico é significativamente reduzida.

aviso Não é recomendado que aumente o âmbito de transacção. Transacções de execução longa podem conduzir a número excessivo e indesejado bloquear, bem como aumentaram sobrecarga. Utilize o SQL Server 7.0, SQL Server 2000 e contadores de desempenho do SQL Server 2005 Bases de dados SQL Server: para ver os contadores de baseadas no registo de transacções. Especificamente, flushed de registo de bytes/seg poderão indicar muitas transacções pequenas, conduzindo a actividade do disco mecânico alta.

Observe as instruções associadas com o registo de esvaziamento e determinar se o número de esvaziamentos de registo pode ser reduzido. No exemplo acima, uma única transacção foi implementada. No entanto, em vários cenários de Isto pode conduzir a um comportamento de bloqueio indesejável. Observe a estrutura da transacção. Talvez algo como o seguinte para efectuar secções para reduzir o registo frequente e pequeno esvaziar actividade:
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 não pode ver o impacto no desempenho mesmo de frequentes e escreve o registo de transacções pequeno. SQL Server 6. x reescreve a mesma página de registo 2 KB tal como as transacções consolidadas. Isto pode reduzir o tamanho do registo significativamente comparado com alinhamentos de limite de sector de byte 512 no SQL Server 7.0, SQL Server 2000 e SQL Server 2005. Reduzir o tamanho do registo directamente relacionado com a quantidade de actividade de unidade mecânico. No entanto, como descrita acima, o SQL Server 6. x algoritmo pode expor transacções consolidadas.
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: 230785 - Última revisão: 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 2005 Server Enterprise
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Workgroup
  • 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 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: 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