Blog do EzequielPortuguese PFE SQL Server Team
The purpose for this procedure to to perform an intelligent defrag on one or more indexes for one or more databases. The 1st release was inspired by an earlier release of Michelle Ufford’s code in SQLFOOL.com site, and has since evolved to suit different and added needs. In a nutshell, this procedure automatically chooses whether to rebuild or reorganize an index according to its fragmentation level, amongst other parameters, like if page locks are allowed or the existence of LOBs. All within a specified time frame you choose, defaulting to 8 hours. The defrag priority can also be set, either on size, fragmentation level or index usage (based on range scan count), which is the default. It also handles partitioned indexes, optional statistics update (table-wide or only those related to indexes), rebuilding with the original fill factor or index padding and online operations, to name a few options.
A while back I blogged here about how a good strategy of log file growth could potentially impact ongoing operations with your SQL Server. It’s known that VLFs (number and size) impact on the performance of such actions as scanning all VLFs for transactions that are marked for replication or log backup operations. Following that blog post, I became curious as to how having a poor strategy could potentially impact some less than obvious operations within SQL Server and decided to put that to a test..
EDIT (11-01-2013): Fixed issue with generating all logins even when single database was chosen.
I've recently joined the PFE team in Portugal, and one part of the job i like is giving something back to the community. Whenever possible, i will be focusing my posts on SQL scripts that may help on everyday DBA tasks, something in the likes of a "SQL Swiss Army Knife". According to BOL, SQL securables "are the resources to which the SQL Server Database Engine authorization system regulates access".
Hello all, Here is another one focusing on SQL scripts that may help DBAs, following the series "SQL Swiss Army Knife". This time we are exploring an alternative way of verifying autogrow times besides checking the ErrorLog for any recorded information, and that is when an error 5144 or 5145 occurs.
Here is another one focusing on SQL scripts that may help DBAs, following the series "SQL Swiss Army Knife". This time we are exploring FILESTREAM.