eGenerator - Time to Complete Full Regeneration

I was just wondering what the average time to do a full web generation should be?

What factors could affect the generation time?

It takes us about 3-3.5 hrs total. Applications and reports take 2+ hours and the others between 30-60 minutes.

We have 2 workstations that we run the egen process on. One is has a 3.2GHz dual core processor with 3GB of memory and the other has a 2.8GHz single core processor with 4GB of memory. There doesn't seem to much difference in performance between the two when running the egen process. However, the dual core machine does do the R92TAM quite a bit quicker (30 minutes compared to 1-1.5 hrs).

One thing that seems to have helped our times is the 1Gbps connection between the egen machine and the database (make sure you force the 1Gbps/full-duplex connection and not let the nic auto-detect the connection).

Also, I run everything sequential and I like to do the Application and Reports last.

BTW - you never mentioned your times or infrastructure...mine is in my signature.

Thanks for the reply! Sounds like it is definitely possible to generate A LOT faster then we have been doing. I am ashamed to say we are pushing in the 16 hour range! This information alone just what I needed to prove something should be done about the current eGenerator speed.

We have been running into problems with virus scan on the machine slowing things down too. Do you have to contend with a virus scanner?

I don't have the specs of the egen machine but it is an older Win2000 workstation that is clunky at best. We are getting a dual cure machine so it sounds like that will help.

Do you know how much gain you'd be looking in a full regnen when truncating the F989999 and F989998 versus not truncating them? We normally don't truncate, but I have suggested we do this as well.

-----------------------------------
E1 8.9
Tools Release 8.96
WAS6 / IHS6 / Solaris
Solaris Enteriprise Server

We use Symantec AntiVirus for our virus scanner. We setup an exclusion to not include c:\e811 in the real-time scanning. That seemed to help A LOT!

From my understanding, truncating the F989998 & F989999 would not change the eGen times. I believe that, when doing an eGen, the rows have to be written over anyway. I have also read several Oracle docs and been in classes where they state that truncating the files is the "Best Practice".

Looks like you could have a pretty big "win" without much effort.

Good Luck!

The "official statement" is that if you do not truncate the tables, the generation process must find and delete the row prior to new insert. If you truncate the table, the process will run a bit faster as there is no delete statement to process.

Thanks for the clarification, Charles.

To add to what Charles said, and probably what you've heard from Oracle, when you do a TRUNCATE, you also reset the highwater mark, so space from your deleted records will be reused. I'd highly recommend doing a truncate first, then run your e-gen. This is assuming, of course, that you don't have users accessing these tables

For Oracle Database installs you might consider:

truncate table f989999 reuse storage ;
truncate table f989998 reuse stroage ;

instead of:

truncate table f989999 ;
truncate table f989998 ;

A) The truncate will run a bit faster, though it may be hard to measure. Truncate will run faster than DML, regardless, as it avoids the overhead of the delete statement.

B) If you're planning a full web gen, the tables will naturally move the high water mark back to near its original position.

If you use the 'reuse storage' option, it avoids the process of deallocating and reallocating the storage for the segment. Overall, it may be a more "nice" process for your database.

"To truncate a table or cluster, the table or cluster must be in your schema or you must have DROP ANY TABLE system privilege." - Oracle® Database SQL Reference

To help with our times we turned off the insert delete logging on the generation machine for full gens. Open your jdelog.properties file in the web-inf\classes directory. Comment out the bottom two stanzas, this was given to me by the Oracle Engineer that wrote the application.