Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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
A página é a unidade fundamental de armazenamento de dados no SQL Server. Uma extensão é uma coleção de oito páginas fisicamente contíguas. As extensões ajudam a gerenciar páginas de forma eficiente. Este guia descreve as estruturas de dados usadas para gerenciar páginas e extensões em todas as versões do SQL Server. Compreender a arquitetura de páginas e extensões é importante para projetar e desenvolver bancos de dados com desempenho eficiente.
Páginas e extensões
A unidade fundamental de armazenamento de dados no SQL Server é a página. 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 E/S de disco são executadas no nível da página. Ou seja, o SQL Server lê ou grava páginas de dados inteiras.
As extensões são uma coleção de oito páginas fisicamente contíguas e são usadas para gerenciar eficientemente as páginas. Todas as páginas estão organizadas em extensões.
Páginas
Num livro normal, todo o conteúdo é escrito em páginas. Semelhante a um livro, o SQL Server grava todas as linhas de dados em páginas e todas as páginas de dados têm o mesmo tamanho: 8 KB. Num livro, a maioria das páginas contém os dados - o conteúdo principal do livro - e algumas páginas contêm metadados sobre o conteúdo (por exemplo, o índice e o índice). Novamente, o SQL Server não é diferente: a maioria das páginas contém linhas reais de dados que foram armazenados pelos usuários; estas são chamadas páginas de dados e páginas de texto/imagem (para casos especiais). As páginas de índice contêm referências de índice sobre onde os dados estão. Finalmente, existem páginas do sistema que armazenam vários metadados sobre a organização dos dados.
Cada página começa com um cabeçalho de 96 bytes que é usado para armazenar informações do sistema sobre a página. Essas informações incluem o número da página, o tipo de página, a quantidade de espaço livre na página e o ID da unidade de alocação do objeto proprietário da página.
A tabela a seguir mostra os tipos de página usados nos arquivos de dados de um banco de dados do SQL Server.
| Tipo de página | Conteúdos |
|---|---|
| Data | Linhas de dados com todos os dados, exceto texto, ntext, image, nvarchar(max), varchar(max), varbinary(max) e dados xml , quando o texto na linha é definido como ON. |
| Index | Entradas de índice. |
| Texto/imagem | Tipos de dados de objetos grandes: text, ntext, image, nvarchar(max), varchar(max), varbinary(max) e dados xml . Colunas de comprimento variável quando a linha de dados excede 8 KB: varchar, nvarchar, varbinary e sql_variant. |
| Mapa de Alocação Global (GAM) Mapa de Alocação Global Compartilhada (SGAM) |
Informações sobre se as extensões são alocadas. |
| Espaço Livre de Página (PFS) | Informações sobre alocação de páginas e espaço livre disponível nas páginas. |
| Mapa de Alocação de Índice (IAM) | Informações sobre as extensões utilizadas por um quadro ou índice por unidade de atribuição. |
| Mapa alterado em massa (BCM) | Informações sobre extensões modificadas por operações em massa desde o último BACKUP LOG demonstrativo por unidade de alocação. |
| Mapa Alterado Diferencial (DCM) | Informações sobre extensões que mudaram desde a última BACKUP DATABASE declaração por unidade de alocação. |
Observação
Os ficheiros de registo não contêm páginas. Eles contêm uma série de registros de log que não têm um tamanho fixo.
As linhas de dados são armazenadas na página em série, começando imediatamente após o cabeçalho. Uma tabela de deslocamento de linha começa no final da página e cada tabela de deslocamento de linha contém uma entrada para cada linha na página. Cada entrada de deslocamento de linha armazena a distância entre o primeiro byte da linha e o início da página. Assim, a função da tabela de deslocamento de linha é ajudar o SQL Server a localizar linhas em uma página rapidamente. As entradas na tabela de deslocamento de linha estão em sequência inversa da sequência das linhas na página.
Suporte de linha grande
As linhas não podem abranger páginas; no entanto, partes da linha podem ser movidas para fora da página da linha, de modo que a linha pode ser muito grande. A quantidade máxima de dados e sobrecarga contida em uma única linha em uma página é de 8.060 bytes. Isso não inclui os dados armazenados no tipo de página de texto/imagem.
Esta restrição é relaxada para tabelas que contêm colunas varchar, nvarchar, varbinary, ousql_variant . Quando o tamanho total da linha de todas as colunas fixas e variáveis em uma tabela excede a limitação de 8.060 bytes, o SQL Server move dinamicamente uma ou mais colunas de comprimento variável para páginas na unidade de alocação ROW_OVERFLOW_DATA, começando com a coluna com a 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 na unidade de alocação ROW_OVERFLOW_DATA, um ponteiro de 24 bytes na página original na unidade de alocação IN_ROW_DATA é mantido. Se uma operação subsequente reduzir o tamanho da linha, o SQL Server moverá dinamicamente as colunas de volta para a página de dados original.
Considerações sobre estouro de linha
Uma linha não pode residir em várias páginas e pode estourar se o tamanho combinado de campos de tipo de dados de comprimento variável exceder o limite de 8060 bytes. Para ilustrar, uma tabela pode ser criada com duas colunas: uma varchar (7000) e outra varchar (2000). Individualmente, nenhuma coluna excede 8060 bytes, mas combinadas podem fazê-lo se toda a largura de cada coluna for preenchida. O SQL Server pode mover dinamicamente a coluna de comprimento da variável varchar(7000) para páginas na unidade de alocação ROW_OVERFLOW_DATA. Ao combinar varchar, nvarchar, varbinary, ousql_variant, ou colunas de tipo definidas pelo usuário CLR que excedam 8.060 bytes por linha, considere o seguinte:
Mover registros grandes para outra página ocorre dinamicamente à medida que os registros são alongados com base em operações de atualização. As operações de atualização que encurtam os registros podem fazer com que os registros sejam movidos de volta para a página original na unidade de alocação de IN_ROW_DATA.
Consultar e executar outras operações de seleção, como classificações ou junções em registros grandes que contêm dados de estouro de linha, diminui o tempo de processamento, porque esses registros são processados de forma síncrona em vez de assíncrona.
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. Se for provável que haja consultas frequentes em muitas linhas de dados de estouro de linha, considere normalizar a tabela para que algumas colunas sejam movidas para outra tabela. Isso pode ser consultado em uma operação assíncrona
JOIN.O comprimento de colunas individuais ainda deve estar dentro do limite de 8.000 bytes para colunas de tipo definido pelo usuário varchar, nvarchar, varbinary ou sql_variant e CLR. Apenas seus comprimentos combinados podem exceder o limite de linha de 8.060 bytes de uma tabela.
A soma de outras colunas de tipo de dados, incluindo dados char e nchar , deve estar dentro do limite de linha de 8.060 bytes. Os dados de objetos grandes também estão isentos do limite de linha de 8.060 bytes.
A chave de índice de um índice clusterizado não pode conter colunas varchar que tenham dados existentes na unidade de alocação ROW_OVERFLOW_DATA. Se um índice clusterizado for criado em uma coluna varchar e os dados existentes estiverem na unidade de alocação IN_ROW_DATA, as ações subsequentes de inserção ou atualização na coluna que empurrariam os dados para fora da linha falharão. Para obter mais informações sobre unidades de alocação, consulte SQL Server e Azure SQL index architecture and design guide.
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 registro para tabelas que usam colunas esparsas é de 8.018 bytes. Quando os dados convertidos mais os dados de registro existentes excedem 8.018 bytes, MSSQLSERVER ERROR 576 é retornado. Quando as colunas são convertidas entre tipos esparsos e não esparsos, o Mecanismo de Banco de Dados mantém uma cópia dos dados de registro atuais. Isso dobra temporariamente o armazenamento necessário para o registro.
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 .
Extensões
As extensões são a unidade básica na qual o espaço é gerido. Uma extensão é de oito páginas fisicamente contíguas, ou 64 KB. Isso significa que os bancos de dados do SQL Server têm 16 extensões por megabyte.
O SQL Server tem dois tipos de extensões:
- Extensões uniformes são de propriedade de um único objeto; 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 o SQL Server 2014 (12.x), o Mecanismo de Banco de Dados não aloca extensões inteiras para tabelas com pequenas quantidades de dados. Uma nova tabela ou índice geralmente aloca páginas de extensões mistas. Quando a tabela ou índice cresce a ponto de ter oito páginas, ele muda para usar extensões uniformes para 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 padrão para a maioria das alocações em um banco de dados de usuários é tempdb usar extensões uniformes, exceto para alocações pertencentes às primeiras oito páginas de uma cadeia do IAM. As alocações para master, msdbe bancos model de dados ainda mantêm o comportamento anterior.
Observação
No SQL Server, 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 sinalizador de rastreamento 1118.
A partir do SQL Server 2016 (13.x), a funcionalidade fornecida pelo TF 1118 é habilitada automaticamente para tempdb todos os bancos de dados de usuários. Para bancos de dados de usuário, esse comportamento é controlado pela SET MIXED_PAGE_ALLOCATION opção de ALTER DATABASE, com o valor padrão definido como OFF, e TF 1118 não tem efeito. 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.
Importante
A sys.dm_db_database_page_allocations função do sistema não está documentada e está sujeita a alterações. A compatibilidade não é garantida.
A partir do SQL Server 2019 (15.x), a função de sistema sys.dm_db_page_info está disponível e retorna informações sobre uma página em um banco de dados. A função retorna uma linha que contém as informações de cabeçalho da página, incluindo , object_idindex_ide partition_id. Esta função substitui a necessidade de uso DBCC PAGE na maioria dos casos.
Gerencie alocações de extensão e espaço livre
As estruturas de dados do SQL Server que gerenciam alocações de extensão e controlam o espaço livre têm uma estrutura relativamente simples. Isto tem as seguintes vantagens:
As informações de espaço livre são densamente embaladas, portanto, relativamente poucas páginas contêm essas informações.
Isso aumenta a velocidade, reduzindo o número de leituras de disco necessárias para recuperar informações de alocação. Isso também aumenta a chance de que as páginas de alocação permaneçam na memória e não exijam mais leituras.
A maioria das informações de alocação não está encadeada. Isso simplifica a manutenção das informações de alocação.
Cada alocação ou desalocação de página pode ser realizada rapidamente. Isso diminui a contenção entre tarefas simultâneas que precisam alocar ou desalocar páginas.
Gerenciar alocações de extensão
O SQL Server usa dois tipos de mapas de alocação para registrar a alocação de extensões:
Mapa de Alocação Global (GAM)
As páginas GAM registam as extensões que foram atribuídas. Cada GAM cobre 64.000 extensões, ou quase 4 gigabytes (GB) de dados. O 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 SGAM cobre 64.000 extensões, ou quase 4 GB 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 for0, a extensão não é usada como uma extensão mista, ou é uma extensão mista e todas as suas páginas estão sendo usadas.
Cada extensão tem os seguintes padrões de bits definidos no GAM e SGAM, com base em seu uso atual.
| Utilização atual da extensão | Configuração de bits GAM | Configuração de bits SGAM |
|---|---|---|
| Gratuito, não está a ser utilizado | 1 | 0 |
| Extensão uniforme ou extensão total mista | 0 | 0 |
| Extensão mista com páginas gratuitas | 0 | 1 |
Isso causa algoritmos simples de gerenciamento de extensão.
- Para alocar uma extensão uniforme, o Mecanismo de Banco de Dados pesquisa um
1pouco no GAM e o define como0. - Para encontrar uma extensão mista com páginas livres, o Mecanismo de Banco de Dados pesquisa um pouco o SGAM
1. - Para alocar uma extensão mista, o Mecanismo de Banco de Dados procura um
1bit no GAM, define-o como0e, em seguida, também define o bit correspondente no SGAM como1. - Para desalocar uma extensão, o Mecanismo de Banco de Dados garante que o bit GAM esteja definido como
1, e o bit SGAM esteja definido como0.
Os algoritmos usados internamente pelo Mecanismo de Banco de Dados são mais sofisticados do que os descritos neste artigo, porque o Mecanismo de Banco de Dados distribui dados uniformemente em um banco de dados. No entanto, mesmo os algoritmos reais são simplificados por não ter que gerenciar cadeias de informações de alocação de extensão.
Rastreie o espaço livre
As páginas de Espaço Livre de Página (PFS) registram o status de alocação de cada página, se uma página individual foi alocada e a quantidade de espaço livre em cada página. O PFS tem 1 byte para cada página, registrando se a página está alocada e, em caso afirmativo, 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 é alocada a um objeto, o Mecanismo de Banco de Dados usa as páginas PFS para registrar quais páginas na extensão são alocadas ou livres. Essas informações são usadas quando o Mecanismo de Banco de Dados precisa alocar uma nova página. A quantidade de espaço livre em uma página é mantida apenas para páginas de pilha e texto/imagem. Ele é usado quando o Mecanismo de Banco de Dados precisa encontrar uma página com espaço livre disponível para manter uma linha recém-inserida. Os índices não exigem que o espaço livre da página seja controlado, porque o ponto no qual inserir uma nova linha é definido pelos valores da chave de índice.
Uma nova página PFS, GAM ou SGAM é adicionada no arquivo de dados para cada intervalo adicional que ele acompanha. Assim, 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. Para ilustrar, a página ID 1 é uma página PFS, a página ID 8088 é uma página PFS, a página ID 16176 é uma página PFS e assim por diante.
Há uma nova página GAM de 64.000 extensões após a primeira página GAM e ela acompanha as 64.000 extensões que a seguem; A sequência continua em intervalos de 64.000 graus. Da mesma forma, há uma nova página SGAM 64.000 extensões após a primeira página SGAM e páginas SGAM adicionais em intervalos subsequentes de 64.000 extensões.
A ilustração a seguir mostra a sequência de páginas usadas pelo Mecanismo de Banco de Dados para alocar e gerenciar extensões.
Gerenciar o espaço usado pelos objetos
Uma página do Mapa de Alocação de Índice (IAM) mapeia as extensões em uma parte de 4 GB de um arquivo de banco de dados usado por uma unidade de alocação. Uma unidade de atribuição é um dos três tipos:
IN_ROW_DATA
Contém uma partição de uma pilha ou índice.
LOB_DATA
Contém tipos de dados de objeto grande (LOB), como xml, varbinary(max) e varchar(max).
ROW_OVERFLOW_DATA
Contém dados de comprimento variável armazenados em colunas varchar, nvarchar, varbinary ou sql_variant que excedem o limite de tamanho de linha de 8.060 bytes.
Cada partição de uma pilha ou índice contém pelo menos uma unidade de alocação IN_ROW_DATA. Ele também pode conter uma unidade de alocação LOB_DATA ou ROW_OVERFLOW_DATA, dependendo do esquema de heap ou índice.
Uma página do IAM cobre um intervalo de 4 GB em um arquivo e é a mesma cobertura de uma página GAM ou SGAM. Se a unidade de alocação contiver extensões de mais de um arquivo ou mais de um intervalo de 4 GB de um arquivo, haverá várias páginas do IAM vinculadas em uma cadeia do IAM. Portanto, cada unidade de alocação tem pelo menos uma página do IAM para cada arquivo no qual tem extensões. Também pode haver mais de uma página do IAM em um arquivo, se o intervalo das extensões no arquivo alocado à unidade de alocação exceder o intervalo que uma única página do IAM pode registrar.
As páginas do IAM são alocadas conforme necessário para cada unidade de alocação e são localizadas aleatoriamente no arquivo. 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.
Importante
A sys.system_internals_allocation_units visualização do sistema é apenas para uso interno e está sujeita a alterações. A compatibilidade não é garantida. Esta vista não está disponível na Base de Dados SQL do Azure.
Uma página do IAM tem um cabeçalho que indica a extensão inicial do intervalo de extensões mapeado pela página do IAM. A página do IAM também tem um bitmap grande 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á alocada para a unidade de alocação proprietária do 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 Mecanismo de Banco de Dados precisa inserir uma nova linha e nenhum espaço está disponível na página atual, ele usa as páginas do IAM e do PFS para localizar uma página para alocar ou, para uma pilha ou uma página de texto/imagem, uma página com espaço suficiente para manter a linha. O Mecanismo de Banco de Dados usa as páginas do IAM para localizar as extensões alocadas à unidade de alocação. Para cada extensão, o Mecanismo de Banco de Dados pesquisa as páginas PFS para ver se há uma página que pode ser usada. Cada página do IAM e do PFS abrange muitas páginas de dados, portanto, há poucas páginas do IAM e do PFS em um banco de dados. Isso significa que as páginas do IAM e do PFS geralmente estão na memória no pool de buffers do SQL Server, para que possam ser pesquisadas rapidamente. Para índices, o ponto de inserção de uma nova linha é definido pela chave de índice, mas quando uma nova página é necessária, ocorre o processo descrito anteriormente.
O Mecanismo de Banco de Dados aloca uma nova extensão a uma unidade de alocação somente quando não consegue encontrar rapidamente uma página em uma extensão existente com espaço suficiente para manter a linha que está sendo inserida.
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 . No mesmo grupo de arquivos com dois arquivos, se um arquivo tiver o dobro do espaço livre que o outro, duas páginas serão alocadas do arquivo com o espaço disponível para cada página alocada do outro arquivo. Isso significa que cada arquivo em um grupo de arquivos deve ter uma porcentagem semelhante de espaço usado.
Rastrear extensões modificadas
O SQL Server usa duas estruturas de dados internas para controlar extensões modificadas por operações de cópia em massa e extensões modificadas desde o último backup completo. Essas estruturas de dados aceleram muito os backups diferenciais. Eles também aceleram o registro em log de 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.
Mapa Alterado Diferencial (DCM)
Isso acompanha as extensões que mudaram desde a última
BACKUP DATABASEdeclaração. Se o bit para uma extensão for1, a extensão foi modificada desde a últimaBACKUP DATABASEinstrução. Se o bit for0, a extensão não foi modificada.Os backups diferenciais leem apenas as páginas do DCM para determinar quais extensões foram modificadas. Isso reduz consideravelmente o número de páginas que um backup diferencial deve verificar. O período de tempo em que um backup diferencial é executado é proporcional ao número de extensões modificadas desde a última
BACKUP DATABASEinstrução e não ao tamanho geral do banco de dados.Mapa alterado em massa (BCM)
Isso rastreia as extensões que foram modificadas por operações bulk-logged desde a última
BACKUP LOGinstrução. Se o bit para uma extensão for1, a extensão foi modificada por uma operação bulk-logged após a últimaBACKUP LOGinstrução. Se o bit for0, a extensão não foi modificada por operações bulk-logged.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 bulk-logged. Nesse modelo de recuperação, quando um
BACKUP LOGé executado, o processo de backup verifica os BCMs em busca de extensões que foram modificadas. Em seguida, inclui essas extensões no backup de log. Isso recupera as operações bulk-logged se o banco de dados for restaurado a partir de um backup de banco de dados e uma sequência de backups de log 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, porque nenhuma operação bulk-logged é registrada. Eles 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 as operações bulk-logged como operações totalmente registradas.
O intervalo entre as páginas DCM e BCM é o mesmo que o intervalo entre as páginas GAM e SGAM, 64.000 extensões. As páginas DCM e BCM estão localizadas atrás das páginas GAM e SGAM em um arquivo físico da seguinte maneira:
