none
Tamanho de um bloco de disco RRS feed

  • Pergunta

  • Olá gente.

    Sou novo no mundo sql, mas estou estudando bastante sobre ele. Eu li que o sql tem páginas com tamanho de 8k e que ele lê estas páginas de 8 em 8 páginas. Então ele carrega na memoria 64k.

    Isso quer dizer que eu teria maior velocidade com meu sql se eu colocasse o tamanho de cada bloco de disco com 64k? Pois se ele for ler tabelas com índice cluster, ele pegará (eu não lembro o nome mas acho que é 8 páginas de 8k contiguas) :P, então gastará apenas uma única leitura naquele bloco de disco.

    Tem lógica?

    Hoje meu disco está com 512bytes e é raid 5 e tem só o arquivo mdf, e estou percebendo muito status do tipo latch. Alguém consegue me ajudar? Obrigado a todos.

    =D

    quinta-feira, 29 de julho de 2010 17:15

Respostas

  • Boa tarde Sql Novato, tudo bem?

    Na verdade o conceito para sistemas operacionais está correto.. porém, de acordo com suas informações, você está trabalhando com um disco exclusivo para seu banco de dados..o raid 5 realmente é mais lento que o raid 0 ou 1. Porém, em caso de recuperação de desastre ele é rápido e recomendado e mais utilizado em ambientes de banco de dados (BOL).

    Melhor seria um ambiente RAID 10, mas seu custo é caro.

    Agora voltando a questão do alinhamento... independente de você trabalhar com um disco exclusivo ou não, é preciso ter em mente que ao formatar um disco, o sistema operacional colocará sua assinatura... porém, esta assinatura independe do tamanho de cada bloco.

    O conceito é bem parecido com páginas do sql.. o sq possui páginas de 8192 bytes. Cada endereço físico é conhecido como offset, formando um array da posição 0 0x00 - 0x00 até 8191 0xFF - 0xFF. Toda página do sql possui uma estrutura chamada cabeçalho que vai do offset 0 0x00 - 0x00 até 95 0x5F - 0x5F, 96 bytes.

    Assim é para o disco. Por padrão os SO MSFT anteriores ao 2008, inicia o disco com 31,5 kb.. o sql server trabalha com o conceito de extent que é a movimentação de 8 em 8 páginas o que matemáticamente resulta em 64kb. Se pegarmos então 31,5kb e multiplicarmos por 1024, será possível obter o offset que iniciam os dados no disco. Devemos pegar este endereço e dividir pelo bloco de leituras da ferramenta desejada (sql mdf 64kb) e teremos um valor não inteiro. O resultado sigifica que os offsets não estão alinhados. Isso causa o efeito que você desenho acima (copiando sua imagem para msotrar o resultado):

    Sem Alinhamento: 32k---|inicio bloco 2--fim bloco|2inicio bloco 3--fim bloc|o3inicio bloco 4[...]

    Como o disco é segmentado, se não iniciarmos um dado desejado no "lugar certo", toda vez que o Sql fizer um cálculo para saber onde está o dado, ele poderá dar umas "voltinhas a mais" --> IOs desnecessários resultando no tipo de espera pageiolatch_sh citado.

    Tentado resumir toda a conversa, você deverá usar um programa chamado: DISKPART (presente no SO MSFT 2k3 newer) para iniciar o offset em 1MB ou 1024kb, que resulta no offset: 1,048,576 ou 1,048,576 bytes. Para isso você deve deletar as partições do disco desejado e recriar a partição com esse offset. Você pode obter mais informações sobre a ferramenta no Bing, procurando pela ferramenta Diskpart.

    Depois, deve formatar o disco com blocos de 64kb, se dividirmos o offset 1,048,576 por 64, teremos um valor inteiro, significando que os discos estão alinhados... cálculos redondos para o sql trabalhar, menos "voltinhas" com IOs e mais performance..

    Para o LDF, o sql server não trabalha com páginas e sim com registros de logs e por ser escrito com apis do SO, ele usa páginas de 4kb... ele não pode ser colocado em um sistema de arquivos comprimido, por questões de cálculo isso também reduz a performance...

    Tá voltando ao resumo..

    Não é a formatação de 64kb apenas que vai lhe ajudar.. é a formatação com blocos de 64kb mais o início do offset após a assinatura do SO que lhe ajudará a ter (copiando novamente seu desenho), o seguinte resultado:

    Alinhamento 1: 1MB---|inicio bloco 2--fim bloco2|inicio bloco 3--fim bloco3|

    Atenciosamente,

    Dobereiner Miller Silva Rodrigues

    sqlinternal.blogspot.com


    Aquilo que sou é aquilo que me foi outorgado
    segunda-feira, 9 de agosto de 2010 19:39

Todas as Respostas

  • SQL Novato,

    Então não podemos pensar que esta alteração possa melhorar a performance do SQL Server. Para que você possa entender o conjunto de oito páginas de dados é definido como uma Extended no tamanho de 64kbs. Por padrão o Windows trabalho com 4kbs para área relacionada ao seu bloco de disco.

    Este tipo de alteração poderá refletir negativamente em outros aplicativos que trabalham neste mesma máquina.

    Você destacou que esta utilizando RAID 5 em um único banco de dados? Qual é o tamanho deste banco? Talvez você poderia analisar outras possibilidades de melhoria de performance para seu ambiente, implementando outros recursos, talvez poderia utilizar mais de um filegroup e dividir seu banco em diversos arquivos de dados.

    Sobre este status latch, em quais situações você identificou isso?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    sexta-feira, 30 de julho de 2010 01:13
    Moderador
  • Olá, eu ainda tenho alguma dúvida sobre isso.

    O sql tem um os embutido que trabalha independente do sistema operacional, correto?.

    Eu desenvolvo um sistema operacional na faculdade e quando eu crio a partição MBR (master boot record) eu a construo com 512 bytes, depois eu reservo 31kb para a assinatura do os. Ou seja, assumo 32kb para iniciar o sistema. Eu sei que se eu escrever qualquer outra coisa no meu sistema, eu tenho que escrever em offssets, com blocos que através de um cálculo eu tenha um endereço inteiro. Mais ou menos assim ó:

    Alinhamento 1: 32k---|inicio bloco 2--fim bloco2|inicio bloco 3--fim bloco3|

    Isso seria um alinhamento do disco. Agora, se eu não fizer isso, eu teria algo assim:

    Sem Alinhamento: 32k---|inicio bloco 2--fim bloco|2inicio bloco 3--fim bloc|o3inicio bloco 4[...]

    A fórmula que usei para definir o tamanho do disco foi algo mais ou menos assim:

     Partition_Offset ÷ Stripe_Unit_Size

    Stripe_Unit_Size ÷ File_Allocation_Unit_Size

    O resultado dela sendo inteiro eu tenho o alinhamento, igual no alinhamento 1.

    Veja o trecho de um artigo que encontrei no technet:

    Sector Size vs. Stripe Size

    The sector size is the smallest physical storage unit on the disk. The sector size is a fixed size set by the disk manufacturer, currently at 512 bytes. The stripe size refers to the unit of data that is written and accessed from a disk in a RAID system. This is a configurable value that is set when designing the storage array system. A smaller stripe size allows data to be distributed to more disks and increase I/O parallelism. Note that the stripe size of a single SQL Server extent (64 KB) is the lower limit. For the same data, a larger stripe size means the data can be stored on fewer disks and decrease the I/O distribution and the degree of parallelism. We recommend a 64 KB or 256 KB stripe size for most workloads. When the workload includes table and index range scans on tables that are larger than 100 MB, a stripe size of 256 KB allows for more efficient read-ahead.

    O link: http://technet.microsoft.com/pt-br/library/cc966414%28en-us%29.aspx

    O que vocês me dizem disto?

    Minha base de dados é pequena cerca de apenas 140gb.

    Obrigado pessoal

    sexta-feira, 30 de julho de 2010 12:31
  • Bom, antes de tentar ajudá-lo, preciso das seguintes informações:
    1. Qual o perfil de uso do database, relação read/write?
    2. Você tem um baseline dos principais coletores de sistema?
     a.Physical Disk-Avg.Disk Reads/sec (Deve estar abaixo de 85% da capacidade do drive);
     b.Physical Disk-Avg.Disk Writes/sec (Deve estar abaixo de 85% da capacidade do drive);
     c.SQL Server:Buffer Manager-Buffer Cache Hit Ratio (Deve exceder os 90%, o ideal é permanecer em 99%);
     d.SQL Server:Buffer Manager-Page Life Expectancy (Usado para dimensionar a memória. Deve permanecer acima de 300 segundos);
     e.SQL Server:General Statistics-User Connections (usado para dimensionar a memória-50Kb por usuário);
     f.SQL Server:Databases-Transactions/sec;
    3. Quais os valores e incidências de auto-crescimento dos arquivos de data e log?
    4. Este servidor possui outra aplicação concorrente?

    Bom, o SQl organiza os dados em Data Extents (conjunto de 8 data pages de 8K cada um) que são posteriormente carregados para a memória durante as diferentes operações do database (Buffer Data Manager) e despejados em disco após o commit das transações (quando falamos de DML's, o select é um pseudo-dml). Caso você tenha muitas transações simultâneas que estressam o sistema de disco (RAID-5) o SQL começa a utilizar o Page File (area de swap) para agiliar o processo de leitura dos dados do disco, o SQL gerencia os data pages conforme o estado do mesmo na area de memória virtual (dirty Data Pages, etc.). Nesta situação, a lentidão do banco pode estar sendo causada pelo sistema de disco adotado RAID-5 (stress nas operações de escrita -> qtdade de escrita x Quantidade de discos do Raid) com blocagem de apenas 512 bytes somado a uma provável falta de memória.

    É recomendado que você distribua os arquivos MDF (data files) em volumes com blocagem de 64 Kb alinhados conforme spec de bloco inical da controladora de disco(use o comando PARTDISK), os arquivos LDF's (T-Logs) em partições também alinhadas e com blocagem de 32 Kb (devido a intensa escrita/checkpoints, etc.) e se possível separar os arquivos do TempDB em volumes reservados com blocagens de 32Kb (data+log no mesmo volume) e/ou 32 para partições de log e 64Kb para partições de dados.

    Espero ter ajudado.

    sábado, 31 de julho de 2010 15:11
  • Boa tarde Sql Novato, tudo bem?

    Na verdade o conceito para sistemas operacionais está correto.. porém, de acordo com suas informações, você está trabalhando com um disco exclusivo para seu banco de dados..o raid 5 realmente é mais lento que o raid 0 ou 1. Porém, em caso de recuperação de desastre ele é rápido e recomendado e mais utilizado em ambientes de banco de dados (BOL).

    Melhor seria um ambiente RAID 10, mas seu custo é caro.

    Agora voltando a questão do alinhamento... independente de você trabalhar com um disco exclusivo ou não, é preciso ter em mente que ao formatar um disco, o sistema operacional colocará sua assinatura... porém, esta assinatura independe do tamanho de cada bloco.

    O conceito é bem parecido com páginas do sql.. o sq possui páginas de 8192 bytes. Cada endereço físico é conhecido como offset, formando um array da posição 0 0x00 - 0x00 até 8191 0xFF - 0xFF. Toda página do sql possui uma estrutura chamada cabeçalho que vai do offset 0 0x00 - 0x00 até 95 0x5F - 0x5F, 96 bytes.

    Assim é para o disco. Por padrão os SO MSFT anteriores ao 2008, inicia o disco com 31,5 kb.. o sql server trabalha com o conceito de extent que é a movimentação de 8 em 8 páginas o que matemáticamente resulta em 64kb. Se pegarmos então 31,5kb e multiplicarmos por 1024, será possível obter o offset que iniciam os dados no disco. Devemos pegar este endereço e dividir pelo bloco de leituras da ferramenta desejada (sql mdf 64kb) e teremos um valor não inteiro. O resultado sigifica que os offsets não estão alinhados. Isso causa o efeito que você desenho acima (copiando sua imagem para msotrar o resultado):

    Sem Alinhamento: 32k---|inicio bloco 2--fim bloco|2inicio bloco 3--fim bloc|o3inicio bloco 4[...]

    Como o disco é segmentado, se não iniciarmos um dado desejado no "lugar certo", toda vez que o Sql fizer um cálculo para saber onde está o dado, ele poderá dar umas "voltinhas a mais" --> IOs desnecessários resultando no tipo de espera pageiolatch_sh citado.

    Tentado resumir toda a conversa, você deverá usar um programa chamado: DISKPART (presente no SO MSFT 2k3 newer) para iniciar o offset em 1MB ou 1024kb, que resulta no offset: 1,048,576 ou 1,048,576 bytes. Para isso você deve deletar as partições do disco desejado e recriar a partição com esse offset. Você pode obter mais informações sobre a ferramenta no Bing, procurando pela ferramenta Diskpart.

    Depois, deve formatar o disco com blocos de 64kb, se dividirmos o offset 1,048,576 por 64, teremos um valor inteiro, significando que os discos estão alinhados... cálculos redondos para o sql trabalhar, menos "voltinhas" com IOs e mais performance..

    Para o LDF, o sql server não trabalha com páginas e sim com registros de logs e por ser escrito com apis do SO, ele usa páginas de 4kb... ele não pode ser colocado em um sistema de arquivos comprimido, por questões de cálculo isso também reduz a performance...

    Tá voltando ao resumo..

    Não é a formatação de 64kb apenas que vai lhe ajudar.. é a formatação com blocos de 64kb mais o início do offset após a assinatura do SO que lhe ajudará a ter (copiando novamente seu desenho), o seguinte resultado:

    Alinhamento 1: 1MB---|inicio bloco 2--fim bloco2|inicio bloco 3--fim bloco3|

    Atenciosamente,

    Dobereiner Miller Silva Rodrigues

    sqlinternal.blogspot.com


    Aquilo que sou é aquilo que me foi outorgado
    segunda-feira, 9 de agosto de 2010 19:39