Link to home
Start Free TrialLog in
Avatar of Jagadeesh M
Jagadeesh MFlag for United States of America

asked on

Oracle rownum in db2 - Java data archiving

I have a data archiving process in java that moves data between db2 and sybase. FYI - This is not done through any import/export process because there are several conditions on each table that are available on run-time and so this process is developed in java.

Right now I have single DatabaseReader and DatabaseWriter defined for each source and destination combination so that data is moved in multiple threads. I guess I wanted to expand this further where I can have Multiple DatabaseReaders and Multiple DatabaseWriters defined for each source and destination combination.

So, for example if the source data is about 100 rows and I defined 10 readers and 10 writer, each reader will read 10 rows and give them to the writer. I hope process will give me extreme performance depending on the resources available on the server [CPU, Memory etc].

But I guess the problem is these source tables do not have primary keys and it is extremely difficult to grab rows in multiple sets.

Oracle provides rownum concept and i guess the life is much simpler there....but how about db2? How can I achieve this behavior with db2? Is there a way to say fetch first 10 records and then fetch next 10 records and so on?

Any suggestions / ideas ?

Db2 Version - DB2 v8.1.0.144 Fix Pack Num - 16 Linux
ASKER CERTIFIED SOLUTION
Avatar of Kent Olsen
Kent Olsen
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Jagadeesh M

ASKER

and how does that rownum change if some inserts are being made while my readers are reading the data...
The row_num is applied over the result set returned by the SELECT statement.  Rows added by another process MAY be included in this query, depending on timing.  If they are included, they will of course get a row_num value to indicate their position in the list.

All bets are off regarding what is actually returned on subsequent queries.  Run the query, delete some rows, and run the query again.  The results may be exactly what you expect, (the next 10 rows), but they might also surprise you.  The safest approach is to sort the results of the query, but that is adding a lot of overhead to a process with a primary mission of deleting data.


Kent