RE: Optimizing Big Index Build on Standard Edition

Mark,

If you do the arithmetic, and take the pessimistic 2x storage then the index would have to be a single column index with an average column length of 2.

I like the SSD idea -- but as an alternative is there a local disk on the server which could be used to create a local TEMP for the duration ?

Some questions I'd ask myself:

While most of the waits were direct path read temp, what fraction of the session time was CPU and what was I/O ? Creating a very large memory isn't always the fastest way to sort.
What were the sizes of the reads and writes to temp ? Has the internal code done something odd because of a large boundary condition ?
What is the average column length of each of the columns in the index
How sure are you that the session is taking up the maximum memory that you want it to 


Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
_at_jloracle

________________________________________
From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] on behalf of Mark W. Farnham [mwf_at_rsiz.com]
Sent: 31 January 2014 13:57
To: charlottejanehammond_at_yahoo.com; 'ORACLE-L'
Subject: RE: Optimizing Big Index Build on Standard Edition

IF indeed the problem is slow throughput of temp disk, and
IF indeed no other work is being done, and
IF about 2x the index size is not bigger than 96GB minus enough room to run
your database (sga size plus enough room for the background sessions, the
rebuilt session, and probably a few monitoring session),
--