Biographical Information
Kevin Kline
Technical Strategy Manager for SQL Server Solutions, Quest Software
|
Kevin Kline is the technical strategy manager for SQL Server Solutions at Quest Software. A Microsoft SQL Server MVP, he is a founding board member of PASS and the author of several books, including SQL in a Nutshell (O'Reilly & Associates). Kline is a top-rated speaker at industry trade shows and has been active in the IT industry since 1986. For information about Quest Software, go to www.quest.com
|
|
Microsoft SQL Server's relational engine has offered new instrumentation that improves by light years with each new release. The introduction of Dynamic Management Views (DMVs) in SQL Server 2005 provided a much-needed equivalent to Oracle's long-standing and capable V$ and X$ system views. SQL Server 2008 has provided another dramatic improvement to its instrumentation with Extended Events (also known as XEvents) that promises to offer even greater opportunities to tune, trace and troubleshoot the inner workings of a SQL Server application. All of this stands in stark contrast with the anemic instrumentation offered in SQL Server Analysis Services, Microsoft's wonderful multi-dimensional data repository that is a free feature-set within the SQL Server product.
If you haven't paid attention to the new social media, you're doing yourself a disservice. Just as email was a game-changer in the 1980s and the internet revolutionized society in the 1990s, social media is making a huge impact on the way people work and interact today. Personally, I was skeptical about social networking until some good friends persuaded me to give it a trial run. It seemed like a great way to dither away some valuable time, but I didn't see the business value in the whole proposition until I tried it.
In my many years on the board of directors of the Professional Association for SQL Server (PASS), I frequently exhorted our members to strive for individual achievement and personal excellence. One of the best paths for many SQL Server professionals is through certification, especially if they lack years of demonstrated on-the-job experience. However, certification only paints half the picture. While it might demonstrate, at a minimum, that you passed a test (or several tests) about the database technology, it tells nothing about your standards for good conduct.
At a rather muted Microsoft TechEd in Los Angeles in May, the crowds were diminished and the educational content was slimmed down. In the past, SQL Server sessions were so abundant that you'd have trouble choosing which of several you might want to attend. This year, the state of the economy was reflected in many ways, including the one, or, in just a few cases, two sessions per time slot allotted SQL Server professionals. Despite the low ebb, the Microsoft SQL Server team made an exciting announcement about the upcoming availability of the SQL Server 2008 R2 CTP (Community Technology Preview).
Listen to a group of database professionals talk for awhile and someone will eventually bring up the topic of data deduplication. Data deduplication is a means to eliminate redundant data, either through hardware or software technologies. To illustrate, imagine you've drafted a new project plan and sent it to five teammates asking for input. That single file has now been reproduced, in identical bits and bytes, on a total of six computers. If everyone's email inbox is backed up every night, that's another six copies backed up on the email backup server. Through data deduplication technology, only a single instance of your project plan would be backed up, and all other instances of the identical file would simply be tiny on-disk pointers to the original.
I was once asked what I thought Microsoft's overall product trajectory for SQL Server was, in light of Oracle's rather obvious trajectory of acquiring multiple application vendors who will, in turn, deploy more and more of their applications to the Oracle database platform. To be honest, I had a little difficulty perceiving a clear and concise strategy statement for the sort of work going on in Redmond. I could see a lot of great features being developed. And I knew the SQL Server development team had developed a lot of new "plumbing" with each new release - features like Service Broker and Extended Events and exponentially more robust capabilities in the Analysis Services product lines. But the strategy itself was veiled and, since Microsoft wasn't explicitly telling us what the grand strategy was, I had difficulty putting my finger on it.
In this season of recession and financial meltdowns, a common question seems to be, "How big is ‘too big to fail'?" Titans of the financial industry made big bets with lots of risk and, when they didn't pan out, American society overall has to pay the price. But, that aside, the very scale of our financial system, by just about every metric, has reached amazing heights, be that number of financial transactions per second, number of traders, number of funds traded, amount of money changing hands—you name it. This might seem like a tangent to the point of databases in general and SQL Server in particular, but there are actually quite a few similarities in my mind.
If you've read the IT press at all these days, you know that SQL Injection (SI) attacks are very common and can be devastatingly effective. In fact, SI attacks-equally easy to execute against Oracle, MySQL, IBM DB2, or Microsoft SQL Server-are among the most common hacks on the Internet today. If a web application runs a relational database on the backend, it can be subject to an SI attack, which ironically, is among the easiest web hacks to prevent.
Implementing PBM in your environment will probably require more than just a few superficial changes.
SQL Server has supported VLDBs (very large databases) for some time now. Back in the SQL Server 2000 days, I recall hearing multi-terabyte databases were unusual but doable. Now, they are commonplace, while databases in the hundreds of terabytes inhabit the part of the map that says "there be dragons." While VLDBs are quite common on SQL Server today, highly scalable systems that can be flexibly extended in the same fashion as Oracle/RAC are less so. So, how do you design a highly available architecture for SQL Server if it's not like Oracle/RAC.
The idea of "SQL Server in the cloud" is all the rage as I write this article. Many SQL Server experts already predict the demise of the IT data center and a complete upending of the current state of our industry, in which large enterprises can spend millions of dollars on SQL Server licenses, hardware and staff. I have to admit, when I first heard about this idea, I was ecstatic. What could be better for an enterprise than to have all the goodness of a SQL Server database with none of the hardware or staffing issues? However, on deeper examination, there is much about which to be cautious.
Third-party applications are a very important part of the IT landscape. Many of us have faced the common dilemma of trying to decide whether to build or buy that next important application our organizations need. (By the way, I'm talking about smaller, specialized applications like an inventory management system for the company warehouse, or a practice management system for a doctor's office. I'm not talking about the huge and incredibly sophisticated ERP systems like SAP and Oracle Financials.)
In a two-part article over the next two months, I'm going to address an important issue for the SQL Server community: the future direction of coding for SQL Server, as directed by Microsoft. I'll start by telling you a bit about the current situation with writing code on and for SQL Server, and, in the next installment, talk more about the ramifications brought on by the current coding environment.
In my last column (published in the February e-edition and the March print edition of DBTA), I reviewed the overall coding landscape for SQL Server with special focus on LINQ to SQL, a new technology introduced by Microsoft in late 2008. LINQ to SQL promised to make developers' lives much easier by allowing them to focus on writing programs in their favorite Visual Studio language and letting LINQ to SQL write all the Transact-SQL code. The problem is that LINQ to SQL writes very bad Transact-SQL code.
In last month's column, "2012 Might Really Be the End of the World as We Know It," I described a number of major developments in the IT industry that are likely to disrupt the life of database professionals everywhere. I categorize those four disrupters - virtualization, cloud computing, solid state drives (SSD), and advanced multi-core CPUs - into two broad groups. I'm going to continue an analysis of these disruptive technologies in inverse order. Today, let's discuss SSDs.
Two columns ago, I started a series of articles pointing out that tough times might be in the future for the DBA profession because of major disruptive changes happening in the wider IT world (see "2012 Might Really Be the End of the World as We Know It"). Last issue, I spoke about the Solid State Disk and how it's changing the way we have to deal with and troubleshoot IO performance (see "The Changing State of Hardware" in the August E-Edition of DBTA). This time, I want to talk about computing power and multicore CPUs. Moore's Law famously states that the numbers of transistors in an integrated circuit will double every 18-24 months.
One of the things I repeatedly encounter when speaking to database professionals working with Microsoft SQL Server is that many of them simply don't know about some of the most elementary and fundamental means of investigating SQL Server performance. For example, I recently created a popular poster for Quest Software that shows all of the most meaningful and useful Windows Performance Monitor (PerfMon) counters. Now friends, PerfMon has been with us since Windows NT Server, and yet, PerfMon counters are a mystery to at least half of the DBAs I meet. Half!
Like most people, I chuckled under my breath when doomsayers started publishing books about the apocalypse predicted by their interpretation of the Mayan calendar. In their view, the Mayan calendar ends in 2012 and thus spells doom for us all - despite the fact that the classical Mayan calendar, like ours today, was cyclical. But as I was considering some of the momentous and disruptive changes we're facing lately, it suddenly hit me. The year 2012 might be the year when life as we've known it as IT and data professionals changes, completely and irrevocably
Three columns ago, I started a series of articles pointing out that tough times are a-comin' for the DBA profession due to major disruptive changes in the wider IT world (see "2012 Might Really Be the End of the World as We Know It"). In previous columns, I have told you about how our lives will change due to major technological changes caused by things such as Solid State Disks (SSD) and massively multicore CPUs.
Let's tie together the last several columns on "2012 Might Really be The End of the World." In this series, I discussed several megatrends in the general IT industry that will have a tremendous impact on the database administration (DBA) profession. The megatrends include both software-related (virtualization and cheap cloud database services) and hardware-related (SSDs and massively multi-core CPUs). These technologies have the potential to obviate many of the core competencies of the DBA, with the first two eliminating or lessening the need for server and hardware configuration and provisioning, and the last two diminishing the need for IO tuning and query tuning, respectively. But those are trends that will take years to reach fruition. What about the near future?
I started a column series a couple of months ago about emerging but significantly disruptive technologies, with a post entitled, "2012 Might Really Be the End of the World as We Know It." I called out four disruptive technologies that will significantly change, if not outright overturn, the day-to-day work of database professionals. Those technologies are virtualization, cloud computing, solid state drives (SSD), and advanced multi-core CPUs.
Three columns ago, I started a series of articles pointing out that tough times are a-comin' for the DBA profession due to major disruptive changes in the wider IT world (see "2012 Might Really Be the End of the World as We Know It"). In previous columns, I have told you about how our lives will change due to major technological changes caused by things such as Solid State Disks (SSD) and massively multicore CPUs.
If you spend any time at all reading IT trade journals and websites, you've no doubt heard about the NoSQL movement. In a nutshell, NoSQL databases (also called post-relational databases) are a variety of loosely grouped means of storing data without requiring the SQL language. Of course, we've had non-relational databases far longer than we've had actual relational databases. Anyone who's used products like IBM's Lotus Notes can point to a popular non-relational database. However, part and parcel of the NoSQL movement is the idea that the data repositories can horizontally scale with ease, since they're used as the underpinnings of a website. For that reason, NoSQL is strongly associated with web applications, since websites have a history of starting small and going "viral," exhibiting explosive growth after word gets out.
One thing I really enjoy about the SQL Server community is its vibrancy. I'll give you details on the SQL Server community's explosive growth in a moment, but let's start by comparing Microsoft SQL Server's user community with those of other significant database platforms.
One fall semester many years ago, I was a university freshman. Actually, I was anything but "fresh." I was dumb enough to think that 8 a.m. was a wonderful time to attend Economics 101. After staying up until the wee hours most every night, the "dismal science" took on more than one meaning as I set my clock just early enough to get to class on time. Along with 30 other very naïve classmates, I staggered into class and did my bleary-eyed best to focus on the lessons at hand. There were lots of Greek compound words and lots of graphs. I learned, for example, that the word economics derives from the Greek "oikonomikos," which means, approximately, "death by slidedecks" and, specifically, "house" (oikos) and "management" (mikos). I barely survived the experience and never took an 8 a.m. class again. Imagine my surprise, then, when a lesson I'd learned (and promptly forgotten) all those years ago jumped back into my consciousness late last year.
After the misery that was 2009, most of the SQL Server users I talk to are happy that 2010 started in languid fashion. Not that there isn't a lot of work to do; on the contrary, there's more work than ever. However, the long hours and multiple projects of 2009, compounded by freezes in all levels of spending, raised the general stress level to unhealthy heights. With the new year, stress levels dropped significantly, and many IT leaders see signs of improving prospects. What does that bode for 2010? I have a couple of predictions, though I doubt they'll surprise many people.
When a new version of one of my favorite products ships, one of the first things I do is open the online help and read "What's New in This Release." I usually look at the new features from two levels. First, I don't install much software that I don't use, so I'm always keen to see what the new features can do to make my life better, my time more productive, my computer faster, my kids behave better, and so forth.
It's almost hard to believe I've been your columnist for Microsoft SQL Server topics for more than 5 years! As an analyst of Microsoft SQL Server, as well as one who's interested in the whole spectrum of database systems, I've tried to provide insight for the questions of "how" and "why" Microsoft has made the choices it has in crafting SQL Server. After all, understanding the context and motivation for a particular set of features-or a particular marketing strategy-can help you fully understand the best choices for your own internal IT strategies and projects.
If managing your corporate data for the long term isn't currently on your mind, it should be, and in several different ways: cost, performance, business continuity, and compliance. First, let's talk about cost and performance. You want to manage your database infrastructure so it can support your growing data needs within budget, while providing acceptable performance to your users. SANs (storage area networks) have enabled us to meet these contradicting goals over the last decade, and, as I mentioned in a previous column, SAN vendors are offering innovative new technologies to push on-disk storage even further. Some interesting new strategies also are helping organizations achieve a more balanced mix of cost versus performance through the use of "tiered storage."
Compliance is one of the most interesting elements of any data management plan - it's a microcosm of evolution in action. When many of the laws that impacted data retention were first enacted, business wasn't collecting a lot of information. Now, data collection happens everywhere. And, as citizens have come to realize that more and more of the information about their daily lives is recorded, they demand their governments provide privacy and protection from misuse of that data.