Autogrowth, shrink and database performance

Question

I have already asked some questions about Autogrowth and shrink. But I have some doubts related to it.
1)I have a database which grows about 300 MB every month. So is it best to set Autogrowth of 300 MB to it? Now 10 MB is set.
2)I have so many small databases which really have data of about 50 MB. But it's physical size is about 900 MB.(So 850 is free space). I have not shrinked this database. As if i shrink it then again when data gets added autogrowth occurs. But adding data to
this database is rare. So I think it will not gro more than 200 mb for next one year. So should i shrink the database? If I keep it as it is Should that cause any performance problem? Or having more free space(more than 90%) in database will cause any problem.
I think most of the people think having large physical size will cause performance problem. So is it true or not?
3) SQL Server 2008 R2 Express Database Size Limit is 10 GB. So is it physical size of both mdf and ldf file together? because I need to consider this if i should shrink database at any point.

Answer 1

1) If this is a database where you expect performance, the current auto growth setting gives the following disadvantages:
- It will affect performance. Database files grow too often and it's unnecessary work for SQL Server during normal operations. It takes time to grow database files and especially if you have not turned Instant File Initialization on, which is highly recommended
by the way. I would prefer to grow databases off peak hours and once a year.
- The database file(s) gets fragmented. If SQL keeps allocating small 10 MB chunks the file will eventually have hundreds of fragments instead of just a few. Fragmentation reduces IO performance.
I would set the database file sizes to what you expect it to grow to within a year, plus 10 % and set auto growth to perhaps 300 MB that will kick in if your calculations were off. Next year you manually grow the database again according to your new 1-year
prediction. That way you will hopefully get less fragmentation and very few operational disturbances due to auto growth in peak hours.
2)
Keeping the database as is will not cause anything else than that the database is consuming unnecessary disk space, a lot of free space does not affect performance negatively. SQL Server does not do more IO just because you have large file(s). Having to little
free space in a db can cause internal fragmentation and will affect performance negatively. However, you should not fill up the spindles to more than 80% (some say 85%) since your storage will be noticeable slower.
You can shrink the database but that usually causes performance problems due to the shrink operation creates massive internal fragmentation in the database. But you can fix that by rebuilding all indexes and tables, starting with the clustered ones first.
So don't shrink the database so much that it must start with growing itself to accommodate for all index rebuilds.
Hope this helps!
Peter