John Sansom - SQL Server DBA in the UK » Administration

Simplify Your DBCC CHECKDB Output

John Sansom — Wed, 14 Jul 2010 11:30:57 +0000

"Defend Your Data"

If you’re a SQL Server Database Administrator and you don’t know what CHECKDB is then you need to stop whatever it is your are doing right now and read this. Seriously, just go ahead and do it now. It will only take you ten minutes to get to grips with the basics and it could save not only your job but also the company you work for. CHECKDB is arguably the most valuable tool in the DBA toolkit and you would be a fool to miss it.

Now as I’m sure you already know, when you perform a DBCC CHECKDB operation, by default you will be provided with a considerable amount of informational output, not all of which you may be interested in.

If like me, you like to make life easy for yourself and you are really only interested in output pertaining to any errors that have been found, then you will pleased to hear of the handy argument NO_INFOMSGS available to you (see example below). Using this argument with your CHECKDB operations will suppress “informational only” output, leaving you in a position to more easily identify any errors that may have been reported.

DBCC CHECKDB(‘DatabaseName’) WITH NO_INFOMSGS, ALL_ERRORMSGS

Note: Technically you do not need to use the ALL_ERRORMSGS argument for errors to be displayed in the more recent versions of SQL Server as this is the default behaviour however, if like a lot of DBA’s you manage multiple versions of SQL Server then it’s good practice to include it in order to be absolutely certain you will get the output your desire across the board.

Life’s complicated enough as it is, so let’s keep things simple when we can.

The Politics of SQL Server Performance

John Sansom — Wed, 30 Jun 2010 13:29:44 +0000

Like most DBA’s I’m sure you often find yourself delivering information to the business concerning the performance of your SQL Server platform but have you ever stopped to consider the wider implications of your actions?

As a SQL Server Database Administrator you are responsible for the overall health and well being of your SQL Server database servers. As part of this, one of your key responsibilities is ensuring that SQL Server is providing a sufficient level of performance.

You probably proactively manage and monitor the performance of your environment in order to validate this, perhaps through the creation and review of baseline performance metrics or with the use of third party monitoring tools.

You Are Monitoring Performance Right?

"Ensuring High Performance"

If you are not currently monitoring the performance of your environment you absolutely should be! As a DBA you have no excuse for not monitoring your SQL Server environment given that you can roll your own performance monitoring solution with very little effort. Doing so is essential to understanding both the resource demands placed on SQL Server and ensuring that it is delivering the performance required by your users.

For details on how to get started and roll your own performance monitoring solutions take a look at Brent Ozar’s excellent SQL Server Perfmon (Performance Monitor) Best Practices.

T-SQL Query Performance Monitoring

As part of your performance monitoring activity you will want to regularly review and identify the poorest performing T-SQL queries in your environment. There are a variety of different methods you can use to do this and a number of these are listed below.

How to Identify Poorly Performing Queries:

Performance Dashboard Reports
SQL Server DMV’s - How to identify the most costly SQL Server queries using DMV’s
SQL Server Profiler
Third Party Monitoring Tools – (Insert your favourite product here)

So now that you have identified the most poorly performing T-SQL queries, what next?

Providing Feedback to the Business

"Super DBA"

With your T-SQL query performance metrics and analysis in hand you’re keen to share the details of your findings with the business but before you go any further, just stop and think for a moment about what it is you are about to do.

You have in your hands a conclusive list of information that not only identifies the worst performing T-SQL queries for your database server but you also have a mountain of evidence in support of this, a clear and irrefutable case. The information you posses has the potential to make quite a few people look bad and possibly even stupid, especially if your analysis has identified some particularly poor coding practices.

So before you publicise your findings and publically declare to the entire development team that they’re a bunch of idiots and you have the data to prove it, I implore you to take heed of the number one rule in SQL Server Performance Politics…..

…..No One Likes a Smart Ass

Being the clever DBA that you are I am certain that you have an abundance of great ideas as to how to improve the performance of the queries you have identified. Whether it be through the creation of new indexes or even a complete overhaul of some of the worst T-SQL you have ever laid eyes upon.

Don’t bring attention to your own amazing work by putting down the work of others either. You will not win yourself any friends and there is no gain to be had from directly showcasing the mistakes of others. Simply put, if you are not the author of said source code then the best thing you can initially do is to just keep your mouth shut. This is done to give the author the time to digest the information you have provided.

So how do you go about effectively implementing change? Funny you should ask. Next up, How To Provide Great Feedback.

DBA Survival Skills – Think Defensively

