Guia de arquitetura de página e extensão

Aplica-se a:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSistema de Plataforma de Análise (PDW)Banco de dados SQL no Microsoft Fabric

Este guia descreve a estrutura de páginas e extensões e a organização de páginas e extensões dentro de arquivos de dados.

Uma página é uma unidade fundamental do armazenamento de dados no Mecanismo de Banco de Dados. O espaço em disco alocado a um arquivo de dados (.mdf ou .ndf) em um banco de dados é logicamente dividido em páginas numeradas de forma contígua de 0 a n. As operações de E/S de disco em arquivos de dados são executadas no nível da página. Ou seja, o Mecanismo de Banco de Dados lê ou grava páginas de dados inteiras.

Uma extensão é uma coleção de oito páginas fisicamente contíguas, usadas para gerenciar de forma eficiente páginas. Cada página pertence a uma extensão.

Os arquivos de log de transações (.ldf) não contêm páginas. Eles contêm uma série de registros de log que não têm um tamanho fixo.

Páginas

Pegue um livro regular: todo o conteúdo nele está escrito em páginas. Semelhante a um livro, o Mecanismo de Banco de Dados grava todas as linhas de dados em páginas. O tamanho de cada página é o mesmo: 8 KiB. Em um livro, a maioria das páginas contém os dados ou o conteúdo principal do livro. Algumas páginas contêm metadados que descrevem o conteúdo, por exemplo, o sumário e o índice.

Da mesma forma, a maioria das páginas no banco de dados contém linhas reais de dados. Elas são chamadas de páginas de dados. As páginas de texto/LOB também contêm dados, mas são usadas apenas por tipos de dados LOB (objeto grande). As páginas de índice contêm estruturas de índice que ajudam a localizar dados com eficiência. Por fim, uma variedade de páginas do sistema armazena os metadados que descrevem a organização e as propriedades dos dados.

A tabela a seguir descreve os tipos de página.

Cada página começa com um cabeçalho de 96 bytes usado para armazenar informações de sistema sobre a página. Essas informações incluem o número da página, o tipo de página e podem incluir outros metadados, como a ID do objeto e a ID de índice do objeto e índice que possuem a página.

Uma estrutura chamada matriz de slots é armazenada no final da página. Cada elemento de 2 bytes na matriz de slots corresponde a uma linha armazenada na página. Um elemento de matriz de slot armazena o deslocamento em bytes da linha em relação ao início da página. O Mecanismo de Banco de Dados usa esses deslocamentos para localizar linhas em uma página.

Quando o Mecanismo de Banco de Dados adiciona uma linha a uma página vazia, ele armazena a linha imediatamente após o cabeçalho. O elemento de matriz de slot para a primeira linha é armazenado no final da página. À medida que mais linhas são adicionadas, elas são armazenadas uma após a outra do início ao final da página, enquanto a matriz de slots cresce do final ao início da página, conforme mostrado no diagrama a seguir.

À medida que as linhas em uma página são excluídas ou atualizadas ao longo do tempo, o espaço livre pode aparecer entre as linhas restantes. Quando uma nova linha é adicionada, ela pode ser armazenada nesse espaço livre, se o espaço for suficiente. Isso significa que as linhas em uma página podem não ser armazenadas fisicamente em nenhuma ordem específica. No entanto, o Mecanismo de Banco de Dados mantém as entradas da matriz de slots em uma ordem lógica. Como resultado, as linhas em uma página também são acessadas em uma ordem lógica, por exemplo, a ordem definida pela chave do índice BTree que possui a página.

Suporte à linha grande

Para dar suporte a linhas grandes que não cabem em uma única página, a parte da linha que não cabe pode ser armazenada em outras páginas. O tamanho máximo de dados e sobrecarga que podem ser contidos em uma única linha em uma página é de 8.060 bytes.

