Member Login
  • Products
    • Qure Suite
    • Qure Analyzer
    • Qure Optimizer
  • Downloads
    • Qure Analyzer (Free)
    • Qure Optimizer (Free Trial)
  • Support
    • Contact Support
    • Frequently Asked Questions
    • Limitations and Known Issues
  • Resources
    • Qure Optimizer Resources
    • Qure Analyzer Resources
    • Whitepapers
    • Videos and Tutorials
    • eBooks
    • Attend an Online Demo
    • inTune eMagazine
    • SQL Server Tuning Blog
  • Learn More
    • About Workload Tuning
    • SQL Server Tuning
    • SQL Server Performance
    • SQL Server Performance Tuning
    • Tips
    • SQL Server Articles
  • Company
    • About DBSophic
    • Management
    • Partners
    • News
    • Success Stories
    • Customer Testimonials
    • Selected Customers
  • Contact Us
Subscribe to blog

SQL Server Tuning Blog

By SQL Server MVP Ami Levin

Subscribe to feed Viewing entries tagged common pitfalls

Variable Size Data Types and Memory Grants

Posted by Ami Levin
Ami Levin
Ami has not set their biography yet
User is currently offline
on Tuesday, 08 May 2012
in SQL Server Tuning

Yesterday, at our 118th Israeli SQL Server User Group Meeting, Adi Cohn delivered a session on common performance pitfalls. One of the issues he mentioned is something every DBA and database designer should be aware of. Many applications use overly large size limit for their variable data types. The reasoning in many cases is simply "Why not?" If you have a variable size column and you made the choice to use one of the VAR data types anyway, why limit the size? Even if you expect to have up to 300 characters in the 'comments' column for example, what is wrong with defining it as 3,000? it's just metadata, right? Wrong...

Although physically, storage will be exactly the same if you define your VARCHAR as 300 or 3,000, it can still make a huge impact on performance. SQL Server needs to estimate the work space that is required for each query and allocate it before the query begins to execute. For variable type columns, the estimation is that the data size will be 1/2 of the max size defined for the column. So if you have a column that is defined as 300 bytes, the allocation estimation will be 150 but for 3,000 - the estimate will be 1,500. On systems that experience memory pressure, this can make a huge difference in performance as your queries will wait for memory allocations, potentially significantly hurting performance in addition to the fact that needless memory will be allocated that could serve SQL Server for much more useful purposes.

...
Tags: common pitfalls, common pitfalls, data types, Performance
Hits: 929 0 Comments Continue reading

Variable Size Data Types and Memory Grants

Posted by Ami Levin
Ami Levin
Ami has not set their biography yet
User is currently offline
on Tuesday, 08 May 2012
in SQL Server Tuning

Yesterday, at our 118th Israeli SQL Server User Group Meeting, Adi Cohn delivered a session on common performance pitfalls. One of the issues he mentioned is something every DBA and database designer should be aware of. Many applications use overly large size limit for their variable data types. The reasoning in many cases is simply "Why not?" If you have a variable size column and you made the choice to use one of the VAR data types anyway, why limit the size? Even if you expect to have up to 300 characters in the 'comments' column for example, what is wrong with defining it as 3,000? it's just metadata, right? Wrong...

Although physically, storage will be exactly the same if you define your VARCHAR as 300 or 3,000, it can still make a huge impact on performance. SQL Server needs to estimate the work space that is required for each query and allocate it before the query begins to execute. For variable type columns, the estimation is that the data size will be 1/2 of the max size defined for the column. So if you have a column that is defined as 300 bytes, the allocation estimation will be 150 but for 3,000 - the estimate will be 1,500. On systems that experience memory pressure, this can make a huge difference in performance as your queries will wait for memory allocations, potentially significantly hurting performance in addition to the fact that needless memory will be allocated that could serve SQL Server for much more useful purposes.

...
Tags: common pitfalls, common pitfalls, data types, Performance
Hits: 929 0 Comments Continue reading

Latest Posts

  • EZManage SQL vendor and developer announced the acquisition of the fast growing company DBSophic.
    The acquisition will expand the acquiring company's solutions for the applicative environment of MS
    Read More
  • A Month of Joins - T-SQL Tuesday #37
    T-SQL Tuesday is now entering its fourth year! Sebastian Meine, who's hosting this month's T-SQL Tue
    Read More
  • Where did I leave my keys?
    "If you walk into a room full of DBAs or DB developers and you feel like having the same kind o
    Read More

Tag Cloud

Maintenance Announcements Performance SQL Graphics Presentations MVP installation SQL Server 2012 common pitfalls data types SSDT TSQL2sDay Qure Analyzer Articles Statistics Performance hardware HA/DR EZManage sql DBsophic RTM Statistics iPad Publications

Blog Calendar

Loading ...
© 2011 DBSophic Ltd. All rights reserved. | Legal