Materialized Views

Question

Materialized Views

DBABC

SSCarpal Tunnel

Points: 4813
More actions
July 30, 2008 at 12:31 pm

#194983

One of my query is using 4-5 tables using Inner or Left Outer joins.
These tables are the main tables of the Db and contains alot of data. Also multiple user & multiple applications are inserting data in these tables as well. So will a materialized view by joining these 4-5 tables will give any performance benefit? Or it will be even more overhead?
Thanks,
Usman

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply

GSquared SSC Guru Points: 260824 More actions · Answer 1

It depends.

If you have a lot of selects on certain conditions, then a materialized view based on those conditions can increase performance for those selects.

On the other hand, materialized views, like any index, do slow down insert/update/delete operations.

In many cases, the slight slow-down on those is worth the large speed-up on selects, but this requires doing some research and making sure the view is exactly what you need.

Used correctly, a materialized view can speed up lots of things. Used poorly, they can slow down lots of things.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Steve Jones - SSC Editor SSC Guru Points: 736478 More actions · Answer 2

I tend to agree with the views expressed above. It can be a useful tool, if you consider the load on your system for Ins/Upd/Del

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 3

usman.tanveer (7/30/2008)
One of my query is using 4-5 tables using Inner or Left Outer joins.
These tables are the main tables of the Db and contains alot of data. Also multiple user & multiple applications are inserting data in these tables as well. So will a materialized view by joining these 4-5 tables will give any performance benefit? Or it will be even more overhead?
Thanks,
Usman

I believe that a materialized view will cause you a world of hurt in this particular case because of all the inserts you say you'll be doing.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

GSquared SSC Guru Points: 260824 More actions · Answer 4

Jeff Moden (7/30/2008)
usman.tanveer (7/30/2008)
One of my query is using 4-5 tables using Inner or Left Outer joins.
These tables are the main tables of the Db and contains alot of data. Also multiple user & multiple applications are inserting data in these tables as well. So will a materialized view by joining these 4-5 tables will give any performance benefit? Or it will be even more overhead?
Thanks,
Usman
I believe that a materialized view will cause you a world of hurt in this particular case because of all the inserts you say you'll be doing.

It depends. It will slow down the inserts, but if those are generally single-table, single-row inserts, the performance hit on that might be negligible. What isn't mentioned is what queries the view will be supporting.

Even with lots of inserts, you can still have a net gain if you have a lot of complex queries that are called frequently.

I've even had a net gain in insert speed in one case, because of an indexed view that was used by those inserts (Insert...Select). Slowed down the insert part, but gained even more from the select part. (Supported complex business rules in an upsert situation.) Went from 600 ms to 40 ms on a common transaction in that database.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 5

Actually, Gus' answer is the best answer... "It depends". This is the kind of thing that you need to test.

Gus, good point about the net gain on things like Insert/Select. 🙂

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Hossam AlFraih SSC Journeyman Points: 84 More actions · Answer 6

Indexed Views will helps by pre-computing aggregations and store them in the index. Moreover, joining tables can be pre-join and results data can be stored.

This can speed up your queries by approx. 50-75% in general. :w00t:

But remember, it always depends! 😉

Good luck.

Patibandla Old Hand Points: 332 More actions · Answer 7

It is truly not suggestible to use an Indexed View when the tables are highly transactional as you mentioned. But if the priority is reporting then you can use the materialized views with NOLOCK on the Tables.

Patibandla Old Hand Points: 332 More actions · Answer 8

Rather you should keep in mind that you will not be allowed to do any properties that affect the deterministic nature of an indexed view like full-text predicates or references to other views aggregation operations etc..

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 9

I am going to join in with the "It depends" group. You need to test if a materialized view is going to help or not. There really is no definative answer here.

Test it, and let us know if it helped or hindered you in this situation.