Descrição do registo e dados algoritmos de armazenamento que expandem a fiabilidade dos dados no 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: 230785
Sumário
Este artigo explica o modo algoritmos de registo e dados do Microsoft SQL Server que aumentam a fiabilidade dos dados e integridade.

Para saber mais sobre os conceitos subjacentes dos motores e ARIES (algoritmo para recuperação e a semântica de exploração de isolamento), consulte as seguintes transacções de ACM no documento de sistemas de base de dados (em "Volume 17. o, número 1, de Março de 1992):

O escritor de oportunidade potencial deste documento é C. Mohan. O documento aborda as técnicas de SQL Server para aumentar a fiabilidade dos dados e integridade no que respeita a falhas.

Recomendamos que leia os seguintes artigos na Microsoft Knowledge Base para mais informações sobre a colocação em cache e debates do modo de falha alternativo:
86903 Descrição da colocação em cache os controladores de disco no SQL Server
234656 Informações sobre como utilizar as caches de unidade de disco com o SQL Server, que deve conhecer todos os administrador de base de dados
Mais Informação
Antes de começar é a aprofundada, alguns dos termos que são utilizados ao longo deste artigo são definidos na tabela seguinte.
TermoDefinição
Bateria com cópia de segurançaBateria separados e localizadas cópia de segurança das instalações directamente disponíveis e controlada pelo mecanismo de colocação em cache para impedir a perda de dados.
Nota Não se trata de uma fonte de alimentação ininterrupta (UPS). Uma UPS não garante qualquer actividade de escrita e pode ser desligada a partir do dispositivo de colocação em cache.
CacheMecanismo de armazenamento intermediária utilizado para optimizar as operações de e/s físicas e melhorar o desempenho.
Página adicionalPágina que contém modificações de dados que ainda não ser descarregada para armazenamento estável. Para mais informações sobre as memórias intermédias de página adicional, consulte o "Escrever páginas"tópico no SQL Server Books Online.
Nota O conteúdo também se aplica a 2012 do Microsoft SQL Server e versões posteriores.
FalhaTudo o que poderá provocar uma falha inesperada de processo do SQL Server. Os exemplos incluem: a energia falha, reposição do computador, erros de memória, outros problemas de hardware, sectores danificados, falhas de unidade, falhas de sistema e assim sucessivamente.
EsvaziarForçar de uma memória intermédia de cache armazenamento estável.
FechaduraObjecto de sincronização utilizado para proteger consistência física de um recurso.
Armazenamento nonvolatileQualquer meio que permanece disponível através de falhas do sistema.
Página afixadaPágina permanece nos dados em cache e não pode ser descarregada para armazenamento estável até que todos os registos do registo associados são seguras numa localização de armazenamento estável.
Armazenamento estávelMesmo que o armazenamento de nonvolatile.
Armazenamento volátilQualquer meio que não irá permanecer intacto em toda a falhas.

Protocolo de registo escrita-para-avanço (WAL)

O termo "protocolo" é uma excelente forma de descrever WAL. É um específico e um conjunto definido de passos de execução necessários para se certificar de que os 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 para trocar dados de uma forma consistente e protegida, assim definido demasiado o WAL descreve o protocolo para proteger os dados.

O documento ARIES define a WAL do seguinte modo:
O protocolo WAL, afirma que os registos que representam as alterações a alguns dados já devem estar num armazenamento estável antes dos dados alterados são permitidos para substituir a versão anterior dos dados de armazenamento nonvolatile. Ou seja, o sistema não tem permissão para escrever uma página actualizada para a versão de armazenamento nonvolatile da página até, pelo menos, as partes de anular os registos de registo que descrevem as actualizações para a página tem sido escritas para armazenamento estável.
Para mais informações sobre o registo de escrita antecipada, consulte o Registo de transacções de escrita-para-avanço tópico no SQL Server Books Online.

SQL Server e o WAL

SQL Server utiliza o protocolo WAL. Para se certificar de que uma transacção é consolidada correctamente, todos os registos que estão associados com a transacção tem de ser protegidos no armazenamento estável.

Para clarificar esta situação, considere o seguinte exemplo específico.

Nota Para este exemplo, assuma que não existe nenhum índice e que a página afectada é página 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
Em seguida, divida a actividade em passos de registo simplistic, tal como descrito na seguinte tabela.
InstruçãoAcções executadas
INICIAR A TRANSACÇÃOEscritas para a área de cache de registo. No entanto, não é necessário esvaziar para armazenamento estável, porque o SQL Server não efectuou quaisquer alterações físicas.
INSERT INTO tblTest
  1. Dados página 150 são obtidos na cache de dados do SQL Server, se ainda não disponível.
  2. A página é fecho na, afixados, e marcado com problemas, e sejam obtidos bloqueios adequados.
  3. Um registo de inserir o registo é criado e adicionado à cache de registo.
  4. É adicionada uma nova linha para a página de dados.
  5. A fechadura é libertada.
  6. Os registos associados à transacção ou a página não tem de ser descarregados neste momento porque todas as alterações serão mantidas em armazenamento volátil.
CONSOLIDAR TRANSACÇÃO
  1. Um registro de Log de consolidação está formado e os registos associados à transacção devem ser redigidos armazenamento estável. A transacção não é considerada consolidada até os registros de log são correctamente atribuídos ao armazenamento estável.
  2. Dados página 150 permanecem na cache de dados do SQL Server e não ser imediatamente descarregados para armazenamento estável. Quando os registros de log são correctamente protegidos, a recuperação pode refazer a operação, se for necessário.
  3. Bloqueios transaccionais são lançados.
Não confundir pelos termos "bloquear" e "registo". Embora seja importante, bloqueamento e registo são problemas separados quando estiver a lidar com o WAL. No exemplo anterior, SQL Server geralmente mantém a fechadura 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 de bloqueio do SQL Server Books Online para obter mais detalhes sobre os tipos de bloqueio.

O exemplo em maior detalhe a ver, poderá perguntar o que acontece quando executar os processos de LazyWriter ou ponto de verificação. SQL Server 7 emite todos os esvaziamentos adequados para armazenamento de registos de registo transaccional associados com a página suja e afixada estável. Isto torna-se de que a página de dados de protocolo WAL nunca pode ser escrita armazenamento estável até tem foi limpa os registos de transacções associado.

Armazenamento de SQL Server e estável

SQL Server aumenta as operações de registo e dados da página, incluindo o conhecimento dos tamanhos de sector de disco (normalmente 4.096 ou 512 bytes).

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

SQL Server utiliza as páginas de dados de 8 KB e o registo (se abatida) múltiplos do tamanho do sector. (A maioria das unidades de disco utilizar 512 bytes como o tamanho de sector predefinido.) Em caso de falha, SQL Server pode conta para operações de escrita maior do que um sector recorrendo a paridade de registo e técnicas de escrita rasgado.

Detecção página rasgado

Esta opção permite que o SQL Server para detectar operações de e/s incompletas causadas por falhas de energia ou outros problemas de inactividade do sistema. Quando verdadeiro, faz com que um bit virado 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. As páginas incompletas normalmente são detectadas durante a recuperação porque qualquer página que foi escrita incorrectamente é susceptível de ser lido por recuperação.

Apesar de páginas de base de dados do SQL Server são 8 KB, discos efectuar operações de e/s, utilizando um sector de byte 512. Por conseguinte, os 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 uma falha de energia) entre a hora em que o 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 é escrito com êxito antes da falha, a página de base de dados no disco aparecem quando actualizado, embora possam não ter êxito.

