sqlPerspectives

Chapter 38 — Successfully Implementing Kerberos Delegation

Guest Blogger — Mon, 18 Oct 2010 21:33:35 +0000

MVP Scott Stauffer does a fantastic job of explaining what Kerberos delegation is, the issues it solves, and provides an extensive list of resources to close out the chapter.

This is the best resource I have found for understanding Kerberos and how to implement it. K. Brian Kelley has an excellent article on SQLServerCentral that is good, but not quite as in-depth as this chapter. Scott lays out the process logically beginning with how and why he came to understand the process, taking you through what Kerberos is, what issues Kerberos delegation solves, and providing a business scenario that Kerberos will solve.

Kerberos is a complex topic which Scott makes simple in his section Understanding Kerberos Delegation. He explains SPN’s (Service Principal Names), permissions needed to work with SPN’s, and the tools you will need.

Scott very clearly takes you through implementing Kerberos from beginning to end. He includes great screen shots and code snippets along with explaining WHY you need to go through each of the steps.

Scott also included a section on validating your delegation setup using a tool called DelegConfig. This tool is run on the client and web tiers and will validate that Kerberos delegation is configured correctly and working.

Finally Scott provides 3 pages of resources to use to learn about and implement Kerberos delegation which includes: tools, blog posts, TechNet articles, MS Help & Support articles, white papers, and webcasts.

This chapter is really a one-stop shop for people who need to understand and implement Kerberos delegation.

Jack is a SQL Server professional currently serving with New Tribes Mission in Sanford, FL. Jack has been working with SQL Server for over 10 years and has worked with versions 6.5 to 2008. Jack is active in the SQL Server Community as President of OPASS, a member of the 2010 PASS Summit Program Committee, and has spoken at several user groups and SQLSaturdays. Jack also blogs regularly about SQL Server and the SQL Server Community at http://wiseman-wiseguy.blogspot.com

Help SQL Server Help You; by making your Backups Smaller and Faster?

Chris Shaw — Wed, 15 Sep 2010 17:18:57 +0000

Ok so I don’t think anyone will complain when I say there are ways to make your backups faster, or even smaller. But I assume that most people that work with SQL Server will right off the bat start thinking about products that compress your backups such as Litespeed for SQL Server, or RedGates Hyperbac to just name a couple of many. These tools will do the job, there is an ROI to using them and in my opinion databases that are Medium to Large should use something like this, even if your disk is a plenty. Then again, there are those groups of us that will stand up and say, heck if I want a smaller backup or a faster backup I will just use the compression in SQL Server Enterprise Edition.

BUT….

What do you do if you are not getting the backups small enough? What if you need to compress it even more? Is there other ways that you can stream line out of your backups, or are compression tools it? The good news is there is even more room that you can reclaim out of your backups. Now here is the spoiler…

This is going to require some work on your side, and the chapter about Efficient backups by Greg Linwood is going to help you get there. There is some stuff in your databases that you may not even need to backup, now the question is how do you get it so that your backups know not to back up all this unneeded data? Well again I am going to refer you back to Chapter 33. I can tell you that here is yet another reason that I don’t think we have enough sessions on how you simply create a database. My next session that I am going to submit to PASS is going to be on this topic. The information that Greg is sharing with you in this chapter is what separates the good DBA’s from the Great DBA’s. It’s not the attribute of how to get more space out of your backups, but the attribute of know how to get the most of your configuration, and creating a configuration that you can get the most out of.

Enjoy the Chapter.

More on Partitioning

Richard Rodriguez — Tue, 14 Sep 2010 04:20:31 +0000

Partitioning for manageability…Having to deal with large tables and expecting performance to be optimal can be a pretty tough task. I was supporting a client that kind of had this scenario where they had a ton of data and no delay when asking for it. It was actually one of my peers on this blog that introduced me to data partitioning. What ended up happening is that the data was partitioned off by date – Jan 1, 2010 – March 31, 2010 on one partition, etc… you get the picture. It helped tremendously by not bogging down the system and kept data access optimal (there was a lot of other “tweaks” which I will not get into).

This next chapter by Dan Guzman does an excellent job of explaining how to manage a large amount of data with partitioning. He goes through execution plans to show the differences with partitioned and non-partitioned data and the costs of each. Of course there are examples that you can try out yourselves. He also writes about some “gotchas” and offers tips so that you can “achieve a successful partitioning implementation”.

This is a great read just like all the others. Don’t forget to try the examples. Thank you for reading this week. Have a good one.

Chapter 32 – Partitioning for manageability (and maybe performance)

Jeremy Lowell — Tue, 14 Sep 2010 04:19:53 +0000

The second chapter in a row on partitioning and it’s another excellent chapter. Dan Guzman – Blog - takes us on an adventure with this chapter in looking at execution plans between partitioning in 2005 and 2008. In addition he takes the time to spell out what some good use cases are for obtaining additional performance gains from partitioning.

I’m glad that he took the time to do that and it’s one of the most mis-understood elements of partitioning. Partitioning will not always increase your performance. As a matter of fact, it could really, really degrade your performance if your partition key, storage and research are well planned.

In my experience, there is almost always a good partition key which can be found in the data you are looking to partition. Often it’s a datetime field such as CreatedDate, TransactionDate or InsertedDate etc… you get the picture. It’s a date that has a natural order to it over time. It’s not to say that all records will always land in perfect order but it is to say that more often than not, they will. Imagine using a column like “ModifiedDate” as your partition key… every time someone or some process updated a record, it would potentially end up in a different partition; could create havoc. Or even worse, a column like “birth-date”. Chances are that very, very few of the Select statements against the employee table contain a where clause with a small range of birthdays…. i.e., I want to see all employees who were born from march – june of 1975. What good would that do except for the monthly query that H.R. runs to send out Happy Birthday cards?

In closing, I’d recommend that you read this set of blog posts in conjunction with the chapters on partitioning to get started and learn a few things along the way. http://sqlperspectives.wordpress.com/category/chapter-31/