A restrição de 8.060 bytes não se aplica aos dados nas colunas usando os tipos de dados LOB. Por padrão, para essas colunas, os dados serão armazenados em linha se houver espaço suficiente. Caso contrário, a linha contém um ponteiro de 16 bytes para uma árvore separada de páginas de texto/LOB armazenando os dados LOB em uma LOB_DATA unidade de alocação. A large value types out of rowopção de tabela controla esse comportamento.

A restrição de 8.060 bytes é relaxada para tabelas e índices que contêm colunas de comprimento variável usando os tipos de dados definidos pelo usuário varchar, nvarchar, varbinary, sql_variant ou CLR. Quando o tamanho total da linha de todas as colunas de comprimento fixo e variável em um heap ou índice excede a limitação de 8.060 bytes, o Mecanismo de Banco de Dados move dinamicamente uma ou mais colunas de comprimento variável para páginas em uma ROW_OVERFLOW_DATA unidade de alocação, começando pela coluna de maior largura.

Isso é feito sempre que uma operação de inserção ou atualização aumenta o tamanho total da linha além do limite de 8.060 bytes. Quando uma coluna é movida para uma página em uma ROW_OVERFLOW_DATA unidade de alocação, um ponteiro de 24 bytes é mantido na página original em uma IN_ROW_DATA unidade de alocação. Se uma operação subsequente reduzir o tamanho da linha, o Mecanismo de Banco de Dados moverá dinamicamente as colunas de volta para a página de dados original.

Por exemplo, uma tabela pode ser criada com duas colunas: uma varchar(7000) e outra varchar(2000). Individualmente, nenhuma coluna excede 8.060 bytes, mas combinada elas o fariam se toda a largura de cada coluna fosse preenchida. Se isso acontecer, o Mecanismo de Banco de Dados moverá dinamicamente a coluna de comprimento da variável varchar(7000) da página original para as páginas em uma ROW_OVERFLOW_DATA unidade de alocação.

Quando uma tabela ou um índice tiver colunas de tipo definidas pelo usuário varchar, nvarchar, varbinary, sql_variant ou CLR que podem exceder 8.060 bytes por linha, considere o seguinte:

• Mover linhas grandes para outra página ocorre dinamicamente à medida que as linhas são alongadas com base nas operações de atualização. As operações de atualização que reduzem linhas podem fazer com que elas sejam movidas de volta para a página original em uma IN_ROW_DATA unidade de alocação.

  Essa movimentação de dados resulta em E/S de disco extra. Operações de processamento de consulta, como classificações ou junções em registros grandes que contêm dados de estouro de linha, podem ser mais lentas.

  Portanto, ao projetar uma tabela com várias colunas de tipo definidas pelo usuário varchar, nvarchar, varbinary, sql_variant ou CLR, considere a porcentagem de linhas que provavelmente fluirão e a frequência com que esses dados de estouro provavelmente serão consultados. Para evitar um desempenho reduzido, normalize a tabela para mover algumas dessas colunas para outra tabela, a fim de reduzir ou eliminar a possibilidade de utilizar o armazenamento de transbordo de linha.

• O comprimento das colunas individuais ainda deve estar dentro do limite de 8.000 bytes para colunas de tipo definidas pelo usuário varchar, nvarchar, varbinary, sql_variant e CLR. Só os comprimentos combinados delas podem exceder o limite de linha de 8.060 bytes de uma tabela.

• A soma dos comprimentos de outras colunas de tipo de dados, por exemplo, char, nchar e dados int , ainda deve estar dentro do limite de linha de 8.060 bytes. No entanto, as colunas que usam os tipos de dados LOB como varchar(max), nvarchar(max) e varbinary(max) são isentas do limite de linha de 8.060 bytes.