Utilizando as caches de controlador de disco de bateria com cópia de segurança, pode certificar-se de que os dados com êxito são escritos no disco ou não escritos de todo. Nesta situação, não defina detecção de página rasgado para "verdadeiro" porque esta não é necessária.

Nota Detecção página rasgado não está activada por predefinição no SQL Server. Para mais informações, consulte o seguinte Web site da MSDN:

Paridade de registo

Verificação de paridade de registo é muito semelhante à 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 avaliados quando é obtido do registo. Forçando registo escritas num limite de 512 bytes, o SQL Server pode certificar-se de que as operações de committal completamente são escritas os sectores de disco físico.

Versões anteriores à versão 7.0 do SQL Server

Versões anteriores do SQL Server que 7.0 não forneceu paridade de registo ou instalações de detecção de bit rasgado. 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 de 2-KB. Isto pode expor as transacções que tenham cometido com êxito. Se a página de registo está a ser escritas de novo durante uma falha, um sector com a transacção consolidada não pode obter rescrito correctamente.

Impactos de desempenho

Todas as versões do SQL Server abrem os ficheiros de registo e dados utilizando a função de Win32CreateFile . O membro dwFlagsAndAttributes inclui a opção de FILE_FLAG_WRITE_THROUGH, quando são abertas 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 ainda pode colocar em cache operações de escrita, mas lazily não é possível esvaziá-los.

