Treinamento de Tuning de Banco de

Dados
Capítulo 2 – Modelagem de Dados – Aspectos Físicos

1
 Objetivos
• Entendendo o processo de leitura e escrita (Input/Output).

• Entendendo os mecanismos para diminuição de leitura e escrita.

• Mantendo dados em memória.

• Componentes de BD que ajudam a diminuir o uso de leitura e escrita.

• Boas práticas em modelagem de dados lógica e física

2
 Entendendo o processo de
Leitura e Escrita (I/O)
• A base de funcionamento de um SGBD é o armazenamento, realizado através de
dispositivos de armazenamento conhecidos como discos rígidos (Hard Disks ou HD)
e mais recententemente os discos em estado sólido (Solid State Disks ou SSD).
• O processo de leitura e escrita envolve uma unidade mínima de armazenamento
usada em banco de dados normalmente chamada de bloco (Oracle) ou página
(SQL Server , MySQL, PostgreSQL e DB2).

Discos SAS:
Os discos SAS são unidades de armazenamento que utilizam a interface SAS para se
conectar ao servidor. Eles são uma evolução dos discos SCSI, oferecendo maior
velocidade e confiabilidade. No contexto dos bancos de dados, os discos SAS são
frequentemente utilizados em ambientes empresariais devido à sua alta capacidade
de processamento e desempenho.

Ao ler dados de um banco de dados em um disco SAS, a operação envolve o acesso

físico aos discos magnéticos, onde os dados são armazenados. Esses discos possuem
braços mecânicos que movem as cabeças de leitura/gravação para a posição correta,
permitindo a recuperação dos dados. O tempo necessário para acessar os dados em
um disco SAS é relativamente maior em comparação com os SSDs, devido à natureza
mecânica desses discos.

Quando ocorre a escrita de dados em um disco SAS, o processo é semelhante. As

cabeças de gravação do disco se movem para a posição correta e gravam os dados
solicitados. No entanto, novamente, o tempo de acesso e gravação é maior em
comparação com os SSDs.

3
SSDs:
Os SSDs, por outro lado, são dispositivos de armazenamento sem partes móveis. Eles
usam memória flash para armazenar os dados, o que permite um acesso muito mais
rápido em comparação com os discos SAS. No contexto dos bancos de dados, os SSDs
são amplamente utilizados para melhorar o desempenho e a eficiência.

Ao ler dados de um banco de dados em um SSD, o tempo de acesso é extremamente

rápido, uma vez que não há partes mecânicas envolvidas. Os dados são lidos
diretamente da memória flash, resultando em tempos de resposta mais curtos e
maior velocidade de leitura.

Da mesma forma, ao escrever dados em um SSD, o processo é acelerado

significativamente. Os dados são gravados diretamente na memória flash, sem a
necessidade de movimentação de cabeças de gravação, resultando em tempos de
gravação mais rápidos e menor latência.

Impacto nos bancos de dados:

Tanto o Oracle, o SQL Server quanto o PostgreSQL podem se beneficiar do uso de
discos SSD em termos de desempenho. O acesso mais rápido aos dados resulta em
tempos de resposta mais curtos, consultas mais rápidas e um melhor desempenho
geral do banco de dados. Isso é particularmente importante em cenários de alto
tráfego e aplicações que exigem tempos de resposta rápidos.

É importante observar que, embora os SSDs ofereçam vantagens significativas em

termos de desempenho, os discos SAS ainda têm seu lugar em determinados
ambientes, especialmente quando se trata de capacidade de armazenamento em
larga escala e custo por gigabyte.

Conclui-se que o uso de discos SAS e SSDs nos bancos de dados Oracle, SQL Server e
PostgreSQL tem impacto direto no desempenho geral do sistema. Enquanto os discos
SAS são mais lentos devido à natureza mecânica, os SSDs oferecem tempos de acesso
e gravação mais rápidos, resultando em um desempenho aprimorado do banco de
dados. A escolha entre os dois tipos de disco depende das necessidades específicas
do ambiente, levando em consideração fatores como capacidade, desempenho e
custo.

3
 Entendendo o processo de
Leitura e Escrita (I/O)
• Discos são acionados por controladoras e promovem o acesso aos dados contidos
nos discos.
• A qualidade das controladoras permitem um acesso mais eficiente aos dados em
disco.
• Uma controladora utiliza canais para realizar o controle dos discos, e normalmente
pode ter mais de um canal para melhorar o acesso aos discos.
• Controladoras normalmente possuem uma area de memória chamada buffer que
garante a retenção dos dados acessados recentemente.

As controladoras de discos têm um papel significativo no processo de leitura e

gravação de dados em um banco de dados. Elas são responsáveis por gerenciar a
comunicação entre o sistema operacional e os discos de armazenamento. As
controladoras de discos atuam como intermediárias, facilitando as operações de
leitura e gravação de dados.

A influência das controladoras de discos no processo de leitura e gravação de dados

pode ser observada de várias maneiras:

Desempenho: As controladoras de discos têm um impacto direto no desempenho do

sistema. Elas determinam a taxa de transferência de dados entre o banco de dados e
os discos de armazenamento. Controladoras de discos mais avançadas podem
oferecer recursos como cache de leitura/gravação e tecnologias de paralelismo,
melhorando significativamente o desempenho de leitura e gravação do banco de
dados.

Tolerância a falhas: As controladoras de discos também desempenham um papel na

tolerância a falhas do sistema. Elas podem fornecer recursos de RAID (Redundant
Array of Independent Disks), que permitem a criação de conjuntos de discos

4
redundantes para proteção contra falhas de disco. Isso aumenta a confiabilidade do
banco de dados, garantindo que os dados estejam disponíveis mesmo em caso de
falha de um ou mais discos.

Recursos de cache: Muitas controladoras de discos possuem cache integrado, que

consiste em uma área de memória rápida para armazenar temporariamente os dados
mais frequentemente acessados. O cache pode melhorar o desempenho de leitura,
reduzindo a latência e acelerando o acesso aos dados. No entanto, é importante
garantir que as operações de gravação sejam realizadas com segurança, considerando
políticas de escrita em cache e mecanismos de proteção de dados.

Configurações e otimizações: As controladoras de discos oferecem uma variedade de

configurações e opções de otimização para ajustar o desempenho e a segurança do
banco de dados. Essas configurações incluem parâmetros de cache, algoritmos de
agendamento de E/S, políticas de gravação em cache, entre outros. O ajuste
adequado dessas configurações pode impactar significativamente o desempenho e a
confiabilidade do banco de dados.

Portanto, as controladoras de discos desempenham um papel crucial no processo de

leitura e gravação de dados em um banco de dados. Elas afetam diretamente o
desempenho, a confiabilidade e a tolerância a falhas do sistema. Ao escolher e
configurar as controladoras de discos, é essencial considerar os requisitos específicos
do banco de dados, como desempenho desejado, tolerância a falhas, recursos de
cache e configurações otimizadas para atender às necessidades do ambiente.

4
 Aplicando o modelo de dados
em um Database
• O modelo de dados deve ser aplicado ao banco de dados como última etapa do
processo de construção.
• Conhecer a arquitetura de discos e hardware, além do conhecimento lógico e físico
do modelo ajudam a sua melhor construção.
• Separar os dados pelo volume, acesso , características como gravação podem
ajudar na busca pelo melhor tratamento dos dados.

A construção de um modelo de dados envolve várias etapas, desde o modelo

conceitual até o modelo físico implementado nos Sistemas de Gerenciamento de
Banco de Dados (SGBDs) Oracle, SQL Server e PostgreSQL. Vou descrever essas
etapas de forma geral:

Modelo Conceitual:
A primeira etapa é a criação do modelo conceitual, que representa as entidades,
relacionamentos e atributos do domínio de negócios em um nível abstrato. Nessa
fase, são utilizadas técnicas como diagramas de entidade-relacionamento (DER) ou
diagramas UML para capturar os requisitos e estruturar o modelo de dados.

Modelo Lógico:
A próxima etapa é a transformação do modelo conceitual em um modelo lógico,
onde são definidas as tabelas, os relacionamentos, as restrições e as chaves
primárias. Isso pode ser feito usando diagramas ER estendidos ou especificações de
esquemas em linguagens como o SQL. O objetivo é representar as estruturas e as
regras do banco de dados de forma independente do SGBD específico.

Modelo Físico:

5
Nesta etapa, o modelo lógico é traduzido em um modelo físico, levando em conta as
características e recursos do SGBD escolhido. Aqui, são definidos aspectos como o
tipo de dado para cada atributo, índices, partições, otimizações de desempenho e
restrições específicas do SGBD. Essa etapa envolve a conversão das estruturas do
modelo lógico em tabelas, colunas, índices e relacionamentos reais no SGBD
escolhido.

Implementação no SGBD:
Depois de projetar o modelo físico, o próximo passo é implementá-lo no SGBD
selecionado. Cada SGBD possui suas próprias ferramentas e comandos para criar as
tabelas, definir as colunas, índices, chaves primárias e estrangeiras, e outras
configurações específicas. A implementação pode ser realizada usando SQL, scripts
ou ferramentas gráficas fornecidas pelo SGBD.

Otimização e Ajustes:
Após a implementação, é necessário otimizar e ajustar o modelo físico de acordo
com os requisitos de desempenho e escalabilidade. Isso pode envolver a criação de
índices adicionais, ajuste de consultas, particionamento de tabelas, configurações de
cache e outras técnicas para melhorar o desempenho e a eficiência do banco de
dados.

É importante observar que, embora o processo de construção do modelo de dados

seja semelhante entre os SGBDs Oracle, SQL Server e PostgreSQL, existem algumas
diferenças nas sintaxes e recursos específicos de cada sistema. Portanto, é necessário
estar familiarizado com a documentação e as melhores práticas de cada SGBD para
realizar a implementação correta e otimizada do modelo físico.

5
 Como construir?
• Para respondermos como construir é necessario realizar algumas perguntas previamente
para determinarmos o que devemos usar para a construção física do banco de dados.
• Perguntas como Finalidade do Banco de Dados?
• Transacional
• OLAP
• Perguntas como volume de dados?
• Mb
• Gb
• Tb
• Pb
• Perguntas como quais ações acontecem no Banco de Dados?
• Insert e Select
• Insert , Update e Select
• Insert, Update , Delete e Select
• Carga de Dados

EXISTEM DIFERENÇAS ENTRE CONSTRUIR MODELOS OLAP E TRANSACIONAIS?

Sim existem diferenças na concepção do modelo de dados ao construir um banco de

dados OLAP (Online Analytical Processing) em comparação com um banco de dados
transacional.

Banco de Dados OLAP:

Um banco de dados OLAP é projetado para suportar análises e consultas complexas
em grandes volumes de dados. O foco principal é a eficiência e o desempenho das
consultas analíticas. Algumas diferenças na concepção do modelo de dados para um
banco de dados OLAP incluem:

Modelagem dimensional: No OLAP, é comum utilizar a modelagem dimensional, que

envolve a criação de tabelas de fatos e dimensões. As tabelas de fatos contêm as
métricas analíticas e as medidas quantitativas, enquanto as tabelas de dimensões
representam os atributos que descrevem as dimensões dos dados (por exemplo,
tempo, produto, localização). Isso permite uma análise mais fácil e eficiente dos
dados.

6
Denormalização: Em um banco de dados OLAP, a denormalização é frequentemente
usada para melhorar o desempenho das consultas analíticas. Isso envolve a
duplicação de dados e a redução do número de junções necessárias para consultas
complexas. A denormalização pode ser aplicada a tabelas de fatos e dimensões,
consolidando informações relevantes em uma única tabela.

Agregação de dados: No OLAP, a agregação de dados é comum para melhorar o

desempenho das consultas. Isso envolve a pré-cálculo e o armazenamento de
resultados agregados em tabelas específicas. Essas tabelas agregadas aceleram as
consultas analíticas, evitando cálculos repetidos em tempo real.

Banco de Dados Transacional:

Um banco de dados transacional é projetado para dar suporte a transações de
negócios, como inserção, atualização e exclusão de registros. O foco principal é
garantir a consistência, a integridade e a recuperação dos dados. Algumas diferenças
na concepção do modelo de dados para um banco de dados transacional incluem:

Normalização: Em um banco de dados transacional, a normalização é amplamente

utilizada para reduzir a redundância de dados e garantir a integridade. O modelo de
dados é projetado para evitar a duplicação de informações e manter a consistência
dos dados em várias tabelas.

Restrições de integridade: No ambiente transacional, são aplicadas várias restrições

de integridade, como chaves primárias, chaves estrangeiras e restrições de unicidade.
Essas restrições garantem a consistência dos dados e evitam a inserção de dados
inválidos ou inconsistentes.

Indexação: Em um banco de dados transacional, a indexação é amplamente usada

para melhorar o desempenho das operações de consulta e atualização. Os índices são
criados em colunas relevantes para permitir uma pesquisa rápida e eficiente.

Embora as diferenças entre um banco de dados OLAP e um banco de dados

transacional sejam significativas, é importante ressaltar que ambos os tipos de banco
de dados podem coexistir e serem integrados em uma arquitetura de dados mais
ampla, para atender às necessidades de análise e operações transacionais de uma
organização.

VOLUMETRIA DE DADOS EM MODELOS OLAP E TRANSACIONAIS:

A determinação da volumetria de dados em modelos OLAP (Online Analytical

Processing) e transacionais pode ser realizada de maneiras diferentes, levando em

6
consideração as características e os requisitos específicos de cada tipo de banco de
dados.

Para modelos transacionais, a volumetria de dados é tipicamente estimada com base

nas transações e nas operações diárias do sistema. É necessário considerar fatores
como a frequência das transações, o volume de dados gerado por transação, a taxa
de crescimento esperada e a retenção de dados. Essas informações podem ser
obtidas por meio de análise de requisitos, histórico de operações anteriores ou
projeções de crescimento futuro.

No caso de modelos OLAP, a determinação da volumetria de dados pode ser mais

complexa. A natureza analítica desse tipo de banco de dados envolve a análise de
grandes volumes de dados históricos e a realização de consultas complexas. Alguns
métodos comuns para estimar a volumetria de dados em modelos OLAP incluem:

Amostragem: Uma abordagem é realizar amostragens representativas dos dados

históricos para determinar a volumetria. Essas amostras podem ser usadas para
extrapolar e estimar o tamanho total do conjunto de dados.

Análise estatística: Pode-se aplicar técnicas estatísticas para analisar os dados

históricos e identificar padrões e tendências. Com base nessa análise, é possível
projetar o crescimento esperado e estimar a volumetria futura.

Modelagem baseada em consultas: Outra abordagem é analisar as consultas

analíticas típicas que serão executadas no banco de dados OLAP. Com base nessas
consultas e em suas características, como os atributos utilizados e as agregações
necessárias, é possível estimar a volumetria dos dados necessários para suportar
essas análises.

Em ambos os casos, é importante considerar fatores como a retenção de dados, a

granularidade dos dados, a taxa de crescimento esperada e a disponibilidade de
recursos de armazenamento. Além disso, é recomendável realizar monitoramento
contínuo e ajustes à medida que o banco de dados evolui e novos requisitos surgem.

É fundamental ressaltar que a estimativa da volumetria de dados é uma tarefa

complexa e pode variar dependendo das particularidades de cada projeto. Portanto,
é aconselhável envolver profissionais experientes em modelagem de dados e análise
de requisitos para garantir estimativas precisas e adequadas para cada tipo de banco
de dados.

EXISTE ALGUMA DIFERENÇA QUANDO UMA TABELA SOFRE APENAS INSERT E SELECT

6
DO QUE QUANDO SOFRE UPDATE E DELETE TAMBEM?

Sim quando uma tabela sofre apenas operações de inserção (INSERT) e seleção
(SELECT), fisicamente falando, há diferenças em comparação com quando a tabela
também sofre operações de atualização (UPDATE) e exclusão (DELETE).

Quando uma tabela sofre apenas operações de inserção e seleção, o banco de dados
pode otimizar o armazenamento dos dados de forma mais eficiente. Por exemplo, o
banco de dados pode usar estratégias de alocação de espaço que sejam adequadas
para inserções contínuas, evitando fragmentação e permitindo um acesso rápido aos
dados inseridos.

No entanto, quando uma tabela também sofre operações de atualização e exclusão, o

cenário muda um pouco. As atualizações e exclusões envolvem a modificação ou
remoção de registros existentes. Como resultado, podem ocorrer fragmentação física
e desordem dos dados no armazenamento.

Quando um registro é atualizado, o banco de dados precisa localizar o registro

existente e substituir seus valores pelos novos valores. Dependendo do tamanho do
registro e do número de colunas atualizadas, pode haver necessidade de realocar o
registro em um novo local no armazenamento, resultando em fragmentação física.

Da mesma forma, quando um registro é excluído, o espaço físico que ele ocupava no
armazenamento é liberado. No entanto, esse espaço pode se tornar vago e
fragmentado, especialmente se ocorrerem várias exclusões em diferentes momentos.

Essa fragmentação e desordem dos dados podem afetar o desempenho das

operações de seleção. Consultas que precisam percorrer a tabela em busca de
registros específicos podem levar mais tempo para serem executadas, pois os dados
estão espalhados e podem exigir acesso a diferentes partes do armazenamento.

Para mitigar esses efeitos, os Sistemas de Gerenciamento de Banco de Dados (SGBDs)

