Guia de arquitetura de páginas e extensões

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

Este guia descreve a estrutura das páginas e extensões, bem como a organização das páginas e extensões dentro dos ficheiros de dados.

Uma página é uma unidade fundamental de armazenamento de dados no Motor de Base de Dados. O espaço em disco alocado para um arquivo de dados (.mdf ou .ndf) em um banco de dados é logicamente dividido em páginas numeradas contíguamente de 0 a n. As operações de I/O do disco contra ficheiros de dados são realizadas ao nível da página. Ou seja, o Motor de Base de Dados lê ou escreve páginas de dados inteiras.

Uma extensão é uma coletânea de oito páginas fisicamente contíguas, usadas para gerir as páginas de forma eficiente. Cada página pertence a uma extensão.

Os ficheiros de registo 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

Num livro normal, todo o conteúdo é escrito em páginas. Semelhante a um livro, o Motor de Base de Dados escreve todas as linhas de dados nas páginas. O tamanho de cada página é o mesmo: 8 KiB. Num 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.

De forma semelhante, a maioria das páginas na base de dados contém linhas reais de dados. Estas são chamadas páginas de dados. As páginas de texto/LOB também contêm dados, mas são usadas apenas por tipos de dados de objetos grandes (LOB). As páginas de índice contêm estruturas de índice que ajudam a encontrar dados de forma eficiente. Finalmente, uma variedade de páginas do sistema armazena os metadados que descrevem a organização e as propriedades dos dados.

A tabela seguinte descreve os tipos de página.

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

Uma estrutura chamada slot array é armazenada no final da página. Cada elemento de 2 bytes no array de slots corresponde a uma linha armazenada na página. Um elemento de slot array armazena o deslocamento em bytes da linha em relação ao início da página. O Motor de Base de Dados utiliza estes deslocamentos para localizar linhas numa página.

Quando o Motor de Base de Dados adiciona uma linha a uma página vazia, armazena a linha imediatamente após o cabeçalho. O elemento do slot array 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 fim da página, enquanto o array de slots cresce do final ao início da página, como mostrado no diagrama seguinte.

À medida que as linhas de uma página são eliminadas ou atualizadas ao longo do tempo, pode surgir espaço livre entre as linhas restantes. Quando uma nova linha é adicionada, pode ser armazenada neste espaço livre, se o espaço for suficiente. Isto significa que as linhas numa página podem não estar fisicamente armazenadas numa ordem específica. No entanto, o Motor de Base de Dados mantém as entradas do array de slots numa ordem lógica. Como resultado, as linhas de uma página também são acessadas por ordem lógica, por exemplo, na ordem definida pela chave do índice BTree que detém a página.

Suporte de linha grande

Para suportar linhas grandes que não cabem numa única página, a parte da linha que não encaixa pode ser armazenada noutras páginas. O tamanho máximo dos dados e da sobrecarga que pode ser contida numa única linha numa página é de 8.060 bytes.

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

A restrição de 8.060 bytes é flexibilizada para tabelas e índices que contêm colunas de comprimento variável usando os tipos de dados definidos pelo utilizador varchar, nvarchar, varbinary, sql_variant ou CLR. Quando o tamanho total das linhas de todas as colunas de comprimento fixo e variável num heap ou índice ultrapassa a limitação de 8.060 bytes, o Mecanismo de Base de Dados move dinamicamente uma ou mais colunas de comprimento variável para páginas numa ROW_OVERFLOW_DATA unidade de alocação, iniciando pela coluna mais extensa.

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 numa ROW_OVERFLOW_DATA unidade de alocação, mantém-se um ponteiro de 24 bytes na página original numa IN_ROW_DATA unidade de alocação. Se uma operação subsequente reduzir o tamanho da linha, o Motor de Base de Dados move dinamicamente as colunas de volta para a página original de dados.

Por exemplo, uma tabela pode ser criada com duas colunas: uma varchar(7000) e outra varchar(2000). Individualmente, nenhuma das colunas ultrapassa os 8.060 bytes, mas em conjunto fariam isso se toda a largura de cada coluna fosse preenchida. Se isto acontecer, o Motor de Base de Dados move dinamicamente a coluna varchar(7000) de comprimento variável da página original para as páginas numa ROW_OVERFLOW_DATA unidade de alocação.

Quando uma tabela ou um índice tem colunas de tipo varchar, nvarchar, varbinary, sql_variant ou CLR definidas pelo utilizador 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. Operações de atualização que encurtam linhas podem fazer com que sejam movidas de volta para a página original numa IN_ROW_DATA unidade de alocação.

  Este movimento de dados resulta em Entrada/Saída (E/S) extra do disco. Operações de processamento de consultas, como ordenações ou junções em registos grandes que contenham dados de sobrecarga de linhas, podem ser mais lentas.

  Portanto, ao desenhar uma tabela com múltiplas colunas de tipo varchar, nvarchar, varbinary, sql_variant ou CLR definidas pelo utilizador, considere a percentagem de linhas que provavelmente irão fluir e a frequência com que esses dados de overflow provavelmente serão consultados. Para evitar um desempenho mais lento, normalize a tabela para mover algumas destas colunas para outra tabela e assim reduzir ou eliminar a probabilidade de usar armazenamento por linhas de sobrecarga.

• O comprimento das colunas individuais deve ainda estar dentro do limite de 8.000 bytes para colunas de tipo varchar, nvarchar, varbinary, sql_variant e CLR definidas pelo utilizador. Apenas seus comprimentos combinados podem exceder o limite de linha de 8.060 bytes de uma tabela.

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

• A chave de índice de um índice agrupado não pode conter colunas varchar que tenham dados numa ROW_OVERFLOW_DATA unidade de alocação. Se um índice clusterizado for criado numa coluna varchar e todos os dados existentes estiverem numa IN_ROW_DATA unidade de alocação, mas uma instrução subsequente INSERT ou UPDATE empurrar os dados fora de linha, a instrução falha. Para mais informações, consulte o guia de arquitetura e design do Índice.

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

• O limite de tamanho de linha para tabelas que usam colunas esparsas é de 8.018 bytes. Durante a conversão entre colunas esparsas e não esparsas, quando os dados convertidos mais os dados existentes ultrapassam os 8.018 bytes, é devolvido o erro 576 . Quando as colunas são convertidas entre tipos esparsos e não esparsos, o Motor de Base de Dados mantém uma cópia dos dados da linha atual. Isto duplica o armazenamento necessário para a linha de dados temporariamente.

• 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 tem dados de overflow de linhas se a função devolver linhas onde a coluna alloc_unit_type_desc é ROW_OVERFLOW_DATA e a coluna page_count é maior que 0.

Extensões

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

Existem 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 são compartilhadas por até oito objetos. Cada uma das oito páginas na extensão pode ser propriedade de um objeto diferente.

Até, e incluindo, SQL Server 2014 (12.x), o Motor de Base de Dados não aloca extensões uniformes a tabelas com pequenas quantidades de dados. Um novo heap ou índice aloca páginas a partir de extensões mistas. Quando o heap ou índice cresce ao ponto de usar oito páginas, muda então para extensões uniformes para todas as alocações subsequentes. Se você criar um índice em uma tabela existente que tenha linhas suficientes para gerar oito páginas no índice, todas as alocações ao índice serão em extensões uniformes.

A partir do SQL Server 2016 (13.x), o Motor de Base de Dados utiliza extensões uniformes para alocações numa base de dados de utilizador e em tempdb, exceto para alocações pertencentes às primeiras oito páginas de uma cadeia IAM. As alocações nas bases de dados master, msdb e model ainda mantêm o comportamento anterior.

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

A partir do SQL Server 2016 (13.x), o TF 1118 não tem qualquer efeito. A funcionalidade fornecida anteriormente pela TF 1118 é automaticamente ativada para todas as bases de dados de utilizadores e para tempdb. Para bases de dados de utilizadores, este comportamento pode ser controlado pela opção de MIXED_PAGE_ALLOCATION base de dados. O valor padrão é OFF, o que significa que são usadas extensões uniformes. Para obter mais informações, consulte opções ALTER DATABASE SET.

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

A partir do SQL Server 2019 (15.x), a função sys.dm_db_page_info sistema devolve informação sobre uma página numa base de dados. A função devolve uma linha que contém dados do cabeçalho da página, incluindo o ID do objeto, o ID do índice e o ID da partição. Em muitos casos, esta função pode ser usada como alternativa suportada ao comando não suportado DBCC PAGE .

Páginas do sistema

Cada ficheiro de dados contém um pequeno número de páginas especiais do sistema que acompanham os metadados que descrevem extensões e páginas. Por exemplo, as páginas do sistema acompanham quais as extensões num ficheiro de dados que são alocadas e quanto espaço livre as páginas têm. Esta secção descreve estas páginas do sistema.

Páginas GAM e SGAM

O Motor de Base de Dados utiliza dois tipos de mapas de alocação para registar a alocação de extensão:

• Mapa de Alocação Global (GAM)

  As páginas GAM registam as extensões atribuídas. Cada página GAM cobre um intervalo de aproximadamente 64.000 extensões, ou cerca de 4 gigabytes (GiB) de dados, chamado intervalo GAM. A página GAM tem 1 bit para cada extensão no intervalo que cobre. Se o bit é 1, a extensão é livre, se o bit é 0, a extensão é alocada.

• Mapa de Alocação Global Compartilhada (SGAM)

  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 utilizada. Cada página SGAM também cobre um intervalo de aproximadamente 64.000 extensões, ou cerca de 4 GiB de dados. O SGAM tem 1 bit para cada extensão no intervalo que cobre. Se o bit é 1, a extensão está sendo usada como uma extensão mista e tem uma página livre. Se o bit for 0, a extensão não é utilizada como uma extensão mista ou é uma extensão mista em que todas as páginas são utilizadas.

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

Para gerir extensões, o Motor de Base de Dados utiliza os seguintes algoritmos conceptuais:

• Para alocar uma extensão uniforme, o Motor de Base de Dados pesquisa a página GAM para um bit 1 e altera-o para 0.
• Para encontrar uma extensão mista com páginas gratuitas, o Motor de Base de Dados pesquisa a página SGAM em busca de um bit 1.
• Para alocar uma extensão mista, o Motor de Base de Dados pesquisa a página GAM por um 1 bit, define-o para 0, e depois também define o bit correspondente na página SGAM para 1.
• Para desalocar uma extensão, o Motor de Base de Dados certifica-se de que o bit na página GAM está definido como 1, e o bit na página SGAM está definido como 0.

Alocação proporcional de preenchimento

O Mecanismo de Banco de Dados aloca extensões daquelas disponíveis no grupo de arquivos usando um algoritmo de alocação de preenchimento proporcional . Por exemplo, num grupo de ficheiros com dois ficheiros, se um ficheiro tiver o dobro do espaço livre do outro, são alocadas duas páginas desse ficheiro para cada página alocada do outro ficheiro. Isto significa que, se as alocações continuarem, todos os ficheiros de um grupo de ficheiros acabam com percentagem semelhante de espaço utilizado.

Para mais informações, consulte Estratégia de preenchimento de ficheiros e grupos de ficheiros.

Páginas do PFS

As páginas de Espaço Livre de Página (PFS) registam o estado 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 acompanha. O byte regista se a página está alocada e, em caso afirmativo, se está vazia, entre 1 e 50 por cento cheia, entre 51 e 80 por cento cheia, entre 81 e 95 por cento cheia, ou entre 96 e 100 por cento cheia.

Depois de uma extensão ter sido atribuída a um objeto, o Motor de Base de Dados utiliza páginas PFS para rastrear quais as páginas dessa extensão que têm dados ou são livres. Esta informação é usada quando o Motor de Base de Dados aloca uma nova página. A quantidade de espaço livre numa página é mantida apenas para páginas do tipo heap e de texto/LOB. Esta informação é usada quando o Motor de Base de Dados tem de encontrar uma página com espaço livre suficiente para guardar uma linha recém-inserida.

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

Intervalos GAM e PFS

Uma nova página PFS, GAM ou SGAM é adicionada no ficheiro de dados para cada intervalo adicional que regista.

Existe uma nova página PFS a 8.088 páginas após a primeira página PFS, e páginas PFS adicionais em intervalos subsequentes de 8.088 páginas. Num ficheiro de dados, o ID de página 1 é uma página PFS, o ID de página 8088 é uma página PFS, o ID de página 16176 é uma página PFS, e assim sucessivamente.

De forma semelhante, há um par de páginas GAM e SGAM que começam nas páginas 2 e 3, respetivamente, e que se repetem para cada intervalo GAM de cerca de 64.000 extensões ou 4 GiB.

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

Páginas IAM

Uma página Mapa de Alocação de Índice (IAM) mapeia as extensões utilizadas 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 três tipos:

• IN_ROW_DATA

  Contém páginas de dados não-LOB, ou partes de dados LOB que possam caber em linhas.

• 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

  Manté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 linha de 8.060 bytes.

Cada partição de um heap ou índice contém sempre pelo menos uma IN_ROW_DATA unidade de alocação. Também pode conter unidades de alocação LOB_DATA e ROW_OVERFLOW_DATA, dependendo dos tipos de dados e do tamanho das linhas presentes na partição.

