Arquivos extensíveis do mecanismo de armazenamento
Aplica-se a: Windows | Windows Server
Arquivos extensíveis do mecanismo de armazenamento
O Mecanismo de Armazenamento Extensível usa os seguintes tipos de arquivos:
Esta tabela contém uma visão geral dos nomes de arquivo de dados gerenciados pelo ESE. Para o Windows Vista e posteriores, a configuração JET_paramLegacyNames afeta os nomes de arquivo usados.
| Rótulo | Valor |
|---|---|
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 um encerramento inesperado do processo ou 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 a seguir 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 estiver definido no parâmetro JET_paramLegacyFileNames. Para obter mais informações, consulte Parâmetros extensíveis do sistema do mecanismo de armazenamento.
Os arquivos de log de transações são nomeados <base><generation-number.log>, começando com 1. O número de geração de log está no 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 1048576º arquivo de log, momento em que os arquivos de log começam a ser nomeados em um formato 11.3 (por exemplo, edb001000000.log). <base.log> é 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 . Extensão LOG normalmente associada a 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 posteriormente; possivelmente imediatamente, potencialmente muito mais tarde. No caso de um 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 recuperação reversível e é feito automaticamente quando JetInit ou JetInit2 é chamado. A recuperação reversível também pode ser executada 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 restaurado 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 <base><generation-number.log> 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 arquivos 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, não é possível existir várias sequências de arquivos de log de transações no mesmo diretório.
Os arquivos de log de transações quase nunca devem ser manipulados manualmente, renomeados, movidos ou excluídos porque os dados corrompidos podem resultar.
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 eles não são mais necessários para recuperação de falhas. Esse processo é uma alternativa para remover arquivos de log como um by-product da execução de um backup. O registro em log circular pode ser controlado com o parâmetro do sistema JET_paramCircularLog . Os arquivos de log de transações não devem ser excluídos usando nenhum 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.
Embora um novo arquivo de log seja criado e seu tamanho seja estendido, ele será chamado <de tmp.log base>. A criação de um novo arquivo pode ser uma operação potencialmente dispendiosa, 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 antecipando a 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 começa a permitir que operações importantes sejam registradas para obter um desligamento limpo.
Windows Vista: No Windows Vista e posterior, os Arquivos de Log de Transações Reservadas são nomeados <RESXXXXX.jrs base>.
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 reservadas são criados antecipando a necessidade de arquivos de log de transações em um cenário fora de disco, eles não contêm nenhuma informação útil.
arquivos de ponto de verificação
O arquivo de ponto de verificação armazena o ponto de verificação para uma sequência de arquivos de log de transações específica. O arquivo de ponto de verificação é chamado <base.chk> ou <base.jcp>, dependendo se o JET_bitESE98FileNames está definido no parâmetro JET_paramLegacyFileNames e sua localização é fornecida por JET_paramSystemPath.
As operações de banco de dados são gravadas primeiro 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 na qual as operações são gravadas no arquivo de banco de dados pode não corresponder à ordem em que foram registradas originalmente. 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 em que todas as operações anteriores ao ponto de verificação foram gravadas no arquivo de banco de dados. Não há nenhuma garantia sobre as operações que ocorrem após o ponto de verificação; alguns podem estar na memória e outros podem ser gravados no banco de dados.
Como todas as operações nos arquivos de log antes do 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 que a recuperação reversível traga um banco de dados específico para um estado limpo.
Arquivos do banco de dados
O arquivo de banco de dados contém o esquema para todas as tabelas no banco de dados, os registros de todas as tabelas no banco de dados e os índices sobre as tabelas. Sua localização é fornecida usando JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase ou JetAttachDatabase2.
Um banco de dados é desligado corretamente somente após uma chamada bem-sucedida para JetTerm ou JetTerm2.
O programa Esentutl.exe pode detectar se um banco de dados é desligado corretamente com a opção "-mh". Por exemplo, "esentutl.exe -mh sample.edb" lerá o cabeçalho de banco de dados de um banco de dados chamado sample.edb e imprimirá o estado de sample.edb. Ele pode imprimir "Estado: Desligamento Limpo" ou "Estado: Desligamento Sujo".
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 reversível. 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 reversível. Corrompidos físicos podem ser bit flips, que serão frequentemente capturados 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 corretamente podem ser movidos ou renomeado com segurança. Se um banco de dados não tiver sido desligado corretamente, ele não poderá 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.
Bancos de dados temporários
O banco de dados temporário é usado como um repositório de backup para tentações e também é usado ao criar índices.
O nome e o local são configurados com JET_paramTempPath.
Os temptables são criados com JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable. Eles também são criados por algumas chamadas à API e usados para retornar informações de esquema (como JetGetIndexInfo).
Liberar arquivos de mapa
Começando com a Atualização de Aniversário Windows 10 (cliente) e Windows Server 2016 (servidor), o ESE adicionou um nível adicional de proteção contra gravações perdidas (ou liberações perdidas) 1, permitindo que detecte esses eventos reinicialização entre processos2. Esse recurso requer a persistência de metadados para um arquivo separado chamado de arquivo de "mapa de liberação".
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 apresenta dois requisitos de 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 será criado e preenchido novamente sob demanda à medida que as páginas forem lidas no banco de dados. A combinação de arquivos de mapa de liberação e banco de dados incompatível é manipulada pelo ESE e força o mapa de liberação incompatível a ser excluído e recriado do zero.
O tamanho de um arquivo de mapa de liberação é diretamente proporcional ao 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 de banco de dados são liberadas. Se o log transacional estiver habilitado (por exemplo, JET_paramRecovery definido como "ativado", o padrão), a atualização do mapa de liberação será executada à medida que o aplicativo cliente faz modificações no banco de dados. Em média, todo o mapa de liberação é gravado na mídia não volátil uma vez para cada 20% de JET_paramCheckpointDepthMax -worth (em bytes) de logs transacionais gerados. O número de operações de gravação depende de quão distribuídas em todo o banco de dados as modificações são. Mas é, no máximo, aproximadamente (todos os tamanhos em bytes):
<flush map file size> / JET_paramMaxCoalesceWriteSize
Se o registro em 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 (via 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 persistidos no arquivo de banco de dados na mídia não volátil. Geralmente, isso é causado por uma pilha de armazenamento com mau funcionamento ou configuração incorreta (software ou hardware). Os aplicativos cliente podem receber um erro JET_errReadLostFlushVerifyFailure de funções ESE que exigem dados de leitura 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 detectar gravações perdidas no tempo de vida de um processo está presente desde Windows 8 (cliente) e Windows Server 2012 (servidor).