Você está offline; aguardando reconexão
Entrar

Descrição dos algoritmos de armazenamento de log e dados que ampliam a confiabilidade de dados no SQL Server

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

230785
Sumário
Este artigo discute como algoritmos de log e de dados do Microsoft SQL Server estendem a integridade e confiabilidade de dados.

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

O principal escritor deste documento é C. Mohan. Este documento aborda as técnicas de SQL Server para estender a confiabilidade dos dados e integridade com relação a falhas.

Recomendamos que você leia os seguintes artigos no Microsoft Knowledge Base para obter mais informações sobre armazenamento em cache e discussões do modo de falha alternativo:
86903 Descrição do cache de controladores de disco no SQL Server
234656 Informações sobre o uso de caches de disco com o SQL Server que cada administrador de banco de dados deve saber
Mais Informações
Antes de começarmos a discussão detalhada, alguns dos termos que são usados em todo este artigo são definidos na tabela a seguir.
TermoDefinição
Bateria reservaBateria separado e localizadas recurso de backup diretamente disponível e controlado pelo mecanismo de armazenamento em cache para evitar a perda de dados.
Observação: Esta não é uma fonte de alimentação ininterrupta (UPS). No-break não garante quaisquer atividades de gravação e pode ser desconectado do dispositivo de armazenamento em cache.
CacheMecanismo de armazenamento intermediário usado para otimizar as operações de e/s físicas e melhorar o desempenho.
Página sujaPágina que contém as modificações de dados que ainda precisam ser liberados para armazenamento estável. Para obter mais informações sobre buffers de página sujo, consulte o "Escrevendo páginas"tópico no SQL Server Books Online.
Observação: O conteúdo também se aplica ao Microsoft SQL Server 2012 e versões posteriores.
FalhaTudo o que pode causar uma interrupção inesperada do processo do SQL Server. Os exemplos incluem: alimentação paralisação, reinicialização de computador, erros de memória, outros problemas de hardware, setores defeituosos, paralisações de unidade, falhas do sistema e assim por diante.
LiberarForçando de um buffer de cache em uma armazenamento estável.
TravaObjeto de sincronização usado para proteger a consistência física de um recurso.
Armazenamento não-volátilQualquer mídia que permanecem disponível por falhas do sistema.
Página fixadaPágina que permanece nos dados em cache e não pode ser liberado para armazenamento estável até que todos os registros de log associados estão protegidos em um local de armazenamento estável.
Armazenamento estávelMesmo que o armazenamento não-volátil.
Armazenamento volátilQualquer mídia que não permanecerão intacta em falhas.

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

O protocolo de termo é uma excelente maneira de descrever WAL. É uma versão específica e um conjunto definido de etapas de implementação necessários para garantir que os dados é armazenado e trocado corretamente e podem ser recuperados para um estado conhecido em caso de falha. Assim como uma rede contém um protocolo definido para trocar dados de maneira consistente e protegida, portanto muito o WAL descrever o protocolo para proteger os dados.

O documento de ARIES define o WAL da seguinte maneira:
O protocolo WAL afirma que os registros do log que representa as alterações para alguns dados já devem existir no armazenamento estável antes dos dados alterados são permitidos para substituir a versão anterior dos dados no armazenamento não-volátil. Ou seja, o sistema não tem permissão para 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 dos registros do log que descrevem as atualizações à página tiverem sido gravadas em uma armazenamento estável.
Para obter mais informações sobre o log de write-ahead, consulte o Log de transações antes de gravação tópico no SQL Server Books Online.

SQL Server e o WAL

SQL Server usa o protocolo WAL. Para certificar-se de que uma transação seja confirmada corretamente, todos os registros do log que estão associados com a transação devem ser protegidos em armazenamento estável.

Para esclarecer essa situação, considere o seguinte exemplo específico.

Observação: Para este exemplo, suponha que não há nenhum índice e que a página afetada é página 150.
BEGIN TRANSACTION   INSERT INTO tblTest VALUES (1)COMMIT TRANSACTION				
Em seguida, divida a atividade em etapas simples de log, conforme descrito na tabela a seguir.
InstruçãoAções executadas
INICIAR TRANSAÇÃOEscrito para a área de cache de log. No entanto, não é necessário liberar armazenamento estável porque o SQL Server não tiver feito nenhuma alteração física.
INSERT INTO tblTest
  1. Dados página 150 são recuperados no cache de dados do SQL Server, se já não está disponível.
  2. A página é travadas, fixado, e marcado como sujo, e bloqueios apropriados são obtidos.
  3. Um registro de Log inserir é criado e adicionado ao cache de log.
  4. Uma nova linha é adicionada à página de dados.
  5. A trava está lançada.
  6. Os registros de log associados à transação ou página não precisa ser liberado neste momento porque todas as alterações permanecem no armazenamento volátil.
