IBM Db2 Database Reviews

Scalability, the IBM i Logical views, journaling.

DB2 was always there, so I can't answer that. Know that I've used MySQL, PostgreSQL, and SQL Server extensively as well, and always missed DB2 for i.

Not sure.

Since before it was called DB2, back on the System/38, so twenty years or so.

Hah! You kidding. DB2 for i? No. Never.

Hah! You kidding. DB2 for i? No. Never. Would you like a description of the IBM i Single-level Store. Add a new drive and you are good to go.

Good to excellent. It can get expensive but third party is very good.

I did not use a different solution prior to IBM DB2.

It was integrated with the IBM i OS.

If you want horizontal scaling and reliability, DB2 for i is absolutely the way to go.

No, I did not evaluate other options before choosing this product.

If you don't know IBM i OS, just use it for DB2 for i, and scalability, reliability, and security. Then consider using partitions for Linux for your business logic.

We primarily use the solution for different banking systems.

The solution is very stable, in both hardware and database.

IBM just came out with new hardware in September, so they are getting ready for the cloud. If they can push through with all those features they're talking about, I think they have a good product lined up. Right now, the solution needs to have end-to-end encryption, to be cloud-ready, to have native support for Linux, and built-in data scientist workbenches. These are promised to us in the new release, and I hope that happens.

End-to-end encryption specifically is something the solution needs to have in the next release.

The solution is very stable.

The solution is very scalable. We don't plan on increasing usage any time soon, however.

Technical support is good. they are pretty responsive.

We also use SAP HANA. These are two different applications, however, and they have different use cases. HANA runs on memory. Db2 is a much more mature, older technology with its own platform. HANA is not that new but it's not that old either. It's much faster for sure. The difference is one is in-memory computing, while the other is a traditional database on hardware on the IBM platform.

The setup is quite complex. The solution and the hardware build are two different events. The deployment itself doesn't take more than two weeks, followed by the setup which can take, depending on the organization and its processes, a few months to a year. It varies from client to client.

IBM assisted us with the deployment. 

They're quite good at what they do. They never deliver on time or on budget. However, they know what they're doing, as it's their product.

The solution is pretty expensive and IBM isn't very transparent in their pricing plans. You need to be aware of what your company specifically needs before purchasing anything.

I'd rate the solution a six out of ten.

We use DB2 HADR to replicate data on LAN to another site. It is easy to takeover to the other site. There is easy integration with TSM.

We replicate TSM servers' databases to the other sites with the HADR feature. We use HADR takeover to switch the TSM service to the other site.

• Automatic upgrade process (e.g., from v9.7 to v10.5) often fails.
• Error messages are rarely unusable (e.g., I/O error -> instance upgrade was unsuccessful. You must issue an instance upgrade manually).
• The same issue with the dialog messages, independent from LOGLEVEL.
• A lot of irrelevant information (hexdumps, etc.)

There were no issues with stability.

There were no issues with scalability.

Technical support, works, but they are slow to get to the real experts, Level-2, who can really help. Level-1 support often asks for irrelevant data.

The initial setup was complex. There are InfoCenter Pages and TechNotes, but these only cover the "usual" cases. You need a lot of experience and/or support.

It depends on the customers. Often, DB2 is more expensive than Oracle on the same environment. There are those with more experience with Oracle, and it is hard to find DB2 DBAs, engineers, and experts.

We did not evaluate other options from a TSM server point of view, as there was no other way. From other way, we evaluated Oracle, which is cheaper and there are more people with Oracle-experience.

Use InfoCenter, then DeveloperWorks, and the TechNotes. :) Do this in order to get experience.

The simplicity of installation/setup and the ability to run without requiring constant maintenance.

For applications, we have Oracle and Microsoft SQL deployed for application systems, but I prefer DB2 for my “systems” usage primarily due to its limited requirement for administration.

Not one that is relevant, it is used purely in a “systems infrastructure” setting rather than as a “business application system”.

In my limited use case, the only major thing would be improved reporting capability.

The first time was in 1989/1990.

Recently, from 2007 to the present day.

No, I had a DB2 instance running on an old IBM x3650 with Windows 2003, which ran continuously for eight years.

It was a performance data repository for our storage and fabric switches, with an average insert activity of several 1,000 per minute (had automatic record pruning setup).

No, but we never had it greater than 100TiB.

Can’t rate it as we never had to use it.

No, I selected DB2 based on previous experience with Oracle and after a brief look at MS SQL.

