developerWorks: This is the developerWorks podcast. I'm Scott Laningham. My guest is Curt Cotner, an IBM Fellow as well as vice president and CTO for database servers at IBM. He's here to talk about DB2 SQL Skin, which is all about reducing the cost and risk of moving certain legacy applications to DB2. Curt, welcome to the podcast.
Cotner: Thank you.
developerWorks: What exactly does DB2 SQL Skin do, Curt?
Cotner: SQL Skin is an attempt to provide a totally different way to migrate applications from Sybase to DB2. So, if you look at how these things have developed over time in the database industry, every database vendor has their own unique product features and syntax; sometimes one vendor has a set of data types that another vendor doesn't. They have SQL syntax that the other vendor doesn't. And this becomes sort of a lock-in feature for each database vendor. It makes it hard to move and change vendors.
Most of the vendors, IBM included, have had some sort of tool that would change your application from one vendor syntax to the other, but those tools were almost always focused just on the database server assets. So it would change your table syntax for the create table. It would change your store procedure syntax.
But those migration tools, they never really address the full picture, because you don't just have the store procedure source code and the table definitions, you have applications out in the network. You have end users sending queries from out in the network. And if you just migrated the server assets, you haven't done anything to fix those things coming in through the network from your distributed applications and distributed users.
So, SQL Skin takes a totally different approach. It allows DB2 to appear to be the same syntax as Sybase, and now what you're allowed to do instead of migrating your application and changing the syntax, you can for the most part leave that application totally unchanged, and you just change it so that instead of pointing to Sybase it points to DB2 and the SQL Skin will allow DB2 to honor those queries and accept the existing Sybase syntax.
So this cuts out a lot of risk and a lot of cost on doing the migration, because now you don't have to modify all your client applications, you don't have to retrain the end users that are sending in the queries. You can continue to do what you used to do with Sybase but now you're just running it on DB2. So in a nutshell, that's what the offering does.
developerWorks: Well, no wonder developers should be so interested in this product, Curt, right? And I wonder, was the development of DB2 SQL Skin in response to requests, or was this really something that you all had been working at for a while knowing that it was needed?
Cotner: Well, we started off first by doing the support that we have in DB2 to honor Oracle syntax, and then when we started taking that to market, there were a lot of Sybase customers that came forward and said, you know, I have a number of reasons why I want to change vendors.
Some of them wanted to change vendors because maybe the renewal price on their maintenance was much higher than they were used to seeing, so they were motivated to get a lower renewal price. Some of them were trying to get down to a smaller number of vendors. There's a lot of customers that are trying to go to just a dual database vendor strategy but not have five or six database vendors like they have today. So, those are some of the kinds of reasons that people would want to go.
But like I said earlier, the thing that's always stopped people in the past is just the sheer cost and risk of rewriting applications and running through the full test cycle. And what we've done with SQL Skin is dramatically reduce the amount of code that has to be touched and the amount of logic that has to be modified so that your test costs go down, your development costs go down. Your training costs go down substantially because the developers, the end users, they all think they're still using Sybase when in fact they're not.
developerWorks: So you don't have to incur so much cost and time and money to get to that improved database efficiency situation that you're hoping to get into in the first place, right?
Cotner: No, that's right. I mean, if you use this layer of code between your application and DB2, DB2 appears to be Sybase. But now you get for free all the application developments that DB2's brought to the market over the years, so things like pureScale, you've now got the ability to scale out to multiple machines that are all part of a shared data experience, and those are things you didn't really have when you were on Sybase.
You get the deep compression, where you can change the amount of disk that you've got spinning to a much smaller number and get much more efficiency. And of course, DB2's always had some tremendous performance advantages. The nice thing about what we've done with the SQL Skin product is it's not an emulation. It actually under the covers will rewrite your source syntax into something that DB2 can optimize very efficiently, and it's not trying to run through this fat emulation layer to make DB2 appear to be something it's not.
Instead, we push down very deeply into the store procedure syntax that DB2 already supports. So, basically when you take a Transact-SQL program [Microsoft/Sybase proprietary extension to SQL] that was written for Sybase, the resulting, I guess you could call it byte codes that run inside of DB2, those are essentially very, very similar to the byte codes that we would have generated if you'd written the same program with DB2's native syntax.
So, there's not a big, heavy emulation layer that's trying to translate between the two worlds; it's a much deeper integration that takes advantage of DB2's native performance capabilities.
developerWorks: That's all very good news for developers working on this type of migration. And the web page, ibm.com/db2, has a very good video with a customer that outlines some of what you've talked about and the kind of benefits that they got in this process using DB2 SQL Skin. Is that the best place, Curt, to go for more information about this product?
Cotner: Yes. I think that the ibm.com/db2 is really the best place. We've put a lot of material out there describing what SQL Skin can do, and we've just come out with some improvements. In the first release of the product, we didn't do anything with triggers, and now that's being supported. So we can take trigger syntax that was in Sybase, and those will be converted into DB2 syntax for triggers. So that makes one less thing that you have to worry about when you do the migration, the triggers can be handled pretty much automatically.
We also have a very nice tool called meet and the meet tool will actually take your Sybase syntax, load it all up, scan the source of your store procedures or your triggers or whatever it is that you've got, and it will go through and analyze and tell you exactly which features here am I going to be able to handle automatically, and which ones will require a little bit of manual intervention.
And we're finding that a lot of customers when they run this tool against their source code, they're finding that in the high 90s, like 97, 99 percent of their source code, can be honored by DB2 with no change whatsoever.
And so one of the things this allows you to do is you can do an assessment of what kind of challenge are you up against in migrating your Sybase application. You can do this with almost no investment of time on your part. You can just feed the things into this meet tool and have it tell you what the story looks like.
developerWorks: Great information. And again, ibm.com/db2 is the place to go for more information about DB2 SQL Skin. Curt Cotner, IBM Fellow and VP and CTO for database servers at IBM. Thanks so much, Curt.
Cotner: Thank you.
developerWorks: This has been the developerWorks podcast. I'm Scott Laningham. Thanks for listening.

Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician.
