THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Browse by Tags

All Tags » Best Practices » Testing   (RSS)
Showing page 1 of 2 (20 total posts)
  • Plan for Diagnostics in Cloud Computing From the Git-Go

    “Git-Go” is something we say in the South that means “right at the start”. I’ve seen several applications for on-premise systems that don’t have much in the way of diagnostics - the developers rely on a debugger, the event logs on the server and client workstation, and most of all, the ability to watch the system from end-to-end. This approach ...
    Posted to Buck Woody (Weblog) by BuckWoody on September 6, 2011
  • Performance impact: The cost of doing small lookups in a large batch update

    Lookup tables are widely used in database applications for good reasons. Usually, a lookup table has a small number of rows and looking it up with a join is fast, especially when the table is already cached. Recently, I needed to update every row in many relatively large tables, each of which was identically structured, had ~25 million ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on April 4, 2011
  • Killing a SQL Server thread? Don’t!

    Sometimes, when you kill a session (i.e. a spid) in a SQL Server instance, the spid just refuses to go away not because it’s doing a rollback. Perhaps, it’s stuck on a certain dependency on something external to SQL Server or it’s just simply stuck for some decipherable reasons. And the spid may hang around for as long as the instance is online ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on February 4, 2010
  • Performance impact: thread mode vs. fiber mode

    SQL Server can run in one of two modes: thread mode or fiber mode. By default, SQL Server runs in thread mode in which a SQL Server worker is associated with a Windows thread throughout all phases of its execution. This can be changed with the sp_configure option ‘Lightweight Pooling’. When Lightweight Pooling is turned on, SQL Server runs in ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on May 4, 2009
  • Performance impact: a large number of virtual log files – Part II

    In my previous post on the performance impact of having a large number of virtual log files (VLFs) in a transaction log, I showed that a large number of VLFs could be very bad for SQL Server 2008 performance. The test workloads were large batch delete, update, and insert. In other words, they were single monolithic transactions that ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on February 12, 2009
  • Performance impact: a large number of virtual log files – Part I

    It is generally known that having a large number of virtual log files (VLFs) in a database transaction log is undesirable. A blog post by the Microsoft support team in Stockholm showed that a large number of virtual log files could seriously lengthen the database recovery time. Tony Rogerson also reported that lots of virtual log files were bad ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on February 9, 2009
  • Performance impact: file fragmentation and SAN – Part IV

    Lies, damned lies, and statistics!   If you have read my three previous posts (1, 2, 3), you may walk away with an impression that on a drive presented from a high-end enterprise class disk array, Windows file fragmentation does not have a significant performance impact. And I’ve given you empirical data—oh yeah, statistics—to support that ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on December 22, 2008
  • Performance Impact: Manual Checkpoints are not Necessarily Evil

    In my two previous posts on the performance impact of frequent manual checkpoints and the I/O behavior of frequent manual checkpoints, I demonstrated that frequently issuing manual checkpoints can be bad for performance and why it's bad from the storage perspective. If you were led to believe that manual checkpoints were always bad, that wasn't ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on August 20, 2007
  • Performance Impact: Frequent Manual Checkpoints and Their I/O Behavior

    In my previous blog post on the performance impact of frequent manual checkpoints, I highlighted the performance peril of going overboard with manual checkpoints, and I suggested that a major contributing factor was the failure of frequent manual checkpoints to take advantage of the throughput potential of the underlying storage. But I didn't ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on August 17, 2007
  • Performance Impact: Frequent Manual Checkpoints

    Recently, I was asked why the following script took a very long time to insert 24GB of data into a single table in SQL Server 2005 (the database was in the simple recovery mode): -- Name: Script 1SET NOCOUNT ON SET IMPLICIT_TRANSACTIONS ON DECLARE @i int SET @i = 1 WHILE @i <= 3145728 -- (1024*1024*3) BEGIN INSERT tbTest(i, ...
    Posted to Linchi Shea (Weblog) by Linchi Shea on August 13, 2007
1 2 Next >
Privacy Statement