Arquivos do mecanismo de armazenamento extensível

Aplica-se a: Windows | do Windows Server

Arquivos do mecanismo de armazenamento extensível

O mecanismo de armazenamento extensível usa os seguintes tipos de arquivos:

• arquivos de log de transações
• Arquivos de log de transações temporários
• Arquivos de log de transações reservadas
• arquivos de ponto de verificação
• arquivos de banco de dados
• Bancos de dados temporários
• Liberar arquivos de mapa

Esta tabela contém uma visão geral dos nomes de arquivos de dados gerenciados pelo ESE. Para o Windows Vista e versões posteriores, a configuração JET_paramLegacyFileNames afeta os nomes de arquivo usados.

Arquivos de log de transações

Os arquivos de log de transações contêm operações em arquivos de banco de dados. Eles contêm informações suficientes para levar um banco de dados a um estado logicamente consistente após o encerramento inesperado do processo ou o desligamento do sistema.

Os nomes dos arquivos de log dependem de um nome base de três letras, que pode ser definido com JET_paramBaseName. Os exemplos abaixo usam um nome base de "edb", porque esse é o nome base padrão. A extensão para os arquivos de log de transações será .log ou .jtx, dependendo se o JET_bitESE98FileNames está definido no parâmetro JET_paramLegacyFileNames. Para obter mais informações, consulte Extensible Storage Engine System Parameters.

Os arquivos de log de transações são nomeados <base><número de geração>.log, começando com 1. O número de geração de log está em formato hexadecimal. Por exemplo, edb00001.log é o primeiro log e edb000ff.log é o 255º log. Os arquivos de log têm cinco dígitos hexadecimais no nome do arquivo de log, até o arquivo de log 1048576, quando os arquivos de log começam a ser nomeados em um formato 11.3 (por exemplo, edb00100000.log). < >.log base é sempre o arquivo de log que está sendo usado no momento. Se o mecanismo de banco de dados não estiver ativo, a geração de edb.log poderá ser identificada usando o seguinte comando: esentutl.exe -ml edb.log.

Embora os arquivos de log de transações tenham o arquivo . LOG extensão comumente associada com arquivos de texto, arquivos de log de transações estão em um formato binário e nunca devem ser editados por um usuário. As operações de banco de dados são gravadas primeiro no log. Os dados podem ser gravados no arquivo de banco de dados mais tarde; possivelmente imediatamente, potencialmente muito mais tarde. No caso de processo inesperado ou encerramento do sistema, as operações ainda estão presentes nos arquivos de log e as transações incompletas podem ser revertidas. O ato de reproduzir arquivos de log de transações é chamado de de recuperação suave e é feito automaticamente quando JetInit ou JetInit2 é chamado. A recuperação suave também pode ser realizada manualmente com a opção "-r" do programa Esentutl.exe. O ato de reproduzir arquivos de log de transações em um banco de dados que é restaurado a partir de um backup é chamado de recuperação rígida.

Os arquivos de log são de tamanho fixo, personalizáveis com JET_paramLogFileSize. Quando o arquivo de log atual (ou seja, edb.log) é preenchido, ele é renomeado para <><.log de número de geração de>base e um novo arquivo de log de transações é necessário no fluxo de log de transações.

Cada instância de banco de dados tem uma única sequência de arquivo de log associada a ela. O Windows XP introduziu JetCreateInstance, permitindo que várias sequências de arquivos de log de transações sejam usadas por um único processo. No entanto, várias sequências de arquivos de log de transações não podem existir no mesmo diretório.

Os arquivos de log de transações quase nunca devem ser manipulados, renomeados, movidos ou excluídos manualmente porque pode ocorrer corrupção de dados.

Os arquivos de log de transações serão excluídos pelo mecanismo de banco de dados durante um backup completo (consulte JetBackup, JetTruncateLog, JetTruncateLogInstance), ou durante operações normais, se o log circular estiver habilitado.

Depois que um arquivo de log de transações é preenchido, o mecanismo de banco de dados precisa criar um novo arquivo de log. O log circular é um meio pelo qual os arquivos de log podem ser limpos automaticamente pelo mecanismo de banco de dados quando não forem mais necessários para a recuperação de falhas. Esse processo é uma alternativa para remover arquivos de log como um subproduto da execução de um backup. O registro circular pode ser controlado com o parâmetro JET_paramCircularLog system. Os arquivos de log de transações não devem ser excluídos usando qualquer outro método.

Arquivos de log de transações temporários

Quando edb.log é preenchido, o ESE precisa criar um novo arquivo. O novo arquivo de transação de log é conhecido como um arquivo de log de transações temporário antes de seu uso pelo ESE.

Enquanto um novo arquivo de log é criado e seu tamanho estendido, ele será chamado <>tmp.log base. Criar um novo arquivo pode ser uma operação potencialmente cara, portanto, o ESE criará o próximo arquivo de log proativamente como uma tarefa em segundo plano.

Como o arquivo de log de transações temporário é criado em antecipação à necessidade de um novo arquivo de log de transações, ele não contém nenhuma informação útil.

Arquivos de log de transações reservados

Os arquivos de log de transações reservados são criados quando o mecanismo é iniciado para permitir que operações importantes sejam registradas para obter um desligamento limpo.

Windows Vista: No Windows Vista e versões posteriores, os Arquivos de Log de Transações Reservadas são nomeados <base>RESXXXXX.jrs.

Windows Server 2003: No Windows Server 2003 e versões anteriores, os arquivos de log de transações reservadas são nomeados res1.log e res2.log.

Quando o mecanismo de banco de dados fica sem espaço em disco, ele não pode criar um novo arquivo de log. A coisa mais segura a fazer é desligar corretamente, mas algumas operações (como operações de reversão) ainda devem ser registradas. A maioria das operações de banco de dados falhará durante esse estágio.

Como os arquivos de log de transações reservados são criados em antecipação à necessidade de arquivos de log de transações em um cenário fora do disco, eles não contêm informações úteis.

Arquivos de ponto de verificação

O arquivo de ponto de verificação armazena o ponto de verificação para uma sequência de arquivo de log de transações específica. O arquivo de ponto de verificação é nomeado <base>.chk ou <base>.jcp, dependendo se o JET_bitESE98FileNames está definido no parâmetro JET_paramLegacyFileNames e sua localização é dada por JET_paramSystemPath.

As operações de banco de dados são primeiro gravadas nos arquivos de log e, em seguida, armazenadas em cache na memória. Em algum momento posterior, as operações são gravadas no arquivo de banco de dados, mas, por motivos de desempenho, a ordem em que as operações são gravadas no arquivo de banco de dados pode não corresponder à ordem em que foram originalmente registradas. As operações gravadas no arquivo de log de transações estarão em um dos dois estados:

• Gravado no arquivo de log de transações e no arquivo de banco de dados.

• Gravado no arquivo de log de transações e ainda não gravado no arquivo de banco de dados.

Muitas operações de banco de dados podem ser armazenadas em um único arquivo de log de transações. Um determinado arquivo de log pode consistir nos seguintes itens:

• Todas as operações gravadas no arquivo de banco de dados.

• Nenhuma operação gravada no arquivo de banco de dados

• Uma combinação de operações gravadas no arquivo de banco de dados e operações ainda não gravadas no arquivo de banco de dados.

O ponto de verificação refere-se ao ponto no tempo no fluxo de log de transações onde todas as operações anteriores ao ponto de verificação foram gravadas no arquivo de banco de dados. Não há garantia sobre as operações que ocorrem após o checkpoint; alguns podem estar na memória e outros podem ser gravados no banco de dados.

Como todas as operações nos arquivos de log anteriores ao ponto de verificação são representadas no arquivo de banco de dados, somente os arquivos de log de transações após o ponto de verificação são necessários para a recuperação suave para colocar um determinado banco de dados em um estado limpo.

Arquivos de banco de dados

O arquivo de banco de dados contém o esquema para todas as tabelas no banco de dados, os registros para todas as tabelas no banco de dados e os índices sobre as tabelas. Sua localização é dada usando JetCreateDatabase, JetCreateDatabase2, JetAttachDatabaseou JetAttachDatabase2.

Um banco de dados é desligado corretamente somente após uma chamada bem-sucedida para JetTerm ou JetTerm2.

O programa Esentutl.exe pode detetar se um banco de dados é desligado corretamente com a opção "-mh". Por exemplo, "esentutl.exe -mh sample.edb" lerá o cabeçalho do banco de dados de um banco de dados chamado sample.edb e imprimirá o estado de sample.edb. Ele pode imprimir "State: Clean Shutdown" ou "State: Dirty Shutdown".

Um banco de dados que não foi desligado corretamente está em um estado de desligamento sujo. Antes do Windows XP, esse estado era chamado de inconsistente. Um banco de dados sujo (inconsistente) pode ser levado a um estado limpo com recuperação suave. Um banco de dados corrompido não é o mesmo que um banco de dados sujo ("inconsistente").

Um banco de dados corrompido refere-se a uma corrupção física ou lógica e não pode ser corrigido com recuperação suave. As corrupções físicas podem ser inversões de bits, que frequentemente serão capturadas pelas somas de verificação nas páginas do banco de dados. Uma soma de verificação com falha em um arquivo de banco de dados se manifesta como um erro de JET_errReadVerifyFailure.