oferecem mecanismos de otimização, como a reorganização de dados (por exemplo,
reindexação, recompactação) e a compactação de espaços vazios. Essas ações podem
melhorar o desempenho e a eficiência das operações de seleção em tabelas que
também sofrem atualizações e exclusões.

Portanto, quando uma tabela sofre apenas operações de inserção e seleção, o

armazenamento dos dados pode ser otimizado de forma mais eficiente. No entanto,
quando a tabela também sofre atualizações e exclusões, pode ocorrer fragmentação
física e desordem dos dados, o que pode afetar o desempenho das operações de
seleção. Os SGBDs oferecem mecanismos de otimização para lidar com esses

6
desafios.

6
 Finalidade – Banco de Dados
Transacional
• A finalidade do banco de dados é fundamental para podermos determinar a sua
construção, onde sistemas transacionais, possuem as seguintes características:

• Transações Curtas.
• Grande volume de transações.
• Transações espalhadas durante o tempo.
• Normalmente não podem ser refeitas automaticamente.
• Movimentam até Tb de informações.
• Dados são mantidos por aplicações.
• O que fazer:
• Tablespaces ou Filegroups diferenciados para tabelas e indices.
• Tablespaces ou Filegroups diferenciados para tabelas de pequeno, medio e grande volumes em
discos ou grupos de discos diferentes.
• Tablespaces ou Filegroups diferenciados para tabelas que sofrem apenas inserção e consulta.
• Tablespaces ou Filegroups diferenciados para “tabelas temporárias”.
• Particionamento de tabelas de grandes volumes (muitos milhões de registros ou mais). - Opcional

7
 Finalidade – Banco de Dados
OLAP
• A finalidade do banco de dados é fundamental para podermos determinar a sua
construção, onde sistemas transacionais, possuem as seguintes características:

• Transações longas de gravação e Leitura.

• Grande volume de transações.
• Transações concentradas durante o tempo (carga).
• Normalmente podem ser refeitas automaticamente.
• Movimentam até Pb de informações.
• Dados são mantidos por aplicações de carga de dados (ETL).
• O que fazer:
• Tablespaces ou Filegroups diferenciados para tabelas e Índices.
• Tablespaces ou Filegroups diferenciados para tabelas de pequeno, medio e grande volumes.
• Tablespaces ou Filegroups diferenciados para tabelas que sofrem apenas inserção e consulta.
• Tablespaces ou Filegroups diferenciados para “tabelas temporárias”.
• Particionamento de tabelas de grandes volumes (muitos milhões de registros ou mais). -
Fundamental
• Blocos (Oracle e DB2) com tamanhos maiores.

8
 Volume de Dados

• O volume de dados armazenado é importante para

definição de como armazenar os dados. Tabelas que
ocupem Gb ou Tb devem ser previamente pré-alocadas
com a finalidade de evitar a criação em excesso de
extensões (Oracle). Quanto mais extensões maior o
esforço em novas alocações de espaço nas extensões
existentes.
• Alocar tabelas maiores em Tablespaces / Filegroups
diferentes pode ajudar a melhorar operações como
junção e subconsulta.
• Alocar tabelas menores em Tablespaces / Filegroups
diferentes dos usados nas tabelas maiores pode ajudar
a melhorar operações de junção.
• Criar mais de um volume (grupos de discos) pode ajudar
na dispersão e nas operações de consultas aos dados.

9
 Ações que ocorrem no Banco
de Dados – Consulta e Inserção
• Devemos separar objetos que sofrem diferentes ações no banco de dados, dessa
forma tabelas que sofrem Inserção e consulta apenas devem ser tratadas
separadamente de tabelas que sofram atualização e de tabelas que sofram
exclusão.

• Tabelas que sofram inserção e consulta apenas

devem ter a chamada Free Space ocupada até o
último byte possivel, já que não terá operação
de atualização.

Bloco Oracle

10
 Ações que ocorrem no Banco de
Dados – Consulta e Atualização
• Devemos separar objetos que sofrem diferentes ações no banco de dados, dessa forma tabelas
que sofrem Atualização além de consulta e inserção,estas devem ser tratadas separadamente de
tabelas que sofram apenas inserção. Normalmente utilizamos os tipos de dados variáveis
(variable characters) que ocupam o que usam, assim sendo em uma operação de update em um
bloco cheio provocará a necessidade de extrapolação do conteúdo em outro bloco, dessa forma
ocorrem as chamadas migrações e consequentemente o encadeamento dos dados.

• Tabelas que sofram atualização e consulta

apenas devem ter a chamada Free Space
reservada para guardar possiveis valores
extrapolados dentro do mesmo bloco. Este
valor pode variar até 50% do total do bloco,
dependendo da quantidade de atualizações
realizadas no bloco.
Bloco Oracle

11
 Ações que ocorrem no Banco de
Dados – Consulta e Exclusão
• Devemos separar objetos que sofrem diferentes ações no banco de dados, dessa forma tabelas
que sofrem Exclusão além de consulta e inserção,estas devem ser tratadas separadamente de
tabelas que sofram apenas inserção ou atualização.A exclusão normalmente cria o chamado
efeito “queijo suiço” nos blocos e páginas fazendo com que as operações de inserção sejam mais
exigidas para “tapar os buracos” deixados pelo processo de exclusão. Objetos com grande
quantidade de Exclusão devem ser reorganizados a medida que se torna mais crítica a
quantidade e o numero de blocos e páginas envolvidas nessas operações

• Tabelas que sofram exclusão e consulta apenas

não devem ter a chamada Free Space
reservada, pelo menos em grande volume pois
a exclusão em si não força o uso da area de Free
Space.

Bloco Oracle

12
 O que pode diminuir a necessidade
de leitura em um disco?
• A leitura é um processo necessário em
consultas , atualizações , exclusões e até
mesmo em inclusões. Reduzir a necessidade Índice
de leitura significa, ler mais rapido e guardar Oracle
em memória o máximo possível.
• Como ler mais rápido???
• A resposta pode ser dada assim, evitando o
acesso sequencial ao dado (do primeiro ao
ultimo registro ,tambem conhecido como full
table scan) fazendo com que acesse apenas
parte dos dados, isso pode ser feito Índice
normalmente através do uso de índices. SQL Server
• Índices mais seletivos (maior número de
valores distintos) são mais interessantes que
os índices menos seletivos. Índices únicos são
mais seletivos que os índices não únicos.

A diminuição da necessidade de leitura em um disco em bancos de dados Oracle, SQL

Server e PostgreSQL pode ser alcançada por meio de diferentes técnicas e recursos
específicos de cada sistema. Vou descrever detalhadamente para cada banco de
dados:

Oracle:

Indexação adequada: O Oracle suporta a criação de índices para melhorar o

desempenho das consultas. Ao projetar e criar índices apropriados para as colunas
usadas em consultas frequentes, é possível reduzir a quantidade de leitura
necessária, pois o Oracle pode usar os índices para recuperar diretamente os dados
desejados.

Uso de materialized views: As materialized views são vistas pré-computadas e

armazenadas fisicamente. Ao criar materialized views para consultas comuns, o
Oracle pode usar essas views para retornar resultados prontos, evitando a leitura de
dados brutos e reduzindo a carga no disco.

Utilização de técnicas de particionamento: O particionamento divide uma tabela

13
grande em partições menores, o que pode melhorar o desempenho das consultas,
reduzindo a quantidade de dados a serem lidos. O Oracle oferece opções de
particionamento, como particionamento por intervalo, particionamento por hash e
particionamento por lista.

SQL Server:

Uso de índices adequados: Da mesma forma que o Oracle, o SQL Server permite a
criação de índices para acelerar consultas. Ao identificar e criar índices apropriados
para as colunas usadas em consultas frequentes, é possível reduzir a quantidade de
leitura necessária, melhorando o desempenho.

Utilização de views indexadas: As views indexadas são views pré-computadas que são
armazenadas fisicamente. Ao criar views indexadas para consultas comuns, o SQL
Server pode usar essas views para retornar resultados prontos, evitando a leitura de
dados brutos.

Implementação de compressão de dados: O SQL Server oferece recursos de

compressão de dados, que podem reduzir o tamanho dos dados armazenados em
disco. Com a compressão, menos dados precisam ser lidos, o que pode melhorar o
desempenho geral do sistema.

PostgreSQL:

Criação de índices adequados: Assim como nos outros bancos de dados, a criação de
índices apropriados no PostgreSQL pode melhorar o desempenho das consultas e
reduzir a necessidade de leitura. É importante identificar e criar índices para as
colunas frequentemente utilizadas em consultas.

Uso de técnicas de particionamento: O PostgreSQL suporta várias opções de

particionamento, como particionamento por intervalo, particionamento por hash e
particionamento por lista. O particionamento pode reduzir a quantidade de dados
lidos, focando apenas nas partições relevantes para cada consulta.

Utilização de cache de consultas: O PostgreSQL possui um mecanismo de cache de

consultas que armazena os resultados das consultas frequentes em memória. Dessa
forma, consultas subsequentes com os mesmos parâmetros não precisam acessar o
disco novamente, reduzindo a necessidade de leitura.

13
 O que pode tornar mais eficiente a
de leitura em disco?
• Dividir uma tabela com muitos registros
em partes menores é uma boa tática para
diminuição da leitura de dados. A isso
chamamos Particionamento de dados,
que consiste em separar fisicamente uma
tabela em porções menores , baseado em
critérios utilizados em consulta.
Tipicamente o tempo (data) são as chaves
de particionamento mais utilizadas.
• A leitura pode ser feita em uma partição
apenas o que melhora a performance da
leitura que ao invés de fazer a leitura de
toda a tabela (full table scan) , faz a
leitura na partição desejada (partition
scan).

14
 Sharding de Dados

• Conceito criado decadas após o surgimento

dos bancos de dados relacionais , foi
integrado aos SGBDS Oracle, PostrgreSQL e
demais SGBDs Relacionais nos ultimos 10
anos.
• Resumidamente consiste na criação de shards
(databases ou schemas em databases) em
diferentes servidores usando recursos
específicos que atuam de forma coordenada
para armazenamento e recuperação de dados
contidos nos diversos shards. Pode ser usados
em uma mesma localidade em servidores
diferentes ou mesmo de forma globalizada
em diferentes servidores geograficamente
espalhados.

Oracle: No Oracle, o processo de sharding é realizado por meio do recurso Oracle

Sharding. Ele permite dividir uma tabela em partições lógicas chamadas de shards,
que são distribuídas entre vários bancos de dados autônomos chamados de shard
databases. Cada shard database é responsável por armazenar e processar uma ou
mais partições dos dados.

O Oracle Sharding utiliza um coordenador (coordinator) para rotear as consultas e

gerenciar a distribuição dos dados. Ele é responsável por direcionar as solicitações de
consulta para os shard databases apropriados e coordenar a união dos resultados. O
coordenador também gerencia a consistência dos dados entre os shards.

A Oracle introduziu o Oracle Database Sharding como um novo recurso no 12cR2, que
usa a estrutura GDS como o Shard Director e forneceu alguns recursos básicos de
sharding. Com o lançamento do Oracle 18cR1, a Oracle adicionou alguns recursos
significativos no sharding, como sharding definido pelo usuário, sharding com
reconhecimento de PDB, reconhecimento de RAC e sharding intermediário. Com o
lançamento do 19c, a Oracle introduziu mais aprimoramentos nos recursos de
sharding do PDB Aware, recursos de sharding de camada intermediária.

15
A arquitetura básica

O diagrama abaixo (retirado da documentação da Oracle) é um bom ponto de partida

para entender a arquitetura da solução de sharding do Oracle Database. Os principais
componentes de um Oracle SDB são:

Sharded database (SDB) – um único banco de dados Oracle lógico que é particionado
horizontalmente em um pool de bancos de dados Oracle físicos (estilhaços) que não
compartilham nenhum hardware ou software

Shards – bancos de dados Oracle físicos independentes que hospedam um

subconjunto do banco de dados fragmentado

Serviço global – serviços de banco de dados que fornecem acesso aos dados em um
SDB

Catálogo de fragmentos (SCAT) – Um banco de dados Oracle com o propósito

expresso de ser o armazenamento persistente para metadados de configuração SDB.

Diretores de fragmentos – ouvintes de rede que permitem roteamento de conexão

de alto desempenho com base em uma chave de fragmentação

Pools de conexão – em tempo de execução, atuam como diretores de fragmentos

roteando solicitações de banco de dados em conexões em pool

Interfaces de gerenciamento – GDSCTL (utilitário de linha de comando) e Oracle

Enterprise Manager (GUI)

Cada fragmento é um banco de dados Oracle independente com seu próprio pool de
recursos de CPUs, armazenamento e rede. Não há exigência de ter recursos
compartilhados entre os shards. Os fragmentos dentro de um SDB podem estar
localizados próximos à rede ou separados geograficamente. Na terminologia da
nuvem, isso seria dentro de uma região ou entre regiões. A versão atual do Oracle
Data Guard reconhece fragmentos. Para HA, os shards em espera podem ser
colocados no mesmo datacenter (ou região) onde os shards primários são colocados.
Para DR, os fragmentos de espera estão localizados em outra região.

SQL Server: No SQL Server, o sharding é realizado por meio de técnicas

personalizadas de particionamento e distribuição de dados. Pode-se implementar o
sharding manualmente, criando várias instâncias de bancos de dados SQL Server e
distribuindo os dados entre eles. Cada instância seria responsável por armazenar e

15
processar uma parte dos dados.

O SQL Server não possui um recurso nativo específico para sharding, mas fornece
recursos como particionamento de tabelas e vistas distribuídas para ajudar na
distribuição e consulta dos dados. É necessário criar e gerenciar a lógica de
roteamento de dados e consulta manualmente.

PostgreSQL: No PostgreSQL, o sharding pode ser realizado usando várias abordagens.

Pode-se usar extensões específicas, como o Citus Data ou o Postgres-XL, que
oferecem recursos avançados de sharding e distribuição de dados.

Essas extensões permitem particionar uma tabela em vários nós ou servidores,

distribuindo os dados de forma horizontal. Cada nó é responsável por armazenar e
processar uma ou mais partições dos dados.

Essas soluções geralmente possuem um coordenador (coordinator) que gerencia a

distribuição dos dados, o roteamento das consultas e a coordenação dos resultados
das consultas. O coordenador garante a consistência dos dados entre os shards e
ajuda na escalabilidade e no desempenho do sistema.

15
 O que pode diminuir a necessidade
de leitura em um disco?
• O particionamento possibilita a divisão fisica de
uma tabela, mantendo a união lógica da mesma
(uma unica definição).
• Espalhar uma tabela em vários discos de forma
controlada é o que podemos fazer com uma tabela
particionada permitindo uso de recursos como
paralelismo (múltiplos processos) para acesso aos
dados.
• Indices tambem podem ser particionados
proporcionando os mesmos benefícios e até
ampliando os benefícios obtidos no
particionamento de tabelas.

16
 O que pode diminuir a necessidade
de leitura em um disco?
• Tabelas organizadas por índices podem
auxiliar ,no sentido de reduzir a carga de I/O
pois mantem em uma mesma estrutura Tabela
índice e dados. Um acesso ao índice já Clusterizada
implica em acesso aos dados. Oracle
• Para cada acesso via índice , não será
necessário um segundo acesso para
localização dos dados.
• Oracle identifica as tabelas com essa
estrutura como tabelas organizadas por
indice (Index Organized Tables) ou IOTS. Índice
• SQL Server identifica esse recurso como Clusterizado
Índice Clusterizado. SQL Server
• Geralmente o índice é associado a chave
primária de uma tabela.

17
 Organização Dados – SQL Server
• A organização dos dados em um database SQL
Server é realizada da forma descrita ao lado,
um banco de dados pode ter um ou vários
filegroups, o filegroup padrão DEFAULT sempre
Banco de Dados será criado
• O FileGroup por sua vez pode conter 1 ou mais
extensões (mistas e uniformes).
FileGroup Arquivo de Dados
• Cada tabela criada por definição ocupa uma
página em uma extensão mista, ao completar 8
páginas , a partir da nona página o SQL aloca
Extensão
extensões uniformes (8 páginas para uma
mesma tabela ou índice).
página SQL Server Bloco S.O.
• Cada extensão pode conter 8 páginas de forma
física.
Estruturas Lógicas Estruturas Físicas

No SQL Server, a organização de dados também segue uma estrutura hierárquica

semelhante ao Oracle, embora os termos e conceitos sejam um pouco diferentes.
Vou descrever como esses elementos se relacionam no SQL Server:

Database (Banco de Dados):

Assim como no Oracle, o database é a camada mais alta na organização de dados no
SQL Server. Ele contém todos os objetos e estruturas relacionados a um ambiente de
banco de dados específico. Cada banco de dados no SQL Server é separado e isolado
dos outros, com suas próprias configurações e conjuntos de dados.

Filegroup (Grupo de Arquivos):

No SQL Server, um filegroup é usado para agrupar arquivos de dados relacionados.
Cada filegroup é uma unidade lógica de armazenamento que pode conter um ou mais
arquivos de dados.

Table (Tabela):
No SQL Server, as tabelas são os objetos de armazenamento primários que contêm os
dados. Cada tabela possui sua própria estrutura de armazenamento e está associada
a um filegroup específico. As tabelas são compostas por páginas, que são as unidades

18
de armazenamento físico no SQL Server.

