Pular para o conteúdo
  • Este tópico contém 2 respostas, 3 vozes e foi atualizado pela última vez 8 anos, 1 mês atrás por Avatar de Fábio PradoFábio Prado.
Visualizando 3 posts - 1 até 3 (de 3 do total)
  • Autor
    Posts
  • #108342
    Avatar de Ricardo NevesRicardo Neves
    Participante

      Boa tarde senhores,

      Vocês conhecem algum material sobre melhores práticas para criação de tablespace e datafiles? Uma consultoria veio atá a empresa hoje e disse que pode melhorar a performance de nosso ambiente apenas recriando/gerenciando nossas tablespaces de uma maneira diferente do que está hoje, além de diminuir nosso número de datafiles e tablespaces, será que conseguem mesmo?

      Nossas tablespaces são criadas da seguinte maneira:

      create tablespace xxxxxx
      Datafile ‘+xxxx’ size 100m
      autoextend on next 100m maxsize 32768m
      LOGGING EXTENT MANAGEMENT LOCAL
      SEGMENT SPACE MANAGEMENT AUTO;

      Esta criação causaria algum problema de I/O ao meu storage?

      Idéias???

      Abs!

      #108343
      Avatar photoJosé Laurindo Chiappa
      Moderador

        Opa : então, no que se refere á críticas / possíveis melhorias no seu gerenciamento de tablespaces, digo que :

        a. vc está usando autoextend con next fixo de 100m : isso implica ** se ** vc tiver um segmento que constantemente cresça mais de 100m por vez vc está Forçando o RDBMS a ir no disco e alocar 100m (o que leva um tempinho, isso É uma série de I/Os físicos), registrar esse extent no dicionário de dados, depois fazer de novo e de novo até completar ou ultrapassar o necessário pro segmento… Obviamente, num caso desses vc Pode observar alguma melhoria deixando o extent size automátio ** ou ** se for o caso colocando um maior….

        e

        b. com SEGMENT SPACE MANAGEMENT AUTO vc diz pro RDBMS que a reserva/controle de espaço nos blocos deve ser feita Automaticamente e de maneira IGUAL pra todos os segmentos naquela tablespace : via de regra isso vai bem, mas COM CERTEZA num aplicativo gerencial/administrativo vc VAI TER aqueles casos excepcionais onde (digamos) a tabela é de Histórico então nenhum espaço deve ser alocado para futuros UPDATEs, aí ganha-se algum espaço (e potencialmente performance evitando os cálculos necessários pro AUTO) indicando-se PCTFREE/PCTUSED customizados…

        Em cima disso, a primeira resposta é : essa consultoria ** FOI ATÉ A SUA EMPRESA ** e LEVANTOU de verdade frequência de alocação e tamanhos de extents, tipo de utilização das tabelas (ie, o quanto são dados “online” e o quanto são “arquivamentos”/dados históricos), o quanto de INSERTs/UPDATEs/DELETEs costuma acontecer, os volumes de dados, etc ??? SE SIM, ok até aceito que ela possa indicar melhoria real, mas SE NÃO, se ela NÂO FEZ a análise real, aí imho essa Consultoria tá te vomitando regras tiradas do bolso do colete, sabe deus se vão ser aplicáveis pro seu caso ou não…
        A única exceção a isso é se o teu Aplicativo é um software de prateleira (ie, não desenvolvido internamente) – um ERP, digamos-, e a tal Consultoria é especializada nesse software : aí sim, mesmo sem levantamento muitas vezes há best practices que quase sempre são aplicáveis… Mas falando do RDBMS como um modo geral, NÃO TEM COMO alguém fazer uma afirmação dessas sem ter ANALISADO TEU AMBIENTE, cuidadosamente…

        Isso dito, a segunda resposta : não, não há um documento de best practices para tablespaces/datafiles , justamente por ser algo que depende MUITO do ambiente, do modo de utilização… Via de regra (exemplos, http://www.oracle.com/technetwork/database/manageability/1241-minhas-pres-128727.pdf , http://www.oracle.com/technetwork/database/manageability/dba-best-practices-ow08-129450.pdf) para tablespaces a Oracle recomenda deixar tudo no automático mas sempre temos que ter olho atento para as Exceções….

        Finalmente, uma Observação : a não ser em casos excepcionais onde estejamos falando de não-sei-quantos terabytes por tablespace com centenas de milhares de segmentos gigantescos, cheios de extents e sendo acessados preferencialmente por scan, tenha em mente que vc até pode ter alguma melhoria mexendo em condições/cláusulas de tablespaces e de extents/segments, mas eu ESPERARIA que tal melhoria fosse mínina, coisa de Poucos Percentuais se chegar a isso – a razão é ÓBVIA, o RDBMS Oracle nunca varre um datafile e/ou tablespace do início ao fim, e sim mantém pointers internos indicando o OFFSET deles a partir do bloco de início…. Assim, QUANTO essa Consultoria te prometeu de melhoria só alterando tablespaces, datafiles, extents e (imagino) segmentos : se foi alguma coisa relativamente baixa OK, é factível, já se te prometeram digamos 30% de melhoria só com isso, eu DE IMEDIATO rejeitaria como papo-furado…. Blz ??

        []s

        Chiappa

        #108344
        Avatar de Fábio PradoFábio Prado
        Participante
        Visualizando 3 posts - 1 até 3 (de 3 do total)
        • Você deve fazer login para responder a este tópico.
        plugins premium WordPress