IBM Db2 Database Reviews

Compared to Oracle, it is so much cheaper.

It has a good, stable performance, and it's not Oracle. 

Some of the internal rearrangement in the administration is not as straightforward as it is in competing products. 

Not very solid compared to its competitors' products.

Scales well enough for a relational database. Not exceptional; scales at or slightly below its peers.

Do not use it. Freely available documentation is a bit weak.

No. I have previous experience extensive with Oracle, SQL Server and Sybase. It is a good product. Better than Sybase, but not as good as Oracle, and comparable to SQL Server. 

I can't comment. I have no experience here.

They are competitive and honest (compared to how peer firms approach licensing conversations).

No, they were the incumbent.

Prototype any use of fringe functionality, XML-specific handling, JSON Processing, NoSQL Extensions, etc. 

Internet & Mobile banking database

E-Payroll & E-Statement solutions

Website database

A) The command set is almost the same in Windows and AIX operating systems, which greatly minimize the administration efforts to manage DB2 in both environments. Needless to say that working with the banking sector (which is my default playground) I need the ability to deal with many operating systems.

B) The ability to understand and interpret PL/SQL queries, with ease switching from Oracle to DB2.

C) Stability, scalability and security with high performance.

Our software products have to be PCI-DSS compliant, so encryption of customers' credit card numbers is a must-have feature. Using DB2 AWSE v11 enables us to do out-of-the-box encryption with ease.

Backing up databases from Windows and restoring them on AIX and vise-versa.

Support for migrating DB2 v9.7 to 11 in a single process with no intermediate versions jumping

No.

No.

IBM Knowledge Base is more than enough, I never asked them for support.

I used Oracle DB and am still using it with some of my customers, but Oracle administration is a nightmare compared to DB2.

The initial setup is straightforward, but securing your environment is a bit more complex.

Use DB2 Express for your development environment, but consider using Workgroup Server Edition if you need to federate two databases together or need to server a huge amount of data. If you plan to be PCI-DSS compliant, use AWSE.

MS SQL Server 2014 and Oracle 12g.

I recommend it to medium-to-large enterprise applications

• PureScale
• Blu acceleration
• XML and JSON datatypes
• Autonomous computing (storage, memory, and maintenance)
• HADR
• NoSQL (RDF and MongoDB).

Due to the stability, the applications can have a very long uptime, even with modifications in the application.

I have never needed to install a fix pack because there is a problem on the engine where new functions are used. Users forget to know that a DB2 is supporting the data.

Monitoring. There are very few applications that really monitor DB2.
Marketing. IBMers from other IBM brands, do not rely on DB2.

12 years.

It is easier to administer and to use than other RDBMS; however, developers like complex things and they get into trouble when using DB2 for the first time.

Not at all.

A lot of scalability can be done in DB2, it only depends on the money you want to invest in it and on the functions that you really need. It can go from a free database to a very big infrastructure.

In other countries, different to US or Canada, the support is not straightforward. This product has a small market share outside North America, and for this reason, experts outside that part of the world are very few, even inside IBM. Thus, the customer support is very basic, and any medium problem needs to go to Canada.

A six out of 10.

I have used a little bit of Oracle, SQL Server, PostgresSQL, and MySQL. They are good platforms, but they are not as easy to work with as DB2 is.

DB2 is easy to install. You just need to run the installer, and that is all. In AIX, it runs smoothly.

In Linux, it requires some libraries. Sometimes in 32 bits they are not easy to get, but once you got them, the installation is normal.

In Windows, it is just next, next. Once the binaries are installed, the instance is created in less than a minute, and it is only necessary to know what an instance means in DB2.

Finally, the database is just a command, that in some very specific cases it need extra parameters. If not, it creates a database in two minutes, and then, you have a powerful database ready to receive your data.

If you are creating a small budget project, DB2 could be your first option. You have almost no limits with the Community-C edition (the free one), and then you can scale up to a supported version. Instead, when you have a very big infrastructure, I recommend you to check what you need, then DB2 could be a very good option.

Ease of use and robust automated security administration and reporting are features any mainframe shop needs and should have. The cost of investing in such products will usually offset the expense associated with the DB2 environment and the efforts to protect those data resources associated with it.

When new DB2 resources are introduced into the environment, the Vanguard Administrator product allows us to quickly build the required RACF security rules and access lists. There are features in the Administrator product that automate the tedious security administration efforts. The Vanguard Advisor product provides a mechanism for monitoring the RACF/DB2 environment, identifying and reviewing security violations that occur, etc. As stated earlier, we also use Vanguard Integrity Professional’s “Security Center” product for RACF DB2 administration. The Security Center has a direct GUI interface to RACF. As such, it does not require the RACF administrator to use TSO to define or change RACF security profiles associated with DB2.

It is worth noting that the RACF security product is used to safeguard the DB2 environment on the mainframe. This allows us to maintain all security rules for resources on the mainframe using the RACF security product. Some shops I have worked in do not use external security managers like RACF, Top Secret or ACF2 to protect the DB2 environment. I have seen instances where installations with DB2 use native internal security.

