View All Messages Processed By Database Mail

The sysmail_allitems view shows every email that Database Mail has tried to process, whether it was successful or not. This view can help you identify problems by showing you the details of the messages that were sent compared with the messages that weren’t sent by giving you the status of each email.

Here are the status values you’ll see:

View Sent Messages

Use sysmail_sentitems to see which messages were successfully sent. Database Mail marks a message as sent when it is successfully submitted and accepted by the SMTP mail server. However, just because an email was accepted by the mail server does not mean it was actually delivered to the recipient. This just means that SQL Server succeeded in giving the message to the email server, and it is up to the email server to actually send the email. If something went wrong after SQL Server passed it off (like a bounce or spam filter snag), you won’t see that here. Those kinds of issues are up to the mail server to handle and won’t show up in SQL Server logs.

View Unsent Messages

Use the sysmail_unsentitems view to find emails still waiting to be sent or retrying after a failure.
Messages marked unsent or retrying remain in the mail queue and could be sent at any time.
Normally, you will not see many messages here unless there is a delay or email processing issue.

Database Mail marks a message as unsent when it waits in the queue but has not yet been processed.
If a message shows a retrying status, Database Mail tried to send it but could not reach the SMTP server. Retry behavior depends on the settings for Account Retry Delay and Account Retry Attempts.
(For configuration details, see the sysmail_configure_sp stored procedure.)

View Failed Messages

The sysmail_faileditems view is used to return only the messages with the failed status. Use this view to determine which messages were not successfully sent by Database Mail and get message details to help you identify the nature of the problem.

To search for errors that are related to failed emails, use the sysmail_faileditems view to get the mailitem_id of the failed email, and then search for that mailitem_id in sysmail_event_log.

Microsoft also offers this extensive list of Database Mail troubleshooting techniques.

View Email Attachments

Use the sysmail_mailattachments view to list each attachment sent by Database Mail and its properties, such as file name and file size. This view does not store the attachment content, but it lets you track and verify attachments associated with each email. To link attachments to specific emails, cross-reference the mailitem_id with the other Database Mail views listed above.

Take Control of Your Database Mail

Don’t let email issues slow you down. Proactive SQL Server Database Mail troubleshooting keeps your environment stable and your team confident.

Tired of Troubleshooting SQL Server Issues Alone?

Let The SERO Group help you keep your SQL Servers running smoothly. Schedule a quick, no-pressure discovery call today.

The post How to Troubleshoot SQL Server Database Mail Issues Using Built-In View appeared first on The SERO Group.

Compression in SQL Server is a feature that helps to reduce the amount of storage needed for tables and indexes. Think of it like compressing a large file into a smaller one. You’re taking the same data but making it more compact and efficient. The goal is to save space, reduce I/O, and make the most of your storage resources. When data is compressed, the storage required to hold the same data is reduced, which can lead to more efficient use of disk space and faster read operations.

SQL Server provides two main types of compression: row-level compression and page-level compression. Each has its strengths and specific use cases, depending on your data and workload.

Row-Level Compression

Row-level compression focuses on the individual rows within a table. In SQL Server, data types like CHAR, INT, and BIGINT are usually stored in fixed-length formats. This means that if a column is defined to be 100 characters long, but only 10 characters are used, the remaining 90 characters are just sitting there, wasting space. Even if you don’t need all the space, SQL Server still reserves it.

Row-level compression addresses this issue by converting those fixed-length columns into variable-length columns. For example, that 100-character CHAR column would only store the 10 characters you actually need, along with a small amount of overhead for metadata. The result is a more compact representation of your data because SQL Server only stores what it needs, cutting down on the unnecessary padding.

Row-level compression also gets rid of the redundancy of NULL values, replacing them with a more efficient marker. And for small data types like boolean values, SQL Server uses a technique called bit-packing, which allows multiple small values to be stored together in a single byte, saving even more space. The result is smaller, more efficient data storage.

Row-level compression also gets rid of the redundancy of NULL values, replacing them with a more efficient marker. And for small data types like boolean values, SQL Server uses a technique called bit-packing, which allows multiple small values to be stored together in a single byte, saving even more space. The result is smaller, more efficient data storage.

Page-Level Compression

While row-level compression is a great first step, page-level compression takes it a bit further. SQL Server organizes data in “pages” behind the scenes, and each page uses 8KB of storage. With page-level compression, SQL Server compresses entire pages of data, not just individual rows. The idea here is that, rather than just compressing individual rows, SQL Server applies a two-step process to an entire page of data. It’s like compressing a whole chapter of a book instead of just one sentence.

First, SQL Server applies row-level compression to each row within the page, making the data smaller. But then it goes a step further and looks for repeating patterns across rows on the same page (like repeated values) and stores them more efficiently. Let’s say there’s a column in your table with a lot of repeated values, like a date or NULLs. Rather than storing that repeated data over and over again, SQL Server will build a dictionary of those repeated values and store a reference to them instead. This is a huge win in terms of space savings, especially for large tables with lots of repetitive data.

Is SQL Server Compression Right for You?

Compression can offer significant benefits, but it’s not a one-size-fits-all solution. For starters, there may be a slight CPU overhead. Compression isn’t free. Compressing and decompressing data requires processing power. In some cases, especially with page-level compression, this may put a slight strain on the CPU, which might slow down write operations like inserts, updates, and deletes.

Another potential downside is that compression doesn’t always yield massive savings depending on the nature of your data. For example, if your tables are relatively small, you might not see much benefit from compression. Also, if you are storing images in your database (and you really, really shouldn’t be), SQL Server will not be able to compress those. Compression tends to shine most when you have large datasets with lots of redundant values or many NULL entries.

On the flip side, if you’re dealing with a read-heavy workload, compression can significantly improve performance by reducing the amount of data that needs to be read from disk. This is where the benefits of compression really stand out, as it can cut down on I/O and make your database queries faster.

SQL Server compression is a powerful feature for saving space and potentially improving read performance. It helps with both storage and I/O efficiency, especially for large databases with repetitive data. But it’s important to keep in mind that there could be slight trade-offs, particularly when it comes to CPU usage. Testing is key: before you apply compression across your entire database, it’s worth evaluating the impact on both CPU resources and storage.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post Should You Use SQL Server Compression to Optimize Storage and Performance? appeared first on The SERO Group.

What is a Clustered Index?

Think of a clustered index as the primary organizer of your data. It defines the physical order of the data rows in a table. When you create a clustered index on a table, SQL Server sorts the data in that table according to that clustered index. Essentially, the table itself becomes the index, and the data rows are sorted and stored in the same order as the clustered index key.

The catch: you can only have one clustered index per table.This is because there can only be one way to physically organize the data on the hard drive. This index is often created on the primary key column, but it doesn’t have to be.

Earlier SQL Server documentation called the clustered index the most important index for a table. Microsoft values clustered indexes so highly that SQL Server automatically creates one on the primary key if you don’t specify it!

What is a Non-Clustered Index?

Unlike clustered indexes, non-clustered indexes do not define the physical order of the data rows. Instead, they create a separate structure that helps SQL Server find data more quickly. A good way to think of a non-clustered index is like a miniature copy of your table containing just the columns listed in the index. As data is added or modified in your table, SQL Server automatically keeps the non-clustered indexes in sync.

Non-clustered indexes are what make your queries run faster. Having smaller, more targeted data sets allows SQL Server to more quickly hone in on the data it is after. For example, if you’re frequently filtering your data by customer name or order status, a non-clustered index on those columns can help make those queries faster. And, with non-clustered indexes, you can have multiple indexes on a table, which is useful when you need to optimize searches on different columns.

Another cool thing about non-clustered indexes is that they can be used as something referred to as covering indexes. A covering index contains all of the data your query needs, so SQL Server can retrieve the data directly from the index without even touching the actual table. This can save a lot of time and reduce the number of I/O operations. Covering indexes are great for smaller, frequently run queries.

Having Too Many Non-Clustered Indexes

Non-clustered indexes boost query performance, but too many can hurt your database. Each added index increases storage requirements. More importantly, modifying data forces SQL Server to update every related index. More indexes mean slower operations, especially in write-heavy databases.

For example, if you have 1 table that has 10 non-clustered indexes on it, inserting 1 row will actually result in 11 inserts (1 insert for the table and 1 additional insert for each of the 10 indexes). Every time the data is modified in the table, the indexes must also be updated to reflect the changes.

Thankfully, SQL Server provides tools that let you see which indexes are being used and which ones are not. You can query SQL Server’s Dynamic Management Views (DMVs), such as sys.dm_db_index_usage_stats, to identify indexes that are rarely used. Drop unhelpful or unused indexes to reduce overhead and improve performance.

Both clustered and non-clustered indexes improve SQL Server performance, but using them correctly is crucial. Clustered indexes define data order, while non-clustered indexes speed up queries. Balance your index strategy by choosing the right indexes for each query.

Want to Work with Us?

Want expert help managing your SQL Servers? The SERO Group takes the guesswork out of optimization. Schedule a no-obligation discovery call with us today to get started.

The post Clustered vs. Non-Clustered Indexes: How to Optimize SQL Server Performance appeared first on The SERO Group.

Here are a few of the ways your database design can impact your application’s success:

Faster Data Retrieval

A well-designed database makes it easier and faster to find the data your application needs. For example, properly structuring your tables and relationships and having good indexes in place allows SQL Server to quickly locate the right information in your database.

Without these optimizations, your database has to do more work, leading to slower response times. Over time, as your database grows, these delays can pile up, frustrating users and affecting your app’s overall performance.

Structured for Future Growth

Applications often start small but grow in complexity and size over time. A good database design prepares your application to handle increasing data volumes and user loads. For example, splitting a large table into smaller partitions based on date ranges or geographical regions helps ensure queries are faster because they only have to search the relevant data.

As your app attracts more users, it will face increased demand for data access and processing, and your database needs to be able to handle this pressure. Techniques like indexing, query optimization, and using appropriate isolation levels play a big role in maintaining performance under heavy loads. And strategies like row-level locking or read replicas can ensure that high traffic doesn’t impact the user experience.

If these types of strategies aren’t considered during the design phase, you might face significant challenges as your application tries to scale.

More Efficient Resource Utilization

Good database design ensures that your application uses system resources like CPU, memory, and storage as effectively as possible. This means your app can perform well even with limited or less expensive hardware, saving money and avoiding unnecessary upgrades.

For example, choosing the right data types for your data columns can reduce storage requirements and speed up processing. And indexing, when done correctly, significantly improves the read performance of your queries and can cut down on memory and CPU usage, while missing indexes can slow down your entire application.

In Conclusion: SQL Server Database Design Matters

Taking the time to plan your database properly can save you headaches down the road and ensure your application is fast, reliable, and ready for anything.

Want to Work With The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How Proper Database Design Improves SQL Server Performance and Scalability appeared first on The SERO Group.

Just to be clear, storing sensitive information as a clear text string is a really, really, really bad idea.

Not encrypting information in a database can cause serious problems. As just one example, if the database is compromised, all user passwords could be exposed. Data breaches are becoming more and more common. If the authorities come knocking on your door, you need to be able to show them that you at least made a concerned effort to protect that data.

Encrypting text that will need to be decrypted

In some cases, you may be able to store your sensitive data as strongly encrypted text that will never need to be decrypted. For example, hashing a password used for your application login and then just comparing the hashed password for the login instead of the actual password. But, in most cases, being able to decrypt the sensitive data is going to be necessary.

In these cases,  ENCRYPTBYPASSPHRASE (available in SQL Server 2008 and up) offers one of the simplest ways for you to encrypt sensitive information in a way that can also be decrypted (by using DECRYPTBYPASSPHRASE). At its very basic, ENCRYPTBYPASSPHRASE requires two mandatory arguments: a passphrase used to generate the encryption key and the text to be encrypted.  Notice that it specifies a passphrase, not password. There is an important difference between these two.

A passphrase vs. a password

As described in the ENCRYPTBYPASSPHRASE documentation: 

A passphrase is a password that includes spaces. The advantage of using a passphrase is that it is easier to remember a meaningful phrase or sentence than to remember a comparably long string of characters.

Many people don’t realize that you can use a space as a legitimate special character in most passwords. By doing this, you can generate a much more secure password sentence (or phrase) instead of a single word. An example of a passphrase may be something like “I forgot my password!”

Just to be clear, a space is not required in your passphrase for ENCRYPTBYPASSPHRASE. If you wanted to use a GUID for your passphrase or a random string such as “Zgt9$Ex%*unZO8Z},” that is perfectly acceptable.

Using ENCRYPTBYPASSPHRASE

For the examples in this post, I am going to use the encryption passphrase “This is my Passphrase!”, and the text to be encrypted is “ABC123”.

The basic syntax is:
ENCRYPTBYPASSPHRASE(‘encryption passphrase’, ‘text to encrypt’)

There are other arguments that can be used with ENCRYPTBYPASSPHRASE (see MSDN Doc), but for this simple example we are just using the two mandatory arguments.

To view the encrypted value of the text “ABC123”, you would use this script:

SELECT ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123');

That SELECT statement will return a VARBINARY value such as: 0x0100000093EEC20B790EF208B1FB631F0AB3028E3A8C196643C4BD578528A0DFAE7AB45B

It is important to note that the VARBINARY value returned from ENCRYPTBYPASSPHRASE is nondeterministic, meaning that even with the same input it will not generate the same output every time.  So you can run the exact same SELECT statement multiple times and get a different result each time.

Thankfully, this output has no bearing on using the DECRYPTBYPASSPHRASE function. As long as you have the correct passphrase, DECRYPTBYPASSPHRASE will successfully decrypt any of those VARBINARY results to their original value.

Storing an encrypted value in a table

Now that we know how to encrypt a sensitive text string, let’s take a look at how to store that encrypted value in a table.  Since the value returned from ENCRYPTBYPASSPHRASE is a VARBINARY data type, that is how we want to store it since this is also the data type required by DECRYPTBYPASSPHRASE.

The first thing we need to do is determine the size of our encrypted column in our table. The VARBINARY values returned by ENCRYPTBYPASSPHRASE can vary in size, with maximum size of 8,000 bytes. The size of the returned value is going to depend on the size of the actual text being encrypted. You can use the DATALENGTH function to help figure that out. If you have a way to control the maximum allowed length of the sensitive text value you want to encrypt, use that size for your table column, but try not to use VARBINARY(8000) if you don’t have to.

Here is a simple example of storing our encrypted text in the [Password] column of a table:

CREATE TABLE dbo.Users ([UserName] VARCHAR(50), [Password] VARBINARY(50))
 
INSERT INTO dbo.Users ([UserName], [Password])
VALUES ('Charlie Brown', ENCRYPTBYPASSPHRASE(N'This is my Passphrase!', N'ABC123'))
 
SELECT [UserName], [Password]
FROM dbo.Users

Using DECRYPTBYPASSPHRASE

Now that we have our sensitive text encrypted, we need to be able to decrypt it as well.  This is easily done by using the DECRYPTBYPASSPHRASE function with the same passphrase we encrypted our text string with. However, DECRYPTBYPASSPHRASE also returns a VARBINARY value, which we will have to convert to a string.  This can be done by adding a CONVERT function to our SELECT statement.

SELECT [UserName], CONVERT(NVARCHAR, DECRYPTBYPASSPHRASE(N'This is my Passphrase!', [Password]))
FROM dbo.Users

Now you should see your decrypted value returned correctly in clear text. ENCRYPTBYPASSPHRASE offers a quick and easy way for you to encrypt text in SQL Server and can be useful for encrypting sensitive information if you need to be able to decrypt it later. 

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post How to Encrypt Sensitive Text in SQL Server with ENCRYPTBYPASSPHRASE appeared first on The SERO Group.

I should also mention that the results of these queries will only go back to the last SQL Server start time. Anything that occurred before then won’t be available.

Logins Vs. Users

First, let’s take a look at the difference between “logins” and “users” in SQL Server, as people sometimes get them confused, or think they’re the same thing. A “login” allows access to a SQL Server instance. A “user” allows access to a specific database on that instance. Usually, a user is tied to a login, although you can have a user that is not tied to a login (known as a loginless user).

When was the last time a login was used?

--list of logins and last time each logged in
SELECT [Login] = login_name 
	,[Last Login Time] = MAX(login_time)
FROM sys.dm_exec_sessions
GROUP BY [login_name];

Which logins have logged in within the last X hours?

--all logins in the last 4 hours
SELECT [Login] = login_name
	,[Last Login Time] = login_time
	,[Host] = HOST_NAME
	,[Program] = PROGRAM_NAME
	,[Client Interface] =  client_interface_name
	,[Database] = DB_NAME(database_id)
FROM sys.dm_exec_sessions
WHERE [login_time] > DATEADD(HH,-4,getdate())--modify date as needed
ORDER BY [login_time] desc

How many times has each login logged in within the last X hours?

--login counts for the last 4 hours
SELECT [Login] = login_name
	,[Last Login Time] = MAX(login_time)
	,[Number Of Logins] = COUNT(*)
FROM sys.dm_exec_sessions
WHERE [login_time] > DATEADD(HH,-4,getdate())--modify date as needed
GROUP BY [login_name]
ORDER BY [Login] desc

Which logins have Sysadmin access?

--check for logins with sysadmin access
SELECT [Login] = name
	,[Login Type] = type_desc
	,[Disabled] = is_disabled
FROM     master.sys.server_principals 
WHERE    IS_SRVROLEMEMBER ('sysadmin',name) = 1
ORDER BY [Login]

Checking A User’s Access To Databases

This query will return a list of databases that the specified user has access to. This will work for SQL Server Logins as well as Active Directory Logins. This is done by specifying EXECUTE AS LOGIN just before the query. (also be sure to specify REVERT after the query runs)

It should be noted that this query only shows you what databases the user can access, not the permissions the user has on the databases.

EXECUTE AS LOGIN = 'YourDomain\User.Name' --Change This
	SELECT [name]
	FROM MASTER.sys.databases
	WHERE HAS_DBACCESS([name]) = 1
REVERT

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post Useful Scripts For SQL Server Logins and Permissions appeared first on The SERO Group.

Ideally.  

But let’s be honest—how often does that happen? Even if you’re committed to staying current, finding out which deprecated features are still in use can be a challenge. Fortunately, SQL Server tracks this information for you. Simply run the following query against sys.dm_os_performance_counters to get a list of deprecated features and how many times each of them has been used.

SELECT  object_name, instance_name, cntr_value
FROM	sys.dm_os_performance_counters
WHERE   counter_name = 'Usage'

According to the MSDN doc on the Deprecated Features Object, doing this:

provides a counter to monitor the features designated as deprecated. In each case the counter provides a usage count that lists the number of times the deprecated feature was encountered since SQL Server last started.

Microsoft SQL Server, Deprecated Features object

(That MSDN doc also has a description of what each of the deprecated features is, which is very useful.)

While this won’t tell you where a deprecated feature is being used, it will tell you which ones are being used. Knowing which deprecated features are still in use is crucial when planning a migration to a new SQL Server release, especially if those features will no longer be supported. This insight helps prevent disruptions and ensures a smoother transition to the updated system.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post Tracking Deprecated Features in SQL Server appeared first on The SERO Group.

Each database has a Compatibility Level setting that activates certain features of its version. When SQL Server 2014 introduced the Cardinality Estimator, you could disable it by setting the Compatibility Level to SQL Server 2012. For a full list of enabled features at each level, see the Differences Between Compatibility Level sections of the MSDN Docs.

Unfortunately, most people don’t realize that updating the compatibility level setting is a manual process. SQL Server won’t automatically match the database compatibility level to the server version. This also applies when upgrading an existing SQL Server. It’s actually very common to see databases on newer servers with older compatibility levels.

The one exception to this rule

When migrating a database to a new server, SQL Server automatically upgrades the database’s compatibility level to the lowest version supported by the new server. For example, a database with SQL Server 2005 compatibility will be upgraded to 2008 when restored on SQL Server 2019, as 2008 is the earliest version supported by SQL Server 2019.

How can I find my database’s compatibility level?

Find the compatibility level for you database by querying the sys.databases DMV.

-- Find Compatibility Level for all databases on the server
SELECT name, compatibility_level  
FROM sys.databases; 
 

You can also view the compatibility level under Options in the Database Properties:

How do I change my database’s compatibility level?

To change your database compatibility level, simply change the Property above. You can also run the following ALTER DATABASE command:

--change compatibility level to 2019 for your database
ALTER DATABASE [YourDatabase]
SET COMPATIBILITY_LEVEL = 150;  
GO

Notice that the compatibility level setting in the ALTER DATABASE command is actually a numerical value. As seen in the database properties screenshot above, each compatibility level has a numerical value assigned to it, and that is what we use in the database settings. Be sure to check this list of Supported Compatibility Level Values for the version of SQL Server you are running.

Want to work with The SERO Group?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a no-obligation discovery call with us to get started.

The post A Manual Adjustment: Compatibility Level Settings in SQL Server appeared first on The SERO Group.

What does NOLOCK do?

A SELECT statement in SQL Server locks data to prevent modifications during querying. The lock is released after the query finishes, allowing data changes to resume. These locks ensure SELECT statements return only valid data, not data that’s in the process of being modified.

Using NOLOCK in your query removes data protection safeguards. It’s the same as setting the Transaction Isolation Level to READ UNCOMMITTED, which allows the query to pull in data that is in the process of being modified and has not been committed to the database yet. In SQL Server terms, this is called a “Dirty Read” and should not be trusted. With a Dirty Read, the data returned by your query may or may not exist, depending on the outcome of other T-SQL statements that may be running at the same time.

In most cases within a transactional (OLTP) database, the results from a SELECT statement using NOLOCK should not be relied upon for accuracy. However, there are occasional exceptions (details below).

Why Does NOLOCK Make My Query Faster?

Too often, NOLOCK is used as the “turbo-boost” button for your queries. While it’s true that a SELECT query will run faster when using NOLOCK, it does so by ignoring the safeguards put in place to ensure that your query is returning accurate data. By not putting these locks in place, you reduce the overhead of the query and bypass part of the process SQL Server normally uses when processing your query, thereby making it run faster.

However, some of the side effects of using NOLOCK include missing rows, reading rows twice, reading multiple versions of the same row, and returning rows that have been deleted.

What’s the point in having a faster query if it doesn’t return the correct results?

When should I use NOLOCK?

NOLOCK can be useful when querying data that doesn’t change often, or in the case of an analytical (OLAP) database where data writing only occurs during a scheduled time, like a data warehouse that only runs INSERT/UPDATE/DELETE statements at night and where users do reporting during the day.

For example, think about a “States” table that just contains a list of US states. The list isn’t going to change, and you won’t have to worry about that data being modified while you’re querying it. In a case like this, using NOLOCK shouldn’t cause any issues.

Alternatively, there are situations where your query can accept certain inconsistencies. For instance, when querying sales trends over the last 6 months, real-time precision may not be necessary.

The main advantage of using NOLOCK is that you can avoid deadlocks with concurrent queries. However, frequent deadlocks may indicate that using NOLOCK will return incorrect results.

Avoid NOLOCK to Maintain Data Consistency and Integrity

You should rarely, if ever, use NOLOCK in a transactional database. You certainly shouldn’t be using it blindly in all of your SELECT queries. If you can tolerate some data inaccuracy in your results, then NOLOCK may be OK. Overall, I’d still recommend prioritizing data integrity by steering clear of NOLOCK.

Want to work with The SERO Group?

Want to learn how SERO Group simplifies SQL Server management? Schedule a no-obligation discovery call to get started.

The post Quick Tips for Faster SQL Servers: When (Not) to Use NOLOCK appeared first on The SERO Group.

So, why is this considered a bad practice?

It’s inefficient.

The “sp_” prefix is used by SQL Server to designate internal system procedures. So, whenever SQL Server sees “sp_” at the beginning of a stored procedure, it looks in the master database first.

CREATE PROCEDURE (Transact-SQL) – SQL Server, 2023, learn.microsoft.com

So, using the “sp_” prefix for a stored procedure is like giving SQL Server bad directions and then wondering what’s taking it so long.

It causes conflicts with system procedures with the same name.

If you accidentally named your stored procedure the same thing as one of those system procedures, SQL Server will execute the system procedure instead of your database procedure.

It means taking the long way around every time.

This what SQL Server is triggered to do every time an “sp_” stored procedure is called:

1. Stop processing in your database.
2. Jump over to the master database.
3. Scan every stored procedure.
4. Come back to your database.
5. Find and execute the procedure you were looking for in the first place.

All of those steps take time. Multiplying that time by the number of stored procedures, then multiplying that by the number of times those procedures are called per day, you can end up with significantly slower performance.

The simple solution

When you avoid the “sp_” prefix, you ensure that SQL Server immediately looks in your database. This makes the procedure faster to find and execute. What’s not to like about that?

One exception: utility procedures

If you’re creating a utility procedure, like sp_whoisactive, that you intend to run everywhere, then using the “sp_” prefix can be useful. Do so sparingly and only when creating a procedure in the master database that you want to have accessible from all other databases.

Want to work with us?

Want to learn more about how The SERO Group helps organizations take the guesswork out of managing their SQL Servers? Schedule a call with us to get started.

The post Quick Tips for Faster SQL Servers: Don’t Name Your Stored Procedures Using The “sp_” Prefix appeared first on The SERO Group.