maybe ur tables have grown bigger and fragmented. You may consider reorganizing it. Consider partitioning and run parallel query on all partitions
i) Fragmented how?
ii) Why partition?
iii) Parallelism would speed the result, but use more resources ... seems rather like a brute force method if all else fails.
1.) frequent deletes makes tables fragmented.
2.) large tables are good candidates for partitioning.
3.) sacrifice resources just to get valuable data.
4.) peace
i) Ah, you mean that there are fewer rows in a table with the same high water mark. Hmmm, I'm having trouble thinking of how this might cause a longer running query though...
ii) This will have to be a fundamental area of disagreement .. maybe the reverse is true, that small tables are less likely to be candidates for partitioning, but partitioning is powerful ju-ju which will often cause a slow down in queries if not properly applied.
iii) Again, powerful stuff. There are many "if's" to work out before commiting to such a plan.
iv) Of course!
The fact table in those queries are partitioned. As I mentioned before, there are two changes here. 1. I created some bitmap indexes on some foreign key columns. I was planning to enable star transformation. 2. We loaded some historical data over the last a couple of month to the fact table.
Reply With Quote
Originally Posted by yxez
peace 
Bookmarks