Newsletters




SQL Server Drill Down

SQL Server Drill Down explores all aspects of Microsoft SQL Server and related applications, with a particular emphasis on issues of interest to SQL Server data professionals. Key areas of focus include business intelligence, database performance, data integration, virtualization, data protection.



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.

Posted August 14, 2009

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).

Posted July 13, 2009

Now that I know I can post, let me state at least some of what I stated broefe.The thinking patterns of a person is something that is learned over time and is driven by success and motivation and curiosity. Success , of course, does not necessairly mean the greatest success to be had, but some success.Outside of people like you and I, most get rather lazy about thinking and once they become somewhat successful are reluctant to improve further.Optimizing SQL require one of two approaches: (a) an intimate knowledge of how the underlying database works basically, how it will parse the SQL, how it will attempt to optimize the SQL, how it will attempt to match it to indexes and the like. The other approach is by trial and error .Alas, SQL, if my may say so myself, sucks as a language. Basically, it works hard at trying to hide all the low-level machinations of the database system; yet you can't write good SQL unless you deal with those low-level machinations!!! The very fact that it hides these details makes it even trickier to optimize, because its optimizer is trying to be a one size fits all , and it has to guess about a lot.Indeed, in optimizing SQL, not only are you dealing with the low-level machinations, but you are also dealing with the default assumptions of its optimizer, as well! It's kinda insane having to work around both.So, that certain data analyist will never be able to deal with all of these complications. He is to be understood, actually, because he is actually trying to use SQL in the way it was intended so as to not have to deal with all the low-level details that he shouldn't have to deal with anyway.Alas, this is really the failing of many, if not most computer languages, ORMs, and other systems designed to simplify and to hide complexity to really effectively use them eventually you have to understand the complexity it's trying to hide you from, and worse how it's trying to hide you from it!!!!!It's amazing how little has changed over the years. I ran into these same issues dealing with Microsoft's infamous MFC framework, and even Java. I had to deal with this in my C and C++ days, and also had to deal with it when I wrote a lot of PHP code.So, for just kicking it around, the SQL language it great! But when you get serious that all the limitations comes to the fore. And this is true of nearl everything in computerdom.My, this came out quite a bit different from what I wote broefe!

Posted June 15, 2009

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.)

Posted May 15, 2009

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.

Posted April 15, 2009

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.

Posted March 15, 2009

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.

Posted January 15, 2009

Implementing PBM in your environment will probably require more than just a few superficial changes.

Posted December 15, 2008

Posted September 15, 2008

Pages
1
2
3

Sponsors