This article shows how to reduce the periodic spikes in the CPU that are caused by the periodic-executing jobs. There is a good reason to make some changes for dismissing them.

Test Coverage

by Steve Jones

SQLServerCentral.com

Editorial

We don't test software well enough. Obviously we don't write high enough quality software, but testing should catch more issues. Steve Jones talks about how you can perform better T-SQL testing.

How to Fix Ten SSDT Deployment Snags, With or Without ReadyRoll

by Additional Articles

SimpleTalk

SQL Server Data Tools (SSDT)

Even a database development framework like Sql Server Data Tools (SSDT) doesn't get it right all the time, and there are ten deployment 'gotchas' in particular that can cause some head-scratching amongst developers to get right. From his unique perspective of creating a tool to make such deployments in SSDT less stressful, Dan Nolan discusses each pitfall and how to avoid it, whether you have ReadyRoll or not.

Better Coding, More Savings

by Steve Jones

SQLServerCentral.com

Editorial

The way we write code impacts our users, but it can also impact our wallet, especially in cloud computing. Steve Jones wonders how many people bother to profile and test their code.

How to Capture Deleted Records

by Darko Martinovic

SQLServerCentral.com

T-SQL

This article shows a few techniques that help in capturing deleted records.

The Toolchain for the Job?

by Phil Factor

SQLServerCentral.com

Editorial

Phil Factor ponders the use of toolchains in automation, and wonders if there might not be a better way.

Managing multiple database versions

by Additional Articles

Redgate

SQL Compare

Sometimes, it's necessary to have different versions of a database running in production. But how do you establish a single source of truth in source control? Alex Yates from DLM Consultants shows how to use object filters in SQL Compare to build multiple database versions from the same source.

Which Indexes are not Used?

by Additional Articles

Database Journal

Indexing

During the development cycle, indexes will be placed on SQL Server tables to speed up performance when searching for records. Lots of thought probably has gone into creating just the right mix of indexes based on how developers think customers will use the system. But how do you tell if all the indexes are being used once your database has been implemented into production?