Database Underground | Sean McCown | May 2006

MORE ENTRIES

May 2006

May 17, 2006 | Comments: (0)

Some of you may remember at the end of last year I said I would be keeping my eye on a company called SQL Farms. Today I have my first update on their progress.

They've got an editor that has tons of very rich functionality, but one of my favorites is the server grouping. What it does is allow you to group servers and/or databases together and then simultaneously run queries against them as a group. So you could pull back job info on all of your production servers at once with a single query. The results pane even aggregates the results for you. There are many other features you'll find useful, but rather than spin a bunch of cycles on explaining it to you myself, I'll just relay to you what they sent me.

If anyone has any questions on the product feel free to write me and if I don't know the answer, I'll get you a contact at SQLFarms who does. Anyway, here's the feature list in their own words.

SQL Farm Combine™ is a code deployment and change management tool, built into a rich-feature integrated development environment (IDE). The main advantage of SQL Farm Combine™ is that it allows enterprises to automate and build processes around the Dev <=> QA <=> Production lifecycle of SQL code releases, where the three environments are either connected or disconnected (disconnected environments reflects the fact that developers do not have access to the QA or production servers, and software engineers in QA do not have access to the Production machines). Another key benefit of SQL Farm Combine™ is that it supports SQL code deployment (queries, scripts) onto any number of databases and servers in parallel (patent-pending technology), therefore Combine is extremely useful for deploying code and/or running queries on multiple databases and servers at the same time in small to very-large SQL server environments. As an example, SQL Farm Combine™ Beta participants included companies with anywhere from 5 to 270 SQL servers.

Novel features of SQL Farm Combine:

Change management and deployment

1. Code packaging: SQL Farm Combine™ allows developers to collaborate and work together on their SQL releases. Once the SQL code is composed, developers then build a single code package for their release, which contains SQL scripts and maps each script to a set of target databases, on any number of servers.

2. Easy package transfer between development, QA, and Production, and a single-click package deployment on all target databases and servers: Code packages are constructed and configured once by the developers. Packages are then sent to QA and Production, and can be deployed by a click of button against all the appropriate target databases and servers, without requiring package reconfiguration. Furthermore, before deploying the package in QA or Production databases, software engineers in QA and Production DBAs can open the package, view the package content, choose which package scripts (if any) will not be run against the target databases and servers, or instruct the tool to deploy the package on only a sub-set of the configured target databases and servers.

3. Transacted or non-transacted code deployment: With SQL Farm Combine™, users can auto-compose code packages by selecting the database objects to be deployed. Using Combine’s feature-rich scripting dialogs, users can choose whether database changes will be made under a single transaction, or will not be transacted at all. When transactions are used, if any errors occur on the target databases during code deployment (i.e., package execution), all changes are then automatically rolled back.

4. Deployment verification results: All results returned from target databases and servers during the deployment of a code package (including result sets, warnings, errors, execution plans, etc.) can be saved into a single proprietary file. This file can then be returned to QA engineers or developers, and can be opened using the Combine application on their workstations, to view and examine all results and possible issues that arose during package execution.

5. Complete source control support: During package and project development, developers can collaborate and coordinate the composition of code packages by using source control features in Combine.

6. Easy configuration and maintenance: SQL Farm Combine™ can be configured once and by a single developer, using rich wizards and configuration options. All configuration values and parameters can then be exported and then imported by other developers, QA software engineers, and Production DBAs.

7. Executing code packages from the command line: Users and developers can configure Combine packages and then initiate package execution by invoking Combine from the command line with all appropriate parameters.

Distributed parallel data access

8. Running queries and scripts on multiple databases on any number of servers in parallel: SQL Farm Combine™ allows users to configure groups of target databases and store all configurations for future use. Users can then run scripts and queries against multiple databases and servers in parallel, and receive aggregated results from all target databases, as well as execution plans, messages, and all other outputs from each target database.

9. Compare execution plans returned from multiple databases: When running queries against multiple databases in parallel, Combine users can easily compare estimated or actual execution plans returned from each target database.

General features

10.1. Configurable interfaces – windows and components within the SQL Farm Combine™ user-interface can be customized by the user, docked in different locations in the application, and rearranged according to the user needs.

10.2. Intellisense, InfoTips, and Auto-Complete – SQL Farm Combine™ contains a built-in SQL and T-SQL code compiler that helps developers with Intellisense, InfoTips, and auto-complete features while they write SQL code. Unlike other tools that provide intellisense features for SELECT and other simple statements, SQL Farm Combine™ supports intellisense and auto-complete of all DBCC, SET, and many other (both simple and complex) SQL and T-SQL commands.

10.3. Code snippets – SQL Farm Combine™ includes many code snippets and templates that allow users to instantiate and embed them in their SQL code. Combine snippets are automated in the sense that users can easily replace code references with desired object names.

10.4. Context sensitive SQL and T-SQL help and language reference by Microsoft® – As we all know, Microsoft® help files and help content are non-redistributable. To overcome this difficulty and provide users with the latest Microsoft® SQL and T-SQL help, Combine™ contains SQL and T-SQL context sensitive help that redirects users to the appropriate Microsoft® books-online Web pages.

10.5. Saving grid data - Result sets displayed in SQL Farm Combine™ grids can be saved as an excel file, csv file, XML file, or can written to a SQL database.

10.6. Rich editor features – Editing features include outlining, book-marking, line numbering, auto-commenting, word coloring, and many other user-friendly features.

10.7. Rich-feature object browser – Combine’s object browser includes all the standard features available in other IDE application, topped by the ability to register multiple servers at the same time, validating the registration of multiple servers by connecting to all servers in parallel to save time, as well as the ability to import/export all object browser settings.

10.8. Execution plans – Estimated and actual execution plans can be presented graphically, as result sets, or as text (as returned from SQL server). Extended details regarding each node in the execution plan are available as well, and details can be copied and pasted as text to other applications.

10.9. Many other usability features, such as rich user-interfaces, wizards, dialogs, and so on, throughout the application.

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on May 17, 2006 01:49 PM

May 12, 2006 | Comments: (0)

SQL Server 2005 SP1 Hotfix Released

Expect to see the SP1 hotfix posted on the web Monday.

Posted by Sean McCown on May 12, 2006 03:57 PM

May 12, 2006 | Comments: (0)

Why Apprenticeships are Important

If you ever wonder why I get so discouraged at the state of knowledge transfer in the database field, this is why. There's a wonderful blog today that examplifies exactly what's wrong with how we learn things.
If I were IBM, I'd track this guy down and beat him with a wet noodle. The blatant stupidity displayed is just incredible. Anyway, here's the blog... have a good laugh.

http://blogs.ittoolbox.com/oracle/guide/archives/009252.asp

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on May 12, 2006 07:18 AM

May 08, 2006 | Comments: (0)

Database Apprenticeship

One thing that saddens me is that this country has lost the concept of apprenticeships. It used to be that whenever you wanted to learn a trade you would pick a professional who could teach you and you would become his apprentice. What does it really mean to be an apprentice though? What separates an apprentice from what he have here now?

Well, it's really the frame of mind of both parties. Here in America we have the concept of a jr. DBA, though few companies actually take advantage of this personnel goldmine. In radio and medicine both they have interns, and those are more or less apprenticeships, but we don't have anything like that in IT. Again, the problem is in the mindset of both parties... the Sr. and the Jr. In IT, you get hired to do a job. You may be at a jr. level, but you're still hired for that specific job. And the company and the sr. both expect you to be able to do it. There is no real education going on though, and anything you learn, you pretty much have to take on yourself through books and seminars. When you take on an apprenticeship you're there to learn databases. That means that mentoring is the primary goal and the job itself is secondary. That doesn't mean you don't pay them, it just means that you change the dynamic from sr. and the jr. to master and apprentice.

In my former life I was a French chef. I apprenticed the old world way under a real French chef. What does that mean? Well, I traveled with him, I did his laundry, I washed his car, ran his errands, and did whatever other piddling thing he wanted. He paid me well, but only in the restaurant. Outside the restaurant, everything I did for him was completely on my own time, and honestly it's the least I could do for teaching me his life's work. I've been out of the kitchen for several years now, and I still come when he calls. I know that kind of lifestyle sounds strange to a lot of you, but my dream was to become a chef, and that's how it's done in the real cooking world. Of course, I don't still do his laundry, but I do help him with things especially since he's in his twilight now. After all, he did teach me his life's work, and it's still the least I can do.

