Help com Performance

Discussão em 'Banco de Dados / Database' iniciado por robsonbraga, Abril 14, 2010.

Página 3 de 3
  1. ItaloSantiago

    ItaloSantiago Sem Pontuação

    Fizemos um esquema bem legal aqui na empresa que foi separar tabelas com mais de 1gb .

    Segue um exemplo, talvez ajude.

    b /bancos/d3/bi/gp100/srmovcon.b1 f 1000064
    b /bancos/d3/bi/gp100/srmovcon.b2 f 1000064
    b /bancos/d3/bi/gp100/srmovcon.b3
    #
    d "Schema Area":6,64;1 /bancos/d1/gp100/srmovcon.d1
    #
    d "Schema Dados":7,128;512 /bancos/d1/gp100/srmovcon_7.d1 f 1500032
    d "Schema Dados":7,128;512 /bancos/d1/gp100/srmovcon_7.d2 f 1500032
    d "Schema Dados":7,128;512 /bancos/d1/gp100/srmovcon_7.d3 f 1500032
    d "Schema Dados":7,128;512 /bancos/d1/gp100/srmovcon_7.d4 f 1500032
    d "Schema Dados":7,128;512 /bancos/d1/gp100/srmovcon_7.d5
    #TABELA DOCRECON
    d "Schema docrecon":8,128;512 /bancos/d1/gp100/srmovcon_8.d1 f 1500032
    d "Schema docrecon":8,128;512 /bancos/d1/gp100/srmovcon_8.d2 f 1500032
    d "Schema docrecon":8,128;512 /bancos/d1/gp100/srmovcon_8.d3 f 1500032
    d "Schema docrecon":8,128;512 /bancos/d1/gp100/srmovcon_8.d4 f 1500032
    d "Schema docrecon":8,128;512 /bancos/d1/gp100/srmovcon_8.d5
    #TABELA DOCUSOS
    d "Schema docusos":9,128;512 /bancos/d1/gp100/srmovcon_9.d1 f 1500032
    d "Schema docusos":9,128;512 /bancos/d1/gp100/srmovcon_9.d2
    #TABELA MOV-INSU
    d "Schema mov-insu":10,128;512 /bancos/d1/gp100/srmovcon_10.d1 f 1500032
    d "Schema mov-insu":10,128;512 /bancos/d1/gp100/srmovcon_10.d2
    #TABELA MOVIPROC
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d1 f 1500032
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d2 f 1500032
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d3 f 1500032
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d4 f 1500032
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d5 f 1500032
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d6 f 1500032
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d7 f 1500032
    d "Schema moviproc":11,128;512 /bancos/d1/gp100/srmovcon_11.d8
    #TABELA PROCUSOS
    d "Schema procusos":12,128;512 /bancos/d1/gp100/srmovcon_12.d1 f 1500032
    d "Schema procusos":12,128;512 /bancos/d1/gp100/srmovcon_12.d2
    #INDICES
    d "Schema indices":13,1;8 /bancos/d1/gp100/srmovcon_13.d1 f 1500032
    d "Schema indices":13,1;8 /bancos/d1/gp100/srmovcon_13.d2 f 1500032
    d "Schema indices":13,1;8 /bancos/d1/gp100/srmovcon_13.d3 f 1500032
    d "Schema indices":13,1;8 /bancos/d1/gp100/srmovcon_13.d4 f 1500032
    d "Schema indices":13,1;8 /bancos/d1/gp100/srmovcon_13.d5 f 1500032
    d "Schema indices":13,1;8 /bancos/d1/gp100/srmovcon_13.d6 f 2009728
    d "Schema indices":13,1;8 /bancos/d1/gp100/srmovcon_13.d7


    Essa situação resolveu meu problema.

    Att.

    Ítalo
    ItaloSantiago, Abril 15, 2010
    #13
  2. ItaloSantiago

    ItaloSantiago Sem Pontuação


    Concordo com neljr,

    Um exemplo típico que tivemos aqui.

    Para a área de Gestão de Saúde, um tempo atrás a Datasul soltou um df com 6 indices para incrementar em uma determinada tabela. essa minha tabela tem uns 12 a 15gb. e meu Bi (habilitando o large files) cresceu aproximadamente, 5gb.

    Após isso tivemos sérios problemas com performance, truncamos o BI e e fizemos a reindexação... e a performance melhorou consideravelmente.

    Enfim, não acredito que seja mito não.

    Abraço.


    Ítalo
    ItaloSantiago, Abril 15, 2010
    #14
  3. kirchner

    kirchner Membro Participativo Moderador

    Então,

    Truncar o BI piora o desempenho por pelo menos dois motivo:
    - o banco de dados tem que ser parado, o que faz com que todo o cache seja perdido. Isto significa milhões de acesso a disco dependendo do tamanho do banco;
    - o arquivo do BI é reduzido fisicamente, o que significa que ele terá que crescer novamente se houver demanda. Primeiro você gasta recurso para diminuir ele, depois gasta novamente para aumentar. Este problema pode ser amenizado com o parâmetro -bigrow.

    Alguns procedimentos exigem o BI truncado, então em algumas situações é importante. Mas não vejo porque transformar isso em rotina.

    O tamanho do arquivo de BI não influencia o tempo nem quantidade de checkpoints. O que influencia é o tamanho do cluster do BI. Quando maior o cluster, mais tempo entre os checkpoints.
    De qualquer forma, o checkpoint é um processo importante e necessário para o banco de dados (do contrário ele nem existiria), e fazer com que ocorra apenas 1 checkpoint por dia normalmente não é uma boa ideia.
    kirchner, Abril 15, 2010
    #15
  4. neljr

    neljr Sem Pontuação

    Boa noite.
    Kirchner, bem, o BI tem q ser truncado com a base offline então não precisamos nos importar com acesso a disco inicialmente.
    Até porque isso é realizado durante um processo de manutenção.
    Concordo que é um processo importante para o banco. Mais ja vi clientes com um numero assustador de checkpoints onde com isso ai sim a questão de acesso a disco conta muito.
    O I/O de disco subia muito causando um grande gargalo em diversosmomentos do dia.
    O gastar para aumentar semper vai existir na minha opinião.
    O problema é que esses checkpoints tem que ser digamos meio que controlados, pois imagine, por algum motivo perder todos os dados do BI por um comando por exemplo truncate -F. Pois era a unica maneira de conseguir fazer o banco voltar. Dependendo do metodo de backup, pode-se perder muito tempo de dados e com certeza o emprego de alguem.
    Acho que a melhor forma é gerenciar o crescimento do BI e em alguns casos realizar esse truncamento caso os parametros não estejam "redondos".

    Abraço.
    neljr, Abril 16, 2010
    #16
  5. kirchner

    kirchner Membro Participativo Moderador

    Esse é o meu ponto: se você precisa executar o TRUNCATE BI toda hora para garantir a recuperabilidade e estabilidade do banco de dados, tem alguma coisa muito errada mais embaixo.

    Claro que é ruim perder um BI com 200 MB de transações pendentes quando o banco cai. Mas quando você tem um plano de recuperação (e não apenas um plano de backup) estas questões são insignificantes.

    E se algum DBA realmente chegar numa situação em que a única opção é o TRUNCATE -F, de duas uma:
    - os dados não são importantes, então o banco pode ser danificado sem problemas;
    - não há um plano de recuperação adequado à criticidade dos dados.
    kirchner, Abril 19, 2010
    #17
Página 3 de 3

Compartilhe esta Página