DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!


Artigo SQL Magazine 03 - Otimização e Tunning – Parte II

Artigo da Revista SQL Magazine -Edição 3.

Atenção: por essa edição ser muito antiga não há arquivo PDF para download.
Os artigos dessa edição estão disponíveis somente através do formato HTML.

 

Clique aqui para ler todos os artigos desta edição

Otimização e Tunning – Parte II

 

Nessa edição daremos continuidade as dicas sobre performance, enfatizando rotinas de reindexação e configurações globais dos servidores SQL Server 2000.

 

Um caso típico de fragmentação

 

Com o passar do tempo, as tabelas tendem a adquirir fragmentação – os dados que inicialmente ficavam próximos se tornam “espaçados”. Como analogia, imagine aquele caderninho de telefones, desses que todo mundo tem. Sempre que iniciamos um caderninho novo, temos a mesma idéia em mente: serei organizado o bastante para que esse caderninho não vire uma bagunça. Com o passar do tempo,  percebemos que algumas páginas estão praticamente vazias (não existem muitos nomes inciando com a letra “Z”), outras quase totalmente cheias (letra “P”)  e  várias páginas em fase de “transbordamento” (letra “A”,”C”, etc), sendo necessário o aproveitamento das folhas em branco para acomodar tantos nomes. Um dia, a situação torna-se insustentável – simplesmente não conseguimos achar de maneira eficiente o que procuramos, pois somos obrigados a folhear diversas páginas, num leva-e-traz que consome tempo e paciência. Por fim, decidimos aposentar o atual caderno, substituindo-o por outro. Resta-nos “passar a limpo” todos os endereços.

Num database os problemas não são muitos diferentes; precisamos periodicamente “passar a limpo” as páginas de dados, eliminando a fragmentação. Vejamos como isso acontece.

 

Conceitos sobre armazenamento de dados

 

No SQL Server 2000, o armazenamendo é feito em estruturas físicas conhecidas como “páginas”. Páginas constituem a unidade básica de I/O, possuem tamanho fixo de 8KB e são exclusivas para cada objeto (duas tabelas não podem compartilhar a mesma página). Por questões de otimização, páginas são agrupadas em unidades lógicas  denominadas “extents”. Uma extent corresponde a 8 páginas (64KB) e normalmente é a unidade utilizada para alocação de espaço para tabelas e índices. Observe que extents são alocadas para um mesmo tipo de página (veja tabela 1); dessa forma, páginas de dados e de índices são alocadas em extents distintas.

Uma extent pode ser compartilhada por mais de um objeto (extents mistas); normalmente um objeto nasce, cresce até 8 páginas em extents mistas, e passa para extents exclusivas. Os principais tipos de páginas encontram-se relacionadas na tabela 1.

 

Tabela-1: Principais tipos de páginas encontradas num database

 

Tipo de Página

Função

Data

Armazenam dados de tipos diferentes de text, ntext e image

Index

"



ATENÇÃO! A exibição deste artigo foi interrompida.


  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!






    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!



Publicidade
Autor
Equipe Devmedia

Noticias/Dicas/Artigos publicados.




Space do autor
Estatísticas
Favorito:
Comentários:
Feedback:
Utilidade:
0   0
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2012 - Todos os Direitos Reservados a web-03