Calling all SQL Server users! SQLBits is going west to Newport, Wales on the 19th-21st November 2009. Saturday 21st is a community day and will be free!
It’s being hosted from the Celtic Manor resort, so you could also bring your golf clubs too! I will suggest that if you did play golf on the Montgomery course, hire a buggy! Or a trolley at the very least!
I was interested to read that MySpace use SQL Server. MySpace is a huge database. They have some 4 petabytes of total data which is a huge environment. The actual architecture behind the website is very impressive.
I’d recommend any SQL Server geek to go through this slideshow and get a flavour of how things tick behind the scenes.
I stumbled across a blog by Mark Ginnebaugh and thought I’d publish the link through his blog which is also a good read!
http://www.slideshare.net/markginnebaugh/myspace-data-architecture-june-2009
Do you backup production databases? If you do, fantastic. If you don’t, well, cross your fingers and just about everything else and hope that you don’t suffer a failure of any kind!
I read a number of posts in various forums where a database has become corrupt or there is no backup and you get a vast array of answers as to why there is no backup in place. In some cases, you may find that somebody has had the production databases dumped on them because they mentioned that they saw a SQL statement one time. While it’s still not really acceptable that there may be no backup in this scenario, it is understandable. However, if you are in this situation, then I would suggest you read Books on Line and ensure your data is backed up – don’t forget the restores too…A backup is no good if you can’t restore it!
For those full time DBA’s who have no backups, you have no excuse at all. Every DBA should be able to backup and restore databases in a variety of configurations and scenario’s.
I can’t stress enough the importance of backups.
Rant over! I’ll actually put together a series of posts to walk through backups and restores and the various configurations and scenarios.
We’ve all used DBCC SHRINKFILE or DBCC SHRINKDATABASE, right? It’s a really usefull tool. However, I stumbled across a blog by Paul Randall today and learnt something new. The shrink process can fragment your indexes!
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
Typically, DBA’s may shrink the database or data file following an index rebuild to reclaim the space. However, testing out Paul’s sample code, I discovered I had 99% fragmentation! This shocked me. Although I do not perform the shrink as part of the process, I would occasionally shrink some data files if our disks started alerting at 90%. In some cases, I’d reclaim back 25% of the database so it was a nice fix!
While Paul’s link demonstrates this issue by deleting a filler table, the same problem does occur if you simply add ramdom data to an index, rebuild the index and then shrink the data file – I tested this by inserting GUID values in batches.
This fragmentation only concerns the shrinking of the data files. Shrinking a log file does not cause the same problem.
So for all of you DBA’s out there who do use the shrink commands offered, think again, you could well undo all of your maintenance you have just performed!