A opção FILE_FLAG_WRITE_THROUGH certifica-se de que quando uma operação de escrita devolve uma conclusão com êxito, os dados são correctamente armazenados em armazenamento estável. Isto alinha com o protocolo WAL que assegura 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 de bateria com cópia de segurança. Estes mecanismos de colocação em cache não garantem o ciclo de operações de escrita através de uma potência ou ponto de falha semelhante. Apenas garantirem a conclusão das operações de escrita de sector. Este é especificamente por que razão a escrita rasgada e a detecção de paridade de registo foram incorporados no SQL Server 7.0 e versões posteriores. Como as unidades continuarem a aumentar de tamanho, as caches ficar maiores e que podem expor maiores quantidades de dados durante uma falha.

Muitos fornecedores de hardware fornecem soluções de controlador de disco de bateria com cópia de segurança. Estes caches de controlador podem manter os dados na cache durante vários dias e mesmo para permitir que o hardware de colocação em cache a ser colocados no segundo computador. Quando a energia for restaurada correctamente, os dados unwritten está completamente limpa antes de é autorizado o acesso a dados suplementar. Muitos deles permitem uma percentagem de leitura versus a cache de escrita a estabelecer para um desempenho ideal. Alguns contêm áreas de armazenamento de memória de grandes dimensões. De facto, para o segmento de mercado muito específico, alguns fornecedores de hardware fornecem disco topo de gama bateria com cópia de segurança a colocação em cache de sistemas de controlador com 6 GB de cache. Estes podem melhorar significativamente o desempenho da base de dados.

Avançadas implementações de colocação em cache será capacidades em caso de uma reposição do sistema, falha de energia ou outro ponto de falha rescrever de identificador do FILE_FLAG_WRITE_THROUGH pedir por não desactivar a cache de controlador porque podem fornecer verdadeiro.

Transferências de e/s sem a utilização de uma cache podem ser consideravelmente mais demoradas do devido a um para o tempo mecânico que é necessário para mover as cabeças de unidade, taxas de rotação e outro factores de limitação.

Ordenação de sector

Uma técnica comum utilizada para aumentar o desempenho de e/s é o sector ordenação. Para evitar a circulação de cabeça mecânica são ordenados os pedidos de leitura/escrita, que permite o movimento mais consistente da cabeça obter ou armazenar dados.

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 armazenamento estável antes da escrita de página pode ser emitida. No entanto, utilização da cache poderá devolver êxito de um pedido de escrita de registo sem os dados a ser gravados para a unidade real (isto é, escrita armazenamento estável). Isto pode conduzir a emitir o pedido de escrita de página de dados do SQL Server.

Com a participação de cache de escrita, os dados é ainda considerados em armazenamento volátil. No entanto, uma chamada de Win32 API WriteFile, exactamente como o SQL Server vê a actividade, um código de retorno de êxito foi obtido. SQL Server ou qualquer processo que utiliza a chamada deWriteFileAPI pode determinar a onlythat os dados correctamente obteve armazenamento estável.

Para efeitos de debate, partem do princípio de que todos os sectores da página de dados são ordenados para escrever antes dos sectores dos registos registo correspondente. Isto viola imediatamente o protocolo WAL. A cache está a escrever uma página de dados antes dos registros de log. A menos que a cache é totalmente bateria com cópia de segurança, uma falha pode causar resultados resultantes de catástrofes.

Quando avaliar os factores de desempenho ideal para um servidor de base de dados, existem muitos factores a considerar. A mais importante é, "Meu sistema permite capacidades FILE_FLAG_WRITE_THROUGH válidas?"

Nota Qualquer cache que são totalmente usingmust suportar uma solução de bateria com cópia de segurança. Todos os outros mecanismos de colocação em cache são suspeita para a Corrupção de dados e perda de dados. SQL Server faz com que todos os esforços para garantir o WAL activando FILE_FLAG_WRITE_THROUGH.