CONFIRMAR TRANSAÇÃO
  1. Um registro de Log de confirmação é formado e os registros de log associados à transação devem ser gravados em uma armazenamento estável. A transação não é considerada confirmado até que os registros de log são atribuídos corretamente para o armazenamento estável.
  2. Dados página 150 permanecem no cache de dados do SQL Server e não é imediatamente liberados para armazenamento estável. Quando os registros de log são protegidos corretamente, recuperação pode refazer a operação, se necessário.
  3. Bloqueios transacionais são liberados.
Não confundir os termos "bloquear" e "log". Embora importante, log e bloqueio são problemas separados ao lidar com o WAL. No exemplo anterior, SQL Server geralmente contém a trava na página 150 para o tempo necessário para realizar as alterações físicas inserir na página, não a toda hora da transação. O tipo de bloqueio adequado é estabelecido para proteger a linha, intervalo, página ou tabela, se necessário. Consulte as seções de bloqueio do SQL Server Books Online para obter mais detalhes sobre tipos de bloqueio.

Observando o exemplo mais detalhadamente, você pode perguntar o que acontece quando os processos LazyWriter ou ponto de verificação são executados. SQL Server 7 emite todas as liberações apropriadas para o armazenamento de registros de log transacional que estão associadas com a página suja e fixada. Isso garante que a página de dados de protocolo WAL nunca pode ser gravada em uma armazenamento estável até que os registros de log de transações associados foram liberados.

Armazenamento do SQL Server e estável

SQL Server aprimora as operações de página de log e dados, incluindo o conhecimento de tamanhos de setor de disco (normalmente 4.096 ou 512 bytes).

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

SQL Server usa páginas de 8 KB de dados e o log (se liberado) 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 uma falha do SQL Server pode responder para operações de gravação maior do que um setor empregando paridade de log e técnicas rasgadas gravação.

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 paralisações do sistema. Quando for verdadeiro, isso causará 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 em disco. Se um pouco está no estado incorreto quando a página for posterior leitura pelo SQL Server, em seguida, a página foi escrita incorretamente; página interrompida for detectada. Páginas rasgadas geralmente são detectadas durante a recuperação, porque qualquer página que foi escrita incorretamente é provável de ser lido pela recuperação.

Apesar de 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. Página interrompida pode ocorrer se o sistema falhar (por exemplo, devido a uma falha de energia) entre a hora em que o sistema operacional grava o primeiro setor de 512 bytes em disco e a conclusão da operação de 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 do banco de dados em disco aparecerá como atualizados, embora talvez não tenham êxito.

Usando os caches de controlador de disco de bateria, você pode ter certeza de que dados sejam gravados com êxito no disco ou não gravados em todos os. Nessa situação, não defina detecção de página interrompida como "true" porque isso não é necessário.

Observação: Detecção de página interrompida não está habilitada por padrão no SQL Server. Para obter mais informações, consulte o seguinte site da MSDN:

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 são sempre escritos com o registro de log e avaliados quando o registro é recuperado. Forçando a gravações de log em um limite de 512 bytes, do SQL Server pode Certifique-se de que as operações committal completamente são gravadas para os setores de disco físico.

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 preencherem a página de log de 2 KB. Isso pode expor as transações confirmadas com êxito. Se a página de registro está sendo reconfigurada durante uma falha, um setor com transação confirmada não pode obter reescrito corretamente.

Impactos sobre o desempenho

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

A opção FILE_FLAG_WRITE_THROUGH certifica-se de que quando uma operação de gravação retorna a conclusão bem-sucedida, os dados são armazenados corretamente no armazenamento estável. Essa evolução se alinha com o protocolo WAL que garante que os dados.
Várias unidades de disco (SCSI e IDE) contêm caches integrados de 512 KB, 1 MB ou maior. No entanto, os caches de disco normalmente se baseiam em um capacitor e não uma solução de bateria. Esses mecanismos de cache não podem garantir o ciclo de gravações em uma potência ou ponto de falha semelhante. Eles apenas garantir a conclusão das operações de gravação do setor. Isso é especificamente por que a detecção de paridade de log e rasgada gravação foram criados no SQL Server 7.0 e versões posteriores. Como as unidades continuam a crescer em tamanho, os caches se tornam maiores e eles podem expor quantidades maiores de dados durante uma falha.

Muitos fornecedores de hardware oferecem soluções de controlador de disco de bateria. Esses caches controlador podem manter os dados em cache por vários dias e até mesmo permitam o hardware cache sejam colocados em um segundo computador. Quando a alimentação é restaurada corretamente, os dados não gravados são liberados completamente antes de ter permissão de acesso a dados adicional. Muitas delas permitem que uma porcentagem de leitura versus cache de gravação seja estabelecida para um desempenho ideal. Alguns contêm áreas de armazenamento de memória grande. Na verdade, para um segmento muito específico do mercado, alguns fornecedores de hardware oferecem discos de bateria high-end sistemas de controlador com 6 GB de cache em cache. Isso podem melhorar significativamente o desempenho do banco de dados.