Semelhante a uma página GAM ou SGAM, uma página IAM cobre um intervalo de 4 GiB num ficheiro. Se a unidade de alocação contiver extensões de mais do que um ficheiro, ou mais de um intervalo de 4 GiB de um ficheiro, múltiplas páginas IAM estão ligadas numa cadeia IAM. Portanto, cada unidade de alocação tem pelo menos uma página IAM para cada ficheiro onde possui extensões. Também pode haver mais do que uma página IAM num ficheiro, se o intervalo das extensões alocadas à unidade de alocação no ficheiro exceder o intervalo que uma única página IAM pode registar. Uma página IAM num ficheiro pode rastrear extensões nesse ficheiro e em qualquer outro ficheiro da mesma base de dados.

Ao contrário das páginas PFS, GAM e SGAM que se repetem a intervalos fixos, as páginas IAM são atribuídas conforme necessário para cada unidade de alocação. A sys.system_internals_allocation_units visualização do sistema aponta para a primeira página do IAM para uma unidade de alocação. Todas as páginas do IAM para essa unidade de alocação estão vinculadas em uma cadeia do 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 em que 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 é 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 para a unidade de alocação proprietária da página do IAM.

Quando o Motor de Base de Dados tem de inserir uma nova linha e não há espaço disponível na página atual, utiliza páginas IAM e PFS para encontrar uma página para alocar a linha. Para as páginas de heap ou texto/LOB, utiliza da mesma maneira as páginas IAM e PFS para localizar uma página com espaço suficiente para armazenar a linha. O Motor de Base de Dados utiliza páginas IAM para encontrar as extensões atribuídas à unidade de alocação. Para cada extensão, pesquisa nas páginas do PFS para ver se há uma página que possa ser usada.

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

O Motor de Base de Dados atribui uma nova extensão a uma unidade de alocação quando não consegue encontrar rapidamente uma página numa extensão existente com espaço suficiente para armazenar a linha a ser inserida.

Páginas DCM e BCM

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

As páginas Differential Changed Map (DCM) aceleram as cópias de segurança diferenciais. O Bulk Changed Map (BCM) acelera as operações de cópia em massa quando uma base de dados utiliza o modelo de recuperação com registo em massa. Como as páginas GAM e SGAM, essas estruturas são bitmaps em que cada bit representa uma única extensão.

• Páginas DCM

  Estas páginas acompanham as extensões que mudaram desde a última cópia de segurança completa da base de dados. Se o bit para um extent for 1, o extent foi modificado. Se o bit for 0, a extensão não foi modificada.

  Backups diferenciais leem as páginas DCM para determinar quais as extensões que foram modificadas. Isto reduz o número de páginas que um backup diferencial tem de ler e escrever. O tempo que um backup diferencial demora é proporcional ao número de extensões modificadas desde o último backup completo da base de dados, e não ao tamanho total da base de dados.

• Páginas BCM

  Estas páginas acompanham as extensões que foram modificadas por operações de registo em massa desde o último backup do log de transações. Se o bit de uma extensão for 1, a extensão terá sido modificada. Se o bit for 0, a extensão não foi modificada.

  Embora as páginas BCM apareçam em todas as bases de dados, só são relevantes quando a base de dados utiliza o modelo de recuperação logada em massa. Neste modelo de recuperação, quando é realizada uma cópia de segurança do registo de transações, o processo de backup analisa as páginas BCM à procura de extensões que foram modificadas. Inclui essas extensões no backup dos registos para permitir a recuperação caso a base de dados seja restaurada a partir de uma cópia de segurança da base de dados e de uma sequência de backups dos registos de transações.

  As páginas BCM não são relevantes numa base de dados que utiliza o modelo de recuperação simples, porque nenhuma operação em bloco está totalmente registada. Também não são relevantes numa base de dados que utiliza o modelo de recuperação completo, porque esse modelo de recuperação trata as operações em bloco registadas como operações totalmente registadas.

As páginas DCM e BCM são armazenadas nos mesmos intervalos GAM de aproximadamente 4 GiB que as páginas GAM e SGAM, respectivamente. As páginas DCM e BCM seguem as páginas GAM e SGAM num ficheiro físico da seguinte forma:

Conteúdo relacionado

• Fundamentos de E/S do SQL Server
• sys.allocation_units (Transact-SQL)
• Pilhas (tabelas sem índices agrupados)
• 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