Search results matching tags 'Best Practices' and 'Writing'

The Year That Was - 2012

KKline — Mon, 31 Dec 2012 19:31:00 GMT

2012 was, simply stated, a year that kicked my butt. When I wasn't struggling professionally, I was struggling personally. Health issues, culminating in a diagnosis of Type II diabetes, and the passing of my father soon after Thanksgiving marked my biggest struggles. I apologize to those of you who are normally on my Christmas card list for not sending any this year. The wind was not in my sails. On the positive side of the ledger, I made a scary but exciting leap to SQL Sentry midyear. This was a huge shake-up after 10 years with my previous employer, but one which has been met with unbridled enthusiasm everywhere I've gone. Thank you for the handshakes, high-fives, and hugs! We're doing some really exciting things at SQL Sentry (such as SQLPerformance.com and Plan Explorer Pro) and I hope to engage with you more than ever in 2013.

Blogging Activity, Plus Leadership Skills & Professionalism

2012 marked a bit of a shift in my content creation direction. I've seen an uptick in struggles in the non-IT part of our career - communications, leadership, motivation, goal-keeping, all of those sort of things. I feel like I have some wisdom to contribute in that space. So, in addition to technical blog posts, I been putting down more of my experiences and lessons learned on the interpersonal side of the IT career path. My top ten blog posts for the year reflect some of that new direction:

Do You Have One of "the Three W’s" to Sit on a Board of Directors? -- Important tips for any IT pro considering a role in strategy and executive leadership.
Timewarp: What Is a Relational Database? -- With all the talk about NoSQL databases, let's go back to the fundamentals.
Want Another Reason to Hate iTunes? -- A throw-away article that precipitated a maelstrom of comments. Them Apple fanboys are passionate!
Why Do IT Pros Make Awful Managers? -- Not all IT pros make awful managers, but when they're awful it's often for similar reasons.
High-Availability White Papers and Resources for SQL Server -- Read the latest about AlwaysOn Availability Groups, and more.
New White Paper: SQL Server Extended Events and Notifications -- SQL Server 2012 great augments the Extended Events feature set. Find out how.
Build Your Own Microsoft Operations Management Pack -- Resources to build out your own SCOM management pack.
Help Me Update the History of SQL Server -- I started with SQL Server when it was still an OS/2 product. Jeesh! Lots of versions have come out since then.
TIE: Recorded Webcast Available: Extend SCOM to Optimize SQL Server Performance Management and The Expert's Conference (TEC) - For AD, SharePoint, Exchange, PowerShell and Other Admins -- Pointers to a webcast about extending SCOM and the TEC conference.
A Fond Farewell to Quest Software -- I learned so much in 10 years at Quest Software.

As I mentioned in the opening paragraph about blogging, I'm putting more energy into best practices for professional growth among IT pros. Along those lines of thought, I started a website called ForITPros.com with my long-time friend Joe Webb (Twitter | Blog) and, in partnership with SSWUG, developed a 2-DVD set and streaming media class called Leadership Skills for IT Professionals containing 14 hours of leadership and soft skills training specifically crafted for IT teams.

I've also been working with PASS on the Professional Development Virtual Chapter (VC), led by Mark Caldwell (Twitter). We've already got a full year of content schedule and are trying to figure out how fit in more sessions. Maybe moving to more than one webcast per month? The PASS Professional Development VC archive has lots of great content for you to review and future sessions are detailed at the PASS Professional Development VC homepage.

In-Person Activity

2012 was busy where I actually appeared in person or put in a big effort to write or create content. Here's a run-down: Articles (2), Conference Spoken (12), Customer Calls (88), Customer Visits (4), Magazine Columns (14) at SQLMag.com and DBTA.com, New Books (1) with Ross Mistry, PASS Chapter Presentations (12), Pre-cons/Full-day Seminars (4), SQL Saturdays (4), SSWUG Sessions (4), TechNet Radio Broadcasts (2), Technical Book Reviews (3), and Webcasts (10).

In 2013, I expect to travel a bit less. But I also expect to do many more webcasts. Let me know if you have some ideas about what you'd like to learn! One business trip that I refuse to give up, though, is SQLCruise. (Register!) I know it sounds like the worst possible way to learn. I mean who'd want to learn on a cruise ship in the Caribbean?!? (I hope you could detect the sarcasm dripping from those two sentences.) But here are two favorite aspects of of SQLCruise that are totally ferreals - 1) You simultaneously can relax and focus on learning. You are disconnected from the mainland. You don't have to worry about the mobile phone going off. 2) You get extended ours in a intimate setting with the top talent in the SQL Server world. It's always a pleasure to attend a conference session from the best in the industry. But you'll get hours of time to talk with these veterans of the industry about your specific problems and situations. It just doesn't get better than that.

