Olá Julino esses dias estavamos discutindo sobre isso olha o que o chiappa respondeu em um dos email que mandeí para a lista.
Cara, afirmar de cara limpa, SEM nenhuma restrição, que X é melhor, independente de qual aplicativo se usa, de quaisquer condições, como dá a entender a citação que vc faz desse tal livro, é no mínimo arriscado : de curiosodade, que livro é esse ?? Bom, vamos pingar os Is aí : pro Extent Management é isso mesmo, pode ser UNIFORM ou AUTO. A opção de UNIFORM indica que os extents vão ser sempre do mesmo tamanho, PORTANTO vc a usará quando SABER que esse tamanho é bom e apropriado, e isso INDEPENDE em grande porção de "tamanho de tabela", ok ? Tranquilamente vc PODE ter uma tabela pequena, de alguns poucos milhares de registros que seja mas que seja de tamanho previsível e que vc QUEIRA obter um Full table scan o mais eficiente possível, E onde vc queira ter uma previsão bem exata do espaço que será consumindo, então num caso desses faria TODO O SENTIDO usar UNIFORM, confere ?? A outra opção numa tablespace LMT, a AUTO ou SYSTEM allocated (vc não diz mas pelo contexto tá claro que é LMT que vc, corretamente, está usando), realmente inicialmente cria primeiro extents de 64 Kb, depois nas próximas vezes que o segmento pedir mais espaço vai paulatinamente aumentando o tamanho dos extents : ela é mais indicada imho pros casos onde vc NÃO tem como saber nem o tamanho ótimo de extent pra favorecer I/Os nem o tamanho máximo/mínimo da tabela. ==> Só para constar, a questão do tamanho do extent pega nos seguintes pontos : a) o I/O multiblock no Oracle é feito por extent, se vc tiver um extent menor do que o tamanho do seu I/O multiblock vc está tendo aí um uso ineficiente da sua capacidade de I/O b) um extent muito grande pode levar a desperdício de espaço, pois assim que vc cria um segmento (ainda sem dados!!) o bd já aloca um extent, então extent de vários Mbs prum segmento que vai ter tipo meia dúza de linhas é desperdício TOTAL de espaço Já pro ASSM (Auto Segment Space Management) realmente ele funciona como descrito, mas ele TEM SIM implicações e consequências, acho meio irresponsável tascar num livro "ah, usa ele que é melhor e mais fácil" sem explicar o que vc pode encontrar, vc o pode usar SE e apenas SE for nos casos onde as implicações não te tragam complicações ;) Por exemplo, preenchimento dos blocos : embora o algoritmo seja absolutamente não-documentado, com certeza ele deve mudar o preenchimento dos blocos cfrme o uso da tabela, é responsivo, e não há como ser pró-ativo, naquelas tabelas de históricos, coisa do tipo, onde vc SABE que só haverá INSERTs, e portanto quer ZERO espaço reservado para UPDATEs, faz todo sentido ter alocação manual e especificar PCTFREE 1 PCTUSED 99, ou mesmo 100% se aceitar. ==> Agora, coisas como acima são execeções, imho o ponto (algumas vezes contrário) principal do ASSM é : com espaço administrado por bitmap, é comum que diferentes bits apontem pra diferentes blocos, sobe bem a chance de vc ter diferentes INSERTs no mesmo segmento sendo alocados para blocos diferentes, aí é mais provável de vc ter (digamos) o insert do cliente 45 caindo no bloco X, o INSERT do cliente 46 no bloco Y, cliente 47 no bloco Z, assim por diante... E daí ? Daí que (cfrme o mecanismo de I/O do banco que todos nós já conhecemos, ou falei aqui em vão ;), o bd Oracle ** NÃO ** faz I/O de uma linha, mas sim de um bloco todo, no caso proposto se os clientes todos fosse lidos após o INSERT, se eles estivessem num só bloco só um bloco de dados iria pro cache, já se estiverem em nn blocos diferentes serão os nn blocos que vão subir pro cache, PORTANTO exigindo muito mais espaço no cache e PORTANTO talvez até num caso extremo tendo que tirar outros blocos de outros segmentos do cache pra fazer espaço... O Jonathan Lewis fala disso no livro de CBO mais recente dele, que estou lendo, por isso q fiquei sabendo desse cara, já que no meu banco só uso tablespaces non-ASSM . Fica ESPERTO com isso, teste BEM antes de sair usando... []s Chiappa --- Em [email protected], Welvis Douglas Silva Moreto <[EMAIL PROTECTED]> escreveu > > Olá pessial, estou com algumas duvida e não seu quando > vou utilizar isso algume podeira me ajudar dizendo se > entendi correto e me explicar se possivel quando devo > utilizar. > > Extent Management > > UNIFORM - Vai alocar de desalocar extents do > mesmo tamenho. Se não for especificado na criação vai > ser de 1M. > AUTOALLOCATE - Os tamanhos dos Extents são > diferentes é recomendado ou melhor utilizado para > proposito geral "tabelas grandes e pequenas". > > Segment Space Management > MANUAL - Usa Free List Bloks para inserir > junto com os parametos pct_free e pct_used, no caso de > Update e Delete usa o pct_used. > AUTO - Usa Bitmaps para gerenciar a free list > para ver qual qual bloco é valido para insert. Os > parametros pct_free e pct_used são ignorados, e não > são validos para temporary tablespaces ou system > tablespaces Automatic segment space management é > melhor e reduz sua atarefa de manutenção. Técnica > preferida "diz o livro que estou estudando". > > Bom, bem resumido acho que é isso. > > muito obrigado . > > att > > Welvis Douglas. --- Juliano <[EMAIL PROTECTED]> escreveu: > Olá lista. > > Instalei o Oracle 9i e criei novamente a base de > dados um cliente. > Acontece que antes esse banco usava tablespace DMT e > agora eu criei > as mesmas como LMT, conforme exemplificado abaixo. > > Por não conhecer o tamanho dos objetos, todas as > tablespaces ficaram > como AUTOALLOCATE. > > Acontece que hoje, os objetos mais utilizados no > Banco possuem algo > em torno de 85 extents. E o cliente reclama que > SOMENTE em um > processo de fechamento o tempo de execução dobrou. > Ainda estou > pesquisando outras hipóteses, mas gostaria de saber > se esses 85 > extents podem realmente ter comprometido a > performance?? > > Agradeço a atenção e ajuda de todos. > > > CREATE TABLESPACE XXX_DATA > DATAFILE > '\xxx\data.dbf' SIZE 2048 M > LOGGING > DEFAULT NOCOMPRESS > ONLINE > PERMANENT > EXTENT MANAGEMENT LOCAL AUTOALLOCATE > SEGMENT SPACE MANAGEMENT AUTO > > > > > _______________________________________________________ Você quer respostas para suas perguntas? Ou você sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ -------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/[email protected]/ --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: http://www.oraclebr.com.br/ __________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