John Sansom — Mon, 12 Apr 2010 13:17:31 +0000

No matter how much of a Super Hero DBA you consider yourself to be, I can guarantee you that there that there will come a time when you have to deal with either a disaster scenario or some form of mistake. Interestingly however, it is what happens next that separates the Pro’s from everyone else.

Things can and will go wrong

So faced with the absolute certainty that things can and will go wrong at some point, what can you do about it?

My advice is to arm yourself with this knowledge. If you know that something will go wrong at some point then you can prepare what you plan to do about it ahead of time so that you are not caught out unexpectedly.

Adopting a defensive mindset

Your database environments are business assets and in your role as a DBA it is your responsibility to guard and protect them.

Before you implement any administrative tasks whether it be deploying a set of database patches to your environment, modifying table data or creating new objects, whatever changes you plan to make, I advise you to always adopt a doomsayer’s frame of mind before carrying out the implementation.

Ask yourself:

What is the worst that could happen?
What are the things that could go wrong?
Have I covered myself adequately?

Preparation is the key

Having identified possible risks for a given scenario you should then plan how you can either avoid them completely or what you will do if they come to bare.

To give you an idea of the type of preparation you may wish to undertake you could plan how you might:

Avoid risk completely
- Do you really need to make this change i.e. does it have to be done?

Minimise risks where possible
- Backup your databases
- Leverage database Snapshots
- Ensure adequate testing has been performed
- Perform certain types of changes during maintenance windows or out of business hours in order to minimize any possible impact there could be.

Devise risk response plans
- Outline a plan of the steps that you will take in the event of a specific risk or disaster scenario occurring.
- Test the plan.

Start thinking defensively today

Adopting defensive thinking is the first step to ensuring that you are ready to fight back against disaster scenarios and eventualities outside of your control.

Start thinking defensively today, what’s the worst that could happen?

TLC and SQL Server Error Log Management

John Sansom — Tue, 06 Apr 2010 12:36:26 +0000

"TLC"

One of the very first tasks I like to do when presented with a new SQL Server Instance is to review what’s been happening of late in the SQL Server Error Log file. Doing so can often provide a quick insight into items that require my attention. It’s not uncommon to encounter backup failure messages, performance warnings or even nasty error messages.

If the SQL Server Instance has not been given a dose of TLC (no not that 90′s R&B group) for some time, you can often encounter a rather large error log file. This can be a pain to work with because it can take an age to open up in management studio and navigation can be cumbersome.

Managing the SQL Server Error Log

So in order to make working with your SQL Server Error log files easier, it’s a good idea to proactively manage their size.

There are two ways that you can go about this. Modify the configuration properties for your SQL Server Error Log files. (In SQL Server Management Studio simply right click the SQL Server Log folder in Object Explorer and choose configure).
Make use of the system stored procedure sp_cycle_errorlog to immediately cycle the error log.

By default SQL Server retains the last six sql server error log files. The number of files for retention can be modified be editing the configuration properties for the SQL Server Error log.

I’m not going to waste time re-inventing the wheel here as there are already some great tutorials available on the net via your trusty friend Google. I particularly like the general overview of SQL Server Error Logs available at SQL Server Pedia.

Cut that large log down to size

The way I like to do things is even before looking to define a suitable log management scheme for a server, as soon as I encounter a large error log file I like to cycle that log right away using sp_cycle_errorlog. This gets things under control immediately. Simply execute:

EXEC master.sys.sp_cycle_errorlog;

Give your SQL Server Logs some TLC today…

SQL Snippet: Who owns that SQL Server Job?

John Sansom — Wed, 10 Mar 2010 12:20:08 +0000

Here is a handy T-SQL script that will list all SQL Server Agent Job owners by job.

From an administration perspective, this query can come in handy when you need to ensure/validate the job owners on your server. One common mistake that I have seen is that when a user creates a new SQL Server Agent Job via SQL Server Management Studio, by default their Login will be assigned as the owner of the job. This is often not a desirable choice of owner and so it’s good idea to do a little house keeping every once in a while and check who the current Job Owners are for your environment.

USE msdb;

SELECT
A.Name AS JobName,
B.name AS JobOwner
FROM dbo.sysjobs A
INNER JOIN master.sys.syslogins B ON
A.owner_sid = B.sid;

More Handy SQL Snippets

I hope you find this SQL Snippet useful in your administration of SQL Server. If you have any questions regarding this snippet, SQL Server Agent Jobs or anything to do with SQL Server then let me know!

SQL Snippet: What SQL Server Agent Jobs were running at that time?

John Sansom — Wed, 30 Dec 2009 09:00:22 +0000

Here is a SQL Snippet that can be used to identify the SQL Server Agent Jobs that were running on a server at a particular point in time.

This can come in very handy if you need to troubleshoot a performance issue after the fact and want to find out if there were any jobs running on your server at a particular point in time retrospectively. The cumbersome alternative is to use a combination of the Job Activity Monitor,Job History and Schedules interfaces within SQL Server Management Studio (SSMS).

To use this snippet simply substitute in the DateTime that you are interested in.

/*--------------------------------------------------------------------------------------------------------------
Date: 29/12/09
Author: John Sansom
Description: Script to identify SQL Server Agent jobs that were
running on the server at a particular time
----------------------------------------------------------------------------------------------------------------*/

DECLARE @jobsRunningAt DATETIME;

--Modify the value here to be the DateTime you are Interested in.
SET @jobsRunningAt = '2009/12/28';

WITH JobHistorySummary AS
(
SELECT
jobs.job_id,
job_name = jobs.[name],
step_id,
step_name,
run_time,
run_time_hours = run_time/10000,
run_time_minutes = (run_time%10000)/100,
run_time_seconds = (run_time%10000)%100,
run_time_elapsed_seconds =
(run_time/10000 /*run_time_hours*/ * 60 * 60 /* hours to minutes to seconds*/) +
((run_time%10000)/100 /* run_time_minutes */ * 60 /* minutes to seconds */ ) +
(run_time%10000)%100,
Start_Date = CONVERT(DATETIME, RTRIM(run_date)),
Start_DateTime =
CONVERT(DATETIME, RTRIM(run_date)) +
((run_time/10000 * 3600) + ((run_time%10000)/100*60)
+ (run_time%10000)%100 /*run_time_elapsed_seconds*/)
/ (23.999999*3600 /* seconds in a day*/),
End_DateTime =
CONVERT(DATETIME, RTRIM(run_date))
+ ((run_time/10000 * 3600)
+ ((run_time%10000)/100*60)
+ (run_time%10000)%100)
/ (86399.9964 /* Start Date Time */)
+ ((run_duration/10000 * 3600)
+ ((run_duration%10000)/100*60)
+ (run_duration%10000)%100 /*run_duration_elapsed_seconds*/)
/ (86399.9964 /* seconds in a day*/)
FROM msdb.dbo.sysjobs jobs WITH(NOLOCK)
INNER JOIN msdb.dbo.sysjobhistory history WITH(NOLOCK) ON
jobs.job_id = history.job_id
WHERE step_name = '(Job outcome)' --Only interested in final outcome of jobs
)
SELECT
job_id,
job_name,
Start_DateTime,
End_DateTime
FROM JobHistorySummary
WHERE Start_DateTime <= @jobsRunningAt AND End_DateTime >= @jobsRunningAt
ORDER BY End_DateTime DESC;

SQL Server Essentials – Part 2: Why you should be using the FULL Recovery Model

John Sansom — Mon, 27 Jul 2009 12:15:05 +0000

In Part 1 of the “SQL Server Essentials” series we discussed the Database Administrator’s primary responsibility.

Given that your data is so important, how can you manage and ensure it’s safekeeping? Should a data loss event occur, you want to be in a position to enable you to protect the majority, if not all, of your data.

What can I do to defend myself against data loss?

You want to be able to create copies of your database data and to store them in a safe place, so that should a data loss event occur, you are able to recover any lost/damaged data as a result.

Fortunately help is at hand in order to achieve this objective. The most basic and simple defence mechanism at your disposal is the SQL Server backup and restore component. It provides an essential safeguard for protecting critical data stored in SQL Server databases.

SQL Server data backup

There are several scopes of data backups available for use in SQL Server. These being:

a whole database
a partial database
a set of files
a set of filegroups

For each of these SQL Server supports both FULL and DIFFERENTIAL backups.

A full backup contains all the data in a specific database or set of filegroups or files, and also enough log to allow for recovering that data.
A differential backup contains only the data that has changed since the differential base (last full backup).

For detailed documentation regarding SQL Server Backups, there is excellent coverage in SQL Server Books Online. A good starting point would be Backing Up and Restoring Databases in SQL Server. You should consider this as part of your Essential Reading List.

Data loss, it will happen to you

You should always work under the assumption that a data loss event will occur at some point and that it will have a detrimental impact to your database. Adopting this frame of mind will assist you with planning accordingly for such an event, so that you are not caught out unexpectedly.