Extent (Extensão):
O SQL Server também usa o conceito de extensão, que é uma unidade física de
armazenamento composta por oito páginas contíguas. As extensões são usadas para
alocar e armazenar os dados em páginas.

Page (Página):
A página é a menor unidade de armazenamento físico no SQL Server. Cada página
tem um tamanho fixo, geralmente 8 KB. Os dados são armazenados em páginas
dentro das extensões.

DataFile (Arquivo):
No SQL Server, um arquivo representa uma unidade física de armazenamento no
sistema operacional. Cada filegroup pode ser composto por um ou mais arquivos,
que são gerenciados pelo sistema operacional e contêm as páginas de dados.

18
 Organização Dados - Oracle
• A organização dos dados em um database
Banco de Dados Oracle é realizada da forma descrita ao lado,
um banco de dados pode ter várias
tablespaces (pelo menos 3 + 1 Criada pelo
Tablespace administrador).
• A tablespace por sua vez pode conter 1 ou
mais segmentos (1 tabela ou índice é
Segmento Arquivo de Dados considerado um segmento).
• Cada segmento contem pelo menos 1
extensão, a medida que esta é preenchida
Extensão
criam-se nova extensões, logo cada segmentox
pode conter uma ou mais extensões.
Bloco Oracle Bloco S.O.
• Cada extensão pode conter 1 ou mais blocos
Oracle, que são utilizadados para o
armazenamento.
Estruturas Lógicas Estruturas Físicas

A organização de dados no Oracle é estruturada em várias camadas, incluindo

database (banco de dados), tablespace, segmento, extensão, bloco, arquivo de dados
e blocos armazenados nos datafiles no sistema operacional. Vou explicar cada um
desses elementos:

Database (Banco de Dados):

O database é a camada mais alta na organização de dados do Oracle. Ele contém
todos os objetos e estruturas de armazenamento relacionados a um ambiente de
banco de dados específico. Cada banco de dados no Oracle é separado e isolado dos
outros, com seus próprios conjuntos de dados e configurações.

Tablespace:
Um tablespace é uma unidade lógica de armazenamento no Oracle. Ele é usado para
agrupar objetos relacionados, como tabelas, índices e partições. Cada tablespace é
composto por um ou mais arquivos de dados (datafiles) que são alocados no sistema
operacional.

Segmento:
Um segmento é uma estrutura de armazenamento dentro de um tablespace. Ele

19
representa uma coleção lógica de extensões que armazenam os dados reais de uma
tabela, índice ou outro objeto do Oracle. Cada tabela ou índice tem seu próprio
segmento no tablespace.

Extensão:
Uma extensão é uma unidade física de armazenamento que compõe um segmento.
Ela consiste em um ou mais blocos de dados contíguos. As extensões são alocadas
automaticamente pelo Oracle para armazenar os dados de acordo com a
necessidade.

Bloco:
O bloco é a menor unidade de armazenamento físico no Oracle. Ele representa uma
quantidade fixa de espaço em disco, geralmente 8 KB. Os dados são armazenados em
blocos dentro de extensões e são acessados pelo Oracle em operações de leitura e
gravação.

Arquivo de Dados:
O arquivo de dados (datafile) é um arquivo no sistema operacional que contém os
blocos físicos de dados armazenados pelo Oracle. Cada tablespace é composto por
um ou mais arquivos de dados. Esses arquivos são gerenciados pelo sistema
operacional, e o Oracle os utiliza para armazenar e acessar os dados.

Blocos Armazenados nos Datafiles:

Os blocos armazenados nos datafiles são as unidades físicas de armazenamento de
dados no Oracle. Eles contêm as informações reais das tabelas, índices e outros
objetos do banco de dados. Cada bloco possui um identificador único e pode conter
dados de uma ou várias linhas de uma tabela.

19
 Organização Dados – PostgreSQL
• A organização dos dados em um database
PostgreSQL é realizada da forma descrita ao
lado, um banco de dados pode ter um ou
vários Tablespaces.
Banco de Dados
• O Tablespace por sua vez pode conter 0,1 ou
mais tabelas e índices.
Tablespace
• A página PostgreSQL possui tamanho fixo de
Arquivo de Dados
8kb

Tabela/Indice

página PostgreSQL Bloco S.O.

Estruturas Lógicas Estruturas Físicas

Assim como no Oracle e no SQL Server, o PostgreSQL também segue uma estrutura
hierárquica para a organização de dados. A estrutura está descrita abaixo.

Database (Banco de Dados):

No PostgreSQL, o database é a camada mais alta na organização de dados. Cada
banco de dados no PostgreSQL é separado e possui suas próprias configurações e
conjuntos de dados.

Tablespace:
O tablespace é uma unidade lógica de armazenamento no PostgreSQL. Ele é usado
para agrupar objetos relacionados, como tabelas, índices e outros dados.
Diferentemente do SQL Server e Oracle a tablespace representa apenas um diretorio
em disco onde serão aramazenadas tabelas e indices

Table (Tabela):
As tabelas são os objetos de armazenamento primários no PostgreSQL. Cada tabela
pertence a um tablespace específico e contém os dados organizados em páginas.

Page (Página):

20
A página é a menor unidade de armazenamento físico no PostgreSQL. Ela possui um
tamanho fixo, normalmente de 8 KB, e é onde os dados são armazenados nas tabelas.
As páginas são organizadas em blocos contíguos no disco.

DataFile (Arquivo):
Os arquivos, também conhecidos como datafiles, são as unidades físicas de
armazenamento no sistema operacional para os dados do PostgreSQL. Cada
tablespace pode conter um ou mais arquivos, que são gerenciados pelo PostgreSQL.

Quando uma tabela ou um índice é criado no PostgreSQL, um arquivo físico

correspondente é criado no sistema operacional para armazenar os dados dessa
tabela ou índice. Esses arquivos são gerenciados pelo PostgreSQL e estão associados
ao tablespace definido para o objeto.

Cada tabela ou índice possui seu próprio arquivo físico dedicado no sistema de
arquivos, onde as páginas de dados correspondentes são gravadas. Esses arquivos
são identificados pelo sistema usando uma estrutura de metadados interna.

Ao realizar operações de inserção, atualização ou exclusão de dados em uma tabela,

o PostgreSQL grava as alterações diretamente nos arquivos físicos associados a essa
tabela.

Os tablespaces, por sua vez, fornecem uma abstração lógica para agrupar e gerenciar
esses arquivos físicos relacionados. Os tablespaces determinam a localização do
armazenamento dos arquivos no sistema de arquivos e fornecem um nível de
controle e organização para o armazenamento de dados.

20
 Filegroups (SQL Server)

• Filegroup é uma organização lógica de dados que agrupa arquivos de dados

(datafiles), e tem como função armazenar estruturas como tabelas, índices,
visões indexadas , tabelas particionadas entre outras.
• A organização de dados e índices sugere uma separação destes objetos em
Filegroups diferentes com intuito de promover uma separação física dos
mesmos, preferencialmente em arquivos em discos diferentes, buscando a
melhoria do processo de leitura e gravação.
• Recomenda-se que tabelas que concentrem chaves estrangeiras vindas de
outras tabelas fiquem em filegroups especificas, separadas das tabelas
relacionadas que devem ficar em filegroups diferentes (se possível em
discos diferentes).

Os filegroups (grupos de arquivos) são uma estrutura de armazenamento no SQL

Server que permite agrupar objetos relacionados e controlar a localização física dos
dados. Aqui estão os principais pontos sobre filegroups no SQL Server:

Conceito:
Filegroup: No SQL Server, um filegroup é uma unidade lógica de armazenamento que
agrupa objetos relacionados. Os objetos, como tabelas e índices, são armazenados
em filegroups.
Organização dos Dados:
Arquivos de Dados: Dentro de cada filegroup, existem um ou mais arquivos de dados
(datafiles) que armazenam os dados dos objetos relacionados ao filegroup. Os
arquivos de dados são alocados no sistema operacional e compõem o
armazenamento físico dos dados no SQL Server.
Atribuição de Objetos:
Atribuição de Filegroups: Ao criar uma tabela ou um índice no SQL Server, é possível
especificar o filegroup onde deseja que eles sejam armazenados. Essa atribuição
permite controlar a localização física dos dados e distribuir os objetos em diferentes
filegroups conforme necessário.
Backup e Restauração:

21
Backup Granular: Os filegroups no SQL Server permitem a realização de backups e
restaurações granulares. É possível fazer backup e restaurar filegroups específicos, o
que possibilita a recuperação seletiva de dados em caso de problemas.
Desempenho e Manutenção:
Gerenciamento de Espaço: Os filegroups também ajudam no gerenciamento do
espaço em disco. É possível definir políticas de crescimento e configurações de
aumento automático (autoextend) para os arquivos de dados em cada filegroup,
permitindo um gerenciamento eficiente do espaço disponível.

Otimização de Desempenho: Ao distribuir os objetos em diferentes filegroups, é

possível melhorar o desempenho, distribuindo a carga de leitura e gravação entre
diferentes dispositivos de armazenamento. Isso pode ser especialmente útil em
cenários onde se tem acesso a diferentes discos físicos ou partições.

21
 Filegroup (SQL Server)

• Arquivos de dados (datafiles) são os componentes físicos

de armazenamento do SQL Server , todo banco de dados
deve ter ao menos um arquivo de dados, e este arquivo
pertence a somente um único banco de dados.
• Arquivos de dados estão ligados a uma estrutura lógica de
gerenciamento chamada de grupo de arquivos (filegroup).
Cada grupo de arquivos pode ter por sua vez pode ter um
ou mais arquivos de dados.
• O grupo de arquivos serve para organizar os arquivos de
dados permitindo um gerenciamento dos mesmos de
forma única.
• Todo banco de dados tem ao menos um grupo de
arquivos, que é chamado de PRIMARY. É possível criar
mais grupos de arquivos e depois associa-los a novos
arquivos criados no banco de dados.

Existem várias maneiras para definir a criação de grupos de arquivos, descrevemos

algumas delas abaixo:

- FileGroup DADOS para armazenamento de tabelas e filegroup INDICES para

armazenamento de Indices
- FileGroup DADOS_LEITURA para aramazenamento de tabelas usadas para leitura e
filegroup DADOS para armazenamento das demais tabelas e filegroup INDICES para
armazenamento de Indices
- Filegroup SISTEMA_A_DADOS para armazenamento das tabelas referentes ao
sistema A e SISTEMA_B_DADOS para armazenamento das tabelas referentes ao
sistema B

22
 Tablespaces (Oracle)

• Tablespaces é uma organização lógica de dados que agrupa arquivos de

dados (datafiles), e tem como função armazenar estruturas como tabelas,
índices, visões materializadas, tabelas particionadas , tabelas XML entre
outras.
• A organização de dados e índices sugere uma separação destes objetos em
tablespaces diferentes com intuito de promover uma separação física dos
mesmos, preferencialmente em arquivos em discos diferentes, buscando a
melhoria do processo de leitura e gravação.
• Recomenda-se que tabelas que concentrem chaves estrangeiras vindas de
outras tabelas fiquem em tablespaces especificas, separadas das tabelas
relacionadas que devem ficar em tablespaces diferentes (se possível em
discos diferentes).

Conceito:
No Oracle, um tablespace é uma unidade lógica de armazenamento que agrupa
objetos relacionados, como tabelas, índices, tablespaces temporários e undo
tablespaces. Cada tablespace é composto por um ou mais arquivos de dados
(datafiles) que são alocados no sistema operacional. Os tablespaces permitem o
controle granular do armazenamento dos dados no Oracle.

Finalidade:
Os tablespaces no Oracle são usados para controlar onde os dados são armazenados
fisicamente no sistema de arquivos. Eles permitem separar e gerenciar os dados de
forma eficiente, garantindo a organização e a otimização do armazenamento.

Criação:
No Oracle, os tablespaces são criados usando a declaração CREATE TABLESPACE.
Durante a criação, são especificados o nome do tablespace, o local onde os arquivos
de dados serão armazenados, o tamanho inicial do datafile e outras opções de
configuração.

Tipos de Tablespaces:

23
O Oracle oferece vários tipos de tablespaces, incluindo:

Tablespace de Dados (Data Tablespace): É usado para armazenar dados de tabelas e

índices.

Tablespace de Índice (Index Tablespace): É usado exclusivamente para armazenar os

índices das tabelas.

Tablespace de Undo (Undo Tablespace): É usado para armazenar as informações

necessárias para desfazer ou rolar de volta transações no Oracle.

Tablespace Temporário (Temporary Tablespace): É usado para armazenar dados

temporários usados em operações como classificação e junção.

Atribuição de Tablespaces:
Ao criar uma tabela, um índice ou qualquer outro objeto no Oracle, é possível
especificar o tablespace no qual deseja que eles sejam armazenados. Se nenhum
tablespace for especificado, o objeto será atribuído ao tablespace padrão do banco
de dados. Também é possível mover objetos existentes para outros tablespaces
usando a declaração ALTER TABLE.

Gerenciamento de Espaço:
Os tablespaces permitem o gerenciamento eficiente do espaço em disco no Oracle. É
possível especificar opções de aumento automático (autoextend) para os datafiles
dos tablespaces, permitindo que eles cresçam automaticamente à medida que mais
espaço é necessário. Além disso, é possível monitorar e gerenciar o espaço utilizado
nos tablespaces para evitar problemas de espaço insuficiente.

Backup e Restauração:
No Oracle, os tablespaces desempenham um papel crucial no gerenciamento de
backup e restauração. É possível realizar backups e restaurações granulares,
selecionando tablespaces específicos. Isso permite uma recuperação eficiente de
dados em caso de falhas ou corrupção.

Considerações:
Ao trabalhar com tablespaces no Oracle, é importante considerar fatores como
desempenho, disponibilidade e gerenciamento de espaço em disco. É recomendável
planejar cuidadosamente a distribuição dos tablespaces, considerando a capacidade
de armazenamento, o desempenho de E/S e a segregação lógica dos dados de acordo
com as necessidades do aplicativo.

23
 Tablespace smallfile - Oracle
• É o tipo de tablespace padrão utilizada em
sistemas OLTP.
• Caso não seja especificada é o tipo padrão de
tablespace a ser criada.
• Podemos ter 1 ou mais arquivos de dados
associados a uma tablespace smallfile.
• Cada arquivo de dados suporta tipicamente 4
milhões de blocos, sendo tecnicamente o
limite do tamanho do arquivo de dados
– Bloco 2K – 7.629Gb
– Bloco 4K – 15.258Gb
– Bloco 8K – 30.517Gb
– Bloco 16K – 61.035Gb
– Bloco 32K – 122.07Gb

Os tablespaces smallfile no Oracle são uma opção de criação de tablespaces que

possuem algumas características específicas.

Principais características dos tablespaces smallfile:

Tamanho Limitado: Os tablespaces smallfile possuem um limite de tamanho máximo

definido pelo Oracle. Esse limite é geralmente menor do que o suportado pelos
tablespaces bigfile.

Vários Datafiles: Os tablespaces smallfile são compostos por vários datafiles, que são
arquivos físicos onde os dados são armazenados. Cada datafile tem um tamanho fixo
e é alocado no sistema operacional.

Alocação de Espaço: A alocação de espaço nos tablespaces smallfile é feita de forma

incremental, ou seja, os datafiles são adicionados conforme a necessidade de
armazenamento aumenta. Cada datafile pode crescer automaticamente até seu
tamanho máximo definido.

Limitação no Número de Datafiles: Os tablespaces smallfile têm um limite no número

24
de datafiles que podem ser adicionados. Esse limite varia de acordo com a versão do
Oracle, mas geralmente é de até 1022 datafiles por tablespace.

Gerenciamento Simplificado: Os tablespaces smallfile são mais simples de gerenciar

em comparação com os tablespaces bigfile. Eles são recomendados para bancos de
dados menores e aplicações que não exigem grandes quantidades de
armazenamento.

Desempenho: Em algumas situações, os tablespaces smallfile podem oferecer um

desempenho ligeiramente melhor em comparação com os tablespaces bigfile, devido
a um melhor balanceamento de E/S e gerenciamento de dados.

É importante notar que, com o Oracle 12c e versões posteriores, a Oracle Corporation
recomendou o uso de tablespaces bigfile como a opção padrão para criação de
tablespaces, devido às suas vantagens em relação ao tamanho máximo e ao
gerenciamento simplificado.

Portanto os tablespaces smallfile no Oracle são caracterizados por terem um limite

de tamanho máximo menor, serem compostos por vários datafiles, terem alocação
de espaço incremental e terem um limite no número de datafiles permitidos. Eles são
recomendados para bancos de dados menores e aplicações com necessidades de
armazenamento mais modestas.

24
 Tablespace Bigfile - Oracle
• É o tipo de tablespace padrão utilizada em
sistemas OLAP.
• Deve ser especificada na criação da tablespace.
• Podemos ter apenas 1 arquivo de dados
associado a uma tablespace bigfile.
• Arquivo e tablespace se fundem logicamente.
• Não é possivel adicionar novos datafiles a uma
tablespace Bigfile.
• Não é possivel converter uma tablespace
bigfile em smallfile e vice-versa.
• O limite tecnico de blocos em uma tablespace
bigfile é de 4 bilhões de blocos.
– Em blocos de 32Kb - 128Tb

As tablespaces bigfile no Oracle são uma opção de criação de tablespaces com

características específicas. Aqui estão as principais características das tablespaces
bigfile no Oracle:

Tamanho Máximo: As tablespaces bigfile permitem um tamanho máximo muito

