THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Linchi Shea

Checking out SQL Server via empirical data points

Checking out the competition

Among the database management systems, I’m most comfortable with SQL Server. But if I have to give myself a label, I would consider myself more a database engineer than a SQL Server engineer. That is because I’m immensely interested in different perspectives on key database technologies, in how the same or similar idea is implemented differently among the DBMS platforms, and in what different ideas are being pursued by different DBMS platforms.


In particular, I find that getting exposed to multiple perspectives on a hotly-debated issue would move you closer to the truth. Technology issues are no exception.


Take for example the scalability of the shared-disk cluster in general, and the scalability of Oracle RAC in particular. If you listen to Oracle, this is the greatest thing since sliced bread.  But if you listen to the Oracle competitors, it’s a piece of technology highly limited in scalability.


I happen to have spent the past few weeks studying Oracle RAC scalability under various database benchmarks. And surprise! It scales nicely on some benchmarks, not so on some others, and may even degrade the performance on still others. So depending on how they cherry pick the results, they can all be correct. The truth is somewhere in the middle. But unless you check out these different perspectives, you may not even know where the middle lies.

Now, this post is not about whether Oracle RAC (or DB2 DPF or the forthcoming Sybase shared-disk cluster) is the right way to implement database scale-out, or what should drive the future database utility computing. The point is that if you don’t want to be limited to just using what a vendor ships to you, and you want to evaluate a database technology, checking out what other vendors are doing can help you establish an effective framework for the evaluation.

Indeed, in the middle lies the truth!


Published Sunday, January 13, 2008 1:06 AM by Linchi Shea



AaronBertrand said:

I think this is a great line of thinking, Linchi.  One caution is that we're not all at multi-national corporations where we can just abandon one vendor for another, or implement a completely new hardware infrastructure, or port all of our existing code to a new platform.  So the audience that can follow your advice is somewhat limited, by definition.  :-)

January 13, 2008 9:00 PM

Linchi Shea said:


I might not be clear. But this post is not about switching vendors. Nor is it directed towards any particular vendor. Even if you are working with only one vendor, are happy with it, and have absolutely no intension of switching your platform, it's still helpful to understand the overall DBMS landscape. What are others doing? How is a particular feature working across the platforms (e.g. database compression)?

And it doesn't mean you have to spend a huge amount of time conducting painstaking tests to find everything out yourself. Just by reading technical papers/blogs, you can find a lot about a feature on different platforms. For instance, I'm currently very curious about how database compression is done in SQL2008. But I need a framework to help me appreciate it. And since both DB2 and Oracle have database compression, it's convenient to use them as that framework of reference.

I'm arguing that if you are a SQL Servre guy, understanding what Oracle or DB2 is doing can make you a better SQL Server guy. If you are an Oracle person, understanding what SQL Server or DB2 is doing can make you a better Oracle person. And so on and so forth.

January 14, 2008 12:06 AM

Dr Tree said:

Linchi - I thought that was a really good post, and I agree with your observations. I think it's really helpful to watch what other vendors and the market in general is doing. You never know when Microsoft is going to pick up a trend or a piece of technology from another vendor and put it in one of their products.

January 14, 2008 7:49 AM

steve dassin said:

Are you sure you want to leave yourself open to the charge of maturity?

Raising the issue of looking 'around' seems to run counter to prevailing

winds. It's bad enough there's a lack of desire to do this but even worse

is the shortsightedness of what's happening within MS. Hopefully people

will take your lead and realize you can walk and chew gum at the same time.

Take a bow:)

January 14, 2008 11:00 PM

Linchi Shea said:


Well, other than being curious and wanting to know where I am in my journey, I'm just tired of vendors' touting prior art as original. Worse, I see users jumping up and down, overly excited about something that is really not that exciting -- again because they don't know it's prior art.

I like to go to various DBMS vendors' seminars/presentations, and run into this all the time. I remember once hearing an Oracle guy bragging about 10g's Automatic Memory Management. I'm like, "Calm down dude! What's the matter? SQL Server has had that for a long time." No, I'm not picking on Oracle. All vendors commit this offence.

January 15, 2008 12:17 AM

Kevin Kline said:

I'm not sure whether I should be suprised, disturbed, or complacent. But this morning, I was greeted

January 16, 2008 4:09 PM

KKline said:

Great post!  As a heterogeneous DBA but a SQL Server specialist and evangelist, I feel that it's always enriching to know what the competition is doing.  Thanks for the insight,


January 16, 2008 4:14 PM

Alex Wellhausen said:

First off, thank you for this valuable information. Second, pardon me for unceremoniously skipping from this topic of discussion to a slightly different one, though pretty close to the SQL business. I believe, you can recommend something to me and help me here as I am not a SQL guru. I have to run the databases here and no surprise, we've selected Microsoft SQL Server. I feel like it'll be much easier to get in it than in other DB engines for me. Correct me if I'm wrong. I started with SQL express - oh, I know you'll probably be laughing at this out loud but I mostly need SQL as an auxiliary solution for the other solutions we use for working with various tasks here. Well, some tools just store their data in SQL databases so I HAVE to have SQL servers here. After all I find it legally acceptable to store program data in SQL rather than say in a flat file. Applications today need to store a whole lot of data. Configuration data, user input data, communication data, some other specific data that you wouldn't have imagined it could exit. I don't know if I am right or wrong but I just think it makes sense storing program data in SQL if you have something to configure. We used a tool that had proprietary database engine implemented in it and it was bad experience. It worked poorly. So I thought it would be a good idea to implement something easy to use and fast to operate. SQL. However, that poses a new problem to solve. Once you have a database you have to backup it. The need to manage backups through scripts makes me cringe. Yeah I've learned some basic SQL commands like backup database blah blah with init, COMPRESSION. But now what? I am still confused. In fact I don't really want to dig deep into SQL as I'm afraid it would overkill for what I need. I want it to be as fast as it's technically possible. Ah, by the way, compression. Yeah, great thing. I noticed that it makes a serious impact not only on a effective storing but it also affects processing speeds. Almost every database that I tried to compress with SQL since I started with SQL 2008 was finishing its backup in less time when I had been applying compression. But then again it turned out to be a battle for time and ironically all the time I saved from compressing a database was spent then on making SQL scripts. Since I am new to SQL I have to compile my scripts from various available scripts and it takes a lot of time.  The cool thing is that I recently stumbled upon a tool called Litespeed, tried it and found it very interesting. Look, it has both management features and a plethora of settings for a backup. I haven't yet explored all its options but I those that I've tried were enough for me to enjoy it. I don't know how this was accomplished, but it turned out that it compressed those databases I had been working with much better than the results I got from running compression scripts with that SQL build that I've tested. What was really surprising to me was that it did not require me to install SQL server 2008. So I just decided to put it under a stress-test and set it to work with SQL Server 2005. I was easy to configure. It was almost like with SQL Server 2008 setup compared to SQL 2005. Or like Windows Server 2008 setup compared to Windows Server 2003 RTM setup (you know they've improved it in R2). So I managed to setup and configure it quicker than I  expected. That was the first thing that I liked there. Third, I heard like it's impossible to have a backup database compressed and encrypted in SQL. I believe that source was wrong. I think, they meant there that it's impossible to apply compression to an encrypted backup file. I think if you apply encryption to a compressed database this should work well. Correct me if I'm wrong. Anyway even if I am wrong, I'd say you are able to compress AND encrypt my database in Litespeed. It was a great surprise that I was able to save database backup on a remote share without needing to take another steps like I did it when I managed backup with Management Studio. I know there's also TO DISK=''\\*" in SQL but again it was unhandy for me to always change parameters.

By the way, I scanned the Lightspeeds website (ScriptLogic) and it seems they good with SQL technologies

Looks like their management tools use SQL pretty tightly. I saw something for managing security on SQL, something that looked awesome. I don't know. What do you think?


February 29, 2008 5:20 AM
New Comments to this post are disabled

About Linchi Shea

Checking out SQL Server via empirical data points

This Blog


Privacy Statement