Advanced implementações de cache irá alça de FILE_FLAG_WRITE_THROUGH solicitar desativando o cache do controlador não porque eles oferecem verdadeiro regravar recursos no caso de uma reinicialização do sistema, falha de energia ou outro ponto de falha.

Transferências de i/o sem o uso de um cache podem ser muito mais devido ao tempo de mecânico é necessária para mover os cabeçotes da unidade, taxas de rotação e outro fatores de limitação.

Classificação do setor

Uma técnica comum usada para aumentar o desempenho de i/o é o setor de pedidos. Para evitar a movimentação do cabeçote mecânica as solicitações de leitura/gravação são classificadas, permitindo um movimento mais consistente da cabeça para recuperar ou armazenar dados.

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

Com o envolvimento de cache de gravação, os dados ainda são considerados como sendo em um armazenamento volátil. No entanto, desde a chamada Win32 API WriteFile, exatamente como o SQL Server vê a atividade, um código de retorno bem-sucedido foi obtido. Qualquer processo que usa a chamadaWriteFileAPI ou do SQL Server pode determinar a onlythat 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 do log correspondente. Isso viola imediatamente o protocolo WAL. O cache é escrever uma página de dados antes dos registros de log. A menos que o cache de bateria totalmente, uma falha pode causar resultados catastróficos.

Ao avaliar os fatores de desempenho ideal para um servidor de banco de dados, existem muitos fatores a serem considerados. O mais importante é, "Meu sistema permitir recursos FILE_FLAG_WRITE_THROUGH válidos?"

Observação: Qualquer cache são usingmust totalmente suporta uma solução de bateria. Todos os outros mecanismos de cache duvidosas para corrupção de dados e perda de dados. SQL Server faz todos os esforços para garantir a WAL habilitando FILE_FLAG_WRITE_THROUGH.

Testes mostraram que muitas configurações de unidade de disco podem conter a gravação em cache sem o backup de bateria apropriado. Unidades SCSI, IDE e EIDE se beneficiar de caches de gravação. Para obter mais informações sobre o funcionamento do SSDs em conjunto com o SQL Server, seethe o seguinte artigo do Blog de engenheiros do CSS SQL Server:


Em muitas configurações, a única maneira de desabilitar o cache de gravação de uma unidade IDE ou EIDE corretamente é usando um utilitário específico do fabricante ou por meio de jumpers localizados na própria unidade. Para certificar-se de que o cache de gravação está desabilitado para a unidade em si, entre em contato com o fabricante da unidade.

Unidades SCSI também têm caches de gravação. No entanto, esses caches podem ser desativados normalmente pelo sistema operacional. Se houver qualquer dúvida, entre em contato com o fabricante da unidade para utilitários apropriados.

Empilhamento de Cache de gravação

Gravação de que empilhamento de Cache é semelhante ao setor de pedidos. A seguinte definição foi obtida diretamente do site de um fabricante líder IDE unidade:
Normalmente, esse modo está ativo. Escreva o modo de cache aceita que o host gravar dados no buffer até que o buffer está cheio ou a transferência de host estiver concluída.

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

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

Outra técnica comum é usada para proteger dados é detectar setores defeituosos durante a manipulação de dados. A explicação a seguir vem do site de um fabricante líder IDE unidade:
Esse recurso faz parte do cache de gravação e reduz o risco de perda de dados durante as operações de gravação adiada. Se ocorrer um erro de disco durante o processo de gravação de disco, as paradas de tarefa do disco e o setor suspeito é realocada para um pool de setores alternativos que estão localizados no final da unidade. Após a realocação, a tarefa de gravação de disco continua até que seja concluída.
Isso pode ser um recurso muito eficiente se backup de bateria é fornecida para o cache. Isso permite modificação apropriada na reinicialização. É preferível para detectar os erros de disco, mas a segurança de dados do protocolo WAL novamente exigiria que isso seja feito a tempo real e não de uma maneira adiada. Dentro dos parâmetros WAL, a técnica AWR não pode evitar 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 deve imediatamente saber sobre a falha para a transação pode ser anulada corretamente, o administrador pode ser alertado e corrigir as etapas necessárias para proteger os dados e corrigir a situação de falha de mídia.

Segurança de dados