Os testes demonstraram que várias configurações de unidade de disco podem conter escrita em cache sem a cópia de segurança adequado da bateria. Unidades SCSI, IDE e EIDE tirar o máximo partido das caches de escrita. Para mais informações sobre como SSDs funcionam em conjunto com o SQL Server, seethe após o artigo de blogue de engenheiros do CSS SQL Server:


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

Unidades SCSI também tem caches de escrita. No entanto, estes caches normalmente podem ser desactivados pelo sistema operativo. Se existir qualquer questão, contacte o fabricante da unidade para utilitários adequados.

Empilhamento de Cache de escrita

Escreva a que cache de empilhamento é semelhante a ordenação do Sector. Foi efectuada a seguinte definição directamente a partir de à esquerda IDE unidade Web site do fabricante:
Normalmente, este modo estiver activo. Escreva o modo de 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 do anfitrião está concluída.

Inicia uma tarefa de escrita do disco armazenar os dados do anfitrião para o disco. Comandos de escrita do sistema anfitrião continuam a ser aceites e os 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 o débito da unidade.

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

Outra técnica comum que é utilizada para proteger dados é detectar sectores danificados durante a manipulação de dados. A explicação seguinte provém de à esquerda IDE unidade Web site do fabricante:
Esta funcionalidade faz parte da cache de escrita e reduz o risco de perda de dados durante operações de escrita adiada. Se ocorrer um erro no disco durante o processo de escrita de disco, as paragens de tarefa do disco e o sector suspeito é novamente atribuída a um conjunto de sectores alternativos que se encontram no fim da unidade. Na sequência da reafectação, a tarefa de escrita de disco continua até esta estar concluída.
Isto pode ser uma funcionalidade muito poderosa, se a bateria de segurança é fornecida para a cache. Isto fornece as modificações adequadas ao reiniciar. É preferível para detectar os erros de disco, mas a segurança de dados do protocolo WAL novamente o exijam a ser executado em tempo real e não de forma diferida. No prazo dos parâmetros WAL, a técnica AWR não é possível contabilizar uma situação em que uma operação de escrita do registo falha devido a um erro de sector mas a unidade está cheia. O motor de base de dados tem imediatamente de saber sobre a falha para a transacção pode ser interrompida correctamente, o administrador pode ser alertado e corrigir as medidas tomadas para proteger os dados e corrigir a situação de falha de suportes de dados.

Segurança de dados

Existem várias precauções que deve ser um administrador de base de dados para garantir a segurança dos dados.
  • É sempre uma boa ideia para se certificar de que a estratégia de cópia de segurança é suficiente para recuperar de uma falha catastrófica. Armazenamento fora das instalações e outras precauções são adequadas.
  • Teste a operação de restauro da base de dados num secundário ou verificar base de dados frequentemente.
  • Certifique-se de que quaisquer dispositivos de colocação em cache podem tratar todas as situações de falha (falha de energia, sectores danificados, unidades incorrectas, falha de sistema, lockups, colector de energia e assim sucessivamente).
  • Certifique-se de que o dispositivo de colocação em cache:
    • Integrou bateria de segurança
    • Pode escreve de reemissão ligação
    • Pode ser totalmente desactivado se for necessário
    • Processa o remapeamento de conjuntos de sectores danificados em tempo real
  • Activar detecção página incompleta. (Esta acção tem alguma impacto no desempenho.)
  • Configure unidades RAID, permitindo uma comutação quente de uma unidade de disco danificada, se for possível.
  • Utilize os controladores mais recentes de colocação em cache que lhe permite adicionar mais espaço em disco sem reiniciar o sistema operativo. Isto pode ser a solução ideal.

Testes de unidades

Para proteger totalmente os dados, deverá certificar-se de que todos os caches de dados correctamente é processado. Em muitos casos, tem de desactivar a escrita em cache da unidade de disco.

Nota Certifique-se de que os vários tipos de falha consegue processar correctamente a alternativa mecanismo de colocação em cache.