maior em comparação com as tablespaces smallfile. O limite de tamanho é
determinado pelo sistema de arquivos do sistema operacional e pode ser de vários
terabytes ou até petabytes.

Único Datafile: Diferentemente das tablespaces smallfile, as tablespaces bigfile

possuem apenas um datafile por tablespace. Esse datafile é um arquivo físico onde
todos os dados do tablespace são armazenados.

Gerenciamento Simplificado: O uso de um único datafile nas tablespaces bigfile

simplifica o gerenciamento do espaço de armazenamento. Não é necessário lidar
com a alocação e gerenciamento de vários datafiles, o que facilita as operações de
backup, restauração e expansão do tablespace.

Desempenho Aprimorado: As tablespaces bigfile podem oferecer um melhor

25
desempenho em certos cenários. Como os dados estão concentrados em um único
datafile, há um potencial de redução na fragmentação e uma melhoria no acesso aos
dados.

Extensão Incremental: O crescimento de uma tablespace bigfile ocorre de forma

incremental, ou seja, o datafile existente é estendido automaticamente à medida que
mais espaço é necessário. Isso simplifica a tarefa de gerenciar o espaço de
armazenamento, eliminando a necessidade de adicionar vários datafiles conforme o
tablespace cresce.

Uso Recomendado: As tablespaces bigfile são recomendadas para aplicações e

bancos de dados que exigem grandes quantidades de armazenamento, como
sistemas de data warehousing, bancos de dados OLAP e outras aplicações com
necessidades de armazenamento em larga escala.

É importante destacar que, ao usar tablespaces bigfile, é necessário garantir que o

sistema de arquivos do sistema operacional tenha suporte ao tamanho máximo
desejado e que haja espaço suficiente disponível no disco.

Resumindo as tablespaces bigfile no Oracle são caracterizadas por permitirem um

tamanho máximo maior, possuírem apenas um datafile por tablespace, oferecerem
gerenciamento simplificado e proporcionarem um desempenho potencialmente
melhor. Elas são recomendadas para aplicações com grandes necessidades de
armazenamento e oferecem vantagens em termos de simplicidade e desempenho.

25
 Tablespaces (PostgreSQL)

• Tablespaces é uma organização lógica

de dados que agrupa arquivos de dados
(datafiles), e tem como função
armazenar estruturas como tabelas,
índices, visões materializadas, tabelas
particionadas entre outras.
• A organização de dados e índices
sugere uma separação destes objetos
em tablespaces diferentes com intuito
de promover uma separação física dos
mesmos, preferencialmente em
arquivos em discos diferentes,
buscando a melhoria do processo de
leitura e gravação.
• Recomenda-se que tabelas que
concentrem chaves estrangeiras vindas
de outras tabelas fiquem em
tablespaces especificas, separadas das
tabelas relacionadas que devem ficar
em tablespaces diferentes (se possível
em discos diferentes).

Os tablespaces no PostgreSQL são uma característica importante que permite o

gerenciamento flexível do armazenamento físico dos dados.

Conceito:
Um tablespace é uma unidade lógica de armazenamento no PostgreSQL que agrupa
objetos relacionados, como tabelas, índices e outros dados. Cada tablespace é
composto por um ou mais arquivos de dados (datafiles) que são alocados no sistema
operacional. Os tablespaces fornecem uma abstração lógica que permite separar e
organizar os dados em diferentes locais físicos.

Finalidade:
Os tablespaces no PostgreSQL são usados para controlar onde os dados de tabelas e
índices são armazenados fisicamente no sistema de arquivos. Eles permitem a divisão
dos dados em unidades de armazenamento separadas, possibilitando a distribuição
do armazenamento em diferentes dispositivos, como discos rígidos, partições ou até
mesmo sistemas de arquivos remotos.

Criação:
É possível criar tablespaces no PostgreSQL usando a instrução CREATE TABLESPACE.

26
Durante a criação, é especificado o nome do tablespace, bem como o local onde os
arquivos de dados serão armazenados. Esses arquivos podem ser pré-existentes ou o
PostgreSQL pode criar automaticamente os arquivos no local especificado.

Tipos de Tablespaces:
O PostgreSQL oferece dois tipos de tablespaces:

Tablespace Regular: É o tipo de tablespace padrão no PostgreSQL. Os arquivos de

dados do tablespace regular são armazenados localmente no sistema de arquivos do
servidor PostgreSQL.

Tablespace Mapeado por Simbólico (Symlink): É um tipo especial de tablespace em

que os arquivos de dados são armazenados em um local diferente do sistema de
arquivos. Isso é possível por meio do uso de links simbólicos (symlinks) que mapeiam
o local real dos arquivos de dados.

Atribuição de Tablespaces:
Ao criar uma tabela ou um índice no PostgreSQL, você pode especificar o tablespace
onde deseja que eles sejam armazenados. Se nenhum tablespace for especificado, o
objeto será atribuído ao tablespace padrão do banco de dados. Também é possível
mover objetos já existentes para outros tablespaces usando a instrução ALTER TABLE
ou ALTER INDEX.

Backup e Restauração:
Os tablespaces no PostgreSQL desempenham um papel importante no
gerenciamento de backup e restauração. É possível realizar backups e restaurações
granulares, selecionando tablespaces específicos. Isso permite uma abordagem mais
eficiente para a recuperação de dados, especialmente em ambientes com grandes
volumes de dados.

Considerações:
Ao trabalhar com tablespaces no PostgreSQL, é importante considerar fatores como
desempenho, disponibilidade e gerenciamento de espaço em disco. É recomendável
planejar cuidadosamente a distribuição dos tablespaces, considerando a capacidade
de armazenamento, a performance de E/S e a segregação lógica dos dados de acordo
com os requisitos do aplicativo.

26
 Tabelas - Oracle
Os dados em um banco de dados são
armazenados em tabelas. As linhas são armazenadas sem uma ordem
específica, de acordo com os espaços disponíveis.
Embora idênticas do ponto de vista lógico,
existem vários métodos físicos de O DBA tem pouco controle sobre a distribuição das
armazenamento destas tabelas: linhas.

Tabelas normais (heap tables)

Tabelas particionadas
Tabelas organizadas por índice
Tabelas de cluster
Tabelas Externas (armazenamento externo em
arquivos)
Visões Materializadas
Tabelas de Filas (Queue Tables)

27
 Conceitos Básicos Banco de
Dados – Data Blocks - Oracle
BLOCK HEADER
BLOCK DIRECTORY
• Blocos são estruturas de armazenamento utilizadas pelos SGBDs para
FREE SPACE garantirem a persistência dos dados . Alguns bancos de dados também
chamam este componente de Página. O SGBD Oracle chama este component
ROW n
como bloco. Os dados são armazenados no formato de registros ou linhas
....
(rows), ocupando a área de dados até o limite desta que é chamado de FREE
...
SPACE ou área livre, usada exclusivamente para operações de Atualização de
....
dados (UPDATE). O tamanho padrão para um bloco é de 8Kb mas pode variar
....
de 2 a 32Kb.
...
ROW 3ROW 1
3
ROW 3ROW 2
• É A UNIDADE DE MEDIDA PARA LEITURA E GRAVAÇÃO.
ROW 3ROW 1

ROWID TAMANHO
ROW OVERHEAD NUM COLUNAS VALOR COLUNA
(CHAINED) COLUNA

Blocos correspondem a forma como os SGBDS armazenam seus dados. Um bloco

Oracle pode ser armazenado em um ou mais Blocos de disco em um sistema
operacional ou utilizando o sistema de armazenamento do Oracle conhecido como
ASM.

28
 Estrutura de um bloco/Linha
Oracle
O bloco é dividido em 2 partes distintas , o
header block que contem informações
importantes para a gestão do bloco e o
registro que é composto de um row header
que contem informações sobre a linha ,
bloqueios realizados sobre ela, isso para
cada registro dentro do bloco, além disso
para cada linha ,cada coluna contem 2
estruturas que é o column length que indica
o tamanho ocupado pelo registro e o column
value que indica o valor alocado para a
coluna específica

29
 Estrutura de um bloco/Linha
Oracle
Cabeçalho da linha (row header)
Usado para armazenar o número de colunas da linha, as informações sobre encadeamento e o status de
bloqueio da linha.
Dados da linha (column length e column value)
Para cada coluna, o servidor Oracle armazena seu tamanho e valor.
É necessário um (para colunas com até 250 bytes) ou três bytes para armazenar o tamanho da coluna.
O valor da coluna é armazenado imediatamente após os bytes de tamanho.
Informações adicionais
As linhas adjacentes não precisam de espaço entre elas.
Cada linha contém um slot no diretório de linhas existente no cabeçalho do bloco. O slot aponta para o
início da linha.

30
 Tabelas – SQL Server
• Tabelas são estruturas para armazenamento de dados e podem ser classificadas como pilhas (Heap) quando
não possuem índices clusterizados e tabelas (tables) quando possuem um índice clusterizado.
• Tabelas podem ter associadas regras para manipulação chamadas constraints, que se aplicam as ações de
DML (Insert,update, delete e Merge) na tabela.
• Tabelas Regulares estão associadas a um único filegroup, porem tabelas particionadas podem estar
associadas a mais de um filegroup.
• Tabelas com índices clusterizados residem juntas em uma mesma página.

Uma tabela somente pode ter um único índice clusterizado, geralmente associado a
chave primária. O índice clusterizado é armazenado conjuntamente com os dados da
tabela. Uma tabela pode ser criada sem índices ou apenas com índices não
clusterizados.

Uma tabela pode ter vários índices não clusterizados.

31
 Diferenças entre Tabelas Regulares
(Heap) e Tabelas com índices
clusterizados – SQL Server
• Tabelas Regulares:
• Dados armazenados em ordem não regular
• Dados específicos podem não ser recuperados
de maneira rápido a não ser que possuam acesso
através de índice não clusterizado.
• páginas não são ligadas (linked) para acesso
sequencial necessita acesso as páginas de
alocação de índices (IAM – Index allocation Map)
• Desde que não tenha índices clusterizados, não
há necessidade de tempo adicional para manter
os índices.
• Essas tabelas possuem o valor 0 para coluna
index_id na visão sys.indexes.

32
 Conceitos Básicos Banco de Dados
– Data Pages – SQL Server
PAGE HEADER
• Páginas são estruturas de armazenamento utilizadas pelos SGBDs para
ROW 1 garantirem a persistência dos dados . Alguns bancos de dados tambem
ROW 2 chamam este componente de Bloco. O SGBD SQL Server chama este
ROW 3 componente como página. Os dados são armazenados no formato de
.... registros ou linhas (rows), ocupando a área de dados até o limite desta
... que é chamado de FREE SPACE ou área livre, usada exclusivamente para
.... operações de Atualização de dados (UPDATE). O tamanho padrão para
.... uma página é de 8Kb.
...
ROW n
• É A UNIDADE DE MEDIDA PARA LEITURA E GRAVAÇÃO.

3 2 1

ROW OFFSET

Uma página SQL Server possui como padrão 8192 bytes, sendo que o page header
ocupa 96 bytes e 36 bytes são reservados para o Row Offset (que controla a alocação
na página), restando 8060 bytes livres para armazenamento de dados.

33
 Tipos de páginas – Data Pages
SQL Server

Página de Dados Página de Índices

Página de Dados: Página que contem dados (tabelas) exceto colunas dos tipos de
dados: text, ntext, image, nvarchar(max), varchar(max), varbinary(max) e xml.

Página de Indice: Informações relativas aos índices.

Página de Texto/Imagem: Para tabelas que contenham tipos de dados: text, ntext,
image, nvarchar(max), varchar(max), varbinary(max) e xml.E os tipos de dados
varchar, nvarchar, varbinary e sql_variant quando forem superiores a 8060 bytes.

Mapa de Alocação Global (GLOBAL ALLOCATION MAP – GAM) e Mapa de Alocação

Global Compartilhada (SHARED GLOBAL ALLOCATION MAP – SGAM): Armazena
informações sobre alocações das extensões. Uma página SGAM pode armazenar
informações de 64000 extensões (EXTENTS) o que equivale a 4Mb, logo a cada 4 mb
haverá uma página SGAM, o mesmo irá ocorrer com as páginas do tipo GAM.
Resumindo as páginas GAM guardam informações de extensões (EXTENTS) uniformes
e a SGAM de extensões (EXTENTS) mistas.
Espaço Livre em Página (FREE PAGE SPACE): Espaço livre nas páginas.

Mapa de alocação de Indice (INDEX ALLOCATION MAP – IAM): Contem informações

34
sobre a alocação de extensões de dados e índices.

Bulk Changed copy: Informações sobre extensões modificadas pelas operações em

massa desde a última instrução BACKUP LOG por unidade de alocação.

Mapa de alterações diferenciais (Differential Changed Map): Informações sobre

extensões modificadas desde a última instrução BACKUP DATABASE por unidade de
alocação.

34
 Tabelas – PostgreSQL
• Tabelas são estruturas para armazenamento de dados e podem ser classificadas como tabelas regulares,
particionadas, unlogged,filas ou ainda visões materializadas.
• Cada tipo de tabela suporta determinadas funcionalidades, a tabela mais comum é a regular que é a mais
utilizada de todas.
• Cada versão do PostgreSQL suporta determinados tipos de tabelas específicas.
• Toda tabela é criada apontando para algum tablespace (especificado no comando ou default do banco de
dados)

tipos de tabelas disponíveis:

Tabela Regular (Regular Table):

A tabela regular é o tipo mais comum no PostgreSQL.

Armazena os dados de forma persistente em colunas e linhas.
Pode conter qualquer número de colunas e ter restrições e índices definidos.

Tabela de Partição (Partitioned Table):

A tabela de partição permite dividir os dados em várias tabelas menores, chamadas

partições, com base em critérios pré-definidos.
Cada partição pode ser armazenada em diferentes tablespaces ou até mesmo em
diferentes servidores.
Ajuda a melhorar o desempenho e facilita a manutenção de grandes conjuntos de
dados.

Tabela Temporária (Temporary Table):

35
A tabela temporária é criada para armazenar dados temporários durante a execução
de uma sessão ou transação.
Os dados são visíveis apenas para a sessão de conexão que a criou e são
automaticamente descartados quando a sessão é encerrada.
Útil para armazenar resultados intermediários de consultas complexas ou
compartilhar dados temporários entre várias etapas de um processo.
Tabela de Unlogged:

A tabela de unlogged (unlogged table) é semelhante à tabela regular, mas não

registra as alterações feitas nela no log de transações.
Adequada para operações de carga em massa ou dados temporários que não
precisam ser recuperados após uma falha no sistema.
Tabela de Filas (Queue):

A tabela de filas (queue table) é usada para implementar uma estrutura de fila, onde
os registros são adicionados no final e removidos do início.
Útil para processamento assíncrono ou sistemas de mensagens.

Tabela de Materialized View:

A tabela de materialized view armazena os resultados de uma consulta em cache,

permitindo acesso rápido aos dados pré-calculados.
Os dados são atualizados periodicamente para manter a sincronização com a consulta
original.

TABLESPACE PADRÃO PARA CRIAÇÃO DE TABELAS / INDICES E DEMAIS OBJERTOS QUE

ARMAZENAM DADOS:

Quando uma tabela é criada no PostgreSQL sem especificar o tablespace, ela é

armazenada no tablespace padrão do banco de dados. O tablespace padrão é
definido durante a criação do banco de dados e pode ser alterado posteriormente
usando a instrução ALTER DATABASE.

Ao criar uma tabela sem especificar um tablespace, o PostgreSQL usa o tablespace

padrão como local de armazenamento para essa tabela. Isso significa que, a menos
que seja explicitamente especificado, todas as tabelas recém-criadas serão
armazenadas no tablespace padrão.

É importante ressaltar que é possível mover uma tabela existente para um tablespace
diferente usando a instrução ALTER TABLE e especificando o novo tablespace
desejado. No entanto, essa alteração pode exigir a reorganização dos dados da

35
tabela, o que pode levar algum tempo dependendo do tamanho da tabela e da
quantidade de dados envolvidos.

Portanto, caso nenhum tablespace seja especificado durante a criação de uma tabela
no PostgreSQL, ela será armazenada no tablespace padrão configurado para o banco
de dados em questão.

35
 Conceitos Básicos Banco de Dados
– Data Pages – PostgreSQL

• Em PostgreSQL temos as seguintes estruturas cabeçalho de página (page header) para armazenamento
de dados de controle da página, mapa de verificação de bits(page verification bitmap) para verificação
dos dados de integridade dos dados armazenados na página, item array offset para armazenar os
deslocamentos físicos dos itens na página, item array que armazena os dados e metadados dos itens na
página, representa uma linha de tabela ou índice

• É A UNIDADE DE MEDIDA PARA LEITURA E GRAVAÇÃO.

No PostgreSQL, uma página é a unidade básica de armazenamento no sistema de

arquivos do banco de dados. A estrutura de uma página no PostgreSQL é composta
por várias seções que organizam os dados e metadados do banco de dados. A seguir,
descrevo as seções principais de uma página no PostgreSQL:

Cabeçalho da página: É a primeira seção da página e contém informações sobre o

tipo de página, o número da página, o número de itens armazenados na página e
outras informações de controle.

Mapa de bits de verificação de página (Page Verification Bitmap): É um mapa de bits

que verifica a integridade dos dados armazenados na página. Ele é usado para
garantir que a página não tenha sido corrompida.