Maybe that's the problem. Maybe nobody grows up saying, "I want to be a DBA." There's no passion for databases like there is for cooking. I mean, you can't smell SQL code(even though a lot of it stinks), and you can't make nice flowers out of a DR strategy. I think I'm one of the very few who actually gets excited about databases. I completey geek-out when something new comes out, or a find a new way to solve an old problem. It may not be pretty to look at, but I can look at a SQL window just like I'm staring at a plate of Lobster Thermidor.

I guess this is a good time to talk about why apprenticeship is so important to begin with. I mean, why am I making this distinction in the first place? Well, the most honest answer is the quality of learning that goes on. Sure, you can read books, but a lot of times you fail to grasp the meaning, or the significance unless there's someone there showing you what's important. Books are also limited in what they can cover, and they may only be concentrating on one aspect of the topic. A mentor can take a topic and fully expand on it so you have a full understanding. Plus, in case you don't understand something, a mentor can keep explaining until you get it. Is it possible though that you can't really learn databases solely from books? I'd say it's entirely possible. I see it every day in the poor quality of the code I review from DBAs and developers with over 10yrs experience. Clearly nobody ever took them aside and showed them what they need to know.

Right after I left cooking, I took a low-level helpdesk job at a start-up company. The company only had 2 customers, so I wasn't very busy and I read all day long. I read SQL, and IIS and NT. I practiced and I practiced some more. There was a very senior tech there who took me under his wing and showed me things, and explained the things I had misread or just plain didn't understand. I considered myself his apprentice though I don't think he ever knew it. The truth is I learned more in our 30 min. talks than I did all week studying on my own. He was probably the most knowledgable tech I've ever met, and he was patient and gave me lots to think about. In fact, he was our very own Tom Yager, and I don't think he knows to this day what our time together meant to me(don't anybody go tell him, he doesn't read my blog), and how his teachings not only gave me a solid foundation of basics, it inspired me.

Anyway though... the colleges are full of young people who would love to apprentice. Think about it. You can pay them less, and even draw up some kind of agreement that they'll stick around for a year or two. It's a win/win. And if enough companies do that, the poor code, and low knowledge bar will slowly start to disappear.

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on May 8, 2006 07:46 PM

May 07, 2006 | Comments: (0)

Microsoft Plans to Release SP1 Hotfix for SQL Server 2005

The issues caused by installing SP1 for SQL Server 2005 have been addressed and Microsoft is releasing a hotfix this week. The hotfix will correct the timeout errors received when trying to connect to SSIS as well as some other minor issues that surfaced with the service pack.

Microsoft is doing some testing and hopes to have the hotfix released by the end of the week, but if testing goes really well, it could be sooner.
It’s important to understand what caused the issue so you can decide how important this hotfix is to you. The issue was simple. When the SSIS team compiled their fixes to be added to SP1, they issued a new certificate for the file that changed. By issuing this new certificate it put the new version out of synch, certificate-wise, with the old file, so there are now two certificates to validate when the .Net framework connects to the Certificate Revocation List. So the simple explanation is that having to validate two certificates exceeded the timeout limit for the connection, therefore causing a timeout when trying to connect to the SSIS server.
There’s another situation that could cause this issue: The situation where the server is configured for certificate revocation checking and it doesn’t have internet connectivity. The internet connectivity could be blocked by a firewall, permissions, or just plain network issues.

This is why the workarounds I posted last week work. They revolve around either fixing connectivity issues, or disabling certificate revocation checking.
There's another workaround I got from Microsoft. Configure your firewall to return errors. If the firewall drops packets when they cannot reach their target, then the certificate checking does not return a failure - it just hangs about waiting, and eventually the service control manager says "this is taking too long" and times out. However, if the firewall returns an error, then the service control manager knows that the Certificate Revocation List could not be reached, and can continue.
Checking for a revoked certificate is something the .Net framework does - the Service control manager knows that sometimes this can fail, so it continues even when a failure is returned - but it it needs an error message, not a timeout.

But these are only workarounds, so unless you can’t install the hotfix for a specific reason, I suggest you install it as soon as you can if you’ve already installed SP1. And I can’t stress enough that the workarounds are just that. It’s really best to install the hotfix if you can.

