For the second part of this series, I’m relying on a project hosted on codeplex which can be found by the name TSQL Code Smells Finder. The solution consists out of 3 files (one PowerShell script, a text file containing a list with possible errors and a whitelist file) and build within PowerShell, therefore it’s not that complicated to extend the solution later.
When moving a new SQL server database into production or taking over maintenance duties for large and heavenly used databases, you might want to perform some audit’s allowing you to ask some additional questions when the development team is still available or just being aware of possible performance issues / special maintenance routines etc.
I won’t cover why enabling AutoShrink is such a bad idea. There are numerous articles on the web, pointing this out in great detail. However, as a DBA you might want to know how many AutoShrink databases are active on your servers.
Personally, I like to keep a close eye on my servers and users/customers. However, not like to do everything manually. This is not only very time consuming, but also most likely to find important issues rather late, hence the script below.
Very short and simple post however, oh so important especially when a software vendor requires using specific version / hotfix.
The SQL Server SMO client API can be used query and alter settings and objects within your SQL Server instances, however in case you want to query your user database, you will run into some limitations. The client API simply isn’t aware of your data objects and therefore not exposing a typed scheme. Fortunately, it’s pretty easy to accomplish when using the SQL Server PowerShell Module (SQLPS)
Recent Comments