If an installation does not use an external security manager product like RACF, Top Secret or ACF2, then native internal DB2 security would have to be used to safeguard DB2 resources. This results in the DBA's being responsible for security profiles that protect DB2 resources. It's better to let the DBAs do the job they do best; that is, define the resources and then let the security team protect them accordingly, with their input of course.

We have used this solution for approximately 10 years.

There were no stability issues.

There were no real scalability issues. Features in the Vanguard RACF security products allow the installation to determine security policy for DB2 resources and build the security rules as needed.

I think the Support Team at Vanguard Integrity Professionals is great. I have never had a problem with Support getting back to me in a timely manner with the information I need to resolve issues.

We have not used any external security managers other than RACF to safeguard the mainframe DB2 environment. At one point I was involved in looking at IBM’s zSecure product as an alternative RACF security and audit tool.

The initial setup of the automated security products like Administrator and or Advisor is straightforward. I highly recommend a Systems Programmer install the products to maximize the software investment a company makes.

I am not directly involved with pricing and licensing, but I know that despite the associated cost of the software prudent and practical use of these products will be cost-effective. Mainframe software, after all, is expensive and you by strategically planning a security implementation up front will be beneficial in getting desired audit and security results.

If your computing budget allows you to get automated security and audit products for your mainframe environment and the applications that run on it, you are fortunate. It is then your responsibility to maximize the software investment to insure all resources on the mainframe platform are adequately protected.

Truth be told, companies using mainframes spend a lot of money on not just hardware, but the software (DB2/RACF/etc.), that runs on it. It goes without saying that any mainframe installation with DB2 and RACF needs reliable security products to administer the environment provide security and audit reporting and streamline efforts to safeguard the environment.

From personal experience, I submit that software that enhances and automates security administration efforts for the mainframe and it isn’t cheap either. It’s important for a mainframe organization to maximize the financial investment in such tools.

In addition, an installation running DB2 and RACF needs to make an important decision. That is, who will be responsible for securing the environment. If RACF or another external security manager is not used than internal DB2 security will need to be employed for safeguarding resources. It’s important to have a security process in place to:

• Determine what DB2 resources need protection and identify who the users or groups are that need access, and the type of access (inquiry, update, etc.).
• Audit settings: What type of violations are being monitored and what is the process for reporting them.
• Security reporting: Periodic re-certification of security rules and access lists, etc. Things (access requirements) change over time.
• Change control: Security updates which need to be applied in the event of employee hiring, transfers and terminations. Managing a mainframe environment is difficult enough without having to also worry about security clutter.

Incidentally, this is only a partial list of things to consider when securing a DB2 environment. For example, this write-up doesn’t even address backup, recovery, and/or restoration issues (process/procedures).

In the many years I have been administering RACF and other security, I have come to conclude that there perfect security does not exist for any application or specific resource. A practitioner I once observed at a security conference summed it up by saying, "Computer security is a journey that never ends..." Ever changing new technological developments and access requirements mean you have to adapt accordingly from a security perspective.

Data structure -- easy access batch or interface.

All parts of storage mediums, including VSAM and sequential files to make the system work.

Applications are used within the boundaries of their functionality and/or business purposes.

While there are different situations that may occur either on a daily basis or once in a while, solutions are limited to the scope of their usage. So it's very difficult to determine if any improvements are needed or suggested.

This would be a situation basis and an attempt to use the product
outside of the business scope.

Since the early 1970s (IBM DB2 V2).

Very rarely.

Very rarely.

Excellent, if this question is referencing our DBAs.

N/A.

Not involved.

Not involved.

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.

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.

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.

We use it to provide for back-end DB for many proprietary applications. The most valuable features are reliability, performance, and portability across different platforms.

We have moved a lot of our applications off zOS to distributed platforms and IBM UDB DB2 has been extremely critical in our solution to provide for a scale-able, cost-effective and reliable DBMS solution on distributed platform.

The other advantage is we don't have to make lot of changes in the application DB2 access layer in order for it to work with IBM DB2 UDB. These applications have been originally designed to work with the host database (IBM DB2 zOS).

I would definitely like to see a better interface to interact with the database. Performance monitoring tools which come out of the box don't need to come along with all the bells and whistles. They need to be effective and intuitive. There are ways to do that out-of-box even today, but it can be improved

We have used this solution for over 15 years.

There were no issues with stability.

There were no issues with scalability.

The IBM Technical Support model is satisfactory.

We used XDB (Micro Focus RDBMS equivalent to DB2) which used to have scalability and reliability issues in our development environments. We switched to IBM UDB DB2 in our DEV environments on account of its reliability and scalability.

The setup was straightforward. However, the Linux setup can be improved.

I love the way the product is licensed on zOS and zLinux (core-based). However, IBM needs to improve their licensing for cloud environment, as we are planning to leverage that platform extensively in the future. Right now, the setup for AWS/Azure licensing is very confusing and not cost-effective.

We evaluated Oracle, but the ease of application re-hosting with IBM DB2, as well as its comparable reliability and scalability tilted it in favor of IBM DB2 UDB.

For folks looking to re-host applications that are using zOS DB2, our advice is to strictly go with IBM UDB DB2. Do not consider other options, as they usually require extensive changes in the application layer.

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.