By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Both scenarios are playing out in firms around the world these days, says Kevin Kline, director of SQL Server solutions at Quest Software Inc. and president of the International Professional Association for SQL Server. And when they do, it's time for CIOs to take stock and figure out how to maximize their SQL Server investment.
Do you see SQL Server popping up in a lot of Oracle shops these days?
Kevin Kline: That's a very, very common thing that we see in the marketplace. Most all the big shops and very many of the [medium-sized] and even smaller shops now are heterogeneous to some degree or another. And so, with the Quest tools being heterogeneous as well, I do spend some time working with customers on those sorts of [integration] questions. For example, I was just at a major manufacturing company in Germany that uses both Oracle and SQL Server, and we talked a lot about those issues. The month before in the U.S., I was at a huge pharmaceutical company that uses Oracle extensively, but they also have SQL Server. [They] were kind of startled to find out that when they did a scan they had over 600 SQL Servers on just one subnet inside of the company. So some [Oracle shops] open the door for SQL Server and before they know it they've got a lot of it.
How does the proliferation of SQL Server within a predominantly Oracle-based shop usually play out?
Kline: There are a couple of different ways that SQL Server will come into an Oracle shop. The first is from a top-down decision. Rather than buy these expensive Oracle licenses for a reporting application that doesn't have the same kind of usage loads as the main Oracle app, [company executives may choose to] go with a much less expensive SQL Server installation. But there's also some other paths through which SQL Server comes in. A lot of shops buy a lot of apps rather than build their own, and the ISP that they go with [often] writes on a SQL Server back end -- so the product that they buy comes in with SQL Server. Or, for example, they're using something like [Microsoft SharePoint Server, which] uses SQL Server as its back-end database. SharePoint in its own right grows quite rapidly in most sites that I've been to, because it's just such a useful and effective product at what it does. So, before you know it, you've got a couple hundred SharePoint sites up and quite a few SQL Servers as well.
What challenges typically arise after an IT shop goes heterogeneous?
Kline: Typically -- in an environment where it's coming from the bottom up rather than top down -- one of the things that happens is they have to get a grip on how much SQL Server they have because it wasn't purchased through an organized process. [The perspective from the top] is that they are often very surprised by how much SQL Server they have. The follow-on challenge after that becomes, 'How do we manage this now that we realize we have a major corporate investment? We want to protect those data assets and make sure that we have good availability, good recoverability and good performance. So, let's get this under the control of some talented DBAs.' And so that often means -- particularly if they're [primarily] an Oracle shop -- hiring people or training staff for new skills.
What advice do you have for CIOs who find themselves in this situation?
Kline: I think a lot of times it's a good idea to take the [SQL Server] investment seriously. There is still a mindset among many Oracle people that SQL Server is this sort of play database and it's not really ready for prime time. But in fact, it can scale extremely high. It can do pretty much any level of work that you throw at it if you design it for that load from the beginning. One of the key points of advice is to make sure that you know how to utilize it and then you'll get the most value out of it. Otherwise, if you continue to think of it as kind of a departmental-level database, then you're never going to get your money's worth out of it. […] If you don't have good people and you don't take it seriously, then you might wind up confirming your initial thought that this is just a departmental-level database. It's kind of a self-fulfilling prophecy.
What would you say are some of the strengths and weaknesses of Oracle and SQL Server?
Kline: They come from two different mindsets and I think that both [mindsets] have really good uses and applications. For Oracle, for example, one of its strengths is that it's well-known for being a highly scalable database. But one of its weaknesses is that it's so darn tunable. When you compare SQL Server and Oracle, I think the last release of Oracle had over 450 different knobs and configuration settings that you can tune, whereas SQL Server had 53 or so. On the one hand, with Oracle, it's a powerful machine, but you really have to know how to work the machine in order to get it to do any of these things well. It takes a lot of skill and a lot of capability to get it to scale to a level that you might want with a mission-critical application.
SQL Server, on the other hand, of course is well-known for being less expensive and easy to stand up and easy to install and get working. But [there is also a] misperception that it is not as scalable. So, the weakness in a lot of cases is that it's a victim of its own marketing [which says it's] simple and easy to use, and a lot of people don't try to take it from that simple and easy-to-use database into that better-performing level of enterprise databases.
Do you see a lot of situations in which an application is calling on both Oracle and SQL Server?
Kline: We're seeing a lot of single applications that use both databases on the back end. But the most common scenario we're seeing is where the production app is going to be on Oracle but then the reporting app is on SQL Server. Again, the idea is to capture the lowest total cost of ownership. In that scenario, you've got data pumping across from Oracle to SQL Server very regularly. And SQL Server makes it really easy because it includes some great replication tools for free that replicate between Oracle and SQL Server heterogeneously. [It also includes] some really good ETL [