Há várias precauções que deve ter um administrador de banco de dados para garantir a segurança dos dados.
  • É sempre uma boa idéia para certificar-se de que sua estratégia de backup é suficiente para se recuperar de uma falha catastrófica. Armazenamento externo 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 de teste com freqüência.
  • Certifique-se de que os dispositivos de armazenamento em cache podem manipular todas as situações de falha (queda de energia, setores defeituosos, drives defeituosos, paralisação do sistema, travamentos, picos de energia e assim por diante).
  • Certifique-se de que seu dispositivo de armazenamento em cache:
    • Integrou a bateria de reserva
    • Pode reedição grava ao ligar
    • Pode ser totalmente desativada se for necessário
    • Manipula o setor defeituoso remapeamento em tempo real
  • Ativar interrompida detecção de página. (Isso tem pouco efeito no desempenho.)
  • Configure unidades RAID, permitindo um hot swap de uma unidade de disco defeituoso, se for possível.
  • Use controladores de armazenamento em cache mais recentes que permitem que você adicione mais espaço em disco sem reiniciar o sistema operacional. Isso pode ser a solução ideal.

Testes de unidades

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

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

Microsoft realizou testes em várias unidades SCSI e IDE, usando o utilitário SQLIOSim . Este utilitário simula a atividade de leitura/gravação assíncrona pesado para um dispositivo de dados simulados e 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 desabilitada e um intervalo RPM entre 5,200 e 7.200.

Para obter mais informações sobre o utilitário de SQLIOSim , consulte o seguinte artigo da Base de dados de Conhecimento da Microsoft:
231619 Como usar o utilitário SQLIOSim para simular a atividade do SQL Server em um subsistema de disco
Muitos fabricantes de computador solicitar as unidades fazendo com que o cache de gravação desabilitado. No entanto, o teste mostra que isso talvez não sempre seja o caso. Portanto, sempre teste completamente.

Dispositivos de dados

Em situações de quase não registrada, SQL Server exigirá apenas os registros de log a serem liberadas. Ao fazer operações não registradas, as páginas de dados também precisam ser liberadas para armazenamento estável; Não há nenhum registro de log individual 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 armazenamento estável. Usando o protocolo WAL para certificar-se de que os registros de log são armazenados corretamente certifica-se de 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 de cache. Quando o SQL Server libera as páginas de dados para o armazenamento, os registros de log podem ser truncados do log de transações. Se as páginas de dados são armazenadas em cache volátil, é possível truncar registros do log que deve ser usados para recuperar uma página em caso de falha. Certifique-se de que seus dados e o log de dispositivos acomodar o armazenamento estável corretamente.

Aumentando o desempenho

A primeira pergunta que ocorre é: "eu tenho uma unidade IDE que estava em cache. Mas quando eu o desabilitei, meu desempenho tornou-se significativamente menor do que a esperada. Por quê?"

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

Há uma área muito clara para resolver a diferença de desempenho: "Tratar a taxa de transação".

Há muitas transações on-line (OLTP) sistemas que requerem uma taxa de altas transações 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 o desempenho, garantindo 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 com o uso de pequenas transações.

Teste mostra que escreve alta atividade de buffers que é menor que 512 KB ou maior que 2 MB pode causar desempenho lento.
Considere o exemplo a seguir:
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')				
Estes são os resultados do teste de exemplo para SQL Server:
84 SCSI(7200 rpm) segundos
SCSI(7200 rpm) 15 segundos (controlador de cache)

IDE(5200 rpm) 14 segundos (unidade de cache habilitado)
IDE(5200 rpm) 160 segundos

Envolver toda a série de operações de inserção em uma única transação é executado em aproximadamente quatro segundos em todas as configurações.

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

Quando uma única transação é usada, os registros de log para a transação podem ser embalados e uma gravação única, maior pode ser usada para limpar os registros de log coletadas. A intervenção mecânica é reduzida significativamente.

Aviso É recomendável que você não aumentar o escopo da transação. Transações de longa duração podem levar ao bloqueio excessivo e indesejado, bem como aumentaram da sobrecarga. Use os contadores de desempenho do SQL Server : bancos de dados do SQL Server para exibir os contadores de transação com base em registro. Especificamente, Flushed Bytes de Log/s pode indicar muitas transações pequenas levando a atividade de disco mecânicos alta.

Veja as instruções associadas a liberação de log e determinar se o número de liberações de log pode ser reduzido. No exemplo anterior, foi implementada uma única transação. No entanto, em muitos cenários, isso pode levar a um comportamento indesejado bloqueio. Examine o design da transação. Você pode usar código semelhante ao seguinte para executar lotes para reduzir a atividade de liberação de log freqüente e pequeno:
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 oferecer suporte a sistemas "entrega garantida para mídias estáveis," conforme descrito na Requisitos de revisão do programa de confiabilidade do SQL Server e/s Faça o download do documento. Para 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 de artigo que se segue para ir para o artigo da Base de dados de Conhecimento da Microsoft:
967576 Requisitos de entrada/saída de mecanismo de banco de dados do Microsoft SQL Server

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 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
  • kbhowto kbinfo kbmt KB230785 KbMtpt
Comentários