Why you should love your connection strings

Who is responsible for configuring and maintaining connection strings within your organization? Developers, operations, the database team? For me, the correct answer should be everyone – each team has an important part to play in configuring optimal connection strings. Unfortunately in most organizations, once they’re configured that’s it – but there’s so much to gain from giving them a bit of love.

Connection strings are essential to every application – without them we can’t connect and nothing works. So it’s pretty obvious when they are wrong, but what about when they’re just not quite right? Optimizing your connection strings can improve the performance of your application and databases. Using the correct options will make them more secure, faster, require fewer resources, simplify maintenance and reduce the time it takes to diagnose issues.


Basic Settings

There’s an evergrowing list of options available to tune connection strings to suit your application, but it’s difficult to know what does what. This is made worse by most settings having 2 or 3 synonyms, just to keep you on your toes! To help with this, we created an online Connection String Generator which reduces some of the complexity and builds your connection string for you.

You don’t need much to get a connection string working. Most settings have a default if you don’t explicitly set them. Therefore, the minimal amount you need is simply the server name and how you wish to authenticate.

Data Source=database_server;Integrated Security=false;User ID=sql_user;Password=password123

Another setting that I’d like to class as a basic one is Application Name. It won’t improve the performance of your application but you’ll be glad you set it when you’re diagnosing server issues. Application name simply populates the program_name field in sys.dm_exec_sessions. So the next time your application is overloaded or having issues, you’ll know exactly what program on the host is causing it.

Application Name=Steves Test App;

Network and Security

Most people connect to SQL Server using SQL authentication purely through habit. Instead, try running your applications under service accounts, then connecting to SQL Server using integrated security. Here’s why.

Connecting via integrated security removes the requirement of storing passwords in plain text web.config files. Although these can be encrypted, you don’t have the same level of control over these. For example, web.config files may also be stored in source control or emailed around in zipped up folders of the application, which enables more people to gain control to your production systems.

Using Windows authentication over SQL authentication also removes the requirement of synchronizing security ids (SID) between availability group nodes. If you’re not aware of this issue, here’s a blog on synchronizing AG nodes, but if your SIDs are not synchronized, you won’t be able to authenticate after a failover.

Integrated security is simple to implement and much easier after the first time, so please have a good stab at it. Most applications can be updated using the same method when altering the service account for SQL Server and SQL Server Agent. You could go one step further by adding the service accounts that require similar access into AD groups, which will make maintenance and administration easier.

Data Source=database_server;Integrated Security=sspi

Network settings are an area you can get lost in and cause some interesting application problems, but there are few that should be considered when building connection strings.

Setting connection timeout is one. You may not want to wait for the default 15 seconds for new connections if your application tries to log thousands of requests a minute. On the other hand, you may want to allow 60 seconds to connect to a server on the other side of the world.

Connection Timeout=60;

Once the connection is established, subsequent queries will be quicker as the application will reuse the connection. This is where connection pooling comes in.

Connection pooling is a blog in itself but there are three main settings you should consider. Min pool size and max pool size control the size of the connection pool, so how many connections you want to keep open and how many connections you’re likely to use. The main gotcha here is that max pool size has a default of 100, so if you don’t set it, this is what you get. If you’re happy with 100 then actively set that, so you can see what it is rather than relying on secret knowledge.

Creating connections to a database can be expensive. Imagine that person on the phone in videos of the stock exchange. Instead of keeping their colleague on the phone and relaying commands, they dial the phone number of the other person every time, say hello, give them the command to sell (or order pizza? I’m not actually sure what they do) and then say goodbye.

So, we want to keep them open, but there’s a balance. Too few connections will starve your application, but too many can consume precious resources – from using memory in SQL Server, to playing havoc with your load balancer by exhausting the number of concurrent connections allowed and causing issues with load distribution (covered next).

Min Pool Size=10;Max Pool Size=100;

The third option I think you should consider is Connection Lifetime. Its synonym, Load Balance Timeout, gives us a pretty good clue to why you should set it. With pooling, we create a connection and leave it open so it can be reused. This is great until we need to add a new server in a distribute the load. Let’s say we have a hundred connections to servers 1, 2 and 3 but none to 4 as it’s just been restarted. Once this server comes back online it won’t get a new connection until the application needs to create one, and if we’ve set our pools correctly, it won’t.

Setting the connection lifetime tells the application to kill a connection after a certain length of time, giving the load balancer the opportunity to evenly distribute the database connections and therefore load.

Connection Lifetime=300

Complete Connection String

There are so many options that can be set and I haven’t gone into enough detail (more blogs to come) but if we use the Connection String Generator and set the options we’ve discussed in this thread, we’ll end up with the following:

Data Source=database_server;Application Name=Steves Test App;Connection Timeout=60;Integrated Security=sspi;Min Pool Size=10;Max Pool Size=100;Load Balance Timeout=300

Four ways to use instance snapshots

Instance snapshots can be invaluable to anyone working with servers. From tracking differences over time, to change deployment, here are some ideas on how they can help you. Then, discover how you can use the free tools in Aireforge Studio to implement them.

Tracking differences over time

By taking a snapshot of your servers’ configuration at the right moment, you can use it as a baseline for comparison in the future. This is helpful when:

  • You’re taking a holiday and you want to know what happened while you were away.
  • You want to capture the ‘before’ of a client’s servers prior to a health check. You might add this to a report to show the improvements you’ve made.
  • There’s a change freeze and you’d like extra reassurance nothing has been amended by accident.

Change deployment

When you’re deploying changes:

Take a snapshot prior to any changes to use as a configuration back up. Then, when you’re making changes, you can test them against an exact recreation of your servers, helping to minimize mistakes when you go live. You can also do this during performance tuning.

When someone else is deploying changes:

With a snapshot, you’ll be able to see any impact others’ changes may have had on your servers by comparing a pre-changes snapshot with post-release servers.

Remote troubleshooting

Working with servers that you don’t have access to? Get your customer to capture a configuration snapshot, then use this for analysis, comparison and more. This way, you’ll get the information you need, save support costs and reduce turnaround time.

Golden configuration template

When you’ve got a server into an ideal state, you might use a snapshot of it to:

  • Share configurations with colleagues as an example of best practice.
  • Use as a reference or template for future server setup.
  • Use as future reference for the same server if it experiences performance issues later down the line.
  • Create example files to distribute with your software to aid installations.

How Aireforge Studio helps

In Aireforge Studio’s Compare module (totally free), you can capture and save a snapshot. Then, use it for comparison against the same servers (for comparing server differences over time), comparing against other servers (useful when using your server as a golden template, or for viewing and sharing.

Taking a snapshot

From the Compare tab, check the server/s you want to take a configuration snapshot of.  Press the ‘Snapshot’ button, then choose ‘All comparisons’ or ‘Selected comparisons’ (depending on whether you want to snapshot all configuration or just a subset).

Snapshot button

You will then be prompted to save the snapshot to file. That’s it! You can now use this saved snapshot to compare against any of your servers within Aireforge Studio.

Using a snapshot

To compare the snapshot against the same servers captured within it, go straight to the next step. To compare against other servers, select those you wish to compare against first.

Press ‘Load’ and select the snapshot to open. If you recently took the snapshot, it will appear on the drop-down menu.

snapshot 2

Next, a dialog will be shown to let you choose what to do with the snapshot:

Loading snapshot dialog

  • Compare with same servers: compares the contents of the snapshot against the current state of the same servers.
  • Compare with currently selected servers: compares the contents of the snapshot against the currently checked servers on the Compare tab.
  • View only: simply opens the snapshot for viewing, without taking any new snapshot.

When comparing the snapshot against any servers, the comparison will be against the current state of the servers. You will now be presented with the comparison results or a view-only snapshot file.

Watch the video

All of the functionality in this post is free. Download yours at aireforge.com

Image courtesy of https://unsplash.com/@makariostang

Continue reading →

Potential pitfalls using Always On Availability Groups

Always On Availability Groups are a great way to improve uptime and protect against data loss. However, whilst the databases within the availability groups are synchronized, the instance objects, users and configuration settings that the system relies on are not. This could cause the following to happen when you failover:

  • Authentication issues. Your users and database roles are synchronized but do not match up to a server login or server role. Your systems are down and you’re helpless.
  • Missing/incorrect Agent Jobs. A difference in job steps or schedules can result in jobs not being run or data issues due to missing changes and bug fixes.
  • Missing server objects. Issues with Linked Servers, Trigger or an incorrect configuration setting could result in queries failing or performing much slower than the primary.

It’s very easy for server objects to become out of sync, causing the above. Changing a user, fixing a script within jobs, updating the job schedule: these regular tasks can all cause major issues after failing over.

“You should routinely maintain the same set of user logins and SQL Server Agent jobs on every primary database of an Always On availability group and the corresponding secondary databases.” Microsoft Docs

How do I fix it?

Here are some ways you can protect yourself from Availability Groups becoming out of sync:

  1. Use an active directory to help mitigate the SID issues (be aware that you might still encounter differences using this method– users’ rights or disabled users, for example).
  2. Manually compare the SIDs between your instance and AG using scripts.
  3. Compare job information using a text comparison tool like code compare.
  4. Create your own custom script that covers every possible object and setting and manually compare the results on a regular basis.
  5. Use the free comparison tool in Aireforge Community Edition.

I’m too busy for that – is there a faster way?

Use Aireforge Studio’s instance-level comparison tool to quickly spot differences (it’s free). Identify varying SIDs, user access rights, server configuration (e.g. max threshold) between your instances in a few clicks.

You can incorporate these comparisons into weekly checks. Many of our users even run these daily so they’re less likely to be caught out during failover. As a minimum, you could compare and fix any differences before planned failovers or any significant changes.

I’ve found the changes, but I need help fixing it…

Aireforge Advise (not free, but reasonable), will give you the SQL to fix these differences once you’ve identified them.

Aireforge Studio simplifies database management for SQL Server & Azure SQL databases. Download for free at aireforge.com.

How to use Aireforge Studio as a free RDP & SSMS Manager

Working with an estate of hundreds of servers? Finding it difficult to keep a shared, central list of server information up to date?

Everyone seems to have their own solution for maintaining the details their team needs for SQL Server Management Studio/Remote Desktop. Maybe you store this information in a spreadsheet or text file on a shared network drive, have a local copy, or use a specialised separate program to coordinate this knowledge. Maybe you even have it printed out and taped to the wall!

All these methods come with their pros and cons, but besides the pricier options, most require regular manual work. We’ve got another way for you to try, and it’s free.

How Aireforge Studio can help

When using Aireforge Studio, you start by setting up all your servers in the Estate module. The list then becomes your central workspace for you to compare settings, run health checks, scripts etc.

To launch SSMS or Remote Desktop, there’s a right-click option, then the relevant address details are pre-populated. No more moving between documents or copy and paste! You can even give servers friendly names to make your workspace faster to navigate.

For teams, there’s an alternative to a centralised document: share a secure, password protected Aireforge profile. That way, you’re only inputting this data once and everyone is always getting the recent information.

Download your free tools today at aireforge.com.

Visit our Knowledge Base to learn how to set it up.

remotedesktop