The fix was fairly simple on Microsoft’s part though. All they had to do was re-issue the new certificate for the file that is missing it. Just to be on the safe side, they also increased the timeout for the connection to the Certificate Revocation List.

And since most organizations keep a centralized network location for these types of installs, I suggest you slipstream this hotfix into your network copy of SP1, and if you have SQL Server 2005 itself being installed from a centralized location, you might think about slipstreaming both SP1 and the hotfix into the database install… just to prevent any mishaps.

The KB article fully explaining the hotfix can be found here.
So, with this hotfix, I see now reason why you can’t resume testing with an honest intent to push this into production.

I’ll let you know when it actually gets released.

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on May 7, 2006 08:20 PM

May 04, 2006 | Comments: (0)

Never Outsource DBAs... or Other Critical IT Staff

Outsourcing critical IT functions has always been a mystery to me. I realize it saves the company money in certain aspects, and even saves some admin headaches. However, when you get down to it, it's really just a trade-off. You're trading one set of complications for another. I've been on both sides of the hosted data center and I have to say that I just don't get it. What I really don't get is companies that outsource their helpdesk and network admin functions.

Let's walk through this and see if we can come up with a logical reason for going with a separate data center and helpdesk staff. What are the key benefits? Well, there's typically enough savings in employee benefits that it's worth your while to go the outsourced route. There's also the cost of putting together and maintaining the data center. There's the cost of hiring, training and maintaining the staff.

There may be a couple other smaller benefits, but those are the biggest ones and the ones that count.

Now let's look at the downside to outsourcing your IT staff. For starters, you rarely have any control over the staff. So you have no control of the quality of the people handling your business. You also have no control over your operations. When you sign your contract with your hosting company there are usually backup clauses in there that state how often, and to what extent your data will be backed up. However, hosting centers typically have their own interests in mind and they're going to go the cheap route.

Here's a good example:
A couple years ago, the national hosting company CIHost had a virus sweep their environment and brought down several of their SQL boxes. There were 7-9 effected, I forget how many exactly. Many customers lost months of data because the servers hadn't been backed up to any reasonable degree in months. It was a hosting nightmare, and even worse, their customers trusted them. It just so happens that I was one of the DBAs brought in to get them back online. We sat up to all ends of the night for days working through trouble tickets and trying to restore corrupt DBs just to get back whatever data we could for the customers. When all was said and done, CIHost pretended that they had never heard my name and stiffed me for several thousand dollars.
There are other problems with outsourcing your IT staff. Quite often the outsourcing firm will make decisions that will increase your dependence on them, and not what's best for your business. I have seen that from the inside where I created a solution that would put a company in a good position and my boss told me to suggest a solution that would cause them to have more support issues with us. I recommended the solution he told me to, and then sent the customer a different email from my personal account explaining what he should do instead.

You can also have your business hi-jacked, which is the worse thing that can happen. There's a very large outsourcing company here in Dallas that a lot of companies use, and this company (we'll call them EvilEmpire) takes things over whenever it can. If you ask for a hole in the firewall, they say no, it's against policy. If you ask for a user name change, they say no. If you ask for a new admin to be added to a server, typically say no, and when they do say yes, it's 3 days before you see anything. You never really know who's doing what on your servers because they control the domain admins group and you can't keep them out, and you can't keep them out of your database if you want. In short, your entire business is hi-jacked. They tell you what to do and how to do it.

Here's a little wake-up for you EvilEmpire... you work for us, not the other way around. You're supposed to be making our business easier to run, not putting up walls every time we try to do something.

Remember what I said though. It's not in their best interests to give us what we want, or what's best for us. Their job is simple... keep as many support contracts as they can. If your business happens to run at the same time, then that's ok with them, but it's really not their #1 concern. I've even seem them use helpdesk functions as a way to pressure you into acquiesce to other demands, like bringing on one of their DBAs. It's amazing that the same day you refuse to bring one of their guys on-site, all your tickets take 2 days longer to complete than usual. The situation oddly clears itself up once your new DBA is in place.

It's for these reasons that I really think it's always best to house your own equipment, and to keep your own staff. Sure, you have other headaches, but they're your headaches. If you drop the ball, it's your ball to drop, and you are in full control of it. You can physically go in and make sure the backups were pushed to tape, and not just take somebody's word for it. And in keeping with my previous blog on Keeping DBAs, you can make sure you keep the staff you want instead of relying on a consulting firm to have the policies it takes to maintain their staff.

Posted by Sean McCown on May 4, 2006 05:53 PM

May 03, 2006 | Comments: (0)

Virtualize your DR Strategy

There's been a lot of talk lately about virtualization. I know Tom Yager's hitting it in his column and in his blog... so you know it's important.
I may not be telling you anything you don't already know, but virtualization can help you create a DR strategy that will fit your budget. At my last company, we were able to duplicate over 60 production servers at a remote DR site with just 3 big servers running VMWare. I use the same methodology in my lab where hardware is at a premium.

I know of three companies off the top of my head who are even using virtual servers for the lesser critical databases by stacking several on a single server. This way, you can fit Oracle, MySQL, DB2 (yeah, like anybody's using that), or anything else you like on the same hardware.

OK, I know I'm not saying anything earth-shattering to a lot of you, but I'm constantly surprised how many companies don't even consider virtualization in their DR strategy.

Something else... I really wish we had this technology when I was learning databases. You can put together an entire LAN of database servers on just a couple boxes. I initially learned clustering in VMWare, as well as DTS and replication. So for all of you guys who haven't jumped on this yet, I really suggest you do. There are a lot of DBAs out there who know nothing about clustering, and nothing about replication and the like, who could be getting plenty of experience right on their desktop. Think about it.

And if you don't have enough money for a license for Virtual Server or VMWare, then just email me and I'll give you my key for VMWare...(just kidding VMWare guys, don't have a cow).

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on May 3, 2006 06:27 PM

May 02, 2006 | Comments: (0)

Keep your DBAs

There's been a bit of buzz around lately(again) about methods companies are using to retain their IT staff longer. It would seem that in general the American business community is starting to realize that rotating out the people who run your infrastructure every 6mos is a bad idea, and actually ends up costing more money than keeping them. The articles I've been reading are more about IT staff in general, but I'm going to make this about DBAs since this is a database blog.

Here are the articles I've seen recently:
http://www.eweek.com/article2/0,1895,1944403,00.asp
http://www.optimizemag.com/article/square_off.jhtml?articleId=174401933

This just happens to be one of my hot buttons and I have a lot to say about it. So, if you're a CEO, CIO, or the like, pay attention because I'm about to tell you what your staff is really thinking and what they're afraid to say to you directly.

For starters, let's talk about incentives. Free in-house training, CBTs, tuition reimbursement programs, and everything in that general category don't mean squat. Most DBAs don't have time to go to college outside of work, so offering us tuition reimbursement is an empty gesture.

Bonuses are good. However, they can't be whimsical. Be regular with the bonuses, and be generous. You're not paying us for doing a good job, you're paying us to show how much you appreciate that we're sticking around and continuing to do a good job. Along with bonuses, think raises next. Raises are how you tell us you want us to not start looking for a job. It's been a standard for several years now... DBAs typically give themselves a nice, fat raise every year or so by switching jobs. And that 2% you like to give us isn't going to cut it. Don't even think about coming to the table with anything less than 7%. Anything else says you don't care whether we stay or go.

Here's another hint for you. My time is just as important as yours. I'm getting very offended that I have to choose between feeding my family and raising them. I was recently looking for a job and I turned down several gigs where the company expected me to be in the office 9-12hrs a day. I've got a family... that's unacceptable. Even worse is the support trade-off. When we as DBAs are expected to provide 24/7 support, you're expected to give the rigid schedule a break. Again, I've had a few jobs where I was expected to drop whatever I was doing to answer a support issue. I'm at the movies with the kids, stop and go fix the DB. I'm at the park with my family, or at a party, stop and go fix the DB. Even in the middle of a New Year's Eve party(true story), stop and go fix the DB. Yet, companies continually expect that all of their businees we're taking care of during OUR time should have no effect on my office time. Don't ever step up to me and ask me to provide after hours support and expect me to not take care of some of my personal business during your normal work day. In short... MY time is just as important as yours, and I'm not going to choose between being with my family, and feeding them.

Here's probably the biggest thing you can do to keep your DBAs around. Start a company-wide campaign to even pretend to give a crap about us. I honestly can't count the number of times I've worked for a company for years only to be tossed aside for a cheaper, less-experienced DBA. I'm always the top producer in my department... always. And to have the company I'm spending my nights thinking about improving just throw me away because they want to save 10K, is not only an insult, it proves that you don't care about me as a person. Now, I happen to know that the company I just left is in pretty big trouble database-wise since I left. And I can only assume that the rest were too. You can't get around keeping senior people. You need us. And if we're going to put our time, effort, thoughts, weekends, late nights, etc into making your company run better, and increase the quality of service and product you give your customers, then we deserve a little consideration. No, I take that back... we deserve a Lot of consideration.

One more thing before I get off my rant here. say it with me... flex-time. Practically every company has VPN, and there's no reason why DBAs can't do part of their work from home. They're typically more productive because they have fewer distractions. Give it a try. The ones who prove themselves unworthy get the right taken away, but for those of us who work extra hard from home so we don't lose the right... let us. Trust me on this one. Your DBAs will be far more likely to stick around if you show them a little consideration.

So, if you want us to stick around longer than just a few months, then say it with cash, and say it with perks. And remember, 401K matching and tuition reimbursement aren't perks.

Ok, I'm done.

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on May 2, 2006 05:19 PM

May 01, 2006 | Comments: (0)

What is the Future of DB2?

I often wonder who will ultimatly take the lion's share of the database market. Oracle and Microsoft seem to have a strong lead while IBM and Sybase seem to be lagging behind. And for some reason Sybase seems to be almost not even on the same course as the others.

So I was on the phone with one of the IBM execs last week, and I asked him why I never see DB2 in full production in companies I visit, and when I do, it's usually only in the process of being transitioned to Oracle or SQL Server. He was quite frank with me and said that IBM hadn't been as good at marketing DB2 as they'd like. I didn't really get whether there were any active plans to increase the marketing campaign or not, but he was very discouraged to hear that DB2 isn't more ubiquitous than it is.

The truth is that DB2 has some ground-breaking features that could take the database world to the next level. I think we can all agree that IBM has always pioneered database research. Their last couple versions of DB2 have brought some incredible advancements to the world of databases. The methods they use for updating statistics, caching execution plans, storing XML data, and providing row-level data compression are virually unmatched by any of the other vendors. So again, why are Oracle and Microsoft killing DB2 in the marketplace?

Sure, marketing... that's certainly a factor, but I think the other part of the answer is in the very nature of cross-platform software. Oracle suffers from this to a degree as well. See, DB2 isn't very windows friendly. I haven't found the code editors to be loaded with user-friendly editing features, nor have I found them to be rich in visual aspects either like having nice interfaces, etc. A perfect example can be found in the simple act of running a query. I haven't found anything in the editor that shows you how long the query took. In SQL Server, there's a space at the bottom of the query window that shows you how long the query took. In DB2, the execution time is shown in a separate pop-up window and it goes away as soon as the query is finished, so if you're not watching it, you have no idea how long it took. I ran into this problem recently when trying to compare the execution times of two separate import methods.

Another good example is in the pure lack of astetics in the GUI. I remember a very recent discussion with the editors of the magazine where we were trying to find a good screenshot to put with the preview of Viper, and what it came down to was finding the lesser of the evils. We never did find an eye-pleasing screenshot that was worthy of being printed. You don't have that problem with SQL Server, especially 2005. I think if IBM put some mroe work into their GUI, and gave us a good native development environment, they may be able to market it a little better.

That's really what it boils down to isn't it... astetics. I know if I'm going to spend 12hrs/day in front of a screen I want it to be something nice to look at... even if it's code. I also want the editor to help me as much as possible, and IBM really misses the mark on that one.
What I'm trying to say is simply this: I love the innovations DB2 brings to the table, but I want to stab myself in the eyes every time I have to do something with it because it's just a terrible interface to work with. So being cross-platform is great, but to make DB2 so generic as to be able to fit in all the platforms the same way just keeps it from being truly great on any platform.

I really don't know what the future holds for DB2, whether IBM will be able to market it better or not, but I'm fairly convinced that if they don't do something soon, MS and Oracle will get so far ahead of them, they'll never be a major player in enterprise databases.

Read my book reviews at:
http://www.ITBookworm.com

Posted by Sean McCown on May 1, 2006 05:11 PM

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert