February 5, 2010 at 2:32 am
We had a table with 11 million records which is highly transactional. We had new report requirement which i need to fetch static data from this table joining other table. I had plan to create a clustered index view for fetching data. Is there will be any performance bottle neck if i create an view?
February 5, 2010 at 3:02 am
Sure, whenever you create index on any transactional table , it will degrade the performance.
because whenever DML operation performed on this table , index will get updated.
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
February 5, 2010 at 3:19 am
You have mentioned about fetching static data from the transactional table.Please clarify what does it mean?If data is static, there will be no DMLs then. For reporting purpose, I guess you will mostly run Select statements.If this is so, create a view on the table which is assumed to be static and then index it.Do post if this is the different case.
Thanks
Vivek
February 5, 2010 at 3:27 am
vyas (2/5/2010)
We had a table with 11 million records which is highly transactional.
As above line depicts , this is transactional table, i guess
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
February 5, 2010 at 3:51 am
I know its transactional:cool:.I am asking something else i.e. about fetching static data.Static data means no DMLs..I guess. Vyas can you elaborate your point?
Vivek
February 5, 2010 at 4:14 am
Fetch data means, select only. There is no DML operations involved
February 5, 2010 at 5:38 am
Ok..then my previous post might help you.
Vivek
February 5, 2010 at 6:52 am
Creating an indexed view is not the same thing as creating an index. Actually, it's somewhat more expensive. If your data is highly volatile, as it gets constantly updated, it has to constantly update the indexed view, almost like it's constantly updating a table index. If you're not doing lots of joins or aggregates, and on relatively non-volatile data, then the indexed view is not the way to go. Maybe you need to look into partitioning your data?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 5, 2010 at 7:03 am
Any way to compile the reports every day or every few hours and show the saved version?
If not you can always look at replication on a dedicated server than can handle a heavier load of rebuilding the indexes constantly.
Then there's alway the hybrid version. Onde daily run a query that compiles the data into a report table. Then when the report is running, fetch the data from the report table and then fetch and compile the "new" data for the day. It's especially effective if you have a leading column in the clustered index which keeps the inserted date. If you you can always build an index (even covering) to get that data. That should be much less expansive than the view.
February 7, 2010 at 10:47 pm
Vyas, i was telling the same thing as grant Frithcey mentioned in his first reply.
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
February 7, 2010 at 10:49 pm
Grant
, isnt it different objected creating whenevr we create a index on view. bcoz i read some where that whever we create any indexed view, sql server will create new object as indexed view.
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
February 8, 2010 at 6:22 am
I was not distinguishing view and an indexed view.I know very well that they are two different things:cool:.I guess the above posts are not confusing for Vyas bcoz some posts are getting diverted from the original Q asked:ermm:.Vyas,did u find ur answer?Also, as mentioned earlier, if u can bifurcate ur data which is static and create a view on it might help.Also, I think partitioning would be one of the more efficient ways as mentioned in one of the posts.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply