I am just looking for some stats if anyone wants to share on agging large aso cubes. Size I am looking for is 4 billion initial cells. If anyone wants to throw some out - I'd appreciate it so I can kind of guess whether what we are doing is decent, ugly, or what. Thanks.

Is below what you require...

-------Statistics of dwArcube:dwarcube -------

Dimension Name Type Declared Size Actual Size
===================================================================
Fiscal Period NONE 13 13
Credit Control Area NONE 13 13
Fiscal Year NONE 7 7
Scenarios NONE 28 27
Analytics NONE 5 4
Risk Category NONE 25 25
Reason Codes NONE 16 16
Payment Terms NONE 209 209
Accounting Clerks NONE 113 113
Sales Reps NONE 789 789
Entities NONE 1037 908
Customer NONE 137097 137078
Industry Codes NONE 85 85
Industry Codes 1 NONE 9 9
Customer Class NONE 13 13
Nielsen ID NONE 6 6

Number of dimensions : 16
Declared Block Size : 1
Actual Block Size : 1
Number of Non Missing Leaf Blocks : 0
Number of Non Missing Non Leaf Blocks : 0
Number of Total Blocks : 0
Index Type : B+ TREE
Average Block Density : 0
Average Sparse Density : 0
Block Compression Ratio : 0
Average Fragmentation Quotient : 0



----- Database Information -----

Name : dwArCube
Application Name : dwArCube
Database Type : UNKNOWN
Status : Loaded
Elapsed Db Time : 00:15:18:25
Users Connected : 2
Blocks Locked : 0
Dimensions : 17
Data Status : No Data
Data File Cache Size Setting : 0
Current Data File Cache Size : 0
Data Cache Size Setting : 0
Current Data Cache Size : 0
Index Cache Size Setting : 0
Current Index Cache Size : 0
Index Page Size Setting : 0
Current Index Page Size : 0
Cache Memory Locking : Disabled
Database State : Read-write
Data Compression on Disk : No
Data Compression Type : N/A
Retrieval Buffer Size (in K) : 10
Retrieval Sort Buffer Size (in K) : 10
Isolation Level : Uncommitted Access
Pre Image Access : No
Time Out : Immediately
Number of blocks modified before internal commit : 0
Number of rows to data load before internal commit : 0
Number of disk volume definitions : 0


--Request Info--

Request Type : Data Load
User Name : khanmoh
Start Time : Tue Jun 30 02:58:00 2009
End Time : Tue Jun 30 02:58:02 2009
Request Type : Default Calculation
User Name :
Start Time :
End Time :
Request Type : Outline Update
User Name : khanmoh
Start Time : Tue Jun 30 02:33:40 2009
End Time : Tue Jun 30 02:33:44 2009



---------Database State---------

Description:
Allow Database to Start : Yes
Start Database when Application Starts : Yes
Access Level : None
Data File Cache Size : 0
Data Cache Size : 0
Index Cache Size : 0
Index Page Size : 0
Cache Memory Locking : Disabled
Data Compression on Disk : No
Data Compression Type : N/A
Retrieval Buffer Size (in K) : 10
Retrieval Sort Buffer Size (in K) : 10
Isolation Level : Uncommitted Access
Pre Image Access : No
Time Out : Immediately
Number of blocks modified before internal commit : 0
Number of rows to data load before internal commit : 0
Number of disk volume definitions : 0

I/O Access Mode (pending) : Buffered
I/O Access Mode (in use) : Buffered
Direct I/O Type (in use) : N/A



Zaeem Khan
Hyperion Solutions Manager

I think she means stats more figuratively than literally.

250,000 members, 3 bil cells, 45 min load, 25 min agg views.. that sort of thing.

As anonymous indicated looking for large data sets and agg times others are experiencing. For instance - we have an actuals cube with 1.5 years of data. 18 dimensions. About 370 million load records. Aggs in approx 7 hours and creates 6 billion cells using 36 views. I am trying to determine if that is fast, slow average based on others experience.

Thanks.

I'm pumping about 1.2 billion total rows into 4 different cubes and doing aggs, the process is about 2-3 hours... These could be faster than yours because the individual cubes are smaller with fewer dimensions -- I'll see if I can get some more detailed stats tomorrow.

-Jason

What you did provide is helpful

Just to give you some more feedback, we have a large cube (around 9.5bn cells) which is loaded daily. We slice the daily loads and then merge and re-aggregate over the weekend. A Basic set of aggregations (7 views) takes 1 hour. But then we do a number of other aggregations based on query tracking which adds another 27 views and trundles along for another hours. Hope this helps...

Just re-read my last sentence - this missing number is '9'

So perhaps it is fair to say we are average... Thanks for the stats to do some comparing...