• A chave de índice de um índice clusterizado não pode conter colunas varchar que têm dados em uma ROW_OVERFLOW_DATA unidade de alocação. Se um índice clusterizado for criado em uma coluna varchar e todos os dados existentes estiverem em uma unidade de alocação IN_ROW_DATA, mas uma instrução subsequente INSERT ou UPDATE mover os dados para fora da linha, a instrução falhará. Para obter mais informações, consulte o guia de design e arquitetura de índice.

• Você pode incluir colunas contendo dados de estouro de linha como colunas de chave ou não chave de um índice não clusterizado.

• O limite de tamanho da linha para tabelas que usam colunas esparsas é de 8.018 bytes. Durante a conversão entre colunas esparsas e nãoparsas, quando os dados convertidos mais dados existentes excedem 8.018 bytes, o erro 576 é retornado. Quando as colunas são convertidas entre tipos esparsos e nãoparsos, o Mecanismo de Banco de Dados mantém uma cópia dos dados de linha atuais. Isso dobra temporariamente o armazenamento necessário para a linha.

• Para obter informações sobre tabelas ou índices que podem conter dados de estouro de linha, use a função de gerenciamento dinâmico sys.dm_db_index_physical_stats. Um índice ou partição terá dados de estouro de linha se a função retornar linhas em que a alloc_unit_type_desc coluna está ROW_OVERFLOW_DATA e a page_count coluna for maior que 0.

Extensões

Uma extensão é um conjunto de oito páginas fisicamente contíguas. O tamanho de cada extensão é de 64 KiB.

Há dois tipos de extensões:

• Extensões uniformes pertencem a um único objeto, por exemplo, uma única tabela; todas as oito páginas na extensão só podem ser usadas pelo objeto proprietário.
• Extensões mistas compartilhadas por até oito objetos. Cada uma das oito páginas da extensão pode pertencer a um objeto diferente.

Até e incluindo o SQL Server 2014 (12.x), o Mecanismo de Banco de Dados não aloca extensões uniformes a tabelas com pequenas quantidades de dados. Um novo heap ou índice aloca páginas de extensões mistas. Quando o heap ou índice cresce ao ponto de usar oito páginas, ele alterna para extensões uniformes para todas as alocações subsequentes. Se um índice for criado em uma tabela existente que tiver linhas suficientes para gerar oito páginas no índice, todas as alocações para o índice estarão em extensões uniformes.

A partir do SQL Server 2016 (13.x), o Mecanismo de Banco de Dados usa extensões uniformes para alocações em um banco de dados de usuário e em tempdb, exceto para alocações pertencentes às oito primeiras páginas de uma cadeia de IAM. As alocações nos bancos de dados master, msdb, e model ainda mantêm o comportamento anterior.

Até e incluindo o SQL Server 2014 (12.x), você pode usar o sinalizador de rastreamento (TF) 1118 para alterar a alocação padrão para sempre usar extensões uniformes. Para obter mais informações sobre esse sinalizador de rastreamento, consulte o sinalizador de rastreamento 1118.

A partir do SQL Server 2016 (13.x), o TF 1118 não tem efeito. A funcionalidade anteriormente fornecida pelo TF 1118 é habilitada automaticamente para todos os bancos de dados de usuários e para tempdb. Para bancos de dados de usuário, esse comportamento pode ser controlado pela opção do MIXED_PAGE_ALLOCATION banco de dados. O valor padrão é OFF, o que significa que extensões uniformes são usadas. Para obter mais informações, consulte Opções ALTER DATABASE SET.

A partir do SQL Server 2012 (11.x), a função do sistema sys.dm_db_database_page_allocations pode relatar informações de alocação de página para um banco de dados, uma tabela, um índice e uma partição.

A partir do SQL Server 2019 (15.x), a função do sistema sys.dm_db_page_info retorna informações sobre uma página em um banco de dados. A função retorna uma linha que contém dados de cabeçalho de página, incluindo a ID do objeto, a ID do índice e a ID da partição. Em muitos casos, essa função pode ser usada como uma alternativa com suporte para o comando sem suporte DBCC PAGE .

