Partitioning suggestion?

Question

I am working on Oracle 11gR2 2 node RAC(OLAP database) in Linux.
I have a huge table (estimated to be around 300G) which I need to partition. Still on the designing phase so the table doesn't exist.
The reporting queries will be looking at data for a specific day or month, but the problem here is since the database is global we will have users querying from different places(different timezones) and the data reported should take the timezone for the specific user into consideration. We are looking at around 50 different timings.
We will be storing data for 24 months in this table.
This would be an OLAP database and we are considering real time reporting, so I was thinking of having two separate tables, one table(say TABLE1) to store data for a week(as this will include heavy insertion and updation activities) and the other table(say TABLE2) which will hold data for 24 months. At the end of week, can use partition exchange to merge the tables.
I was thinking of paritioning by week, but the problem is due to timezone differences, I need to query multiple partitions even to get 1 day's worth of data and a few queries which need recent week's data wouldn't be satisfied by TABLE1 and I need to query TABLE2 also.
To give an estimate of the table size it would be growing at 300M per day.
Any suggestions on what would be the best partitoning strategy here?

Answer 1

Firstly, I would like to thank you guys for your interest on this question.
When I say real time, I need to report on data that was generated 2 minutes ago, so the ETL processes have to run every 2 minutes and need to complete within a minute or so.
We would be using streams to get the data from OLTP database on which the ETL queries would be running.
Reports are of different types, the most common ones are daily(reports on every days data upto 5PM for that timezone), interim(any data from 5PM cut off till current time less 2mins) and monthly(monthly data from beginning upto end of the month).
Now you can say that the real time data can be kept separate and other ETL can run every hour or so, but even for daily reports if user queries at 5.02PM for his timezone I need to report the earlier days data upto 5PM which means it also real time, also holds the same for monthly reports which need to be real time when the new months starts. So the ETL has to run every 2 mins.
This is the reason I was thinking of having 2 separate tables, one which would hold 1 week data and the other table would hold rest of data for 24 months. The reason for having first week data separate is this would have heavy inserts and updates happening during first week which means this wouldn't be heavily indexed whereas the other data would see DML activities happening rarely, so they would be heavily indexes for optimum read performance.
These reports are scheduled, but a user can run them in an ad hoc manner too whenever he likes but we won't be looking at many concurrent users, probably 4 to 5 reports running concurrently which might not be the case too mostly but to look at worst case scenarios there might be around 10 people running reports concurrently though the actual user count would be around 5000.
There will be almost 10000 reports running daily of which around 5000 would be scheduled daily reports. Scheduled daily reports will be cached for a week. Scheduled monthly reports will be cached for 6 months. If there are any changes to the data, cached reports will be invalid and the reports need to be run again.
Reports would be pre-written with parameters. Ad hoc reporting is very rare, once in a couple of months.
Daily reports dont aggregate data much, would be selecting data for that specific day which the user has access to(he has access only to local data), so yes it is quite selective without much aggregates. The amount of data generated by a daily report would be around 2-3M and would involve 7500 rows.
Interim reports pull the same data as that of daily reports but they would report data from the cut off time(5Pm everyday) till current time.
Monthly reports involve more aggregated data. The number of rows would be in few hundreds and the size would be few hundred KB.
Regarding the indexes, I was looking at local paritioned indexes for easy maintenance.
Can you please eleborate a bit on this -
Have you worked out how you can write a query which accepts an input from one timezone and does partition elimination against a table partitioned on one of the timestamp datatypes (or even partitioned on a simple date data type).
The table would be having a date column, so I was thinking of converting the time the query was received to the timezone of that specific user and comparing the time with the date column. Will this be ok or am I missing something here?