Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Improving the performance of a Big table Expand / Collapse
Author
Message
Posted Wednesday, August 28, 2013 11:43 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, November 7, 2014 2:28 AM
Points: 268, Visits: 680
I am newbie in Performance tunning. I am trying my hands on PT.

If you are given a very large table and you are said to improve its performance.
what you be the checklist that you guys would prefer(like what to check first and then
this and then.....)?
Post #1489536
Posted Thursday, August 29, 2013 12:25 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 5:55 AM
Points: 13,544, Visits: 11,354
Some of the things I'd check:

* are statistics updated?
* is the table indexed? Are they indexed well?
* Are there unnecessary indexes?
* compression
* partitioning




How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1489541
Posted Thursday, August 29, 2013 1:13 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 8:18 AM
Points: 2,448, Visits: 2,988
You are not to be improving a table, but you need to improve the queries accessing that table. A table can be optimized by the options Koen has mentioned. But there could be much more gained if you look at the executed queries on that table and try to improve them.

** Don't mistake the ‘stupidity of the crowd’ for the ‘wisdom of the group’! **
Post #1489561
Posted Thursday, August 29, 2013 1:17 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 5:55 AM
Points: 13,544, Visits: 11,354
HanShi (8/29/2013)
You are not to be improving a table, but you need to improve the queries accessing that table.


And how can you improve a query? By updating statistics, minimize logging, creating indexes, compress the data, partition the table, ...




How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1489563
Posted Thursday, August 29, 2013 1:26 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: 2 days ago @ 8:18 AM
Points: 2,448, Visits: 2,988
Koen Verbeeck (8/29/2013)

And how can you improve a query? By updating statistics, minimize logging, creating indexes, compress the data, partition the table, ...


You are absolutely right, but without knowing wich queries are executed, you can't create the needed indexes, choose a proper partition schema, etc. . Sounds like the egg and chicken discussion


** Don't mistake the ‘stupidity of the crowd’ for the ‘wisdom of the group’! **
Post #1489574
Posted Thursday, August 29, 2013 3:22 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, November 7, 2014 2:28 AM
Points: 268, Visits: 680
Koen Verbeeck (8/29/2013)
Some of the things I'd check:

* are statistics updated?
* is the table indexed? Are they indexed well?
* Are there unnecessary indexes?
* compression
* partitioning


I am going through the list provided by You one by one. Regarding compression, Does it really improve the performance !!!! Does it not have a extra overhead to read the content (I am not contrary to your statement , i am just asking ) . It would be great if you have some bookmarked link to pros & cons of compression and you can pass it on.
Post #1489618
Posted Thursday, August 29, 2013 3:30 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 5:55 AM
Points: 13,544, Visits: 11,354
Compression leads indeed to more CPU utilization, but if the CPU isn't under pressure, this shouldn't be a problem. Because the data is compressed, you need to use less IO resources, hence a possible faster query.

This isn't a magic button. It's not because you enable compression (and save a lot of disk space for large tables) that your query runs automatically faster. You'll need to test it out.




How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1489620
Posted Thursday, August 29, 2013 3:46 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Today @ 1:50 AM
Points: 519, Visits: 264
Think I agree with both Koen and HanShi on this one, optimising the table is fine, however it is also worth looking at the code accessing it, removal of non performant code like cursors etc. Maybe indexed views rather than direct table access checking if any serious locking is taking place if its a large heavily used table.

Optimisation is something that impacts more than just the underlying tables so a more global view often needs to be taken.
Post #1489621
Posted Thursday, August 29, 2013 4:00 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 6:03 AM
Points: 40,423, Visits: 36,873
Tables don't have performance. Queries have performance. Asking how to improve the performance of a table is meaningless, what you need to do is improve the performance of queries that run against the table.

Table size is not necessarily related to query performance. Large tables can have queries that perform well. Small tables can have queries that perform terribly. What you need to do is identify queries that need tuning and tune them.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1489625
Posted Thursday, August 29, 2013 4:01 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 6:03 AM
Points: 40,423, Visits: 36,873
Koen Verbeeck (8/29/2013)
HanShi (8/29/2013)
You are not to be improving a table, but you need to improve the queries accessing that table.


And how can you improve a query? By updating statistics, minimize logging, creating indexes, compress the data, partition the table, ...


Maybe, no, maybe, maybe, no.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1489627
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse