For derby the default is autocommit=true, which means it will do a synchronous log commit write for every statement.  My reading of the app and the
call to commit at the end seems to indicate you want to only commit
at the end.  Depending on the data distribution (ie. how many times you
call executeUpdate this may be a big issue.  When you run the test do
you see a lot of idle time or is 1 cpu at 100% for 12-14 secs? The suggestion for using aggregates seems like a better way to do the app.

What kind of page cache does oracle have when you compare?  Are you interested in performance of a query when no page is in cache or when
all pages are in cache?  This size table is bigger than the default
derby page cache (1000 pages) so it basically is going to be an I/O test of how fast
stuff can be read from disk each time.  If you want to try a cached
test try setting derby page cache bigger - probably 10,000 pages will
fit that table (probably less - didn't do exact math).

Hello.

You can see example code now. conn.setAutoCommit(false); putted there.

derby.properties:
derby.storage.pageCacheSize=100000
derby.storage.pageSize=32000
#derby.language.logStatementText=true

app run with:
java -Xms100m -Xmx1000m -cp dist/derbytest.jar derbytest.FatTest
So memory is enough for app.

Soft- & Hard-ware:

Code2Duo 2Gz, 2Gb RAM, MS Win XP SP2.
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode)

derby version - 10.3.2.1

Oracle XE with default configuration.