Hi, Probably a crazy idea and probably it can't even work, and I've never tried anything like this, but what if you created a logical standby, and traced the apply processes on it. I think the SQLs should be sorted properly in these trace files. --- Maris Elsins @MarisElsins <https://twitter.com/MarisElsins> www.facebook.com/maris.elsins On Mon, Jun 9, 2014 at 12:54 PM, <Laimutis.Nedzinskas@xxxxxx> wrote: > Hi > > I have a task to capture a work done by many users in parallel and prepare > SQL script such that executing the script yields the same database state as > the work done by users. > > I plan to use LogMiner for that task. However I am not sure how to filter > and order the contents of V$LOGMNR_CONTENTS so that replay yields the same > results as the original transactions. > > In the Oracle documentation I've found the following statements: > > 1. > http://docs.oracle.com/cd/E11882_01/server.112/e22490/logminer.htm#SUTIL1566 > > LogMiner returns all the rows in SCN order unless you have used the > COMMITTED_DATA_ONLY option to specify that only committed transactions > should be retrieved. SCN order is the order normally applied in media > recovery. > > This looks promising but how to deal with rollbacked transactions ? It > looks a bit complicated. > > > 2. > http://docs.oracle.com/cd/E11882_01/server.112/e22490/logminer.htm#SUTIL1574 > When you specify the COMMITTED_DATA_ONLY option, LogMiner groups together > all DML operations that belong to the same transaction. Transactions are > returned in the order in which they were committed. > > I think this is the order of SQL statments that I need. May be someone can > confirm that my assumption is correct: > > replay of COMMITTED_DATA_ONLY ordered by <commit_scn, scn> yields the > same database state as the original transactions ? > > > > Thank you in advance, > Laimis N >