Somente bancos de dados desligados de forma limpa podem ser movidos ou renomeados com segurança. Se um banco de dados não foi desligado corretamente, ele não pode ser movido ou renomeado automaticamente com segurança.

Vários bancos de dados podem ser associados a uma única sequência de arquivos de log de transações.

Bases de Dados Temporárias

O banco de dados temporário é usado como um armazenamento de suporte para temptables e também é usado ao criar índices.

O nome e o local são configurados com JET_paramTempPath.

Temptables são criados com JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. Eles também são criados por algumas chamadas de API e usados para retornar informações de esquema (como JetGetIndexInfo).

Liberar arquivos de mapa

A partir da Atualização de Aniversário do Windows 10 (cliente) e do Windows Server 2016 (servidor), o ESE adicionou um nível adicional de proteção contra gravações perdidas (ou liberações perdidas) 1, permitindo detetar tais eventos de reinicialização de processos cruzados2. Esse recurso requer a persistência de metadados em um arquivo separado chamado arquivo "flush map".

Um arquivo de mapa de liberação é criado para cada arquivo de banco de dados e está localizado no mesmo diretório. O arquivo é nomeado de forma semelhante ao arquivo de banco de dados, mas com uma extensão diferente. Por exemplo, se o aplicativo cliente criar um banco de dados com o caminho completo C:\MyDirectory\MyDabatase.edb, seu arquivo de mapa de liberação correspondente será C:\MyDirectory\MyDabatase.jfm.

Esse aprimoramento introduz dois requisitos para como os arquivos de banco de dados devem ser nomeados:

• Dois bancos de dados no mesmo diretório não devem ter o mesmo nome de arquivo com extensões diferentes. Por exemplo: C:\MyDirectory\MyDabatase.db1 e C:\MyDirectory\MyDabatase.db2.

• 2. Um banco de dados não deve ter uma extensão .jfm.

Quando você copia ou move manualmente um arquivo de banco de dados, seu arquivo de mapa de liberação correspondente também deve ser, respectivamente, copiado ou movido para o mesmo diretório de destino. Se um arquivo de mapa de liberação não estiver presente no momento de um novo anexo de banco de dados (via JetAttachDatabase, um novo arquivo será criado e preenchido novamente sob demanda à medida que as páginas forem lidas do banco de dados. A mistura de arquivos de banco de dados e mapa de liberação incompatíveis é tratada pelo ESE e força o mapa de descorrespondência a ser excluído e recriado do zero.

O tamanho de um arquivo de mapa de liberação é diretamente proporcional ao seu arquivo de banco de dados associado e aproximadamente igual a (todos os tamanhos em bytes, o resultado deve ser arredondado para o próximo múltiplo de 8.192):

8,192 + ((<database file size> / <database page size>) / 4)

Por exemplo: para um banco de dados de 1,5 GB usando um tamanho de página de 32 KB, o tamanho aproximado do mapa de liberação é de 24.576 bytes (ou 24 KB).

O arquivo de mapa de liberação precisa ser atualizado à medida que as páginas do banco de dados são liberadas. Se o log transacional estiver habilitado (por exemplo, JET_paramRecovery definido como "on", o padrão), a atualização do mapa de liberação será executada à medida que o aplicativo cliente fizer modificações no banco de dados. Em média, todo o mapa de descarga é gravado na mídia não volátil uma vez a cada 20% de JET_paramCheckpointDepthMax -worth (em bytes) de logs transacionais gerados. O número de operações de gravação depende de como as modificações são distribuídas pelo banco de dados. Mas é no máximo, aproximadamente (todos os tamanhos em bytes):

<flush map file size> / JET_paramMaxCoalesceWriteSize

Se o log transacional estiver desabilitado (por exemplo, JET_paramRecovery definido como "desativado"), o mapa de liberação será atualizado apenas uma vez quando o banco de dados for explicitamente desanexado de forma limpa (por meio de JetDetachDatabase ou implicitamente desanexado de forma limpa ao encerrar sua instância ESE associada (por meio de qualquer uma das funções JetTerm, desde que JET_bitTermDirty não seja passado).

1 Uma gravação perdida (ou liberação perdida) é definida como uma operação de gravação que retorna com êxito do sistema operacional para o mecanismo de banco de dados ESE, mas os dados reais nunca são persistentes para o arquivo de banco de dados na mídia não volátil. Geralmente é causada por um mau funcionamento ou pilha de armazenamento mal configurado (software ou hardware). Os aplicativos cliente podem receber um erro JET_errReadLostFlushVerifyFailure de funções ESE que exigem a leitura de dados do banco de dados se os dados estiverem localizados em uma região que sofreu um evento de gravação perdido.

2 A capacidade de detetar gravações perdidas durante o tempo de vida de um processo está presente desde o Windows 8 (cliente) e o Windows Server 2012 (servidor).