The SERIAL keyword instructs the server to load all values from the mapped table at once (i.e. not by partition). This is a big win if your table contains data for only a few partitions or if it has very few rows. The SOLVE step will be parallelised, but will only fire for partitions changed by the load step. Obviously you should set the parallelism to the level you want. If only one partition will be affected, then you may choose parallelism = 0.
exec dbms_cube.build('my_cube using (load serial, solve)', parallelism=>2, add_dimensions=>false)
If you look in the OUTPUT column of the cube_build_log where command = 'SOLVE' and status = 'COMPLETED' then you will see entries like this
(it is not empty) AND ( (new values have been loaded into the partition) OR (any (non-partitioning) dimension has changed) )
This tells you why a particular partition was processed. In this example it was because new values were loaded into the partition. Below is a case where the data was unchanged, but one of the dimensions has changed.
<SolveStatistics IS_EMPTY="no" CHANGED_VALUES="yes" CHANGED_RELATIONS="no"/>
The next question is what happens to a partition if the dimensions have changed? This will depend in part on the type of hierarchy change. There is a specific list of changes that will cause a partition to be completely reaggregated. From memory I believe they include
<SolveStatistics IS_EMPTY="no" CHANGED_VALUES="no" CHANGED_RELATIONS="yes"/>
The syntax is accepted in earlier versions, but it will not work properly.
-- Build the single partition representing calendar_quarter '14'. begin dbms_cube.build(q'! UNITS_CUBE USING ( FOR "TIME" WHERE HIER_ANCESTOR(WITHIN TIME.CALENDAR LEVEL TIME.CALENDAR_QUARTER) = '14' BUILD ( LOAD, SOLVE ) ) !', parallelism=>1); end; /