Materialized Views for Query Rewrite
Oracle 9i Rel 2 Ver. 9.2.0.4 Windows 2000 Advanced Server
I am administering a datawarehouse and have been asked to improve the performance of reports being created and run by Cognos. I want to create materialized views and use query rewrite. Can somebody explain the steps to plan and implement this?
I have a couple of sample reports. I'm trying to decide whether or not to do this top down or bottom up from the report. I'm thinking it would be better to implement a consistent vision across the whole star schema rather than try to do this one view and one report at a time.
If I don't do top down, the number of tables in the first report is 12. I'm thinking I have to do this in small chunks joining three or four tables in a view. If I do that will all of them have to be full refresh?
Please answer the following questions:
Is it best to look at the data model and implement mviews based on the key relationships between fact and dim? or, look at the (35) reports and try and create mviews that support various reports?
A few tables in the view, or many?
We don't have many space limitations. The db is only about 15 g in size and I have 300 g available. The db is only really used from 8-6 Monday through Friday so I can refresh etc outside those hours.
If I'm not asking the right questions or approaching this correctly please suggest another direction.
I am administering a datawarehouse and have been asked to improve the performance of reports being created and run by Cognos. I want to create materialized views and use query rewrite. Can somebody explain the steps to plan and implement this?
I have a couple of sample reports. I'm trying to decide whether or not to do this top down or bottom up from the report. I'm thinking it would be better to implement a consistent vision across the whole star schema rather than try to do this one view and one report at a time.
If I don't do top down, the number of tables in the first report is 12. I'm thinking I have to do this in small chunks joining three or four tables in a view. If I do that will all of them have to be full refresh?
Please answer the following questions:
Is it best to look at the data model and implement mviews based on the key relationships between fact and dim? or, look at the (35) reports and try and create mviews that support various reports?
A few tables in the view, or many?
We don't have many space limitations. The db is only about 15 g in size and I have 300 g available. The db is only really used from 8-6 Monday through Friday so I can refresh etc outside those hours.
If I'm not asking the right questions or approaching this correctly please suggest another direction.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It may not be your database at all...How do things perform outside of Cognos. What are you using to build your cubes? Can you explain your environment? How many fact tables, dimensions?
ASKER
The cubes are created and ETL is being done using Informatica power mart. It's a communicable disease reporting database with three fact tables, investigation_fact and disease_rpt_fact are the two main ones, and followup_fact. There are 21 dimension tables with about another 10 or so helper tables. Examples of dimension tables are jurisdiction, location, person, disease, time, etc.
This is all kind of anticipatory, our user base is going to go from 50 to 400 in the next couple of months as we go into full production. The database was created on Oracle Standard and we just got an Enterprise license last week so we don't have any of the Enterprise Edition data warehouse features enabled. We felt the most valuable things to implement and the order we would implement would be mviews, bitmapped indexes, partitioning.... We have about 10 more weeks, essentially to redesign the application, before we reach peak load. We're thinking this isn't going to hold up when we get 400 users on board.
This is all kind of anticipatory, our user base is going to go from 50 to 400 in the next couple of months as we go into full production. The database was created on Oracle Standard and we just got an Enterprise license last week so we don't have any of the Enterprise Edition data warehouse features enabled. We felt the most valuable things to implement and the order we would implement would be mviews, bitmapped indexes, partitioning.... We have about 10 more weeks, essentially to redesign the application, before we reach peak load. We're thinking this isn't going to hold up when we get 400 users on board.
Yes, by upgrading your oracle database to EE version , alone is a big help.
just thinking about the capability added, Materialized views, Bitmapped Indexes, partitioning ..they all are essential ingredients for the success of a databwarehouse database.
You go right ahead.
just thinking about the capability added, Materialized views, Bitmapped Indexes, partitioning ..they all are essential ingredients for the success of a databwarehouse database.
You go right ahead.
15GB datawarehouse?! :-)
I agree, upgrade to EE ASAP, start integrating partitioning, bitmap (join) indexes - you may need to turn them off for ETL as they'll cause all sorts of locking issues if you have them on during your load. Is parallel query available in standard edition?
We tested Cognos during the POC, there's a query rewrite feature which you should use. From memory, Cognos sucks all your data into cubes so the likelyhood of queries hitting the actual database is very small - that's why they're hardware heavy...
I agree, upgrade to EE ASAP, start integrating partitioning, bitmap (join) indexes - you may need to turn them off for ETL as they'll cause all sorts of locking issues if you have them on during your load. Is parallel query available in standard edition?
We tested Cognos during the POC, there's a query rewrite feature which you should use. From memory, Cognos sucks all your data into cubes so the likelyhood of queries hitting the actual database is very small - that's why they're hardware heavy...
ASKER
Cognos has a drill-through capability. We build six cubes from the database which currently satisfies most users. When we are fully up and running I think we will have a lot more drill through activity hitting the database. I can't see a use for bitmap join indexes and materialized views at the same time on the same tables. It seems kind of redundant. If I create a materialized view using columns from four tables that are normally joined what's the point of creating a bitmap join-index on the same tables? Am I missing something here?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.