Remember, a data loss event does not have to be a huge catastrophe. It could be something that in essence is quite simple. For example, the dropping of a database table, or perhaps a developer may need to recover a prior version of a Stored Procedure or Trigger’s source code. If you would like to learn more about the different types of data loss events refer back to Part 1 of the SQL Server Essentials Series, The Database Administrators Primary Responsibility.

You can protect yourself against all but the most extreme data loss scenarios by taking a few simple steps and ensuring you undertake sufficient planning for your requirements.

You may need to take a FULL database backup right now

Should you discover that you do not have a backup of your database data whatsoever, then you are currently very exposed to a data loss event and should create a database backup either immediately or as soon as it is practical to do so.

There are several ways in which you can determine if your SQL Server database has been backed up. A Database Administrator will often create scripts in order to manage such a task. Some examples include:

Why a FULL database backup alone is not sufficient

As you may have gathered by this point, a SQL Server Full database backup provides a copy of your data that is accurate only as of the time it was taken. So any transactions that have subsequently occurred since your database backup, are exposed and vulnerable to a data loss event.

If your database data is relatively static or perhaps you have a read-only database, then this may not be a concern for you and your regular Full database backups may prove sufficient for your requirements.

If on the other hand, your database experiences frequent transactional activity involving data modifications, for example a typical Online Transaction Processing (OLTP) database, then you will want to ensure your data is protected at all times. You will want to ensure that you can recover your database to a particular point in time.

To facilitate this need, each SQL Server database records all transactions and database modifications made by each transaction, within the Transaction Log. The extent to which this information is logged however, is determined by the Recovery Model that your database is using.

SQL Server Recover Models

As described in SQL Server Books Online, Introduction to Backup and Restore Strategies in SQL Server:

“Backup and restore operations occur within the context of a recovery model. A recovery model is a database property that controls how the transaction log is managed. Also, the recovery model of a database determines what types of backups and what restore scenarios are supported for the database. Typically a database uses either the simple recovery model or the full recovery model. The full recovery model can be supplemented by switching to the bulk-logged recovery model before bulk operations. For an introduction to these recovery models and how they affect transaction log management, see Recovery Models and Transaction Log Management.

The full recovery model uses log backups to prevent data loss in the broadest range of failure scenarios, and backing and restoring the transaction log (log backups) is required. The advantage of using log backups is that they let you restore a database to any point of time that is contained within a log backup (point-in-time recovery). You can use a series of log backups to roll a database forward to any point in time that is contained in one of the log backups. Be aware that to minimize your restore time, you can supplement each full backup with a series of differential backups of the same data.”

To summarise the key message here, in order to be able to restore your database to a particular point in time you “must” be using the Full Recovery Model.

For a detailed explanation of these concepts, please refer to SQL Server Books Online:Backup Under the Full Recovery Model which again should be considered as part of your Essential Reading List.

Final Thoughts

I hope you have enjoyed reading this post and that it proves useful in your administration of SQL Server. As always, if you have any queries, comments or suggestions then please do feel free to leave them below using the comments form.

Database backups and SQL Server disaster recovery planning are detailed topics and require much more consideration, research and planning than are presented in this post alone. The important point to take away with you, is that if you want to ensure that you are able to recover your database to a specific point in time, say in response to a data loss event, then you must be using the Full Recovery Model.

In a future installment of the SQL Server Essentials series, we will be taking a closer look at SQL Server backups and discussing how you can plan and devise your very own backup strategy.

SQL Server Essentials – Part 1: The Database Administrator’s Primary Responsibility

John Sansom — Mon, 20 Jul 2009 06:24:55 +0000

You’re busy coding away at your workstation when all of a sudden your manager walks over to you all excited and begins discussing with you, the details of this great new application your company has just aquired. It turns out that he wants you to look after and administer this newly aquired application platform, which by the way, has a SQL Server engine.

You’re a natural when it comes to solving problems and you think you can handle it for sure, that is until slowly but surely it dawns on you that you have never actually had to administer a SQL Server database server before. In fact, you’re not even sure where you should begin.

Well fear not my friend! Whether you are an accidental DBA, just getting started with learning SQL Server technology or perhaps you just want to polish up on the basics. This is the first in a series of blog posts just for you guys and girls that want to get up to speed on the essentials of SQL Server, the core stuff that you just absolutely must know.

So with no time to loose, let’s get started…..

What is the primary and most important responsibility of a SQL Server Database Administrator?

Before you even go anywhere near a keyboard or launch SQL Server Management Studio, the first lesson that you absolutely must take on board is that the primary responsibility of a SQL Server database administrator is “data”.

What’s so special about data?

