creating materialized view in ibm i series

We want to create materialized view in IBM i series v7R1 instead of normal views as we are having performance issue. Could anyone let us know how to create & maintain materialized view .
Syed Shareef AhmedSenior System AnalystAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

Gary PattersonConnect With a Mentor VP Technology / Senior Consultant Commented:
Are you sure you want to use a MQT?

At the moment, in IBM i DB2 though V7R3, MQTs are "point in time" snapshots - they are not dynamically updated as rows are inserted/updated/deleted in the underlying tables (MAINTAINED BY USER is the only maintenance option at create time).

As a result, they are generally only appropriate in systems where the dependent tables are undated infrequently - a data warehouse that is just updated once a day is the classic case, or where a point in time snapshot is acceptable.

Here's how to create them and maintain them:
Dave FordConnect With a Mentor Software Developer / Database AdministratorCommented:
From what you say in the question, it appears that you've successfully created the view, but you're experiencing some sort of "performance issue". Is that correct?

Would you please provide us with more details, such as the source for the view and deails of the performance issue?

Syed Shareef AhmedSenior System AnalystAuthor Commented:
Hi DaveSlash,

Thanks for the response.

Yes your are very correct we have successfully created some views from tables (file) and used in some of reports with those views. The reports are taking time to run but not always, some time it runs fine and other time it takes time. Those reports are also used by our customers through web.

so we thought to create  materialize view.

Gary PattersonVP Technology / Senior Consultant Commented:
Inconsistent query runtimes can have a number of causes, for example:

1) A major table could be substantially cached in memory from a previous query, causing occasional runs to be artificially fast.  We run into this when we're doing performance testing, and run similar tests back-to-back.  To get a true "cold cache" runtime, we have to clear memory pools before running the test to get a good comparative value.

2) Users may be making different selections in the application interface that cause substantially large queries - for example, if they can enter a date range.

3) System load may vary over time.  Contention for CPU, memory, disk resources, etc. can cause wide variations in query runtime performance.

If I was working on this problem, I'd capture some performance data and do a little investigation:

Determine time periods where same query performs well, and when it takes longer.  You might be able to just pull this from the DB2 SQL Plan Cache.  While you're at it look and see if there are indexes advised for the query, and look for other optimization opportunities for the problem query.

Look at Collection Services or iDoctor Job Watcher data from same period to see if you can correlate longer runtimes to high CPU, high disk busy %, etc.

IBM i DB2 Database Performance and Query Optimization manual has a lot of good info on analyzing and resolving performance problems like this:


- Gary
Syed Shareef AhmedSenior System AnalystAuthor Commented:
Thanks a lot all :)
All Courses

From novice to tech pro — start learning today.