Item Offset Array: É uma matriz que armazena os deslocamentos dos itens na página.
Cada item na página é identificado por um número de slot, e o Item Offset Array
mapeia esses slots para os deslocamentos físicos dos itens.

Item Array: É uma matriz que armazena os dados e metadados dos itens na página.
Cada item representa um registro, como uma linha de uma tabela ou um índice.

36
Linhas (Tuples): São as linhas de dados propriamente ditas que são armazenadas na
página. Cada linha representa um registro completo ou parcial de uma tabela ou
índice. As linhas são organizadas em um formato de armazenamento compactado
para otimizar o espaço utilizado.

Página livre (Free Space): É a área da página que ainda não foi utilizada. É usada para
armazenar novas linhas de dados à medida que são inseridas na tabela.

Página de nível superior (Upper Page): É uma seção opcional da página que é usada
em páginas que possuem hierarquia, como páginas de índice. Ela armazena
informações adicionais para a navegação e organização dos dados.

36
 Índices – Oracle
São estruturas de localização para dados armazenados, são
estruturas adicionais e opcionais, porém , conforme o tamanho da
estrutura de dados a ser armazenada, seu uso é quase que
obrigatório.
Da mesma forma que em um livro quando queremos buscar algum
capítulo utilizamos o índice, o mesmo ocorre com os dados, estes
para serem mais fácilmente localizados , usamos a estrutura de
índices.
Índices podem ter os seguintes tipos:
-B-TREE (Padrão). Usado para alta cardinalidade
-BITMAP. Usado para baixa Cardinalidade
-IOT. Usado em tabelas IOT
-índice PARTICIONADO. Usado geralmente em tabelas particionadas

B-TREE:
Este é o índice padrão que o Oracle tem usado desde que as primeiras versões. A fim
de gerenciar corretamente os blocos, o Oracle controla o alocamento dos ponteiros
dentro de cada bloco dos dados. Uma “árvore de blocos” (analogia à forma com a qual
o Oracle aloca os blocos de dados) cresce através da inserção de linhas na tabela.
Quando um bloco é preenchido, o mesmo “racha”, a fim de criar novos “galhos”, ou
se preferir, blocos de dados. É ai que entra o índice do tipo B-Tree, controlando
ponteiros

BITMAP:
índice utilizado para casos de baixa cardinalidade como campos do tipo sexo
(Apenas 2 valores possíveis). Recomendado para pesquisas em campos com baixa
cardinalidade. Deficiência

37
 Criação de Índices
• Índices podem ser criados automaticamente através da criação das constraints de
chaves primarias (primary Keys) ou no caso de chaves únicas (unique Keys).
• O banco de dados não cria nenhum outro índice de forma automática, cabendo ao
analista que cria o modelo de dados definir os índices a serem utilizados de forma
manual nos casos de:
• Acesso a colunas não indexadas através de restrições a cláusula WHERE
• Restrição a colunas com grande quantidade de valores nulos
• A quantidade de registros selecionados não ultrapasse 10% do total de registros da
tabela (apenas para tabelas com milhares ou milhões de registros)
• Caso a restrição ocorra juntamente com uso de função na coluna recomenda-se a
criação de um índice baseado em função sob pena de perda de eficiência no acesso.

Para Oracle o limite recomendado para uso dos índices é de 4% do total de registros
da tabela, embora esse percentual não seja um valor estático final.

38
 Índices B-TREE - Oracle
Utiliza a estrutura de localização (em arvore) utilizando o conceito de tronco, galhos e folhas. Nesta estrutura armazena-
se os valores utilizados para localização e o respectivo ROWID do registro na tabela (para a efetiva localização). Podem
ser únicos (Não possuem valores duplicados) e não únicos (permitem valores duplicados). Periodicamente é recomendada
a recriação dos mesmos, principalmente se a tabela sofrer um alto grau de deleção e inserção de dados. Ou se as colunas
usadas nos índices sofrerem atualização (UPDATE) constante. Podem usar funções como UPPER e LOWER, SUBSTR
entre outras.

39
 Índices Bitmap - Oracle

Utiliza a estrutura de localização (em mapa de

bits), isso pode determinar um índice de tamanho
bastante reduzido, uma vez que não utiliza a
estrutura de rowid para a localização do registro e
sim a localização através de mapa de bits. Muito
utilizado em sistemas de DataWarehouse, em OLTP
seu uso é praticamente inexistente, visto que a
péssima performance quanto ao processo de carga
da base. Quanto mais inserções , mais o índice
aumenta desordenadamente, necessitando ser
recriados constantemente. Por isso podem ser
usados em sistemas de DataWarehouse, pois
podem ser recriados após o processo de carga.

40

40
 Índices Clustered – SQL Server
Este tipo de índice serve para ordenar os dados na tabela, além de propiciar a localização dos dados em índices não
clusterizados. Usualmente são ligados as chaves primárias da tabela. São índices sempre únicos e não nulos, a sua
exclusão exige reorganização da tabela e dos demais índices existentes.

Um índice clusterizado no SQL Server é uma estrutura de dados que define a ordem
física dos dados em uma tabela com base nas colunas-chave do índice. Ao contrário de
um índice não clusterizado, um índice clusterizado reorganiza fisicamente os dados da
tabela de acordo com a ordem especificada pelo índice.

A principal característica de um índice clusterizado é que as linhas de dados na tabela

são organizadas diretamente de acordo com a ordem das colunas-chave do índice. Isso
significa que as linhas com valores semelhantes nas colunas-chave do índice ficam
fisicamente próximas umas das outras no disco. Portanto, uma tabela pode ter apenas
um índice clusterizado, pois a ordem física dos dados é definida por esse índice.

Ao criar um índice clusterizado, é importante escolher as colunas-chave adequadas

que sejam frequentemente usadas em operações de pesquisa e junção de dados. Essas
colunas devem ter uma alta seletividade, ou seja, devem ter valores únicos ou uma
ampla variedade de valores para garantir que a organização dos dados seja eficiente.

41
Os índices clusterizados são úteis em cenários onde há consultas frequentes que
buscam dados com base em uma faixa de valores de coluna específica, como
operações de pesquisa por intervalo. Eles oferecem um alto desempenho para essas
consultas, pois as linhas de dados estão fisicamente organizadas de acordo com a
ordem do índice clusterizado.

É importante observar que, ao criar um índice clusterizado, a tabela é reorganizada

fisicamente no disco para refletir a ordem especificada pelo índice. Isso pode exigir
tempo e recursos significativos, especialmente para tabelas grandes. Além disso, a
inserção, exclusão e atualização de dados podem ser mais lentas em uma tabela com
um índice clusterizado devido à necessidade de reorganização dos dados.

41
 Índices non Clustered – SQL Server
Este tipo de índice serve para melhorar o desempenho de consultas , atualizações e exclusões pois através deles os dados
são ordenados em esquema de arvore binária (btree) e associados as páginas e offsets para localização dos dados. A
recomendação é que os índices não clusterizados devem ser criados após o índice clusterizado ter sido criado
(tipicamente a chave primária da tabela).

Um índice não clusterizado no SQL Server é uma estrutura de dados que melhora o
desempenho das consultas ao criar uma cópia ordenada das colunas selecionadas de
uma tabela. Ao contrário de um índice clusterizado, um índice não clusterizado não
reorganiza fisicamente os dados da tabela.

A principal característica de um índice não clusterizado é que ele armazena uma lista
de valores de colunas-chave juntamente com um ponteiro para a localização física das
linhas correspondentes na tabela. Isso permite que o SQL Server localize rapidamente
as linhas correspondentes às consultas de pesquisa.

Um índice não clusterizado pode ser criado em uma ou várias colunas da tabela, e
essas colunas podem ser ordenadas em ordem ascendente ou descendente. Ele pode
ser criado em uma tabela existente para melhorar o desempenho das consultas ou
como parte do projeto de um novo esquema de banco de dados.

Vale ressaltar que uma tabela no SQL Server pode ter vários índices não clusterizados.

42
Cada índice não clusterizado possui sua própria estrutura de índice separada que
armazena os valores das colunas-chave e os ponteiros para as linhas correspondentes.

Os índices não clusterizados são úteis em cenários onde há consultas frequentes que
buscam dados com base em colunas específicas, como operações de pesquisa e junção
de dados. Eles melhoram o desempenho das consultas ao permitir um acesso mais
rápido aos dados armazenados nas colunas indexadas.

No entanto, é importante ter em mente que a criação de índices não clusterizados pode
ocupar espaço adicional em disco e afetar o desempenho das operações de inserção,
exclusão e atualização de dados, pois os índices precisam ser atualizados sempre que
os dados subjacentes são modificados.

42
 Índices - PostgreSQL
Da mesma forma que para os
bancos de dados SQL Server e
Oracle , os índices servem para
localizar de forma assertiva os
dados que os indexam.
Ao lado demonstramos o acesso a
dados sem o uso de índices
(sequential scan) e depois um
acesso usando índice (index scan)
usando um tipo de índice BTREE.
Abaixo os tipos de índices:
- BTREE - BRIN
- HASH - Expressao
- GIST - Text
- GIN
- SP-GIST

No PostgreSQL, existem diferentes tipos de índices disponíveis para otimizar o

desempenho das consultas. A seguir, estão os tipos de índices comuns no PostgreSQL:

Índice B-tree:

É o tipo de índice mais comum no PostgreSQL.

É eficiente para consultas de igualdade e intervalo.

Armazena os valores das colunas indexadas em uma estrutura de árvore balanceada.

Suporta consultas de correspondência exata, intervalos e ordenação.

Pode ser usado em colunas individuais ou em conjuntos de colunas.

Índice Hash:

43
Usa uma função hash para mapear os valores das colunas em um espaço de hash.

É eficiente para consultas de igualdade.

Ideal para colunas com distribuição uniforme de valores.

Não suporta consultas de intervalo ou ordenação.

Pode ser usado apenas em colunas individuais.

Índice GiST (Generalized Search Tree):

É um índice multidimensional extensível.

Suporta consultas espaciais e texto completo.

É usado para tipos de dados complexos, como geometria, texto, redes e outros.

Pode ser usado em colunas individuais ou em conjuntos de colunas.

Índice GIN (Generalized Inverted Index):

É um índice otimizado para pesquisas de texto completo.

Armazena as palavras-chave e as localizações onde elas ocorrem nos documentos.

Suporta consultas de texto completo eficientes.

É usado em colunas com conteúdo de texto.

Índice SP-GiST (Space-Partitioned Generalized Search Tree):

É um índice multidimensional extensível que suporta particionamento do espaço.

É usado para tipos de dados espaciais complexos, como geometria 3D, pontos em
movimento, etc.

Oferece suporte a consultas espaciais eficientes.

43
Índice BRIN (Block Range INdex): É um índice de range de bloco que divide os
dados em blocos e armazena informações de resumo sobre cada bloco, sendo eficiente
para consultas em larga escala.

Índice de expressão: Permite criar um índice com base em uma expressão ou função,
em vez de uma coluna.

Índice de texto completo: É um índice especializado para consultas de pesquisa de

texto completo, suportando recursos como stemming, pesquisa por frase, ranking e
mais.

43
 Índices chave reversa (Reverse Key Indexes)
Este tipo de índice pode ser usado em
tabelas que sofrem inserção massiva
de dados por múltiplas sessões
simultâneas, tabelas de log, tabelas
críticas podem sofrer bloqueios (Locks)
em função de alta atividade nos blocos
(Oracle) e paginas (SQL Server)
Este recurso somente está disponível
para Oracle e SQL Server
Quando um volume de transações de
update em um mesmo bloco ou pagina
, por exemplo 40 transações
simultâneas em um mesmo bloco um
índice deste tipo pode eliminar o hot
spot de atualização pois um índice
reverso irá espalhar os dados relativos
aos dados acessados através de
múltiplos blocos.

O índice de chave reversa (reverse key index) é uma técnica utilizada em bancos de
dados para otimizar o desempenho de consultas e reduzir o impacto de hot spots nos
índices.

No índice de chave reversa, as chaves dos registros são armazenadas em ordem

reversa dentro do índice. Por exemplo, se uma chave é composta por uma sequência
de caracteres como "ABCDE", no índice de chave reversa ela seria armazenada como
"EDCBA". Essa inversão da ordem das chaves ajuda a distribuir melhor os dados ao
longo da estrutura do índice.

A principal vantagem do índice de chave reversa é reduzir o impacto do hot spot, que
ocorre quando várias operações de inserção, atualização ou exclusão são realizadas
em registros com chaves próximas na sequência. Com o índice de chave reversa,
essas operações são distribuídas de forma mais uniforme ao longo do índice,
evitando concentrações em um ponto específico.

Além disso, o índice de chave reversa pode melhorar o desempenho de consultas que
envolvem a recuperação de registros em uma ordem específica. Por exemplo, em
consultas que utilizam a cláusula ORDER BY em uma coluna indexada com o índice de

44
chave reversa, os dados já estão fisicamente ordenados na direção desejada, o que
reduz a necessidade de reordenamento durante a execução da consulta.

No entanto, o uso do índice de chave reversa também apresenta algumas

desvantagens. A inversão das chaves aumenta a complexidade das consultas que
envolvem operações de busca e pode exigir um processamento adicional para
reverter a ordem das chaves durante a recuperação dos registros. Além disso, o
espaço de armazenamento necessário para o índice de chave reversa pode ser maior
do que o de um índice convencional.

Quanto à sua disponibilidade nos bancos de dados mencionados, o índice de chave

reversa pode ser usado no Oracle e no SQL Server, onde está disponível como uma
opção para criação de índices. No entanto, no PostgreSQL, não há um recurso
específico chamado "índice de chave reversa". No entanto, existem técnicas
alternativas que podem ser utilizadas para atingir resultados semelhantes ao reverter
a ordem das chaves em um índice, como o uso de funções ou a criação de índices
personalizados.

Concluindo, o índice de chave reversa é uma técnica de otimização que pode ser
aplicada em Oracle e SQL Server para melhorar o desempenho de consultas e reduzir
o impacto de hot spots em índices. Embora apresente vantagens significativas, é
importante considerar as desvantagens e avaliar cuidadosamente a sua aplicação em
cada cenário específico.

44
 Tipos de dados – Oracle
Tipo Dado menor valor maior valor tamanho ocupado bytes
VARCHAR2 1 4000/32767 Quantidade usada + 1 a 3
NVARCHAR2 1 4000/32767 Quantidade usada + 1 a 3
CARACTERES
CHAR 1 2000 Tamanho total definido
NCHAR 1 2000 Tamanho Total definido
CLOB 1 4GB Quantidade usada
NCLOB 1 4GB Quantidade usada
LONG 1 2GB Quantidade usada
RAW 1 2000 Quantidade usada
BINÁRIOS LONG RAW 1 2GB Quantidade usada
BLOB 1 4GB Quantidade usada
BFILE 1 4GB Armazenamento Externo
NUMBER 1 38 Tamanho definido / 2 somando se 2 limite 22
NUMÉRICOS FLOAT 1 126 22 bytes
BINARY_FLOAT Ponto flutuante 32 bits 4 bytes
BINARY_DOUBLE Ponto flutuante 64 bits 8 bytes

VARCHAR2:

Tamanho Limite: 1 a 4.000 bytes

Versão Introduzida: Oracle 6
Descrição: Armazena strings de tamanho variável, com um limite máximo de 4.000
bytes. É amplamente utilizado para armazenar texto.
NVARCHAR2:

Tamanho Limite: 1 a 4.000 bytes

Versão Introduzida: Oracle 9i
Descrição: Similar ao VARCHAR2, mas armazena strings de caracteres Unicode,
permitindo suporte para vários conjuntos de caracteres.
CHAR:

Tamanho Limite: 1 a 2.000 bytes

Versão Introduzida: Oracle 6
Descrição: Armazena strings de tamanho fixo, com um limite máximo de 2.000 bytes.
Espaços em branco são preenchidos à direita para atingir o tamanho especificado.
NCHAR:

45
Tamanho Limite: 1 a 2.000 bytes
Versão Introduzida: Oracle 9i
Descrição: Similar ao CHAR, mas armazena caracteres Unicode.
CLOB:

Tamanho Limite: 8.000.000.000 bytes (ou 4 GB em algumas versões)

Versão Introduzida: Oracle 8
Descrição: Armazena grandes volumes de texto, como documentos, com um limite
máximo de 4 GB em algumas versões do Oracle.
NCLOB:

Tamanho Limite: 8.000.000.000 bytes (ou 4 GB em algumas versões)

Versão Introduzida: Oracle 9i
Descrição: Similar ao CLOB, mas armazena caracteres Unicode.
BLOB:

Tamanho Limite: 4.000.000.000 bytes (ou 4 GB em algumas versões)

Versão Introduzida: Oracle 8
Descrição: Armazena dados binários de tamanho variável, como imagens, arquivos e
documentos, com um limite máximo de 4 GB em algumas versões do Oracle.
NUMBER(p, s):

Tamanho Limite: -10^38 +1 a 10^38 -1

Versão Introduzida: Oracle 2
Descrição: Armazena números de ponto flutuante ou números inteiros com precisão
p e escala s. A precisão representa o número total de dígitos e a escala representa o
número de dígitos à direita do ponto decimal.
FLOAT(p):

Tamanho Limite: Depende da precisão do número real

Versão Introduzida: Oracle 6
Descrição: Armazena números de ponto flutuante com precisão variável. A precisão é
especificada pelo usuário.
DATE:

Tamanho Limite: 01/01/4712 a 31/12/9999

Versão Introduzida: Oracle 6
Descrição: Armazena valores de data, incluindo dia, mês, ano e hora, se necessário.
TIMESTAMP:

Tamanho Limite: 01/01/4712 a 31/12/9999

45
Versão Introduzida: Oracle 9i
Descrição: Armazena valores de data e hora até a fração de segundo.
INTERVAL YEAR TO MONTH:

Tamanho Limite: -999.999.999 a 999.999.999

Versão Introduzida: Oracle 9i
Descrição: Armazena um intervalo de tempo em anos e meses.
INTERVAL DAY TO SECOND:

Tamanho Limite: -999.999.999 a 999.999.999

Versão Introduzida: Oracle 9i
Descrição: Armazena um intervalo de tempo em dias, horas, minutos e segundos.
BOOLEAN:

Tamanho Limite: Valores TRUE ou FALSE

Versão Introduzida: Oracle 12c
Descrição: Armazena valores booleanos, representando verdadeiro (TRUE) ou falso
(FALSE).
RAW:

Tamanho Limite: 1 a 2.000 bytes

Versão Introduzida: Oracle 6
Descrição: Armazena dados binários de tamanho fixo, com um limite máximo de
2.000 bytes.
LONG RAW:

Tamanho Limite: 2 GB
Versão Introduzida: Oracle 6
Descrição: Armazena dados binários de tamanho variável, com um limite máximo de
2 GB. Este tipo de dado está sendo descontinuado e é recomendado o uso de BLOB
em seu lugar.
BINARY_FLOAT:

Tamanho Limite: Precisão de ponto flutuante de 32 bits

Versão Introduzida: Oracle 10g
Descrição: Armazena números de ponto flutuante de precisão simples.
BINARY_DOUBLE:

Tamanho Limite: Precisão de ponto flutuante de 64 bits

Versão Introduzida: Oracle 10g
Descrição: Armazena números de ponto flutuante de precisão dupla.
ROWID:

45
Tamanho Limite: Representação física do endereço de uma linha
Versão Introduzida: Oracle 6
Descrição: Armazena um identificador único para uma linha em uma tabela.
UROWID:

Tamanho Limite: Representação lógica e física do endereço de uma linha

Versão Introduzida: Oracle 9i
Descrição: Similar ao ROWID, mas também armazena informações de objetos lógicos,
permitindo referências a objetos em diferentes tablespaces.

45
 Tipos de dados – Oracle
menor maior
Tipo Dado tamanho ocupado bytes
valor valor
DATE Data e Hora de 4712 AC a 9999 DC - 7 bytes
TIMESTAMP Data e Hora com fração decimal até 9 casas (7 a 11 bytes)
TIMESTAMP WITH Data e Hora com fração decimal até 9 casas 13 bytes)
TIMEZONE
DATAS
TIMESTAMP WITH
Data e Hora com fração decimal até 9 casas (7 a 11 bytes)
LOCAL TIMEZONE

INTERVAL YEAR TO
Ano e meses – 5 bytes
MONTH
INTERVAL DAY TO
Dias , Horas, Minutos e Segundos – 11 bytes
SECOND

DATE:

Tamanho Limite: 01/01/4712 a 31/12/9999

Versão Introduzida: Oracle 6
Descrição: Armazena valores de data, incluindo dia, mês, ano e hora, se necessário.

TIMESTAMP:

Tamanho Limite: 01/01/4712 a 31/12/9999

Versão Introduzida: Oracle 9i
Descrição: Armazena valores de data e hora até a fração de segundo.

INTERVAL YEAR TO MONTH:

Tamanho Limite: -999.999.999 a 999.999.999

Versão Introduzida: Oracle 9i
Descrição: Armazena um intervalo de tempo em anos e meses.

INTERVAL DAY TO SECOND:

46
Tamanho Limite: -999.999.999 a 999.999.999
Versão Introduzida: Oracle 9i
Descrição: Armazena um intervalo de tempo em dias, horas, minutos e segundos.

46
 Tipos de dados – SQL Server tamanho
Tipo Dado menor valor maior valor
ocupado
tamanho Time -3.40E + 38 3.40E + 38 4 bytes
Tipo Dado menor valor maior valor
ocupado
Datetime2 1753-01-01 00:00:00.000 9999-12-31 23:59:59.997 8 bytes
Bigint -9,22E+182^63-1 8 bytes
Datetimeoffset 01/01/1900 00:00 06/06/2079 23:59
Int -2,147,483,648 2,147,483,647 4 bytes Char 0001-01-01 31/12/9999
Smallint -32,768 32,7672 bytes Varchar
Tinyint 0 2551 bytes
Varchar(max)
Bit 0 11 a 8 bits
Decimal 1,00E+3810^38–1 1-9 = 5 bytes Text
10 a19 = 9 Mesmo tamanho
Numeric
bytes Nchar 0 chars 8000 caracteres definido para
20-28 = 13 coluna
Money Numero de
bytes
Nvarchar 0 caracteres 8000 caracteres caracteres
29-38 = 17 utilizados + 2 bytes
Smallmoney
bytes Numero de
Float Nvarchar(max) 0 caracteres 2^31 caracteres caracteres
Real no utilizados + 2 bytes
Numero de
Datetime -9,22E+142^63-1 / 10000 8 bytes Ntext 0 caracteres 2,147,483,647 caracteres caracteres
utilizados + 4 bytes
Smalldatetime -214,748.3648 214,748.3647 4 bytes Tamanho definido x
Binario 0 caracteres 4000 caracteres
2
4 bytes até 25
VarBinario 0 caracteres 4000 caracteres
posições e 8
Date -1.79E + 308 1.79E + 308 VarBinario(max) 0 caracteres 2^30 caracteres
bytes entre 26
e 53 posiçoes Image 0 caracteres 1,073,741,823 caracteres

Sql_variant 0 bytes 8000 bytes

Timestamp 0 bytes 8000 bytes

bigint:

Introduzido na versão: SQL Server 2000

Descrição: Armazena números inteiros grandes, com um intervalo de -
9.223.372.036.854.775.808 a 9.223.372.036.854.775.807.
int:

Introduzido na versão: SQL Server 7.0

Descrição: Armazena números inteiros, com um intervalo de -2.147.483.648 a
2.147.483.647.
smallint:

Introduzido na versão: SQL Server 7.0

Descrição: Armazena números inteiros pequenos, com um intervalo de -32.768 a
32.767.
tinyint:

Introduzido na versão: SQL Server 7.0

47
Descrição: Armazena números inteiros pequenos sem sinal, com um intervalo de 0 a
255.
bit:

Introduzido na versão: SQL Server 7.0

Descrição: Armazena um valor booleano, representado como 0 ou 1.
decimal(p, s):

Introduzido na versão: SQL Server 6.0

Descrição: Armazena números decimais exatos com precisão p e escala s.
numeric(p, s):

Introduzido na versão: SQL Server 6.0

Descrição: Similar ao tipo decimal, armazena números decimais exatos com precisão
p e escala s.
money:

Introduzido na versão: SQL Server 6.0

Descrição: Armazena valores monetários, com um intervalo de -
922.337.203.685.477,5808 a 922.337.203.685.477,5807.
smallmoney:

Introduzido na versão: SQL Server 6.0

Descrição: Armazena valores monetários menores, com um intervalo de -
214.748,3648 a 214.748,3647.
float(n):

Introduzido na versão: SQL Server 6.0

Descrição: Armazena números de ponto flutuante aproximados, com uma precisão
de até 15 dígitos.
real:

Introduzido na versão: SQL Server 6.0

Descrição: Armazena números de ponto flutuante de precisão simples.
date:

Introduzido na versão: SQL Server 2008

Descrição: Armazena valores de data, no formato AAAA-MM-DD.
time:

Introduzido na versão: SQL Server 2008

Descrição: Armazena valores de hora do dia, no formato HH:MM:SS[.mmm].

47
datetime:

Introduzido na versão: SQL Server 6.0

Descrição: Armazena valores de data e hora, no formato AAAA-MM-DD
HH:MM:SS[.mmm].
datetime2:

Introduzido na versão: SQL Server 2008

Descrição: Armazena valores de data e hora com uma precisão maior do que o tipo
datetime.
datetimeoffset:

Introduzido na versão: SQL Server 2008

Descrição: Armazena valores de data e hora com informações de fuso horário.
char(n):

Introduzido na versão: SQL Server 6.0

Descrição: Armazena uma string de tamanho fixo de n caracteres.
varchar(n):

Introduzido na versão: SQL Server 6.0

Descrição: Armazena uma string de tamanho variável, com um limite máximo de n
caracteres.
text:

Introduzido na versão: SQL Server 7.0

Descrição: Armazena uma string de tamanho variável, com um limite máximo de
2^31-1 (2.147.483.647) caracteres.
nchar(n):

Introduzido na versão: SQL Server 7.0

Descrição: Armazena uma string Unicode de tamanho fixo de n caracteres.
nvarchar(n):

Introduzido na versão: SQL Server 7.0

Descrição: Armazena uma string Unicode de tamanho variável, com um limite
máximo de n caracteres.
ntext:

Introduzido na versão: SQL Server 7.0

Descrição: Armazena uma string Unicode de tamanho variável, com um limite
máximo de 2^30-1 (1.073.741.823) caracteres.

47
binary(n):

Introduzido na versão: SQL Server 6.0

Descrição: Armazena uma sequência de bytes de tamanho fixo de n bytes.
varbinary(n):

Introduzido na versão: SQL Server 6.0

Descrição: Armazena uma sequência de bytes de tamanho variável, com um limite
máximo de n bytes.
image:

Introduzido na versão: SQL Server 6.0

Descrição: Armazena uma sequência de bytes de tamanho variável, com um limite
máximo de 2^31-1 (2.147.483.647) bytes.
uniqueidentifier:

Introduzido na versão: SQL Server 7.0

Descrição: Armazena um identificador exclusivo global (GUID).
xml:

Introduzido na versão: SQL Server 2005

Descrição: Armazena dados XML em formato texto ou binário.
hierarchyid:

Introduzido na versão: SQL Server 2008

Descrição: Armazena um caminho hierárquico em uma árvore.
sql_variant:

Introduzido na versão: SQL Server 6.0

Descrição: Armazena um valor de qualquer tipo de dados SQL Server, exceto text,
ntext, image, timestamp e sql_variant.
geography:

Introduzido na versão: SQL Server 2008

Descrição: Armazena dados geográficos, como coordenadas de latitude e longitude.
geometry:

Introduzido na versão: SQL Server 2008

Descrição: Armazena dados geométricos, como pontos, linhas e polígonos.
clr_udt:

Introduzido na versão: SQL Server 2005

47
Descrição: Armazena um tipo de dados definido pelo usuário implementado em
código .NET.

47
 Tipos de dados – PostgreSQL
Versão do
Versão do
Tipo de Dado PostgreSQL Tamanho Limite Tamanho Físico Máximo
Tipo de Dado PostgreSQL Tamanho Limite Tamanho Físico Máximo
-32.768 a 32.767 (-2
smallint 6.0 2 bytes
bytes) Tamanho fixo de n
6.0 n bytes
-2.147.483.648 a caracteres
integer 6.0 4 bytes char(n)
2.147.483.647 (-4 bytes) Tamanho ilimitado de
text 6.0 Variável
- texto
9.223.372.036.854.775.80 boolean 6.0 true ou false 1 byte
bigint 6.0 8a 8 bytes date 6.0 Data (4 bytes) 4 bytes
9.223.372.036.854.775.80
7 (-8 bytes) Hora sem fuso horário (8
time 6.0 8 bytes
Precisão e escala bytes)
decimal(precision, scale) 6.0 Variável
personalizadas Data e hora sem fuso
Precisão e escala timestamp 6.0 8 bytes
numeric(precision, scale) 6.0 Variável horário (8 bytes)
personalizadas
Precisão de 6 dígitos Data e hora com fuso
real 6.0 4 bytes timestamp with time zone 7.0 8 bytes
decimais (4 bytes) horário (8 bytes)
Precisão de 15 dígitos
double precision 6.0 8 bytes interval 6.0 Intervalo de tempo 12 bytes
decimais (8 bytes)
Depende do
money 6.0 Moeda (8 bytes) 8 bytes bit 6.0 Bit de comprimento fixo
comprimento
Tamanho variável de até n
character varying(n) 6.0 Variável
caracteres Bit de comprimento Depende do
bit varying(n) 6.0
Tamanho variável de até n variável de até n bits comprimento
varchar(n) 6.0 Variável
caracteres
Tamanho fixo de n Identificador único
character(n) 6.0 n bytes uuid 8.3 16 bytes
caracteres universal (16 bytes)
xml 8.3 Documento XML Variável

smallint:

Tamanho: -32.768 a 32.767 (-2 bytes)

Descrição: Armazena números inteiros de tamanho pequeno.
integer:

Tamanho: -2.147.483.648 a 2.147.483.647 (-4 bytes)

Descrição: Armazena números inteiros de tamanho médio.
bigint:

Tamanho: -9.223.372.036.854.775.808 a 9.223.372.036.854.775.807 (-8 bytes)

Descrição: Armazena números inteiros de tamanho grande.
decimal(precision, scale):

Tamanho: Variável
Descrição: Armazena números decimais com precisão e escala personalizadas.
numeric(precision, scale):

Tamanho: Variável

48
Descrição: Similar ao tipo decimal, armazena números decimais com precisão e
escala personalizadas.
real:

Tamanho: Precisão de 6 dígitos decimais (4 bytes)

Descrição: Armazena números de ponto flutuante com precisão média.
double precision:

Tamanho: Precisão de 15 dígitos decimais (8 bytes)

Descrição: Armazena números de ponto flutuante com alta precisão.
money:

Tamanho: 8 bytes
Descrição: Armazena valores monetários, como moedas.
character varying(n):

Tamanho: Tamanho variável de até n caracteres

Descrição: Armazena strings de tamanho variável, com limite de tamanho definido
por n.
varchar(n):

Tamanho: Tamanho variável de até n caracteres

Descrição: Similar ao tipo character varying, armazena strings de tamanho variável
com limite de tamanho definido por n.
character(n):
Tamanho: Tamanho fixo de n caracteres
Descrição: Armazena strings de tamanho fixo com limite de tamanho definido por n.
char(n):
Tamanho: Tamanho fixo de n caracteres
Descrição: Similar ao tipo character, armazena strings de tamanho fixo com limite de
tamanho definido por n.
text:
Tamanho: Tamanho ilimitado de texto
Descrição: Armazena strings de tamanho variável sem limite específico.
boolean:
Tamanho: 1 byte
Descrição: Armazena valores booleanos (true ou false).
date:
Tamanho: 4 bytes
Descrição: Armazena valores de data.
time:
Tamanho: 8 bytes

48
Descrição: Armazena valores de hora sem fuso horário.
timestamp:
Tamanho: 8 bytes
Descrição: Armazena valores de data e hora sem fuso horário.
timestamp with time zone:
Tamanho: 8 bytes
Descrição: Armazena valores de data e hora com fuso horário.
interval:
Tamanho: 12 bytes
Descrição: Armazena um intervalo de tempo.
bit:
Tamanho: Depende do comprimento
Descrição: Armazena sequências de bits de comprimento fixo.
bit varying(n):
Tamanho: Depende do comprimento
Descrição: Armazena sequências de bits de comprimento variável com limite de
tamanho definido por n.
uuid:
Tamanho: 16 bytes
Descrição: Armazena identificadores únicos universais.
xml:
Tamanho: Variável
Descrição: Armazena documentos XML.

48
 Tipos de dados – PostgreSQL
Versão do
Tipo de Dado PostgreSQL Tamanho Limite Tamanho Físico Máximo
Identificador de objeto (4
oid 6.0 4 bytes
bytes)
Nome de classe de objeto
regclass 7.4 4 bytes
registrado
Nome de tipo de objeto
Versão do regtype 8.3 4 bytes
registrado
Tipo de Dado PostgreSQL Tamanho Limite Tamanho Físico Máximo Configuração de pesquisa de
json 9.2 Dados em formato JSON Variável regconfig 9.1 4 bytes
texto
Dados em formato JSON Dicionário de pesquisa de
jsonb 9.4 Variável regdictionary 9.1 4 bytes
binário texto
point 9.1 Coordenadas de ponto 16 bytes Intervalo de inteiros de 4
int4range 9.2 12 bytes
line 9.1 Linha reta ou infinita 32 bytes bytes
Intervalo de inteiros de 8
lseg 9.1 Segmento de linha 32 bytes int8range 9.2 20 bytes
bytes
Intervalo de valores
numrange 9.2 Variável
Retângulo delimitado por numéricos
box 9.1 32 bytes
coordenadas Intervalo de carimbo de
tsrange 9.2 Variável
data/hora
Caminho aberto ou
path 9.1 Variável Intervalo de carimbo de
fechado de pontos tstzrange 9.2 Variável
Polígono delimitado por data/hora com fuso horário
polygon 9.1 Variável Identificador de objeto (4
coordenadas oid 6.0 4 bytes
Círculo delimitado por bytes)
circle 9.1 24 bytes Nome de classe de objeto
coordenadas regclass 7.4 4 bytes
Endereço IPv4 ou bloco de registrado
cidr 9.4 Variável
endereços IPv4
inet 9.4 Endereço IPv4 ou IPv6 Variável Versão do
macaddr 9.4 Endereço MAC (6 bytes) 6 bytes Tipo de Dado PostgreSQL Tamanho Limite Tamanho Físico Máximo
daterange 9.2 Intervalo de datas Variável
tsvector 8.3 Vetor de pesquisa em texto Variável Tipo de dado composto
composite 6.0 Variável
personalizado
Consulta de texto em vetor
tsquery 8.3 Variável Tipo de enumeração
de pesquisa enum 8.3 4 bytes
personalizado
array 8.0 Array de valores Variável
Intervalo de valores
range 9.2 Variável
genéricos

