[Resolvido] Pages e Extents

[J4P0N315 0]

Bom dia a todos,

 

Estou fazendo um curso voltado para iniciantes chamado "Administrando e Armazenando Dados no SQL Server", e neste, logo no início, são abordados assuntos sobre Pages e Extents.

 

Na prática (pelo menos até agora) eu apenas mexo em banco de dados, tabelas, relacionamentos e etc. Nunca vi nada sobre pages e extents.

 

Gostaria de saber se, na prática, eu mexerei nessas pages e extents ou se são somente conteúdo teórico.

 

Desde já, agradeço a atenção de vocês.

[advaldomesquita 93]

J4P0N315,

 

ha tu vai ver isso sim!

Ao menos quando tiver lidando com questões de performance. Você conseguiu entender o que sao Pages e Extents? Muita gente tem dificuldade de entender, mas um otimo exemplo é o do livro. :lol:

 

 

[J4P0N315 0]

J4P0N315,

 

ha tu vai ver isso sim!

Ao menos quando tiver lidando com questões de performance. Você conseguiu entender o que sao Pages e Extents? Muita gente tem dificuldade de entender, mas um otimo exemplo é o do livro. :lol:

 

Olá, amigo.

Muito obrigado pela resposta.

 

Então...

Na verdade, também não entendi muito bem. Só sei que uma extent é um conjunto de 8 pages e que existem muitos tipos de pages. Cada page guarda informações sobre uma tabela dentro de banco de dados. Seria apenas isto?

 

Será que você consegue me explicar melhor???

Exemplo do livro? Como assim? A qual livro você está se referindo?

 

Desde já, agradeço.

[advaldomesquita 93]

Extents são unidades de alocação de dados do SQL Server, para cada extent podemos ter 8 pages de dados.

 

em uma anlise do Engine do SQL Server teremos os dados das tabelas alocados em extents e dentro de cada extent temos 8 pages, o dado físico que você escrever em uma tabela fica salvo nestas pages que por sua vez estão nos extents.

Complicado né, mas para isso vamos pegar por exemplo um livro. Qualquer livro!

 

Um livro (MDF ou LDF do SQLServer) tem dentro de si várias páginas (Pages) e cada página faz parte de um capítulo (Extents). É deste modo que o SQL armazena os dados.

 

Quando apagamos os dados de uma tabela (DELETE) ou o sobrescrevemos (UPDATE), o Sql não reutiliza os extents, ou seja, não utiliza o mesmo capítulo, mas cria um novo! Tudo isso para melhorar Performance. É mais fácil para o Sql alocar novos do que dar manutenção e mxer com ponteiros internos para os antigos Extents.

 

Em falar em ponteiros, cada tabela possui o seu e este ponteiro fica sempre verificando o próximo Extent livre, não tendo que se preocupar se o anterior esta alocado ou não! Mas e quando chegar no limite do tamanho da Database? O que acontece? Simples. Ele trava o banco, e não aloca mais dados e somente libera este ponteiro quando acontece um Auto-Grow ou um ShrinkDatabase.

Então este ponteiro somente volta ao ponteiro anterior se um destes eventos ocorrem: Auto-Grow ou ShrinkDatabase.

 

 

Bom, é isso. Se não entendeu, pergunte! antes perguntar no fórum do que para seu chefe :devil:

 

 

 

 

 

O script abaixo é um exemplo bem prático sobre o assunto.

Não tenho idéia do fonte. Um colega me passou agora a pouco enquanto discutiamos o assunto:

 

USE Master 

-- Caso exista um banco chamado DBExtent, apaga ele. 


IF (SELECT DB_ID('DBExtent')) IS NOT NULL 
BEGIN 
 USE Master 
 ALTER DATABASE DBExtent SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
 DROP DATABASE DBExtent 
END 

GO 

-- Criar um banco de dados chamado DBExtent 

IF (SELECT DB_ID('DBExtent')) IS NULL 
BEGIN 
 CREATE DATABASE DBExtent 
END 
GO 

USE DBExtent 
-- Vamos criar uma tabela para utilizar nos testes. 

CREATE TABLE TestExtent(ID Int Identity(1,1), 
                    Nome char(100) default '100 Bytes') 

GO 


-- Vamos inserir uma linha na tabela para verificar as pages e extents que foram alocadas 
INSERT INTO TestExtent DEFAULT VALUES 

-- Utiliza a unDocumented Database Console Commands for SQL Server – DBCC EXTENTINFO 
-- Podemos visualizar que foi alocada uma page de dados em um extent misto 
DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 

-- Vamos inserir mais dados para forçar a alocação de um extent uniforme 

INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 

--Podemos visualizar que foram alocadas várias páginas e 2 extents 
DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 

-- Agora vamos apagar os dados da tabela e verificar novamente os extents 
DELETE FROM TestExtent 
-- Os extents continuam aparecendo, assim como a informação do tamanho da tabela. 

DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 
GO 

EXEC sp_spaceUsed TestExtent 

-- Vamos criar uma nova tabela e inserir alguns registros nela, 
-- repare que os extents da tabela TestExtent não são reutilizados 
-- na verdade o SQL aloca novo extents para a tabela. 

CREATE TABLE TestExtent2(ID Int Identity(1,1), 
     Nome char(200) default '200 Bytes') 
GO 

-- Vamos inserir uma linha na tabela para verificar as pages e extents que foram alocadas 

INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 

--Repare que o page_id é diferente dos page_id da tabela TestExtent 

DBCC EXTENTINFO(DBExtent, 'TestExtent2',-1) 
GO 

DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 


-- Ao executar o SHRINKDATABASE os extents da tabela TestExtent são apagados. A informção do tamanho é atualizada 

DBCC SHRINKDATABASE (DBExtent); 
DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 

GO 

EXEC sp_spaceUsed TestExtent 

GO 



-- Vamos inserir mais dados para forçar a alocação de um extent uniforme na tabela TestExtent2 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 

-- Verifique que os page_id que pertenciam a tabela TestExtent foram reutilizados. 

DBCC EXTENTINFO(DBExtent, 'TestExtent2',-1)

 

 

 

[J4P0N315 0]

em uma anlise do Engine do SQL Server teremos os dados das tabelas alocados em extents e dentro de cada extent temos 8 pages, o dado físico que você escrever em uma tabela fica salvo nestas pages que por sua vez estão nos extents.

 

Se eu der um "insert into" em uma tabela, por exemplo, estarei automaticamente gravando dados nas pages referente àquela tabela? Ou seja, os dados escritos em uma tabela não ficam em um único arquivo, mas em várias pages e, consequentemente, várias extents? Pois neste curso eu vi que existem vários tipos de pages. Cada uma grava um tipo específico de dado. Seria mais ou menos isso?

 

Complicado né, mas para isso vamos pegar por exemplo um livro. Qualquer livro!

Um livro (MDF ou LDF do SQLServer) tem dentro de si várias páginas (Pages) e cada página faz parte de um capítulo (Extents). É deste modo que o SQL armazena os dados.

Quando apagamos os dados de uma tabela (DELETE) ou o sobrescrevemos (UPDATE), o Sql não reutiliza os extents, ou seja, não utiliza o mesmo capítulo, mas cria um novo! Tudo isso para melhorar Performance. É mais fácil para o Sql alocar novos do que dar manutenção e mxer com ponteiros internos para os antigos Extents.

 

Entendi! Mas em consequência disso o banco irá crescer muito, pois terá muitos espaços em branco, certo? Se sim, existe uma opção que, mesmo comprometendo a performance, otimiza a ocupação de espaço? Ou sempre se visa o desenpenho de leitura/escrita?

 

Em falar em ponteiros, cada tabela possui o seu e este ponteiro fica sempre verificando o próximo Extent livre, não tendo que se preocupar se o anterior esta alocado ou não! Mas e quando chegar no limite do tamanho da Database? O que acontece? Simples. Ele trava o banco, e não aloca mais dados e somente libera este ponteiro quando acontece um Auto-Grow ou um ShrinkDatabase.

Então este ponteiro somente volta ao ponteiro anterior se um destes eventos ocorrem: Auto-Grow ou ShrinkDatabase.

 

O limite que você diz aqui é aquele setado logo na criação, né (no caso de se usar o SQL Management Studio)? Presumo que o auto-grouw seria permitir que o banco cresça automaticamente conforme a necessidade, e shrinkdatabase seria o encolhimento do banco, certo?

 

Mas na hora de manipular essas extents e pages, eu vejo elas no SQL Management Studio? Ou somente mexo através da linha de comando?

 

Tô vendo que isso é algo avançado. Eu não trabalho com isso. Apenas faço cursos online e mexo com banco e programação porque gosto. Ainda sou iniciante em ambos.

 

Essas coisas de melhorar a performance do banco, otimizar o tamanho e etc, é feito somente por quem mexe exclusivamente no banco, certo? Quem trabalha com isso, nunca mexe com o aplicativo?

 

Muito obrigado por estar esclarecendo todas as minhas dúvidas!!!

 

USE Master 

-- Caso exista um banco chamado DBExtent, apaga ele. 


IF (SELECT DB_ID('DBExtent')) IS NOT NULL 
BEGIN 
 USE Master 
 ALTER DATABASE DBExtent SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
 DROP DATABASE DBExtent 
END 

GO 

-- Criar um banco de dados chamado DBExtent 

IF (SELECT DB_ID('DBExtent')) IS NULL 
BEGIN 
 CREATE DATABASE DBExtent 
END 
GO 

USE DBExtent 
-- Vamos criar uma tabela para utilizar nos testes. 

CREATE TABLE TestExtent(ID Int Identity(1,1), 
                    Nome char(100) default '100 Bytes') 

GO 


-- Vamos inserir uma linha na tabela para verificar as pages e extents que foram alocadas 
INSERT INTO TestExtent DEFAULT VALUES 

-- Utiliza a unDocumented Database Console Commands for SQL Server – DBCC EXTENTINFO 
-- Podemos visualizar que foi alocada uma page de dados em um extent misto 
DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 

-- Vamos inserir mais dados para forçar a alocação de um extent uniforme 

INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 
INSERT INTO TestExtent DEFAULT VALUES 

--Podemos visualizar que foram alocadas várias páginas e 2 extents 
DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 

-- Agora vamos apagar os dados da tabela e verificar novamente os extents 
DELETE FROM TestExtent 
-- Os extents continuam aparecendo, assim como a informação do tamanho da tabela. 

DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 
GO 

EXEC sp_spaceUsed TestExtent 

-- Vamos criar uma nova tabela e inserir alguns registros nela, 
-- repare que os extents da tabela TestExtent não são reutilizados 
-- na verdade o SQL aloca novo extents para a tabela. 

CREATE TABLE TestExtent2(ID Int Identity(1,1), 
     Nome char(200) default '200 Bytes') 
GO 

-- Vamos inserir uma linha na tabela para verificar as pages e extents que foram alocadas 

INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 

--Repare que o page_id é diferente dos page_id da tabela TestExtent 

DBCC EXTENTINFO(DBExtent, 'TestExtent2',-1) 
GO 

DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 


-- Ao executar o SHRINKDATABASE os extents da tabela TestExtent são apagados. A informção do tamanho é atualizada 

DBCC SHRINKDATABASE (DBExtent); 
DBCC EXTENTINFO(DBExtent, 'TestExtent',-1) 

GO 

EXEC sp_spaceUsed TestExtent 

GO 



-- Vamos inserir mais dados para forçar a alocação de um extent uniforme na tabela TestExtent2 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 
INSERT INTO TestExtent2 DEFAULT VALUES 

-- Verifique que os page_id que pertenciam a tabela TestExtent foram reutilizados. 

DBCC EXTENTINFO(DBExtent, 'TestExtent2',-1)

 

Nossa...

Programação em banco de dados. Confesso que ainda não tinha visto isso.

Você joga todas essas linhas na mesma tela onde escreve os outros comandos? Na verdade, isso não passa de um conjunto de vários comandos em linguagem SQL, certo?

 

Muito obrigado pelas dúvidas sanadas! :D

[advaldomesquita 93]

Se eu der um "insert into" em uma tabela, por exemplo, estarei automaticamente gravando dados nas pages referente àquela tabela? Ou seja, os dados escritos em uma tabela não ficam em um único arquivo, mas em várias pages e, consequentemente, várias extents? Pois neste curso eu vi que existem vários tipos de pages. Cada uma grava um tipo específico de dado. Seria mais ou menos isso?

Sim, seria mais ou menos isso. Como existem tipos de Pages a conversa fica mais longa :P

 

Entendi! Mas em consequência disso o banco irá crescer muito, pois terá muitos espaços em branco, certo? Se sim, existe uma opção que, mesmo comprometendo a performance, otimiza a ocupação de espaço? Ou sempre se visa o desenpenho de leitura/escrita?

O limite que você diz aqui é aquele setado logo na criação, né (no caso de se usar o SQL Management Studio)? Presumo que o auto-grouw seria permitir que o banco cresça automaticamente conforme a necessidade, e shrinkdatabase seria o encolhimento do banco, certo?

Você mesmo fez a pergunta e respondeu. Fazer uma manutenção mensal ou diária faz que o banco gere as informações de forma mais rápida.

De uma lida neste tópico que mostra o espaço alocado por tabela, indice e dados:

Total de registros: http://forum.imaster...e-um-banco-sql/

Tipo de dados: http://forum.imaster...-tipo-de-dados/

Espaço livre por DB: http://forum.imaster...de-crescimento/

 

Mas na hora de manipular essas extents e pages, eu vejo elas no SQL Management Studio? Ou somente mexo através da linha de comando?

Tô vendo que isso é algo avançado. Eu não trabalho com isso. Apenas faço cursos online e mexo com banco e programação porque gosto. Ainda sou iniciante em ambos.

Essas coisas de melhorar a performance do banco, otimizar o tamanho e etc, é feito somente por quem mexe exclusivamente no banco, certo? Quem trabalha com isso, nunca mexe com o aplicativo?

Você pode verificar por comandos que lhe passei (DBCC).

É um pouco avançado sim, mas quem trabalha com performance ou ambientes críticos (24x7) enxerga isso direto :devil:

Geralmente este tipo de manutenção é realizado por DBAs. Hoje em dia, inclusive em nível de certificação, há Dba´s programadores, porém em linguagem específica, como BI, CRM, .NET entre outras.

 

Muito obrigado por estar esclarecendo todas as minhas dúvidas!!!

 

Nossa...

Programação em banco de dados. Confesso que ainda não tinha visto isso.

Você joga todas essas linhas na mesma tela onde escreve os outros comandos? Na verdade, isso não passa de um conjunto de vários comandos em linguagem SQL, certo?

 

Muito obrigado pelas dúvidas sanadas!

A ideia do fórum é movimentar idéias :P

Já fui moderador desta área. Infelizmente não sou mais, mas sempre que posso estou por aqui :devil:

A linguagem que escrevi chama-se T-SQL, ou Transact SQL http://pt.wikipedia....ki/Transact-SQL

 

Se tiver dúvidas com relação aos comandos, lógica ou algo referente ao SQL, de uma procurada no fórum que com certeza vai achar a resposta!

 

Abçs e boa sorte!

 

 

ps. a cada post me surpreendo do quanto que eu escrevi hehehehe

[J4P0N315 0]

Se eu der um "insert into" em uma tabela, por exemplo, estarei automaticamente gravando dados nas pages referente àquela tabela? Ou seja, os dados escritos em uma tabela não ficam em um único arquivo, mas em várias pages e, consequentemente, várias extents? Pois neste curso eu vi que existem vários tipos de pages. Cada uma grava um tipo específico de dado. Seria mais ou menos isso?

Sim, seria mais ou menos isso. Como existem tipos de Pages a conversa fica mais longa :P

 

Entendi! Mas em consequência disso o banco irá crescer muito, pois terá muitos espaços em branco, certo? Se sim, existe uma opção que, mesmo comprometendo a performance, otimiza a ocupação de espaço? Ou sempre se visa o desenpenho de leitura/escrita?

O limite que você diz aqui é aquele setado logo na criação, né (no caso de se usar o SQL Management Studio)? Presumo que o auto-grouw seria permitir que o banco cresça automaticamente conforme a necessidade, e shrinkdatabase seria o encolhimento do banco, certo?

Você mesmo fez a pergunta e respondeu. Fazer uma manutenção mensal ou diária faz que o banco gere as informações de forma mais rápida.

De uma lida neste tópico que mostra o espaço alocado por tabela, indice e dados:

Total de registros: http://forum.imaster...e-um-banco-sql/

Tipo de dados: http://forum.imaster...-tipo-de-dados/

Espaço livre por DB: http://forum.imaster...de-crescimento/

 

Mas na hora de manipular essas extents e pages, eu vejo elas no SQL Management Studio? Ou somente mexo através da linha de comando?

Tô vendo que isso é algo avançado. Eu não trabalho com isso. Apenas faço cursos online e mexo com banco e programação porque gosto. Ainda sou iniciante em ambos.

Essas coisas de melhorar a performance do banco, otimizar o tamanho e etc, é feito somente por quem mexe exclusivamente no banco, certo? Quem trabalha com isso, nunca mexe com o aplicativo?

Você pode verificar por comandos que lhe passei (DBCC).

É um pouco avançado sim, mas quem trabalha com performance ou ambientes críticos (24x7) enxerga isso direto :devil:

Geralmente este tipo de manutenção é realizado por DBAs. Hoje em dia, inclusive em nível de certificação, há Dba´s programadores, porém em linguagem específica, como BI, CRM, .NET entre outras.

 

Muito obrigado por estar esclarecendo todas as minhas dúvidas!!!

 

Nossa...

Programação em banco de dados. Confesso que ainda não tinha visto isso.

Você joga todas essas linhas na mesma tela onde escreve os outros comandos? Na verdade, isso não passa de um conjunto de vários comandos em linguagem SQL, certo?

 

Muito obrigado pelas dúvidas sanadas!

A ideia do fórum é movimentar idéias :P

Já fui moderador desta área. Infelizmente não sou mais, mas sempre que posso estou por aqui :devil:

A linguagem que escrevi chama-se T-SQL, ou Transact SQL http://pt.wikipedia....ki/Transact-SQL

 

Se tiver dúvidas com relação aos comandos, lógica ou algo referente ao SQL, de uma procurada no fórum que com certeza vai achar a resposta!

 

Abçs e boa sorte!

 

 

ps. a cada post me surpreendo do quanto que eu escrevi hehehehe

 

Cara,

 

Muito obrigado por todas as respostas. Elas, com certeza, foram de grande ajuda!!! :)

[advaldomesquita 93]

Precisando é só postar :clap: