Maintenance Plan Owner – Back to Basics

We all inherit things from time to time through our profession.  Sometimes we inherit some good things, sometimes we inherit some things that are not so good.  Other times we inherit some things that are just plan annoying.  Yet other times, we inherit things that may be annoying and we probably just haven’t discovered them yet.

Dizzying, I know.

Inheritance

Have you ever taken over a server that had several maintenance plans on it?  Have you ever really checked who the owner of those plans is?  Or, maybe you had a failing job relating to one of these maintenance plans and you changed the job owner, but did you really fix the root cause?  That could be one of those things that you inherited that could be annoying but you just don’t know it yet.

Step by Step

No this is not New Kids on the Block (I think I just threw up in my mouth thinking that).

Let’s create a generic maintenance plan and see what happens.

The first thing we do is navigate to Maintenance Plans under the Management menu in Management Studio.

 

Right Click the Maintenance Plan folder and select New Maintenance Plan… from the context menu.  This will prompt us with the following dialog box.

In this box, we can type a name for this Maintenance Plan that is to be created.  I chose MaintPlanOwner, since that is the topic of this article.

After clicking ok on this dialog box, you will be presented with a blank canvas with which to design your maintenance plan.  I have chose a simple task for the purposes of this article.

I will create a subplan named Statistics and add the Update Statistics task to the canvas.

You can see this illustrated to the left.  I chose to update the statistics on all databases and left all other options as the default option – for simplicity of this article.

At this point, the only thing left to do is to save this Maintenance Plan.  Once the plan is saved, then we can move on to the next step – some fun with TSQL.

 

 

Fun with TSQL

This is the stage of the article where we get to play with TSQL and investigate at a high level the Maintenance Plan we just created.

Within the msdb database, we have some system tables that store information about SSIS packages, DTS packages, and Maintenance Plans.  We will be investigating from a SQL 2008 and SQL 2005 standpoint (it changed in 2005 and then again in 2008).

In SQL 2005, we can query the sysdtspackages90 and sysdtspackagefolders90 to gain insight into who owns these Maintenance Plans.  In SQL 2008 and up, we can query sysssispackages and sysssispackagefolders to gain the same insight.  These system tables are within the msdb database.

In SQL Server, we can use the following to find that I am now the owner of that maintenance plan we just created.

Notice that in this query, I delve out to the sys.server_principals catalog view.  I did this to retrieve the name of the owner of the package that was found in the sysdtspackages90 and sysssispackages tables respective to version of SQL Server. I also am running a dynamic SQL query to support both views dependent on version of SQL Server.  I figured this might be a tad more helpful than the previous version here. This query would yield the following result set for that new “Maintenance Plan” that was just created.

Caveat

Let’s assume that this package is scheduled via a SQL Agent job on a production server.  I then get moved to a different department and no longer have permissions on this particular production server.  The job will start failing due to the principal not having access.  One fix would be to change the owner of the job.

That will work.  However, there is a problem with that fix.  As soon as somebody opens and saves the Maintenance Plan, the owner of the job will revert back to the owner of the Maintenance Plan.  When that happens, then the job will fail again.

A permanent fix is needed.  The permanent fix is to change the owner of the Maintenance Plan.  The following will change the owner to ‘sa’ for both SQL 2005 and SQL 2008 (and up).

SQL 2005

SQL 2008

Now if you run the code used earlier to investigate, you will find that the owner has indeed changed.  The results of that query should be similar to the following.

There you have it.  No more hair tugging over something as benign as the owner of a Maintenance Plan.  This is one of those things that should be looked at as soon as you inherit a new server.

The Wrap

In this article I took a rather long route to a simple fix. It’s easy to try each of the steps I showed in this article thinking it will help. It isn’t illogical to try some of those steps. They just don’t work unfortunately. In the end, getting to know the settings in the database and what the errors are really trying to get at is most helpful. Sometimes, it just takes a few more steps to get to the real meaning of the error.

This has been another post in the back to basics series. Other topics in the series include (but are not limited to): Backups, backup history and user logins.

To Influence or Be Influenced?

Comments: No Comments
Published on: December 11, 2018

How have you impacted somebody in the community?

Well, have I come up with a doozy of a topic for this month for the TSQLTuesday party. Its not easy to step out of ones own comfort zone. Its even more difficult to fathom the thought and action of performing a self review. That is in essence the task at hand – self review or have somebody else review your personal contributions to the community.

In the invite, I mentioned how many of us have been able to come up with lists of people that have impacted us personally. Using that previous exercise would be a pretty good resource for some to maybe find out more how it was they influenced another person in the community.

To be candid, the invite is not just for those who have influenced others but also for those who have been influenced. If somebody had an impact on your career or your personal identity, take a minute to chat with them and let them know!

Surprises

How great is it to provide a service to somebody and then to receive a legitimate and meaningful thank you? The SQL community gives and gives and gives and all too often there is no personal note of gratitude for the help given. Every once in a blue moon, that thank you comes and a really cool calming feeling may just overwhelm you. That is when you know you have done good and have meant something to somebody in their life or career.

I am not talking about the flippant thumbs ups, or likes as you may see in social media. Granted, seeing those likes and retweets is probably nice to see on occasion. It just doesn’t bring a real valid connection to the people you are trying to help.

These kind of personal connections are the types of things that build friendships, networks, and long lasting relationships. Someday, this relationship may turn into a client or co-worker or even future mentor (we all can learn something new from other people).

I have had this kinds of conversations more than a few times with the most recent just occurring today from a client. The latest opportunity came as a candid conversation after taking a week long vacation. The client asked me over for a quick chat and reminded me of how thankful they are for the effort and long hours I have given them. The stability they now see with the environment has brought peace of mind and comfort knowing the database will be up when they need them. It has been a culture shift in how databases are viewed there and it has been a good and meaningful shift. This organization is now setup to bring on more talent to a database team.

Just as meaningful is the opportunity I had to chat with another MVP. This person pulled me aside at a very popular conference. I must admit this one blew me away because I had no idea. This person proceeded to tell me how thankful he was that I was a good example as a friend and mentor. He was also appreciative of the time I would take to answer his technical or non-technical questions. Unbeknownst to me, this was happening while he was hitting a rough patch (his words).

This second experience was extremely humbling to me. I share this because I was unaware of the profound impact I was having on this person who later became an MVP. I didn’t do anything super special. I just did what I felt was right. The experience reminded me of why I do the things I do in the community. While extremely gratifying to give and help, it is also very humbling to be able to give, help and be reminded of how a little effort can have a profound effect.

For me, this reminder came when I was personally getting a little down. I needed the reminder to keep it humble and continue to give. I enjoy helping in various ways in the SQL community and I was getting a little sidetracked from doing those things I enjoy. So by these people pulling me aside and telling me about the influence I had on them, they unwittingly also had an impact on me. As I have said multiple times, when you give, you also get something in return. That is the nature of service.

 

 

 

Circling Back

TSQL2sDay150x150Just because you give to the community doesn’t mean you can’t also receive. It also doesn’t mean that it has to be done without ever knowing the true impact of your giving. You simply cannot improve yourself if you have no clue how well you are doing.

Getting feedback from others is that little check that is needed to help progress and move in the right direction. When allowing time and opportunity for feedback from others, you are doing yourself a service as well as them. As I noted, these people that gave me this feedback not only told me about how much I helped them, but they also impacted me at the right moment to help me remember the reasons behind why I like to help. Give a little and you will also get a little!

The Mystery of Missing Backup Files

Comments: 1 Comment
Published on: December 10, 2018

Yoink – Backups Gone

Not only is this mystery of missing backup files worth discussing now, but has been a mystery worth talking about previously (albeit in slightly different form). One such exploration into this mystery can be read here. And as a requirement for exploring any mystery some tools are necessary to be able to explore the clues that might be revealed. For this mystery, we will be utilizing this script along with our acutely developed sense of perception, ability to fact-find and our ability to troubleshoot.

Without further ado and all of our tools in hand, let’s begin!

Peter Deebweehay and Tommy Tsisamin work at Global Exchange Wholesale Retailers (any similarity to real entities is wholly unintentional and completely fictitious). Both Peter and Tommy are diligent hard working individuals. Peter happens to be a DBA and is stubborn about ensuring databases are backed up regularly. He has carefully planned out the disaster recovery scenarios and has nit-pickingly designed the backup strategy to ensure business continuity.

Tommy on the other hand is just as head-strong about performing his daily duties as the systems administrator. Tommy is responsible for the virtual machines, network infrastructure, operating systems, domain, mail services and desktop machines (OS to hardware). Tommy has also carefully planned out all of the disaster recovery needs of the business for all of the servers and specific workstations of individuals that might be pertinent to the continuity of the business.

Tommy and Peter get along together glowingly. The two work together any time there is a new SQL Server to be stood up and have worked together previously many times to ensure good performance of the SQL Servers on both physical and virtual machines.

Lately users have been complaining about a performance slowdown. The slowdown passes quickly but it keeps coming back. Peter starts to look into the reports and is slowly developing a pattern. He notices that the slowdown occurs every hour. Like a good DBA, Peter decides to implement an Extended Event session to capture the queries and server activity that occurs for a period of 3 hours to hopefully capture data that could indicate what the offender is.

After the three hour window has passed, Peter pulls out the captured data and starts looking it over. He notices that every hour there is a backup that occurs against this database. Peter knows that shouldn’t be happening because it is out of cycle with what he had implemented. To be absolutely certain, Peter decides to check the SQL Agent jobs and the Windows task scheduler. Nothing indicating a backup in either location. Next Peter pulls out his trusty backup history script to confirm the data he pulled from the XE session data. When he starts looking at the data, his jaw drops as he sees something that looks like the following.

Missing backup files

Looking at these results, Peter starts looking in the Backup share he had created for these backups and can’t find anything representing those backups with the GUIDs in the BackupPath result. Then he ponders for a minute. Peter knows he has seen something like this before and then recalls where he saw it. Those Full backups with the GUID as the path are coming from outside of SQL Server.

Peter is curious if Tommy could possibly help with the new-found mystery on this server. When Peter presents the information to Tommy, Peter is met with another jaw-dropping moment. Tommy, with a wry smile and pride in himself, explains to Peter exactly what those GUIDs happen to be (not knowing the connection). Tommy explains that he has set the virtual machine to perform an incremental backup every hour. This incremental backup is represented to SQL Server as a Full database backup and produces a backup that equates to .005MB. With this data, Peter is curious to know if Tommy is quiescing the database(s) prior to doing this incremental backup. As it turns out, Tommy was not. Peter was mildly frustrated but he was able to work out a better solution with Tommy. Without quiescing the database, these full backups become questionable as to the usability to actually recover this server (an incremental OS backup is not the same as a Database Differential backup).

As far as the database is concerned, these GUID backups are much the same as a missing backup. Any backup that is taken that a DBA cannot explain or find would also be a missing backup.

What does this mean for you?

In the case of Peter and Tommy, this meant that there was a bit of a mis-communication and a bit of a performance hit for these off cycle backups. Had Peter implemented differential backups, the recovery plan he had implemented would be for naught because each of those full backups caused by the incremental backup for the VM would break his differential chain. Also, if Peter had attempted to recover the database to a different server, he might have discovered this sooner and before the users had reported the performance issues that led him to the discovery. Not only is a backup plan essential, but monitoring of the logs and backups as well as routine practice restores is necessary.

After reading this article, enjoy more articles similar in nature such as this series on Extended Events or this series called “Back to Basics

Capture the Flag – The Trace Flag

Many people work in a tightly controlled environment. Every change requires a change control form and approval to make a change. In some environments, things are more lax, but you still wish you could tell when certain changes were made. That is even true in some of those tightly controlled environments. You know what I am talking about. Despite the controls in place there always seems to be some change that is unknown or even some cowboy that makes changes as s/he sees fit and forgets to notify people or follow process.

Then come the times when you are new to an environment and you really need to know some basic information about the servers you have just inherited. Well, truth be told, you don’t necessarily have to be new to a job to inherit some new servers. Sometimes, blackbox servers end up getting dropped into your realm of responsibility.

When you run into something like this, you really need to have some means to figure out what changed, when it changed and who changed it. Having that information as a base, you would then have the tools to inquire as to why it might have been changed. One of the things that would be nice to know is around the trace flags that can be enabled in SQL Server. There are trace flags (or knobs) for so many different things within SQL Server that it would be nice to get a handle on them if they do happen to be enabled or even disabled.

As a DBA in SQL Server, you should know by now that there are multiple different ways to do all sorts of things within SQL Server. Today we will discuss three different methods that you could use to perform this investigation for yourself.

Report Style

Did you know that Management Studio comes with a dashboard report? It does! In that report, one will find a pretty decent amount of overview information as a first pass to get to know your server. If you were to right click the instance within SSMS, you can browse to the Reports/Standard Reports submenus. From there you can select the Dashboard report. The path to the reports is similar to what is displayed in the following screen capture.

The report that is of interest is circled in red in the preceding image.

If you have any trace flags enabled (globally) you can see those listed in the report similarly to the following image:

Once again, I have encircled the relevant data in red. From this instance that I queried, I currently have one trace flag enabled. As it stands, this particular trace flag is the one that disables the noise of successful backups from being recorded to your log.

This is one particularly easy method to retrieve that information. A benefit from this method is that you will be able to see some graphs and charts and so forth by using the report.

SQL Query

As logic would dictate, it would seem that we should be able to trap that information through the use of our most frequently used tool – TSQL. Case in point is that the report itself requires the use of TSQL to produce the dataset for the nice display we would see when the report is rendered.

Using similar code to what is used to produce the Dashboard report, we can get a decent understanding of the trace flags that might be employed on your particular instance.  Let’s take a quick look at what we could do.

As you can see, that code is terribly simple. The crux of the code boils down to a DBCC command to return the results of TRACESTATUS. Granted, this is a bit over the top and designed to dump the data into a table for later consumption (for good reason). You can legitimately get away with simply running DBCC TRACESTATUS. The results of this would produce the following for the same instance of SQL Server shown in the Server Dashboard report we already explored. Those results look like the following.

queryout

So far, so good. If I had several trace flags enabled globally on this instance then I would see every single one of them in the result set just displayed. Cool!

To this point, this is wonderful for anything that might be currently enabled on the instance. Should any of those trace flags be disabled shortly after being enabled, or even be disabled months after being enabled but before you run either of the two preceding methods, then you are up a creek without a paddle. That is a problem. How would you trap that cowboy sysadmin or cowboy DBA in that case? Well, you could go with a full blown audit. Or you could try a similar approach but on a somewhat smaller scale.

If you are paying close attention, you are probably thinking to yourself that the query just demonstrated seems more complex than it need be.  After all, the documentation for DBCC TRACESTATUS says that I can run that command with a -1 parameter and just have it return the global trace flags.  And in the script I am showing, I filter on Global = 1.  Well, as it turns out, the -1 option in DBCC TRACESTATUS does not work as documented.  The -1 parameter does not return the appropriate result set and that is reproducible.  If you were curious, the MSDN reference is here.  The use of that parameter value still returns session flags as well.

Extended Event

Oh my, we are talking about something really abstract and difficult now! No, not really.  This is a pretty straightforward approach and easy enough to implement. Within XE, there is an event called trace_flag_changed. If you were curious, you could use a query such as the following to find any events that might be related. The key is finding the correct key terms to find what you need/want.

Running that query will return just one result. You might find a few more if you expand your search criteria to include the term “flag” within the description field. It’s up to you to explore a bit more. As the description and name imply for this particular event, you can presume correctly that it tracks when a TF is either enabled or disabled (the state of the TF changes). Let’s call this a mini audit for a very targeted type of event.

Knowing the name of the event, let’s go ahead and look at a possible setup for an event session to trap data:

This gets us to a point where we can now trap all changes to a trace flag status (enabled/disabled). At this point, a bit of a caution is that the event appears to fire twice for every time it occurs. There is one case where it will not produce a double result for each change. That case happens to be if the TF is already set to the same setting to which you are attempting to change it to. So if it is enabled, trying to enable it again just records one event to fire. However, trying to enable or disable the TF when it is in the opposite state, you will see two occurrences of the event firing. Here is a sample output to help show what happens.

xe_results Trace Flag

Displayed in the preceding image, you will notice both scenarios. In the scenario where the TF was not enabled, and I attempted to enable it, you will see two entries. And then when I disabled that TF after enabling it, I once again got a double entry. A corresponding example is encircled by the green. Now, when I tried to disable a TF that was not currently enabled, you see there is a single entry. That occurrence is marked via the orange circle.

A problem does present itself here with this result set and the use of XE.  How in the heck did I get the results from the XE Session so I could peruse it? Here is a sample script that will help parse this session data.

Now isn’t that really helpful?

Conclusion

Today I covered three different means to help isolate the trace flags in use or the changes to the state of those trace flags. This is good information that any DBA should want to know. It is information to help get an understanding of the health and operating environment of your instance. It is also a means to help identify what might be changing under your nose!

For more uses of Extended Events, I recommend my series of articles designed to help you learn XE little by little.

Need a little help with extensive audits of your servers, check out these articles.

T-SQL Tuesday 109: Influence Somebody Invite

Comments: 6 Comments
Published on: December 4, 2018

How have you impacted somebody in the community?

It has now been 28 months since the last time I hosted a TSQL Tuesday, that was TSQL Tuesday 81. I recapped that event here with the original invite here. It continues to amaze me how quickly time flies and how easily years can blow by in between hosting this awesome party!

The last time I hosted, I issued a difficult task. I dare say this one might be just a touch more difficult. First, I want to jump back into the time machine and visit a few of  TSQLTuesday topics that might be relevant to this month’s challenge.

In November 2017, Ewald Cress (b | t) invited everybody to talk about and basically give thanks to people that have helped impact their careers or lives. Check out the roundup here.

In December 2017, Mala Mahadevan (b | t) invited everybody to set goals for themselves. These goals were supposed to be about learning. But when you get down to the nitty gritty, anything that helps build character and career really comes from something that must be learned. It all starts with a bit of introspection. It is this introspection that I ask you to use as a building block for the party this month.

Lastly, in May 2018, Riley Major (b | t) asked everybody to reflect a bit on the theme from Ewald. This time though, the task was to give back to the community. Pay it forward, if you will, given that you had previously benefited from the kindness of somebody else.

Invitation

Building on the work of these three fine individuals, here comes the difficult task. You have been the benefactor of some awesome help from somebody else. You even wrote about it and in a way, told that person how they impacted you, your career, or both. You have set goals for yourself to become a better you after some personal reflection, meditation, introspection. Then you have given back to the community in some way.

I am not asking you to be braggy, just aware and cognizant. What have you done to impact somebody else in the last 13 months?

How do you know you have impacted them? This is really the hard question. I want stories of how you impacted somebody else for the better. This may mean you will need to talk to some people and have a little retrospective with them.

Why?

This past year we lost some real juggernauts in the SQL Community such as Robert Davis (blog). We all know he impacted many people. We can also assume that he knew he impacted peoples lives. How great would it have been to sit down and have a personal discussion with him to let him know for certain how he impacted your career?

At PASS Summit, I had the opportunity to have such a discussion with somebody completely out of the blue. I know how much that meant to me. I also know that I was rather unaware of the influence I had on this individual.

How?

If you have not already had the opportunity to discuss your influence, make the opportunity. If you have mentored somebody, have a chat with them. If you work with somebody that you might have influenced, have a candid chat. Ask them directly if you have been able to be a good influence to them. Ask them how you might be able to better help them.

I know, this gets us all out of our comfort zones – but we need to do things like this. It is a method of both giving thanks as well as just giving (it is the season).

If you are reading this and don’t feel you have influenced somebody, then talk to somebody that has influenced you. Let them know how you influenced them.

Then, after having this candid chat, please write about both the experience (even the awkwardness), anything you learned from the conversation, as well as some details around what it is you did that impacted said individual.

Doing this little exercise will not only help you to become a more involved team member, community member, and leader it will also help you improve on some of the interpersonal skills used for networking as well as public speaking.

What is T-SQL Tuesday?

TSQL2sDay150x150T-SQL Tuesday is a monthly blog party hosted by a different blogger each month. This blog party was started by Adam Machanic (blog|twitter). You can take part by posting your own participating post that fits the topic of the month and follows the requirements below. Additionally, if you are interested in hosting a future T-SQL Tuesday, contact Steve Jones via the tsqltuesday website – here.

How to Participate

  • Your post must be published between 00:00 GMT Tuesday, December 11e, 2018, and 00:00 GMT Wednesday December 12e, 2018.
  • Your post must contain the T-SQL Tuesday logo from above and the image should link back to this blog post.
  • Trackbacks should work. But, please do add a link to your post in the comments section below so everyone can see your work.
  • Tweet about your post using the hash tag #TSQL2sDay.
«page 1 of 122

Calendar
December 2018
M T W T F S S
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Welcome , today is Thursday, December 13, 2018