Muito obrigado pelas informações!!
Atenciosamente, Rogério Camatini. Em 19 de setembro de 2014 20:19, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Então, colega : a resposta pura e simples é que ** normalmente ** dados > não-comitados NÃO SÃO gravados nos datafiles, mas podem sim ser... > Para podermos entender, primeiro temos que conhecer o mecanismo básico de > manipulação do RDBMS, que é : a informação está presente em linhas de > tabelas, todas as linhas de todas as tabelas estão presentes em blocos, e > TODAS as as alterações são feitas em RAM, no cache. Assim sendo, os passos > são : o bloco com os dados a alterar é localizado e trazido pro cache de > blocos, as alterações feitas nele (os bytes que alteraram, junto com alguns > poucos indicadores, que formam o chamado redo log vector) vão pro log > buffer, e quando o log buffer enche (ou passa de um limite, normalmente 1/3 > do tamanho, ou a cada x segundos, ou a cada commit) esses redo vectors são > gravados no logfile. LOGFILE, não datafile, okdoc ?? Então nós temos no > logfile tanto "dados" de transações comitadas quanto não-comitadas, yep ?? > A transação continua, e assim por diante o(s) bloco(s) que sofreram > alterações são marcados como blocos "sujos", ie, que estão diferentes do > conteúdo em disco dos datafiles... E ululantemente óbvio (mas pessoal > SEMPRE esquece), é uma Exigência , vinda da própria definição de RDBMS, que > a QUALQUER MOMENTO uma transação possa ser desfeita via ROLLBACK, assim > sendo necessariamente o RDBMS *** TEM *** que disponibilizar também a > informação necessária para se desfazer as alterações, o chamado UNDO ou > ROLLBACK... > > Muito bem : em TESE, no melhor dos mundos, as alterações vão sendo > gravadas no logfile, de maneira compacta, chega uma hora que vêm o COMMIT, > aí o bloco sujo é marcado como "a ser checkpointed", e em algum momento o > DBWR simplesmente copia esse bloco para o datafile, atualizando-o.... Sem > ter gravado em momento Algum informação não-comitada nos datafiles, OK ?? > Esse é o IDEAL, é o modo que o RDBMS Oracle tenta trabalhar... > > Na prática, porém, a coisa não é cor-de-rosa assim : por exemplo, se for > disparada uma transação que altere uma grande qtdade de blocos, mais do que > o que tem no cache ?? O RDBMS Oracle se notabiliza por ** NÃO ** impor > limites de número de blocos numa transação, de número de linhas, de nada do > tipo, a não ser os do SO ou limites gerais ultra-altos, ele TEM que > permitir transações enormes, foi feito pra isso... Ou ainda, se n sessões > começarem a usar o cache, com n blocos sendo alterados ?? Ou ainda, se o > logfile encher ?? Infelizmente o cache *** não é infinito ***, muito menos > o logfile, então o RDBMS TERIA que gravar a informação não-comitada em > algum lugar, sim sim ?? > > O lugar no caso é o que sobra, o DATAFILE, yep ? Assim, o que o DBWR faz > é salvar em disco algum/ns do(s) bloco(s) sujo(s), mesmo que não comitados, > e marca o bloco como DEPENDENTE do undo/rollback segment tal e qual.... Aí, > se no futuro vier um COMMIT, o banco simplesmente libera o undo/rollback, e > se vier um ROLLBACK ele lê o undo/rollback e o desaplica do bloco em disco, > e assim vai lendo o undo/rollback anterior, e o anterior, até chegar no SCN > em que a transação começou... > > ESSA é a situação em que o RDBMS pode ** sim ** ter que gravar blocos > com dados não comitados sim nos datafiles, yep yep ?? Ou seja, esgotou (ou > ele acha que vai esgotar) cache, ou logfile, aí não tem como manter a info > não-comitada só na memória e/ou no logfile... > > Dá um look em http://oracleinaction.com/uncommitted-data-in-datafiles/ > que ele mostra um exemplo possível disso, e > https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1670195800346464273 > fala um pouco da teoria, basicamente confirmando o que eu disse ... > > []s > > Chiappa > >