Data is arguably the most valuable asset of a business. It is the lifeblood of the organisation, whithout which it cannot function. As a SQL Server database administrator you have to safeguard your data.

The variety of information that data can describe is possibly limitless, with each variety just as important as the next, to the business it belongs to. Some examples of information that data may be used to describe include:

An Application Backend/Data store
Storing and collecting vast amounts of data from the Large Hardron Collider at CERN or Modelling the human genome
Customer/Client Contact Details
Financial Information / Banking Systems / Credit Card Processing
Company Sales Figures
Order Inventory System
Website Content
Train Timetables / Aircraft Reservation
Library / DVD / Car Rental

The list is, as I’m sure you can imagine, potentially infinte. What should be immediately clear to you however, is that if anything bad were to happen to your data, for example a data loss event were to occur, it would almost certainly have a negative impact to the business. Possibly even serious enough to result in closure. Seriously this can and unfortunatly does happen!

"You're Fired!"

Do NOT let this happen to you.

Data Loss Event Types

To give you an idea of what you’re going to be up against, consider that Wikpedia categorises data loss events into 5 main categories:

Intentional Action
- Intentional deletion of a file or program
Unintentional Action
- Accidental deletion of a file or program
- Misplacement of CDs or floppies
- Administration errors
- Inability to read unknown file format
Failure
- Power failure, resulting in data in volatile memory not being saved to permanent memory.
- Hardware failure, such as a head crash in a hard disk.
- A software crash or freeze, resulting in data not being saved.
- Software bugs or poor usability, such as not confirming a file delete command.
- Data corruption, such as filesystem corruption or database corruption.
Disaster
- Natural disaster, earthquake, flood, tornado, etc.
- Fire
Crime
- Theft, hacking, sabotage, etc.
- A malicious act, such as a worm, virus, hacker or theft of physical media.

Understanding your responsibility

"The weight of the world on your shoulders"

I want you to sit back and to take a moment to think about what it is that you are about to become responsible for.

Make no mistake, as a SQL Server database administrator it is YOU who is responsible for safeguarding the database data. Your actions could be what makes the difference between a data loss event being fatal to your business or merely just a nuissance.

What can I do to look after my data?

Now that you know the Database Administrator’s primary responsibility is the data in their custody, what with all these potential risks vying to get at your precious data, what can you do to defend yourself?

Find out in Part 2 of the SQL Server Essentials Series, where we will look at the SQL Server database administrator’s most formidable defence method and discuss Why you should be using the FULL Recovery Model for your databases.

Have you got a tale to tell about data loss? Please feel free to share your thoughts using the comments box below.

SQL Server Reporting Services Tip: email subscription tweak

John Sansom — Thu, 09 Jul 2009 12:24:00 +0000

What’s the problem?

How to configure SQL Server Reporting Services 2005 to permit users to assign the delivery email address for their own subscriptions.

Why does SQL Server work this way?

When you subscribe to a report, the e-mail delivery settings you work with vary depending on whether your Role includes the “Manage individual subscriptions” task or the “Manage all subscriptions” task. See E-Mail Delivery in Reporting Services for further information.

By default, a Reporting Services user cannot modify the email delivery target for their own subscriptions. Now providing a user the ability to Manage All Subscriptions on a given Report Server is not really a practical solution.

How can I make it work my way?

As an alternative what you can do is modify the security settings of the Report Server to allow a user to specify the delivery email address for their own subscriptions.

This requires a configuration change to the Report Server Configuration File

Modify the value for the “SendEmailToUserAlias” XML Attribtue to be “false” in order to permit any email address to be specified.

See Configuring a Report Server for Email Delivery for detailed instructions.

Additional Considerations

If you are going to permit your Report Server users to be able to specifiy the delivery address for their subscriptions then it is wise in my opinon to also limit the Domains to which you permit delivery to, for example only trusted domains internal to the organisation. This can also be configured within the very same Report Server configuration file.

There you have it. Simple when you know how.

The Definitive Introduction to SQL Server Indexes

John Sansom — Mon, 29 Jun 2009 08:23:07 +0000

It normally is not my style to write a blog post solely about a particular article someone else has published. Typically I just go ahead and add quality resources to the SQL Server Resources area of this site that I have either found myself or had recommended to me.

In this case however an exception must be made!

Brad McGehee has published what could potentially be the best introduction to SQL Server Indexes that I have ever read. It explains in detailed yet incredibly clear language, not only the mechanics of indexes but also the architecture of these data structures (illustrated by some excellent diagrams).

I highly recommend that you read Brad’s Sure Guide to Indexes