Having spent time as both developer and DBA, I’ve been able to identify a few bits of advice for developers who are working closely with SQL Server. Applying these suggestions can help in several aspects of your work from writing more manageable source code to strengthening cross-functional relationships.
Note, this isn’t a countdown – all of these are equally useful. Apply them as they make sense to your development efforts.
1 Review and Understand Connection Options
In most cases, we connect to SQL Server using a “connection string.” The connection string tells the OLEDB framework where the server is, the database we intend to use, and how we intend to authenticate.
Example connection string:
Server=<serverinstance>;Database=<database>;User Id=<username>;Password=<password>;
The common connection string options are all that is needed to work with the database server, but there are several additional options to consider that you can potentially have a need for later on. Designing a way to include them easily without having to recode, rebuild, and redeploy could land you on the “nice list” for your DBAs.
Here are some of those options:
- ApplicationIntent: Used when you want to connect to an AlwaysOn Availability Group replica that is available in read-only mode for reporting and analytic purposes
- MultiSubnetFailover: Used when AlwaysOn Availability Groups or Failover Clusters are defined across different subnets. You’ll generally use a listener as your server address and set this to “true.” In the event of a failover, this will trigger more efficient and aggressive attempts to connect to the failover partner – greatly reducing the downtime associated with failover.
- Encrypt: Specifies that database communication is to be encrypted. This type of protection is very important in many applications. This can be used along with another connection string option to help in test and development environments
- TrustServerCertificate: When set to true, this allows certificate mismatches – don’t use this in production as it leaves you more vulnerable to attack. Use this resource from Microsoft to understand more about encrypting SQL Server connections
2 When Using an ORM – Look at the T-SQL Emitted
There are lots of great options for ORM frameworks these days:
- Microsoft Entity Framework
- NHibernate
- AutoMapper
- Dapper (my current favorite)
I’ve only listed a few, but they all have something in common. Besides many other things, they abstract away a lot of in-line writing of T-SQL commands as well as a lot of them, often onerous, tasks associated with ensuring the optimal path of execution for those commands.
Abstracting these things away can be a great timesaver. It can also remove unintended syntax errors that often result from in-lining non-native code. At the same time, it can also create a new problem that has plagued DBAs since the first ORMs came into style.
That problem is that the ORMs tend to generate commands procedurally, and they are sometimes inefficient for the specific task at hand. They can also be difficult to format and read on the database end and tend to be overly complex, which leads them to perform poorly under load and as systems experience growth over time.
For these reasons, it is a great idea to learn how to review the T-SQL code ORMs generate and some techniques that will help shape it into something that performs better when tuning is needed.
3 Always be Prepared to “Undeploy” (aka Rollback)
There aren’t many times I recall as terrible from when I served as a DBA. In fact, only one stands out as particularly difficult. I needed to be present for the deployment of an application update. This update contained quite a few database changes. There were changes to data, security, and schema.
The deployment was going fine until changes to data had to be applied. Something had gone wrong, and the scripts were running into constraint issues. We tried to work through it, but in the end, a call was made to postpone and rollback deployment. That is when the nightmare started.
The builders involved were so confident with their work that they never provided a clean rollback procedure. Luckily, we had a copy-only full backup from just before we started (always take a backup!).
Even in the current age of DevOps and DataOps, it is important to consider the full scope of deployments. If you’ve created scripts to deploy, then you should also provide a way to reverse the deployment. It will strengthen DBA/Developer relations simply by having it, even if you never have to use it.
Summary
These 3 tips may not be the most common, but they are directly from experiences I’ve had myself. I imagine some of you have had similar situations. I hope this will be a reminder to provide more connection string options in your applications, learn more about what is going on inside of your ORM frameworks, and put in a little extra effort to provide rollback options for deployments.
Jason Hall has worked in technology for over 20 years. He joined SentryOne in 2006 having held positions in network administration, database administration, and software engineering. During his tenure at SentryOne, Jason has served as a senior software developer and founded both Client Services and Product Management. His diverse background with relevant technologies made him the perfect choice to build out both of these functions. As SentryOne experienced explosive growth, Jason returned to lead SentryOne Client Services, where he ensures that SentryOne customers receive the best possible end to end experience in the ever-changing world of database performance and productivity.