Social Media

It's hard to believe that only a year ago, 2011, was my first year on Twitter. By years end, here's where my stats had moved: 5,507 tweets (up from 3,452 tweets), 661 following (up from 531), and 3,720 followers (up from 2,656) . I didn't check my social media numbers last year, so I've got no point of comparison. But I'm currently sitting at 2,327 LinkedIn connections and 1,157 Facebook friends. One of my standing policies on Facebook is that I don't "friend" someone who I haven't personally met. That doesn't help detangle the hopeless mess I've created by having only one identify on Facebook, both personal and public. So, on the one hand, I owe all of my longtime friends a big apology for all of the SQL talk and, on the other hand, a big apology to all of my professional friends for not posting enough news and advice while dilute my status updates with personal minutia. Oh well - it is what it is.

My blogging activity for 2012 was the lowest it's been in many years, down to 44 entries, down from 77 in 2011 and well into the hundreds in 2010. My answer to that sort of doldrums for 2013 is to get sloppy! And by that, I mean less of a perfectionist and more of a content machine that just cranks it out! Most of you, as my readers, have been very forgiving of a misplaced verb, a missing punctuation, or -heck- a totally malformed sentence that makes no sense at all. So I'm going to try much harder to churn through the 700+ nascent blog posts in my notes folder and get those ideas out there!

I hope to see you following me on Twitter soon! Thanks,

-Kevin

Sixth pillar – Well Performing

drsql — Wed, 14 Oct 2009 00:57:31 GMT

I guess eventually I had to admit that performance matters. Whenever I speak, and in all of my books, I try to stress over and over that performance is NOT the only thing. The fact is all too much time is spent trying to make database applications run faster when the real goal should be to architect data structures that solve the problems of the user in a natural way with proper integrity.

But performance is important. Extremely important. Like a fancy sports car, it is the first second thing that a user will notice about the system…The first will be the UI (the paint job).

The problem is that it isn’t the most important thing. Just like a sports car, the most important thing is that everything works. If the car runs 100 miles an hour in first gear, it doesn’t matter if the seats aren’t bolted in and the steering wheel works backwards. I initially defined well performing as “Gives you answers fast”, and in the context of performance, that is true, but in reality, that is a very simplistic attitude. Certainly taken out of context, this is definitely NOT a good explanation of well performing. Maybe: “Does all operations required in a minimal amount of time in consideration of the realities of physics?”

When considering performance, there are many facets to the problem:

Initial Database design – Sometimes the reality of the problem to be solved cannot be done quickly, but often it is just poorly designed data structures that get in the way. Designing the database with the concepts of Normalization close at hand is the first step in getting things right. The relational engine of SQL Server is named relational because it likes data to be formed in a relational manner. The concepts of Normalization are the backbone of relational design (sorry, I have to make mention of Normalization every time I blog, I think).
Concurrency – Hey, if all I ever had to work on were single user systems, life would be easy. But the fact is, on the main database system I work with, there are FAR more than one user. And most of the “users” aren’t humans (no, they aren’t zombies either) but rather machines, reading in data from mail, internet, and phone calls and processing the data. Actual human beings work slowly compared to what a computer can pump in data. And to make sure that the data isn’t complete rubbish by the time the humans actually look at it, we have to use locks, and locks slow things down…But the people want to feel like they come first…it is a difficult task, but good design and decent throttling mechanisms can be used to make it happen. (And don’t get me started on all of the moving parts, disk, memory, etc, etc. Beyond data level locks, you have hardware/resource locks called latches that make certain that the laws of physics are honored.)
Indexing – The first thing most people think of when they are adjusting performance, and for a good reason. An index can turn a full table scan operation into a single row operation, simply by adding a primary or unique constraint (usually part of the logical database design) or any other unique or non-unique indexes that may be needed for the queries. But indexes aren’t free, and you have to be careful not to put useless and irrelevant indexes on “just in case.”
Hardware – SQL Server can be run on simple cheap hardware, and for most situations you wouldn’t notice if it was run on a server that could easily be a file server. Unfortunately, the problem is that as you start to need “real” power, the hardware configuration cannot be so…simplistic. Adding CPU power and RAM is simple, but the worst part of the process is disks. Until solid state drives really hit it big (and even afterwards in many ways) disk drive speed and redundancy is big in making your server run fast.
Good code that accesses your data – No matter how well your database is designed, if you code in a crappy manner, using loops where queries would work better, lots of unnecessary temp tables, poorly formatted search arguments like WHERE datediff(day, columnName, getdate()) > 1 (would not use an index on columnName), you are hosed. If you have the foresight to use stored procedures, you can go back and tune later in the process as you need to (in case you get stuck with programmers who aren’t really relational “yet”), or at least have an architecture where you can adjust the code being executed from your app, you can fix poorly performing code…if not, well, good luck (and get ready to throw away a lot of bucks on hardware.)
Adjusted Database Design – sometimes you just can’t use the design you have, and as a good designer/architect, you have to be big enough to admit that. Denormalization can be a solution (especially if you are trying to optimize reports…) but often you just have to go in and adjust the design in other ways. The better your code/encapsulation layer, the easier it is to do (it might take a bit longer, but it will be straightforward/safe).
Etc – Network speed, faulty hardware, poorly performing applications…I could go on for days, but I won’t. The fact is, there are many problems that can make performance bad, and sometimes they are database related, and sometimes not.

I am not numb to the fact that performance is an issue. It is really a major pain point, because it changes so much with all of the aforementioned factors, but also because it is negotiable. Data integrity is not a negotiable factor. You can’t say “bah!” to users because they complain that “their numbers aren’t adding up”, but “the server seems kind of slow” can easily be written off as whining (mostly because it usually is.) The problem is, whether your company admits it to itself or not, time is money, and if a user has to do a task 200 times a day and performance issues makes it take 10 seconds instead of 4 seconds, it doesn’t seem like much… but 1200 seconds is not a small amount of time in the least. And if there are 100 people doing these same repetitive tasks…that’s a lot of time (and no uncommon in say, a call center.)

So what’s to be done? Planning, testing, having proper environments for testing performance are great things but to do it right you will probably need to double your spending on hardware to have a production and a “pre” production environment to test out your designs under load. Most smaller companies (particularly if the hardware isn’t the backbone of what they do) don’t have that. Production is where the load is tested, and they hope for the best.

Well stop hoping for the best, and design for great performance. Whether you can test performance or not, you can still be prepared by building your database for performance and just as important, for tuning in the easiest manner.

What is a physical database?

drsql — Thu, 11 Jun 2009 22:26:36 GMT

A bit of terminology that gets beaten to death is that of the “physical” database. I would think most every DBA uses this term (I do), but…to mean what? I think there are two common utilizations:

The layer of tables, constraints, indexes, etc used to store data
The actual on-disk structures.

Frankly, until 3 years ago, I used the first interpretation. However, I was beaten up pretty badly by a few people whom I don’t really remember (I think Anith Sen was one of them.) The problem is, I was scolded, “physical” already had a meaning, given it by the “founder” himself, EF Codd.

So, checking his 12 Rules, Codd stated the following two things:

Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.

And actually, the implementation layer really is the logical model if you follow his terminology since his rules were pertaining to the relational model and not the entire design process. This article says it better than I can in a long blog, but I am not sure about that URL (mac.com?):

http://homepage.mac.com/s_lott/iblog/architecture/C465799452/E20080301143528/

The physical layer of a relational database occurs down at the file system level. Codd's "Rule 8" (Physical Data Independence) says that the things we're designing in ERwin (and similar tools) are the things our application depends on. These are not physical in nature, but are the relational implementation.

So the thing I am trying to say is that physical means that a little 5 volt charge is sitting there representing a bit of data in the physical world. I like the term logical to mean implementation platform non-specific.. The thing in the middle is the SQL Server/Relational implementation specific model. It may take liberties to optimize for SQL Server, but it is not physical. That is were partitioning. indexing, filegroups, etc come in. Changes to this layer ought never be noticable by the application.

I guess in the comments, I ought to expect a good number of replies that might start to answer the question. Does it matter? Is it only semantics? Hey if you don’t think semantics matter, I hope that when you find yourself drowning that the person who has the choice of tossing you a life preserver or a sack of door knobs interprets the meaning of your cry for help in the way you intended. You would hate to find yourself at the bottom of a lake thinking “hmm, I wonder why they did that? Did they hate me, of just mis-interpret the meaning of my sentence?"