It was very simple to get up and running. The documentation is very good and the user forums, including IBM wikis, make it very easy to find out most things we did to it as far as setup/tuning are concerned.

As we already use Oracle and MS SQL for applications, I looked at the latest version of Oracle (at the time v9) to examine any differences pertinent to the last time I had looked at it.

MS SQL: I only briefly looked at it. IMHO, it was no match for DB2 or Oracle, as far as what I consider “Enterprise Databases” to be.

Define their use cases as exactly as they can, then look at what DB fits them.
I have seen the app/database team deploy Oracle/MS-SQL when something really simple like MySQL would have been a better option.

Also, before installing DB2 make sure full planning is done regarding scalability and performance requirements.

Definitely, use the planning worksheets and search the DB2 wiki’s and user forums to ensure the setup is optimal from the start, especially as far as layout is concerned.

I have found in the x86 world that products seem to be installed with very little pre-installation planning. With my mainframe background, you don’t install anything until you have examined all available documentation, so you are aware of all the key decision points in the install/setup/layout.

A4: Automatic storage. Disk space management is one of the biggest pain points for a DBA. Even Oracle 11g R2 cannot do better than IBM DB2 when it comes to this feature.

The old system (Wealth Management) was on Microsoft SQL Server platform, however, the performance and stability couldn't meet our requirements. After migrating to DB2, it's much better.

Absolutely -- centralized management tools with UI interface, like Oracle EM .

Three years.

Yes. We even encountered DB2 bug on the Version 9.7.0.9 and it's the reason why we upgraded to Version 9.7.0.11 .

Yes. Many tables or indexes can't be scaled up without reorg step. As an unbreakable system, it's a very bad design.

8 out of 10. IBM Lab is quite strong. The site technical support is good, too.

See my answer to the 'Stability' question.

It's quite complex. It cannot be done without reference.

The reference documents and education resources in the market might not offer as much as Oracle Database or Microsoft SQL Server.

It's still much more than open source databases such as PostgreSQL, but much less than Oracle and Microsoft.

Calculating the license fee is always very complicated and only the IBM sales can get the final answer. It's not a transparent way.

Yes. Oracle Database.

The solution is used for database management.

The solution has very good data compression of up to 50%. For example, if you have 50 terabytes of data, it can be reduced to 25 terabytes.

The capabilities of this solution could improve.

I have been using this solution for many years.

In my experience, it has been stable.

The scalability is good. We have some clients that have over 9,000 users using this solution.

The technical support has been very friendly, responsive, and it is quick to escalate an issue.

I have used previously Cisco MySQL, SQL Server, SAP HANNA, and IBM DB2.

We have approximately 14 technicians doing the deployment and maintenance of this solution.

We normally handle large size businesses and as far as I am aware, the license is negotiable based on the number of users and the quantitative data.

I would recommend this solution to others.

I rate IBM Db2 Database an eight out of ten.

My primary use case is for media management purposes.

Some of the most valuable features are the scaling from a small very cheap installation to a very large enterprise installation. In addition, the backups and assistance are good.

It would be nice if it was easily available on all platforms because nowadays, it is not there as a general database.

It has been very stable.

It has been a very scalable solution for us.

The initial set up was complex, but that was a long time ago.

We considered Oracle. But, Oracle kept coming out with new versions and every time you had to change something in your application.

I suggest to anyone considering this solution to get hands-on experience with the solution, and run some tests and pilots. When evaluating a solution like this one, you must consider the product itself, the support available and how common or popular the product is. I find that if it is a popular product, that means there are a lot of people who know the product well, and it's easy to do work with that particular product.

HADR/TSAMP: It makes planned downtime very manageable, and allows us to handle unplanned outages with very little user impact.

We use IBM DB2 as part of a SAP implementation. DB2's performance and stability has been a key factor in the success of the SAP rollout.

The diagnostic log (db2diag.log file) could be a little bit more user-friendly.

I have used this solution for 16 years.

There were no stability issues.

This is not relevant for me, we have rarely needed to build on the initial server footprint.

Right now, I deal directly with SAP support for DB2 issues. But, when I previously worked for IBM, I found the DB2 support staff to be very helpful and knowledgeable. Due to the size of the company, there was a huge breadth of knowledge and experience.

The installation process and setup is fairly straightforward (assuming that you have a good working knowledge of the underlying OS and basic DB2 concepts).

Take advantage of the dedicated IBM teams that are in place to help with the migration process from other DBMS.