E é claro , isso que eu disse da comparação de performance entre um arquivo gigante de tamanho X gigabytes ou N arquivinhos de tamanho menor que somem X gigabytes no total ser indiferente só vale ** SE ** estamos comparando ambos os casos sendo servidos pelo mesmo exato hardware de I/O - é CLARO que se vc tiver um arquivo A residente num único disco versus os n arquivinhos espalhados em vários discos, aí É CLARO que daria diferença....
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" <jlchiappa@...> escreveu > > Tudo jóia, Rafael ?? Então, na verdade NÂO É o fato de vc abrir o arquivão > grandão que degrada, MAS SIM quando vc abre E LÊ / CARREGA PARA A MEMÓRIA o > arquivo, sim ??? Abrir apenas absolutamente ** Não ** gasta recursos > apreciáveis, é só um file handle que foi usado, não se consumiu RAM, CPU, I/O > ou rede quase nenhum... Faça uma experiência : crie um arquivo gigantesco na > sua máquina de testes, meça a performance da máquina com os utilitários de So > que vc tenha, depois faça um programinha numa linguagem de programação que > domine e permita abrir arquivos (pode ser Java, C, .NET, VB, a que quiser e > conhecer) que abra esse arquivo (SEM o ler, apenas o abra) e fique em pausa , > aí noutra janela meça de novo a performance da máquina, vc vai ver que está > praticamente IDÊNTICA... > É justamente esse o ponto aonde a sua analogia cai pela base , é que o > RDBMS Oracle **** nunca **** lê um datafile inteiro, do começo ao fim, okdoc > ? Por que ?? Vamos ver... > > ==> Primeiramente, ESSA é a principal diferença do RDBMS para o editor de > texto : enquanto o editor de texto é Obrigado a ler o arquivo inteiro (ou uma > porção considerável dele), o RDBMS é um pouquinho mais esperto : ele divide o > datafile em pequenos pedaços de mesmo tamanho (o chamado BLOCO), e em cada > linha de cada tabela ele registra em qual bloco a linha está armazenada - > assim, se ele precisar recuperar a linha X que está, digamos, no bloco 5000 > do datafile, ele *** NÂO VAI ** ler do bloco 1 até o 5000 - como ele SABE o > tamanho do bloco (digamos que seja bloco de 8kb), se a informação está no > bloco 5000 ele faz uma continha de 5000 * 8 kb = 40960000, aí ele pede para > ler apenas essa posição do arquivo, yep ??? Esse tipo de operação, > posicionando o leitor numa dada posição do arquivo e assim evitando varredura > a partir do início se chama FILE SEEK (frequentemente abreviada por FSEEK, ou > similares), e existe em praticamente todas as linguagens de programação > modernas, mas principalmente existe na linguagem C, na qual o RDBMS Oracle > foi escrito... > > E quando não sabemos qual linha contém a informação desejada (ou então > queremos agrupar/processar MÚLTIPLAS linhas da tabela), e portanto não > sabemos quais blocos são necessários, o que livra o RDBMS de ler o arquivo > todo, bloco a bloco ??? O seguinte conceito : quando o RDBMS precisa de > espaço para gravar dados, ele não aloca um só bloco, mas sim TODO um conjunto > de blocos (de tamanho variável) chamado EXTENT, e o bloco de início de cada > extent fica armazenado no database - assim, para a tabela X o RDBMS *** SABE > *** que o primeiro extent começo no bloco tal, PORTANTO obviamente os n > blocos anteriores Não precisam ser lidos, a partir do incício do arquvi, sim > ???? Esquece isso, esse negócio de ler arquivo do início é coisa para editor > de texto, não para RDBMS .... > > Jóia ?? OBVIAMENTE por questão de didática eu falei aqui de modo geral, há > DIVERSOS detalhes importantes que vc VAi captar no manual de Concepts do > database, mas creio que o que eu falei já dá pra ter uma noção de porque o > tamanho do arquivo em si é irrelevante para a performance... Até se vc pensar > friamente um pouco a respeito, outras posições equivocadas sobre performance > (como por exemplo separar tabelas x índices em datafiles diferentes) com os > conceitos que expus caem por terra : SE o RDBMS ** nunca ** lê um datafile do > início ao fim, sempre "pulando" para o bloco desejado OU no mínimo para o > bloco aonde o extent se inicia, que diferença para a performance pode haver > se os índices estão no mesmo arquivo/datafile que os dados (num único enorme > arquivão gigante) ??? Bem pouca, Né ? > > []s > > Chiappa > > OBS : só para constar, o tamanho do arquivo pode ser ** crucial ** por > questões Administrativas, não para performance - por exemplo, em caso de > crash, quanto maior o arquivo mais tempo ele leva para ser voltado do backup, > né ?? Ou ainda , os eventuais limites : de repente o teu hardware, ou qquer > componente do teu software relaionado a discos (ou mesmo o teu SO, porque não > ?) TEm um limite de X gigabytes para um único arquivo, de repente vc pode > acabar com corrupção/erros se deixar o datafile chegar nesse ponto... > Coisas assim, ADMINISTRATIVAS, são aonde o tamanho do datafile importa... > > --- Em oracle_br@yahoogrupos.com.br, Rafael Stoever <rstoever@> escreveu > > > > Boa tarde a todos, > > > > Irei fazer uma analogia sobre um arquivo texto de 10GB e um datafile > > de 10GB e um de 32GB. > > Se efetuarmos a abertura do arquivo de 10GB no sistema operacional > > teremos um problema grande de memoria, podendo ate travar o sistema > > operacional. > > > > Agora a questão são os datafiles grandes 32GB quando abertos pelo > > Oracle para efetuar uma busca muito massiva de dados, ou mesmo somente > > abrir-los, ele poderá ocasionar um problema de performance da mesma forma > > que o editor de texto ? > > Pois ao checar os arquivos abertos pelo Oracle ele fica com o alguns > > datafiles abertos. > > > > Pergunta: O tamanho do arquivo irá influenciar na performance geral da > > maquina quando o oracle for abrir o datafile? > > > > abs > > Rafael Stoever / @rstoever > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