Páginas do sistema

Cada arquivo de dados contém um pequeno número de páginas especiais do sistema que rastreiam os metadados que descrevem extensões e páginas. Por exemplo, as páginas do sistema rastreiam quais extensões em um arquivo de dados são alocadas e a quantidade de páginas de espaço livre. Esta seção descreve essas páginas do sistema.

Páginas GAM e SGAM

O Mecanismo de Banco de Dados usa dois tipos de mapas de alocação para registrar a alocação de extensão:

• GAM (Global Allocation Map)

  As páginas GAM registram as extensões alocadas. Cada página GAM abrange um intervalo de aproximadamente 64.000 extensões ou cerca de 4 gigabytes (GiB) de dados, chamado de intervalo GAM. A página GAM tem 1 bit para cada extensão no intervalo que abrange. Se o bit for 1, a extensão será livre; se o bit for 0, a extensão será alocada.

• SGAM (Shared Global Allocation Map)

  As páginas SGAM registram quais extensões estão sendo usadas atualmente como extensões mistas e também têm pelo menos uma página não usada. Cada página do SGAM também abrange um intervalo de aproximadamente 64.000 extensões ou cerca de 4 GiB de dados. O GAM 1 um bit para cada extensão no intervalo que cobre. Se o bit for 1, a extensão será usada como uma extensão mista e terá uma página livre. Se o bit for 0, a extensão não será usada como uma extensão misturada ou será uma extensão mista em que todas as páginas são usadas.

Para resumir, cada extensão tem os seguintes padrões de bits definidos nas páginas GAM e SGAM, baseados em seu uso atual.

Para gerenciar extensões, o Mecanismo de Banco de Dados usa os seguintes algoritmos conceituais:

• Para alocar uma extensão uniforme, o Mecanismo de Banco de Dados pesquisa a página GAM por um 1 bit e o define como 0.
• Para encontrar uma extensão mista com páginas gratuitas, o Mecanismo de Banco de Dados pesquisa a página SGAM em busca de um bit 1.
• Para alocar uma extensão mista, o Mecanismo de Banco de Dados pesquisa a página GAM por um bit 1, define-o como 0, e então também define o bit correspondente na página SGAM como 1.
• Para desalocar uma extensão, o Mecanismo de Banco de Dados garante que o bit na página GAM esteja definido como 1, e o bit na página SGAM esteja definido como 0.

Alocação proporcional de preenchimento

O Mecanismo de Banco de Dados aloca extensões disponíveis no grupo de arquivos usando um algoritmo de alocação de preenchimento proporcional. Por exemplo, em um grupo de arquivos com dois arquivos, se um arquivo tiver o dobro do espaço livre do outro, duas páginas serão alocadas desse arquivo para cada página alocada do outro arquivo. Isso significa que, se as alocações continuarem, todos os arquivos em um grupo de arquivos acabarão com um percentual semelhante de espaço usado.

Para obter mais informações, consulte a estratégia de preenchimento de arquivo e grupo de arquivos.

Páginas PFS

As páginas PFS (Espaço Livre de Página) registram o status de alocação de cada página e a quantidade de espaço livre em cada página. Uma página PFS tem 1 byte para cada página que ela rastreia. O byte registra se a página está alocada e, se sim, se está vazia, 1 a 50% cheia, 51 a 80% cheia, 81 a 95% cheia ou 96 a 100% cheia.

Depois que uma extensão tiver sido alocada a um objeto, o Mecanismo de Banco de Dados usará páginas PFS para acompanhar quais páginas na extensão têm dados ou são gratuitas. Essas informações são usadas quando o Mecanismo de Banco de Dados aloca uma nova página. A quantidade de espaço livre em uma página só é mantida para páginas heap e texto/LOB. Essas informações são usadas quando o Mecanismo de Banco de Dados precisa encontrar uma página com espaço livre suficiente disponível para manter uma linha recém-inserida.

Os índices BTree não exigem controle de espaço livre de página porque o ponto no qual inserir uma nova linha é sempre determinado pelos valores de chave de índice. Se uma página em um índice BTree não tiver espaço livre suficiente, uma nova página será adicionada e aproximadamente metade dos dados originais da página será movida para a nova página.

Intervalos de GAM e PFS

Uma nova página PFS, GAM ou SGAM é adicionada no arquivo de dados para cada novo intervalo que ele rastreia.

Há uma nova página PFS 8.088 páginas após a primeira página PFS, e páginas PFS adicionais em intervalos subsequentes de 8.088 páginas. Em um arquivo de dados, a ID da página 1 é uma página do PFS, a ID da página 8088 é uma página do PFS, a ID da página 16176 é uma página PFS e assim por diante.

Da mesma forma, há um par de páginas GAM e SGAM que começam, respectivamente, nas páginas 2 e 3, e se repetem para cada intervalo GAM de cerca de 64.000 extents ou 4 GiB.

O diagrama a seguir mostra a primeira ocorrência de páginas PFS, GAM e SGAM no início de um arquivo de dados após a página de cabeçalho do arquivo. À medida que o arquivo cresce, novas páginas PFS, GAM e SGAM aparecem em seus respectivos intervalos.

Páginas IAM

Uma página IAM (Mapa de Alocação de Índice) mapeia as extensões usadas por uma unidade de alocação em um intervalo GAM. Uma unidade de alocação está associada a uma partição de um heap ou índice e pode ser de um dos três tipos:

• IN_ROW_DATA

  Contém páginas de dados não LOB ou partes de dados LOB que podem caber dentro de uma linha.

• LOB_DATA

  Contém páginas de dados LOB, usadas por tipos de dados como varchar(max), nvarchar(max), varbinary(max), xml e json.

• ROW_OVERFLOW_DATA

  Contém páginas de dados LOB usadas por tipos de dados de comprimento variável, como varchar, nvarchar, varbinary ou sql_variant quando os dados excedem o limite de tamanho da linha de 8.060 bytes.

Cada partição de um heap ou índice sempre contém pelo menos uma IN_ROW_DATA unidade de alocação. Ele também pode conter unidades de alocação LOB_DATA e ROW_OVERFLOW_DATA, dependendo dos tipos de dados e dos tamanhos de linha presentes na partição.

Semelhante a uma página GAM ou SGAM, uma página IAM abrange um intervalo de 4 GiB em um arquivo. Se a unidade de alocação contiver extensões de mais de um arquivo ou mais de um intervalo de 4 GiB de um arquivo, várias páginas IAM serão vinculadas em uma cadeia de IAM. Portanto, cada unidade de alocação possui pelo menos uma página IAM para cada arquivo no qual possui extensões de arquivo. Também pode haver mais de uma página IAM em um arquivo, se o intervalo das extensões alocadas para a unidade de alocação no arquivo exceder o intervalo que uma única página IAM pode registrar. Uma página IAM em um arquivo pode acompanhar extensões nesse arquivo e em qualquer outro arquivo do mesmo banco de dados.

Ao contrário das páginas PFS, GAM e SGAM que se repetem em intervalos fixos, as páginas IAM são alocadas conforme necessário para cada unidade de alocação. A exibição do sistema sys.system_internals_allocation_units aponta para a primeira página de IAM de uma unidade de alocação. Todas as páginas de IAM dessa unidade de alocação são vinculadas em uma cadeia de IAM.

Uma página IAM tem um cabeçalho que indica a extensão inicial do intervalo de extensões mapeadas por essa página. Uma página IAM também tem um bitmap no qual cada bit representa uma extensão. O primeiro bit no mapa representa a primeira extensão no intervalo, o segundo bit representa a segunda extensão, e assim por diante. Se um bit for 0, a extensão que ele representa não será atribuída à unidade de alocação que possui a página IAM. Se o bit for 1, a extensão que ele representa será alocada à unidade de alocação que possui página IAM.

Quando o Mecanismo de Banco de Dados precisa inserir uma nova linha e nenhum espaço está disponível na página atual, ele usa páginas IAM e PFS para encontrar uma página para alocar a linha. Para páginas de heap ou texto/LOB, ele também usa páginas IAM e PFS para encontrar uma página com espaço suficiente para armazenar a linha. O Mecanismo de Banco de Dados usa páginas IAM para localizar as extensões alocadas para a unidade de alocação. Para cada extensão, ele pesquisa as páginas do PFS para ver se há uma página que pode ser usada.

Para índices BTree, o ponto de inserção de uma nova linha é determinado pela chave de índice, mas quando uma nova página é necessária, o processo descrito anteriormente ocorre.

O Mecanismo de Banco de Dados aloca uma nova extensão a uma unidade de alocação quando não consegue localizar rapidamente uma página em uma extensão existente com espaço suficiente para manter a linha sendo inserida.

Páginas DCM e BCM

O Mecanismo de Banco de Dados usa dois tipos de páginas do sistema para acompanhar as extensões modificadas desde o último backup completo e extensões modificadas por operações de cópia em massa.

As páginas do Differential Changed Map (DCM) aceleram os backups diferenciais. O BCM (Bulk Changed Map) acelera as operações de cópia em massa quando um banco de dados está usando o modelo de recuperação bulk-logged. Como as páginas GAM e SGAM, essas estruturas são bitmaps em que cada bit representa uma única extensão.

• Páginas do DCM

  Essas páginas acompanham as extensões que foram alteradas desde o último backup completo do banco de dados. Se o bit de uma extensão for 1, a extensão foi modificada. Se o bit for 0, a extensão não foi modificada.

  Backups diferenciais leem as páginas do DCM para determinar quais extensões foram modificadas. Isso reduz o número de páginas que um backup diferencial deve ler e gravar. O período de tempo que um backup diferencial leva é proporcional ao número de extensões modificadas desde o último backup completo do banco de dados, e não ao tamanho total do banco de dados.

• Páginas BCM

  Essas páginas rastreiam as extensões que foram modificadas por operações bulk-logged desde o último backup de log de transações. Se o bit de uma extensão for 1, a extensão foi modificada. Se o bit for 0, a extensão não foi modificada.

  Embora as páginas BCM apareçam em todos os bancos de dados, elas só são relevantes quando o banco de dados está usando o modelo de recuperação com registro em massa (bulk-logged). Nesse modelo de recuperação, quando um backup de log de transações é executado, o processo de backup verifica páginas BCM em busca de extensões que foram modificadas. Ele inclui esses segmentos no backup de log para permitir a recuperação caso o banco de dados seja restaurado a partir de um backup de banco de dados e de uma sequência de backups de logs de transações.

  As páginas BCM não são relevantes em um banco de dados que está usando o modelo de recuperação simples, pois nenhuma operação de logs em massa é completamente registrada. Eles também não são relevantes em um banco de dados que está usando o modelo de recuperação completa, porque esse modelo de recuperação trata operações de log em massa como operações registradas completamente.

As páginas DCM e BCM são armazenadas nos mesmos intervalos GAM de aproximadamente 4 GiB que as páginas GAM e SGAM. As páginas DCM e BCM seguem as páginas GAM e SGAM em um arquivo físico da seguinte maneira:

Conteúdo relacionado

• Fundamentos de E/S do SQL Server
• sys.allocation_units (Transact-SQL)
• Heaps (tabelas sem índices clusterizados)
• sys.dm_db_page_info (Transact-SQL)
• Ler páginas de dados no Mecanismo de Banco de Dados
• Escrever páginas no Mecanismo de Banco de Dados