json:
Tamanho: Variável
Descrição: Armazena dados em formato JSON (JavaScript Object Notation).
jsonb:
Tamanho: Variável
Descrição: Armazena dados em formato JSON binário.
point:
Tamanho: 16 bytes
Descrição: Armazena coordenadas de ponto em um plano cartesiano.
line:
Tamanho: 32 bytes
Descrição: Armazena uma linha reta ou infinita.
lseg:
Tamanho: 32 bytes
Descrição: Armazena um segmento de linha.
box:
Tamanho: 32 bytes
Descrição: Armazena um retângulo delimitado por coordenadas.
path:

49
Tamanho: Variável
Descrição: Armazena um caminho aberto ou fechado de pontos.
polygon:
Tamanho: Variável
Descrição: Armazena um polígono delimitado por coordenadas.
circle:
Tamanho: 24 bytes
Descrição: Armazena um círculo delimitado por coordenadas.
cidr:
Tamanho: Variável
Descrição: Armazena um endereço IPv4 ou bloco de endereços IPv4.
inet:
Tamanho: Variável
Descrição: Armazena um endereço IPv4 ou IPv6.
macaddr:
Tamanho: 6 bytes
Descrição: Armazena um endereço MAC (Media Access Control).
tsvector:
Tamanho: Variável
Descrição: Armazena um vetor de pesquisa em texto para suporte a pesquisa textual
eficiente.
tsquery:
Tamanho: Variável
Descrição: Armazena uma consulta de texto em vetor de pesquisa para suporte a
pesquisa textual eficiente.
oid:
Tamanho: 4 bytes
Descrição: Armazena identificadores de objeto.
regclass:
Tamanho: 4 bytes
Descrição: Armazena nomes de classe de objeto registrados.
regtype:
Tamanho: 4 bytes
Descrição: Armazena nomes de tipo de objeto registrados.
regconfig:
Tamanho: 4 bytes
Descrição: Armazena configurações de pesquisa de texto.
regdictionary:
Tamanho: 4 bytes
Descrição: Armazena dicionários de pesquisa de texto.
int4range:
Tamanho: 12 bytes

49
Descrição: Armazena um intervalo de inteiros de 4 bytes.
int8range:
Tamanho: 20 bytes
Descrição: Armazena um intervalo de inteiros de 8 bytes.
numrange:
Tamanho: Variável
Descrição: Armazena um intervalo de valores numéricos.
tsrange:
Tamanho: Variável
Descrição: Armazena um intervalo de carimbo de data/hora.
tstzrange:
Tamanho: Variável
Descrição: Armazena um intervalo de carimbo de data/hora com fuso horário.
daterange:
Tamanho: Variável
Descrição: Armazena um intervalo de datas.
composite:
Tamanho: Variável
Descrição: Armazena um tipo de dado composto personalizado.
enum:
Tamanho: 4 bytes
Descrição: Armazena um tipo de enumeração personalizado.
array:
Tamanho: Variável
Descrição: Armazena uma matriz (array) de valores.
range:
Tamanho: Variável
Descrição: Armazena um intervalo de valores genéricos.

49
 Visões
• Visões (views) com elas podemos melhorar consultas mais complexas,
inclusive adicionando índices para melhorar a performance das mesmas.
• Visões podem ser colocadas tanto em modelos lógicos , quanto em físicos
(Oracle Data Modeler, SAP Powerdesigner, Erwin)
• Visões tambem podem degradar a performance por isso é importante
avaliar as mesmas antes de implanta-las.

Visões no Oracle:
•Exemplos de uso: No Oracle, as visões podem ser utilizadas para:
• Simplificar consultas complexas: as visões podem ser criadas para
combinar várias tabelas e fornecer uma visão simplificada dos dados.
• Restringir o acesso aos dados: as visões podem ser usadas para fornecer
uma camada de segurança, limitando os dados que os usuários podem
ver.
• Ocultar detalhes de implementação: as visões podem ocultar os detalhes
internos das tabelas subjacentes, fornecendo uma interface mais abstrata
aos usuários.
•Características: No Oracle, as visões têm as seguintes características:
• São atualizáveis: dependendo da complexidade da visão e das regras de
atualização, é possível atualizar diretamente os dados por meio das
visões.
• Podem ser indexadas: é possível criar índices nas colunas das visões para
melhorar o desempenho de consultas frequentes.
• São armazenadas no banco de dados: as definições das visões são
armazenadas no dicionário de dados do Oracle.

50
Visões no SQL Server:
•Exemplos de uso: No SQL Server, as visões podem ser utilizadas para:
• Simplificar consultas e relatórios: as visões podem encapsular consultas
complexas e fornecer uma estrutura mais simples para criar relatórios ou
consultar dados.
• Esconder dados confidenciais: as visões podem ocultar informações
sensíveis, permitindo que apenas determinados usuários tenham acesso
a partes específicas dos dados.
• Fornecer uma camada de abstração: as visões podem ser usadas para
fornecer uma interface consistente aos usuários, independentemente da
estrutura das tabelas subjacentes.
•Características: No SQL Server, as visões têm as seguintes características:
• São atualizáveis: dependendo das regras de atualização definidas, é
possível atualizar os dados por meio das visões.
• Podem ser indexadas: é possível criar índices nas colunas das visões para
melhorar o desempenho das consultas.
• São armazenadas no banco de dados: as definições das visões são
armazenadas no banco de dados.

Visões no PostgreSQL:
•Exemplos de uso: No PostgreSQL, as visões podem ser utilizadas para:
• Simplificar consultas complexas: as visões podem combinar várias tabelas
e fornecer uma consulta mais simples e compreensível.
• Fornecer uma camada de segurança: as visões podem ser usadas para
restringir o acesso a determinadas colunas ou linhas de uma tabela.
• Fornecer uma visão personalizada dos dados: as visões podem ser usadas
para fornecer uma representação específica dos dados, como
agregações, transformações ou filtros.
•Características: No PostgreSQL, as visões têm as seguintes características:
• São atualizáveis (em versões mais recentes): a partir do PostgreSQL 9.3, é
possível criar visões materializadas que podem ser atualizadas
automaticamente.
• Podem ser indexadas: é possível criar índices nas colunas das visões para
melhorar o desempenho das consultas.
• São armazenadas no banco de dados: as definições das visões são
armazenadas no catálogo do PostgreSQL.

50
 Visões Indexadas
• Visões (views) podem tambem serem indexadas, para que possam oferecer
em alguns casos a possibilidade de melhor performance, em especial
quando utilizamos colunas na clausula where de alta cardinalidade (muitos
valores distintos) ou com grande quantidade de valores nulos, nesses dois
casos o índice poderá diminuir a necessidade de leitura de dados para
memória.
• Os índices em visões são indicados especialmente se as colunas usadas nos
mesmos forem de tabelas diferentes, ou se a visão utiliza uma cláusula
where com uma coluna com função (estilo UPPER em Oracle).
• Nesse caso as visões passam a ocupar espaço, não por si mesmas e sim
pelos índices que forem criados em cima das mesmas.
• Alguns SGBDs não permitem esse recurso, porém PostgreSQL e SQL Server
que são o alvo deste treinamento permitem a criação deste recurso

Mysql também não suporta esse recurso até a versão 5.7.

ORACLE:

Ao contrário de outros sistemas de gerenciamento de banco de dados, como o SQL

Server, o Oracle não suporta a criação de visões indexadas.

No Oracle, é possível criar visões normais, que são consultas salvas no banco de
dados, mas elas não têm a capacidade de serem indexadas. Para melhorar o
desempenho das consultas em visões, é possível criar índices nas tabelas subjacentes
às visões.

POSTGRESQL:

As materialized views no PostgreSQL permitem armazenar os resultados de uma

consulta em uma tabela separada, similar ao conceito de visões indexadas em outros
bancos de dados. Essa tabela é atualizada automaticamente de acordo com as

51
alterações nos dados subjacentes, oferecendo um desempenho aprimorado para
consultas frequentes e complexas.

Ao criar uma materialized view, você pode optar por criar índices nessa tabela para
melhorar ainda mais o desempenho das consultas. Esses índices podem acelerar o
acesso aos dados pré-calculados armazenados na materialized view.

É importante mencionar que, no PostgreSQL, as materialized views são atualizadas

manualmente ou por meio de agendamento, diferentemente das visões comuns que
são atualizadas automaticamente. Você precisa explicitamente executar uma
instrução REFRESH para atualizar os dados da materialized view.

SQL SERVER:

No SQL Server, é possível criar visões indexadas (indexed views), também conhecidas
como visões materializadas (materialized views).
As visões indexadas no SQL Server são visões físicas que armazenam os resultados de
uma consulta em uma tabela separada no banco de dados. Essa tabela é atualizada
automaticamente à medida que as alterações nos dados subjacentes ocorrem, o que
permite um desempenho aprimorado para consultas que dependem da visão.

Ao criar uma visão indexada, você pode criar índices na tabela associada à visão para
acelerar ainda mais as consultas. Esses índices permitem o acesso direto aos dados
pré-calculados armazenados na visão indexada, melhorando significativamente o
desempenho de consultas complexas ou agregadas.

As visões indexadas no SQL Server oferecem benefícios em termos de desempenho

ao reduzir o tempo necessário para executar consultas repetitivas e fornecer
respostas mais rápidas aos usuários. Além disso, as visões indexadas podem melhorar
a escalabilidade e a eficiência geral do sistema.

No entanto, é importante considerar que a criação de visões indexadas requer

planejamento adequado, pois pode ter impacto no consumo de espaço em disco e na
manutenção dos dados. Além disso, as visões indexadas são adequadas para
consultas frequentes e consultas que não exigem atualizações frequentes nos dados
subjacentes.

51
 Visões Indexadas

• Os efeitos positivos de visões indexadas são:

• Possibilidade de melhora no tempo de resposta de consultas complexas;
• Possibilidade de pesquisas em colunas não indexadas usando recursos como funções;
• Limitação de efeito de uso do índice apenas pela visão, não sendo aplicado a consultas
realizadas diretamente a tabela, não afetando planos de acesso já criados e
consolidados.

• Os efeitos negativos de uso para as visões indexadas são:

• Aumento no tempo de operações de DML nas tabelas;
• Aumento no espaço para armazenamento de dados;

Visões indexadas, também conhecidas como materialized views, oferecem vantagens

e desvantagens no uso tanto no SQL Server quanto no PostgreSQL. A seguir,
descrevemos as principais características de cada um:
Vantagens das visões indexadas:
SQL Server:

•Melhor desempenho de consultas: as visões indexadas no SQL Server podem

melhorar significativamente o desempenho de consultas complexas ou agregadas, ao
armazenar os resultados da consulta em uma tabela separada e criar índices nessa
tabela.

•Respostas mais rápidas: o uso de visões indexadas permite respostas mais rápidas
aos usuários, pois os dados pré-calculados são armazenados na visão indexada,
reduzindo a necessidade de recalcular a consulta toda vez que é executada.

•Escalabilidade: as visões indexadas podem melhorar a escalabilidade do sistema,

reduzindo a carga de processamento necessário para realizar consultas complexas ou
repetitivas.

52
PostgreSQL:

•Desempenho aprimorado: as materialized views no PostgreSQL oferecem um

desempenho aprimorado para consultas frequentes e complexas, ao armazenar os
resultados da consulta em uma tabela separada.

•Redução de carga no banco de dados: ao utilizar materialized views, as consultas são

direcionadas à tabela preenchida com os dados pré-calculados, reduzindo a carga no
banco de dados principal e melhorando a eficiência geral do sistema.

•Flexibilidade de atualização: as materialized views no PostgreSQL permitem

atualizações manuais ou programadas, o que oferece maior controle sobre o
momento em que os dados são atualizados.

Desvantagens das visões indexadas:

SQL Server:
•Uso de espaço em disco: as visões indexadas no SQL Server requerem espaço em
disco adicional para armazenar a tabela separada com os resultados pré-calculados.
Isso pode ser um problema em ambientes com limitações de espaço de
armazenamento.

•Manutenção de dados: as visões indexadas precisam ser atualizadas conforme os

dados subjacentes são modificados. Isso requer planejamento adequado para
garantir a atualização correta e o gerenciamento da integridade dos dados.

PostgreSQL:

•Atualização manual: as materialized views no PostgreSQL requerem atualizações

manuais ou programadas. Isso pode ser uma desvantagem se as informações
precisarem ser atualizadas com muita frequência ou em tempo real.

•Consumo de espaço em disco: assim como no SQL Server, as materialized views no

PostgreSQL também ocupam espaço em disco adicional para armazenar os dados
pré-calculados.

52
 Visões Materializadas
• Visões podem tambem ter um armazenamento físico, nesse
caso são chamadas visões materializadas (materialized
Views).
• São de grande importância em especial em casos de dados
que necessitem de replicação de dados (cópia física).
• Podem sofrer apenas operações de sincronismo (refresh) que
pode ser realizado em períodos de tempo pré-programados.
• Usadas em mecanismos de replicação assíncronos.
• Permitem mecanismos de indexação.
• Normalmente precisam de um mecanismo de acumulo de log
para que os dados possam ser propagados pelos mecanismos
de replicação.
• São especialmente úteis quando a replicação ocorre em
grandes volumes de dados.

Podem ocorrer entre instâncias em um mesmo servidor (replicação local), ou

entre servidores em uma mesma rede (replicação local) ou ainda entre
servidores separados por redes externas ,dedicadas ou não, chamadas de
replicações remotas.

Apenas os logs de alteração são capturados e através de um mecanismo de

conexão entre instâncias (database link – Oracle, Linked Server – SQL Server),
o mecanismo de atualização da visão materializada (mview refresh) que é o
responsável pela atualização dos dados da visão materializada.

Em Oracle o uso de visões materializadas apenas não garante operações de

DML no objetos replicados, para isso é necessário usar o mecanismo chamado
de advanced replication que permite operações de DML nas visões
materializadas e com isso a replicação pode se tornar bidirecional.

53
Visões materializadas, também conhecidas como materialized views, são objetos de
banco de dados que armazenam os resultados de uma consulta em uma tabela
separada. Essa tabela é preenchida com os dados resultantes da consulta e pode ser
atualizada automaticamente ou manualmente, dependendo do sistema de
gerenciamento de banco de dados utilizado. A seguir, descrevo as características
gerais das visões materializadas, bem como exemplos de uso e
vantagens/desvantagens nos bancos de dados Oracle, SQL Server e PostgreSQL:

Características das visões materializadas:

Armazenamento de resultados: as visões materializadas armazenam os resultados de

uma consulta em uma tabela física, permitindo o acesso rápido aos dados pré-
calculados.

Atualização automática ou manual: dependendo do banco de dados, as visões

materializadas podem ser atualizadas automaticamente em resposta a alterações nos
dados subjacentes ou exigir uma atualização manual programada.

Melhoria de desempenho: as visões materializadas podem melhorar o desempenho

das consultas ao evitar a reexecução da consulta original, usando os dados já
armazenados na tabela materializada.

Suporte a índices: é possível criar índices na tabela materializada para acelerar

ainda mais o acesso aos dados.

Redução da carga do banco de dados: ao usar uma visão materializada, as consultas

podem ser direcionadas à tabela materializada, reduzindo a carga no banco de dados
principal.

Exemplos de uso das visões materializadas:

Agregação de dados: criar uma visão materializada para armazenar os resultados de

uma consulta agregada, como a soma ou a média de valores de uma coluna, para
facilitar consultas futuras mais rápidas.

Pré-cálculo de dados complexos: criar uma visão materializada para armazenar

resultados de consultas complexas que envolvem várias tabelas ou cálculos
intensivos, reduzindo o tempo necessário para obter os resultados.

Cache de dados: usar uma visão materializada para armazenar dados

frequentemente acessados, melhorando o desempenho das consultas repetitivas.

53
Replicação de dados: criar visões materializadas em bancos de dados remotos para
manter cópias locais dos dados, melhorando a disponibilidade e o desempenho das
consultas locais.

Vantagens das visões materializadas:

Desempenho aprimorado: as consultas às visões materializadas são mais rápidas,

pois acessam os dados pré-calculados armazenados na tabela materializada.

Redução do tempo de resposta: a eliminação da necessidade de reexecutar consultas

complexas ou demoradas economiza tempo e melhora a experiência do usuário.

Suporte a consultas complexas: as visões materializadas facilitam a execução de

consultas complexas envolvendo várias tabelas ou cálculos intensivos.

Redução da carga no banco de dados: ao usar uma visão materializada, as consultas

podem ser direcionadas à tabela materializada, reduzindo a carga no banco de dados
principal.

Desvantagens das visões materializadas:

Overhead de atualização: a atualização das visões materializadas pode exigir recursos

adicionais de CPU e E/S, especialmente em cenários de atualização automática
frequente.

Uso de espaço em disco: as visões materializadas ocupam espaço em disco adicional

para armazenar os dados pré-calculados, podendo ser um problema em ambientes
com limitações de armazenamento.

Complexidade de manutenção: a criação e o gerenciamento de visões materializadas

exigem conhecimento e planejamento adequados, especialmente ao lidar com
atualizações e sincronização dos dados.

Funcionalidades incorporadas em visões materializadas nos bancos de dados Oracle,

SQL Server e PostgreSQL:

Oracle: O Oracle oferece recursos avançados para visões materializadas, como

suporte a refresh on commit, que atualiza a visão automaticamente após cada
operação de commit. Além disso, o Oracle permite criar índices e definir opções de
refresh personalizadas para controle granular da atualização dos dados.

53
SQL Server: O SQL Server oferece recursos como indexação de visões materializadas,
suporte a índices filtrados para reduzir o tamanho dos dados armazenados e opções
de agendamento de atualização para controle flexível da atualização dos dados.

PostgreSQL: O PostgreSQL também suporta visões materializadas, permitindo criar

índices para melhorar o desempenho e fornecendo opções de atualização manual ou
programada. No entanto, o PostgreSQL não possui recursos nativos

53
 Tabelas Particionadas
• Tabelas particionadas são um recurso que permitem
que uma tabela seja armazenada em porções físicas
compatíveis com a utilização das mesmas, isso é uma
pesquisa em uma tabela muito extensa ocorre em
função de colunas específicas, nesse caso podemos usar
do recurso de particionamento de tabelas.
• No banco de dados Oracle é considerada uma “option”
logo é necessário o licenciamento e pagamento da
licença de uso da mesma . Já no SQL Server faz parte do
produto Enterprise e pode ser utilizado sem nenhum
custo adicional. Em postgres e MySQL também existe o
recurso de tabelas particionadas.
• O particionamento pode ser realizado através de faixas
de valores (Range) , ou de valores específicos, ou
através de algoritmo de hash que irá decidir em qual
partição o registro será armazenado.

Conceito: As tabelas particionadas são uma técnica de design de banco de dados que
divide uma tabela em partes menores, chamadas de partições, com base em critérios
específicos. Cada partição é tratada como uma unidade separada dentro da tabela,
embora todas juntas formem a tabela completa.

Usabilidade: As tabelas particionadas são amplamente utilizadas em cenários onde

há uma grande quantidade de dados a serem armazenados e consultados. Elas são
especialmente úteis em ambientes de data warehousing e em aplicações que exigem
acesso eficiente a dados históricos.

Vantagens:

Melhor desempenho de consultas: ao dividir os dados em partições menores, as

tabelas particionadas permitem que as consultas sejam executadas de forma mais
eficiente, uma vez que apenas as partições relevantes são acessadas.

Facilidade de manutenção: o particionamento das tabelas pode facilitar as operações

de carga, eliminação e backup de dados, uma vez que é possível trabalhar com partes

54
menores da tabela.

Escalabilidade aprimorada: ao distribuir os dados em várias partições, as tabelas

particionadas permitem uma melhor escalabilidade, já que diferentes partições
podem ser armazenadas e processadas em dispositivos de armazenamento
separados.

Gerenciamento simplificado: o uso de tabelas particionadas pode simplificar o

gerenciamento de grandes volumes de dados, facilitando a organização e a
manipulação de partições individuais.

Desvantagens:

Complexidade adicional de design: a implementação de tabelas particionadas requer

um planejamento cuidadoso e uma consideração detalhada dos critérios de
particionamento, o que pode aumentar a complexidade do design do banco de
dados.

Gerenciamento e monitoramento das partições: é necessário acompanhar e manter

as partições individuais, o que pode exigir um esforço adicional de gerenciamento e
monitoramento.

Potencial duplicação de índices: em algumas implementações, pode haver a

necessidade de criar índices em cada partição, o que pode resultar em duplicação de
índices e uso adicional de espaço em disco.

54
 Tabelas Particionadas
• A volumetria é que irá indicar a necessidade de
particionamento, ou ainda no caso de limpeza das
tabelas através de expurgo de dados. Esses dois eventos
podem ser separados ou juntos, porem a chave de
partição é fundamental para o sucesso do uso do
particionamento
• A chave de particionamento é fundamental para que as
operações de pesquisa ocorram em uma ou em poucas
partições (intra-partition read).
• Particionamentos baseados em faixas de datas são
geralmente eficientes tanto para pesquisas quanto para
processos de arquivamento de dados.
• Tabelas particionadas podem ter ou não indices
particionados, por isso é importante entender e
compreender que a partição deve atender a maioria das
necessidades por pesquisa e para efeito de
arquivamento de dados.

Características das tabelas particionadas no Oracle:

Suporte a vários métodos de particionamento, incluindo por faixa, por lista, por
intervalo e por hash.

Capacidade de particionamento subparticionado, permitindo subdividir as partições

em subpartições.

Índices particionados para melhorar o desempenho das consultas.

Gerenciamento automático de partições, permitindo a adição e exclusão automática

de partições conforme necessário.

Suporte a partições globais e locais, dependendo da estratégia de particionamento

utilizada.

Recursos avançados de compressão de dados para reduzir o espaço de

armazenamento.

55
Características das tabelas particionadas no SQL Server:

Suporte a vários métodos de particionamento, como particionamento por intervalo,

por lista e por hash.

Capacidade de definir funções de particionamento personalizadas.

Índices particionados para melhorar o desempenho das consultas.

Opções de gerenciamento de partições, como a capacidade de alternar partições ou

mover partições entre grupos de arquivos.

Suporte a particionamento baseado em colunas calculadas.

Recursos avançados de compressão de dados para economia de espaço.

Características das tabelas particionadas no PostgreSQL:

Suporte a particionamento baseado em herança de tabelas.

Opções de particionamento por intervalo e por lista.

Capacidade de definir políticas de particionamento personalizadas.

Suporte a particionamento subparticionado.

Índices locais e globais para melhorar o desempenho das consultas.

Recursos avançados de compressão de dados para economia de espaço.

A partir do PostgreSQL 10, melhorias significativas foram feitas no particionamento,

incluindo melhor suporte ao particionamento por intervalo.

55
 Tabelas Temporárias
• Em um modelo de dados muitas vezes encontramos
tabelas usadas por processos de forma temporária e os
dados são desprezados após o seu uso, dessa forma
devem ser elencadas em um modelo de dados, porem
muitas vezes são misturadas com tabelas permanentes,
o que provoca um efeito chamado fragmentação de
datafile , que consiste em espaços vazios dentro de
arquivos de dados, impedindo ou atrapalhando a
alocação desse espaço para novas tabelas serem
alocadas de maneira eficaz. A regra de modelagem é
que essas tabelas sejam criadas segundo os padrões de
tabelas temporárias, usando-se segmentos temporários
de arquivos, em Oracle a tablespace temporária e no
SQL Server o database tempdb. Em alguns casos o
comando COMMIT pode apagar os dados e outas vezes
pode salvar até o fim da sessão corrente.

As tabelas temporárias são objetos em um banco de dados que são criados e

utilizados para armazenar dados temporários durante a execução de uma sessão de
usuário. Elas são projetadas para armazenar dados temporários que são necessários
apenas durante a execução de uma tarefa específica ou uma transação.

Usabilidade:

As tabelas temporárias são amplamente utilizadas em situações em que é necessário

armazenar dados temporários durante a execução de consultas complexas, processos
de carga de dados ou operações transacionais.

Elas podem ser usadas para armazenar resultados intermediários de consultas

complexas, permitindo que os usuários realizem várias etapas de processamento
antes de obter o resultado final.

Também podem ser usadas para armazenar dados temporários durante o

processamento de transações, permitindo a manipulação e o acesso a esses dados

56
em um contexto transacional.

Vantagens:

Eficiência e desempenho: As tabelas temporárias são armazenadas na memória ou

em um espaço de armazenamento temporário, o que geralmente proporciona acesso
rápido aos dados. Isso pode melhorar o desempenho das consultas e das operações
de manipulação de dados.

Escopo limitado: As tabelas temporárias existem apenas dentro da sessão de usuário

em que são criadas. Isso significa que cada sessão de usuário tem sua própria
instância exclusiva da tabela temporária, evitando conflitos de dados entre diferentes
sessões.

Gerenciamento simplificado: As tabelas temporárias são automaticamente

descartadas quando a sessão de usuário é encerrada ou quando a tabela temporária
é explicitamente descartada. Isso reduz a necessidade de gerenciamento manual e
libera recursos do banco de dados.

Desvantagens:

Acesso restrito: As tabelas temporárias são acessíveis apenas dentro da sessão de

usuário em que foram criadas. Isso significa que elas não podem ser compartilhadas
diretamente entre diferentes sessões de usuário.

Perda de dados: Se a sessão de usuário for encerrada inesperadamente ou se a tabela

temporária não for descartada corretamente, os dados armazenados nela serão
perdidos.

Sobrecarga de criação: Criar tabelas temporárias envolve uma pequena sobrecarga de

processamento para criar e descartar as tabelas. Em cenários de uso intenso, pode
haver um impacto mínimo no desempenho.

56
 Tabelas Temporárias
• Tabelas temporárias podem ter aspecto Global, uma vez
criadas persistem (estrutura) através das sessões e não
são eliminadas ao final da sessão (estruturas) e sim
apenas os seus dados são eliminados por cada sessão
realizada. O armzenamento dessas tabelas é feito em
segmentos temporários de memória física, em Oracle é
realizado na estrutura denominada tablespace de UNDO
e no SQL Server é feita no database denominado
tempdb.
• Junções complexas, com ou sem ordenação ou consultas
com funções de agrupamento , ou usando funções
analíticas são boas candidatas ao armazenamento em
tabelas temporárias.
• Em SQL server as tabelas podem ser temporárias locais
e servem a cada sessão individualmente, ao final das
mesmas são eliminadas estruturas e dados

Características, recursos e tipos de tabelas temporárias no Oracle:

Tabelas temporárias locais (Local Temporary Tables):

São criadas usando a cláusula "CREATE GLOBAL TEMPORARY TABLE" no Oracle.

Existem apenas durante a sessão de usuário em que foram criadas.

Os dados armazenados nessas tabelas são visíveis apenas para a sessão de usuário
que as criou.

Os dados são automaticamente removidos quando a sessão de usuário é encerrada.

Podem ser compartilhadas entre várias transações dentro da mesma sessão.

Características, recursos e tipos de tabelas temporárias no SQL Server:

Tabelas temporárias locais (Local Temporary Tables):

57
São criadas usando a cláusula "CREATE TABLE #TableName" no SQL Server.

Existem apenas durante a sessão de usuário em que foram criadas.

Os dados armazenados nessas tabelas são visíveis apenas para a sessão de usuário
que as criou.

Os dados são automaticamente removidos quando a sessão de usuário é encerrada.

Podem ser compartilhadas entre várias transações dentro da mesma sessão.

Tabelas temporárias globais (Global Temporary Tables):

São criadas usando a cláusula "CREATE TABLE ##TableName" no SQL Server.

Existem além da sessão de usuário em que foram criadas e podem ser acessadas por
outras sessões.

Os dados armazenados nessas tabelas são visíveis para todas as sessões que as
acessam.

Os dados são removidos quando a última sessão de usuário que as acessa é

encerrada.

Podem ser compartilhadas entre várias transações em diferentes sessões de usuário.

Características, recursos e tipos de tabelas temporárias no PostgreSQL:

Tabelas temporárias locais (Local Temporary Tables):

São criadas usando a cláusula "CREATE TEMPORARY TABLE" no PostgreSQL.

Existem apenas durante a sessão de usuário em que foram criadas.

Os dados armazenados nessas tabelas são visíveis apenas para a sessão de usuário
que as criou.

Os dados são automaticamente removidos quando a sessão de usuário é encerrada.

Podem ser compartilhadas entre várias transações dentro da mesma sessão.

57
Tabelas temporárias globais (Global Temporary Tables):

São criadas usando a cláusula "CREATE TEMPORARY TABLE" com a opção "ON
COMMIT PRESERVE ROWS" no PostgreSQL.

Existem além da sessão de usuário em que foram criadas e podem ser acessadas por
outras sessões.

Os dados armazenados nessas tabelas são visíveis para todas as sessões que as
acessam.

Os dados são preservados mesmo após o término da transação e são removidos

quando a sessão de usuário que as criou é encerrada.

Podem ser compartilhadas entre várias transações em diferentes sessões de usuário.

57
 Tabelas Externas /File tables
• A modelagem de dados de bancos de dados atuais cada
vez mais utilizam o recurso de armazenamento externo,
o que significa que os dados são armazenados em
arquivos externos ao banco de dados. Podem ser em
geral arquivos textos, utilizando separadores de colunas
ou ainda posicionais.
• Essas tabelas não oferecem suportes a constraints como
chaves primárias (Primary Keys – PKS), chaves únicas
(Unique Keys –UKS), chaves estrangeiras (Foreign Keys –
FKS), checks, e not nulls.
• As tabelas externas são uma excelente forma de
interface de dados entre bancos de dados heterogêneos
e as informações das mesmas podem ser consultadas
através de comando SELECT.
• Não oferecem suporte a outros comandos DML

As tabelas externas são recursos oferecidos por alguns bancos de dados, como
Oracle, SQL Server e PostgreSQL, que permitem acessar e consultar dados de fontes
externas ao banco de dados como se fossem tabelas internas. A seguir, descrevo o
conceito, a usabilidade, as vantagens e desvantagens, bem como as características
das tabelas externas em cada um desses bancos de dados:

Tabelas externas no Oracle:

Conceito: No Oracle, as tabelas externas são definidas como objetos de banco de

dados que representam dados armazenados em arquivos externos, como arquivos
CSV ou arquivos no formato Parquet. Elas fornecem uma maneira conveniente de
consultar e integrar dados externos em consultas SQL.

Usabilidade: As tabelas externas no Oracle são usadas quando é necessário acessar e

consultar dados que estão armazenados fora do banco de dados, como arquivos em
um sistema de arquivos ou dados em um servidor remoto.

Vantagens: As vantagens das tabelas externas no Oracle incluem a capacidade de

58
consultar dados externos sem a necessidade de importá-los para o banco de dados, o
que economiza espaço de armazenamento. Elas também permitem a integração de
dados externos com dados internos do banco de dados para análises e relatórios.

Desvantagens: Entre as desvantagens estão a possível dependência de fontes

externas de dados, a necessidade de garantir a consistência e a integridade dos dados
externos e a possibilidade de desempenho inferior em comparação com tabelas
internas.

Tabelas externas no SQL Server:

Conceito: No SQL Server, o recurso equivalente às tabelas externas é chamado de

"FileTable". O FileTable é uma tabela especial que permite armazenar, gerenciar e
acessar arquivos no sistema de arquivos do servidor como se fossem dados de tabela.

Usabilidade: As FileTables no SQL Server são usadas para armazenar e gerenciar

arquivos no sistema de arquivos do servidor, permitindo que os aplicativos acessem
esses arquivos usando consultas SQL regulares.

Vantagens: As vantagens das FileTables no SQL Server incluem a capacidade de

armazenar e gerenciar arquivos diretamente no sistema de arquivos, tornando-os
facilmente acessíveis e pesquisáveis. Elas oferecem uma maneira eficiente de
armazenar e consultar documentos, imagens ou outros tipos de arquivos.

Desvantagens: Entre as desvantagens estão a dependência do sistema de arquivos do

servidor, a necessidade de garantir a segurança e a integridade dos arquivos
armazenados e a possível complexidade de gerenciamento de arquivos.

Tabelas externas no PostgreSQL:

Conceito: No PostgreSQL, o recurso equivalente às tabelas externas é chamado de

"Foreign Tables". As Foreign Tables permitem que os usuários acessem dados
externos de outras fontes de dados (como outros bancos de dados, serviços web ou
arquivos CSV) como se fossem tabelas internas no PostgreSQL.

Usabilidade: As Foreign Tables no PostgreSQL são usadas para integrar dados de

fontes externas ao banco de dados, permitindo que os dados sejam consultados e
manipulados usando a sintaxe SQL padrão.

Vantagens: As vantagens das Foreign Tables no PostgreSQL incluem a capacidade de

integrar dados de várias fontes em consultas SQL, facilitando a análise e a integração
de dados heterogêneos. Elas oferecem flexibilidade ao acessar dados de diferentes

58
sistemas sem a necessidade de importá-los para o PostgreSQL.

Desvantagens: Entre as desvantagens estão a possível dependência de conectividade

externa, a necessidade de configurar e gerenciar a conexão com a fonte de dados
externa e a possível diferença de desempenho em comparação com tabelas internas.

58
Tabelas Externas /File tables
• Devem ser utilizadas para transporte de dados entre
sistemas e ou bancos distintos ou fisicamente
apartados e ou em casos de bancos de dados OLAP
(Data Warehouse).
• O dicionário de dados armazena informações da
estrutura e apresenta ao SGBD numa estrutura de
tabela, o que possibilita a consulta da mesma.
• O armazenamento pode ser feito ainda para arquivos
binários utilizando-se o tipo de dado BFILE, que
armazena um ponteiro referenciando a tabela e pode-se
abrir o arquivo através de recursos do SGBD oracle, este
recurso difere da tabela externa pois se trata de coluna
listada em uma tabela comum cujo conteúdo está
depositado em um arquivo (texto ou binário).

59