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