Microsoft efectuou testes em várias unidades SCSI e IDE utilizando o utilitário SQLIOSim . Este utilitário simula a actividade de leitura/escrita assíncrona pesada para um dispositivo de simulação de dados e o dispositivo de registo. Estatísticas de desempenho do ensaio 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 sobre o utilitário de SQLIOSim , consulte o seguinte artigo na Microsoft Knowledge Base:
231619 Como utilizar o utilitário SQLIOSim para simular a actividade do servidor de SQL num subsistema de disco
Muitos fabricantes de computadores encomendar as unidades, fazendo com que a cache de escrita desactivada. No entanto, o teste mostra que isto nem sempre será o caso. Por conseguinte, teste sempre completamente.

Dispositivos de dados

Em situações de todos os não-logged, o SQL Server irá requerer apenas os registos de registo ser esvaziada. Ao efectuar operações-logged, as páginas de dados também devem ser descarregadas para armazenamento estável; Não existem registos individuais de registo a gerar as acções em caso de falha.

As páginas de dados podem permanecer na cache até o processo de LazyWriter ou ponto de verificação esvazia-las para armazenamento estável. Utilizando o protocolo WAL para se certificar de que os registros de log são correctamente armazenados certifica-se de que a recuperação pode recuperar uma página de dados a um estado conhecido.

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

Aumentar o desempenho

A primeira pergunta que ocorre é: "Tenho uma unidade IDE que foi a colocação em cache. Mas quando é desactivado, o desempenho tornou-se significativamente menor que o esperado. Porquê?"

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

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

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

Para encontrar significativamente as alterações de desempenho com o SQL Server numa unidade de colocação em cache, a taxa de transacções foi aumentada através da utilização de pequenas operações.

Testar revela que escrever alta actividade de memórias intermédias que for inferior a 512 KB ou superior a 2 MB, pode provocar um desempenho lento.
Considere o seguinte exemplo:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))GOSET NOCOUNT ONGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 10000   INSERT INTO tblTest VALUES ('Test')				
Seguem-se os resultados dos testes de exemplo para o SQL Server:
Segundos de 84 de SCSI(7200 RPM)
15 de SCSI(7200 RPM) 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 das operações de inserção numa única transacção é executado após quatro segundos em todas as configurações.

A razão é o número de esvaziamentos de registo necessárias. Sem a transacção, cada inserção é uma operação em si própria e, sempre que os registos para a transacção devem esvaziar. Cada flush é 512 bytes de tamanho, o que requer a intervenção significativa unidade mecânico.

Quando é utilizada uma única transacção, os registos para a transacção podem ser Unidos e uma operação de escrita única e maior pode ser utilizada para esvaziar os registros de log obtida. A intervenção mecânica é significativamente reduzida.

Aviso Recomendamos que não aumentar o âmbito de transacção. Transacções de execução demorada podem conduzir a excessiva e indesejado bloquear, bem como um aumento de custos gerais. Utilize os contadores de desempenho do servidor de SQL Server: bases de dados de SQL para ver os contadores de baseadas no registo de transacções. Especificamente, Flushed de Bytes de registo/seg pode indicar muitas transacções pequenas conducentes à actividade do disco mecânicas de alta.

Observe as demonstrações associadas com a libertação de registo e determinar se o número de esvaziamentos de registo pode ser reduzido. No exemplo anterior, foi implementada uma única transacção. No entanto, em vários cenários, isto pode conduzir a um comportamento indesejável bloqueamento. Examine a nível da concepção da transacção. Pode utilizar código semelhante ao seguinte para efectuar as secções para reduzir a actividade de esvaziamento de registo mais pequenos e mais frequentes:
BEGIN TRANGOINSERT INTO tblTest VALUES ('Test')WHILE @@IDENTITY < 50BEGIN   INSERT INTO tblTest VALUES ('Test')   if(0 = cast(@@IDENTITY as int) % 10)   BEGIN      PRINT 'Commit tran batch'      COMMIT TRAN      BEGIN TRAN   ENDENDGOCOMMIT TRANGO				
SQL Server requer que os sistemas suportam "entrega para um suporte estável, garantido" conforme descrito na Requisitos de revisão do programa de fiabilidade do SQL Server e/s Transferir o documento. 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 ir para 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: 230785 - Última Revisão: 05/17/2015 07:37:00 - Revisão: 1.0

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

  • kbhowto kbinfo kbmt KB230785 KbMtpt
Comentários