IBM Db2 Database Reviews

We primarily use the solution as the main data store warehouse for the corporation.

It's great as a backend database system utilized to store the data for the entire corporate structure.

Due to the fact that we're going to go with the hardware-specifics of the fact that it's bundled in IBM i, it's exceedingly reliable, as the architecture of the IBM i just does not go down.

It runs very well. It runs very solid. It does everything that I expect it to do. It offers all of the standard RDBMS functionalities and capabilities. I consider Db2 to be a direct competitor with Oracle and SQL servers any day of the week. The difference is what flavor of Db2 you're going to run. You're going to run the Linux Unix, are going to run the IBM i version, and then it comes down to, for me, the IBM i, due to the fact that the architecture does not fail. It does not go down. It does not get hacked. There's never been a successful hacking of an IBM i architecture. You're looking at an environment where your data is extremely secure, compared to a lot of the other RDBMS systems.

The solution is configurable and has what you would consider to be a desktop management configuration capability too. You can partition it off, and you can set up different instances of it and such. The interface is more than adequate. There's nothing great about it, there's nothing poor about it. It's more than capable of doing what you need to do if you do need to do DBA maintenance kind of work to it.

It's going to be a much smaller marketplace for this product, and most significantly, IBM doesn't target marketing to that marketplace. Their view of it is they're maintaining it, they're continuing to upgrade it, they're continuing to grow it, however, they don't go out and try and sell that as an architectural solution the way they do Linux and Unix. That's because once you get inside of the IBM architecture, up until about six or eight years ago, it was not open source. You were tied to the development language of either COBOL or the development language of RPG if you wanted to develop on that platform.

Now, it now supports Java and PHP, and it does open source, but for those reasons, IBM was never looking to market or push that as a viable solution. They didn't push the IBM i as a direct competitor to Oracle, they pushed their Linux Unix versions of it, their IBM Z series against Oracle and SQL server, as it's a more direct head-to-head comparison. The IBM i architecture is the one-off if you will. You're not going to see a lot of people looking at it.

I've been using the solution for 25 years at this point. It's been a while. 

The solution is stable and reliable. The hardware does not fail, the software does not fail, and so the reliability is there, however, the reliability isn't necessarily Db2, it's the fact that it's the IBM i that has the reliability. Db2 is inheriting that, and again, is staying up and running because of that.

The system scales very well. It runs the new power nine chips and it's about to run the new power 10 chips that IBM is releasing as well. For that reason, the current systems out there are 16 CPU Power 10 processors that can have terabytes of memory associated with them. It performs extremely well in the environment. 

The system is very scalable to very large magnitudes. There are some very large Fortune 10 and Fortune 15 companies that run Db2 systems and can attest to the scalability

IBM's technical support is fine and their people are good. When you give them a call they get after it. We're satisfied with the level of service provided. 

The initial setup is very straightforward. Due to the fact that it's bundled inside of the system, you don't have to do any special implementation. As soon as you have the system up and running, and the operating system running, Db2 is already running. There was an instance of it running on the architecture at that moment. There's absolutely zero setup in that environment.

It's hard to separate out the exact pricing. It's bundled; you can't compare head-to-head against Oracle and SQL server at that point, as the costing is embedded inside of the purchase of the operating system software.

We're not a software provider, we're an end-user.

When you start talking about Db2 on Linux and Unix, the current version is version 17.3 or 17.4. The IBM i, the versioning doesn't work the same way, it has to do with the operating system levels that you're running, as to which version of Db2 you're in. It's integrated in with the system, operating system. It's not actually an independent version of Db2, it's integrated in with the operating system on that platform.

Db2 is different in our architectural world than standalone Db2. It's not like standing up an instance of Db2 would be the same as it would in Oracle, or a Microsoft SQL instance, on a Windows 10 server or a Windows 2008 server or whatever it may be. It's the fact that it's bundled in with the software, with the operating system, with the hardware, when you buy that machine. Since it's all bundled inside of it, we're having to go out and independently do things with it. It's inherent, it's bundled. It's probably not the best example of Db2, because even when IBM goes out and talks about Db2, they talk about Db2 zOS, which is the Linux Unix installation. You very rarely see them talking about the IBM i installations. In fact, in even the documentation I was reading in the comparisons, it was comparing the Linux Unix IBM Db2 against Oracle, and against the Microsoft SQL Server.

If you're looking at an alternative to Oracle or to Microsoft SQL server, look at Db2, and then once you're in Db2's world, take a look at IBM i against the IBM Z, and compare the two of them. The stigma that the IBM i has, is that RPG language barrier. Since that barrier has now been removed, you can do everything that you can do on the IBM Z as well. The stability of the platform is what people need to look at. There is a trade-off of uptime and never been hacked operating system against versus Microsoft and Oracle in the news every single day. Microsoft cloud just made a comment in the last 48, 72 hours about their cloud services being hacked. That's just something you do not see happening with that IBM series architecture.

Since Db2 rides inside of very secure architecture, people should probably give it a very good, hard look, compared to Oracle and Microsoft, and say, "Hey it might not be as popular. It might not be as big a deal, but if my data is more secure, and I don't have downtime and I have performance, is it something that we should be looking at?" 

I've been at companies that have looked to move off of that, and when they've looked at the Oracle solution, and, no matter how you power it, and no matter how you scale it, whether you scale it up or you scale it wide, the performance is simply just not there compared to what the IBM systems offer through their Db2, whether it be the i or the Z through what they offer internally in their performance capabilities. Your iOS, your throughputs, your performance cycles, you cannot touch it with Microsoft or with Oracle scalability-wise. That is far and away the most scalable systems and the highest performing systems of the set of them.

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

We are not using this with other users, it is dedicated to our backup solution.

We only have one instance, one user, one service, and we don't have any other users or clients that we connect to.

A database system is a tool used for reporting and to monitor if it is running or if there are any issues. We can set alarms and warnings. It is a backup system that manages the backup.

The most valuable feature is that it is robust. We had a crash of the backup system and the IBM DB2 was always up and consistent. It's robust, and for us, it was always up and running.

The database is deployed using the command line, so we did not test any other tools, aside from DB2 using the command line interface.

Because this solution is a big data database only dedicated to the application server, it is very difficult for us to assess areas of improvement. We use the database, so we don't have any other requirements or need to use it in any other way.

The licensing fees can be reduced. While we don't see the breakdown, we know that IBM licenses for the backup system are very expensive.

I have been working with this solution for ten years.

This solution is stable.

We don't have experience with scalability because the server is also a dedicated server and the physical hardware has always been dedicated from the beginning. After five years, we made a technical upgrade and have been the same since.

My colleague has the primary responsibility for the backup system and he has had to open tickets on two occasions. Each time, they were okay and the issue was resolved. 

The initial setup is simple and straightforward. It's easy to install with no special configuration for a big data database. They make things simple.

It took less than an hour to deploy.

The cost is embedded in the price of the backup solution. We know that the backup solution is quite expensive and with each inside license, there is also a database license.

We don't see what the specific price of the DB2 license is because we pay for the backup license as a package.

This is a robust and stable product but it's expensive.

I would rate this solution an eight out of ten.

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.

We use the solution as a query tool for requesting and updating data.

The solution has the best querying features.

They should make the process of building up queries easier for the solution.

I have been using the solution for some years.

It is a stable solution. I rate its stability nine out of ten.

Presently, we have 200 solution users in our organization.

The solution's technical support team is good.

The solution's initial setup is straightforward. The deployment process involves requesting access to different test environments and productions. It takes a couple of hours to complete.

We implemented the solution in-house.

The solution is intuitive and easy to use once you know how to build up queries. I rate it a nine out of ten.

We use the solution as a database for e-commerce applications.

The solution's most valuable feature is scalability.

The platform itself needs improvement. They should develop a containerized version of the solution. In addition, they should include dashboard features as well.

We have been implementing the solution for customers since 2006.

It is quite a stable solution. I rate its stability as an eight.

We have 34 technical users and over 50 end users for the solution. I rate its scalability as an eight.

The solution's technical support team could respond faster.

Neutral

I have used Oracle in the past. In Comparison, IBM provides better performance and scalability features.

The solution's initial setup process has medium complexity. It takes a few days to complete. I rate the process as a seven.

I rate the solution as a seven.

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.

IBM Db2 Database is a relational database and we use it for all our company's transaction data.

IBM Db2 Database has good performance.

The solution could improve by providing more integration.

I have been using IBM Db2 Database for approximately three years.

IBM Db2 Database is stable.

We have not had an issue with the scalability of the IBM Db2 Database.

The technical support is good.

I would recommend this solution to others.

I rate IBM Db2 Database a nine out of ten.

I handle implementation. I install the Db2 Database before I send it to the developer or the application team. Also, sometimes, I have to migrate the database from one platform to another.

The solution is easy to install and simple to maintain. The most valuable aspect of the solution is its general user-friendliness for users of all kinds.

The solution could improve the centralization aspect of the tools.

It would be ideal if the solution offered backup functionality. Many similar tools already do, which means Db2 is somewhat behind the curve in terms of what a customer might expect from it.

I'm an implementer of the solution in Thailand. I have been working with Oracle Db2 and SQL for more than 10 years. 

The solution is stable so long as you don't have to make any changes to it. I haven't seen any bugs, or glitches on it. I haven't experienced crashes either.

The solution is quite scalable. A company shouldn't have issues with expanding it if they need to.

We typically implement the solution for small to medium-sized organizations.

Technical support is not the best. I would rate them five out of ten. 

The issue is that in order to make a ticket, you may have to call and then you end up being on hold. Sometimes, the person who answers doesn't know how to resolve your issues so it can be frustrating. 

I also have experience with Oracle databases. I find Oracle to be a bit better than Db2 if I'm honest. They have a lot of functionality, for example, and can handle backup and recovery of data. This is not possible on Db2.

The solution is very easy to set up. It's not complex at all.

Deployment takes about one to two hours or so. It's not a long or arduous process by any means. 

You only need one person to deploy and maintain it.

I handle the implementation myself.

I don't know too much about the pricing of the solution. There may be extra fees on top of just the licensing fee. I'm not sure.

I'm looking at other databases right now. I'd prefer something with a backup functionality, which Db2 lacks.

We're currently IBM partners. 

I use the solution extensively. 

I'd like other companies to know it's quite easy to set up and maintain. If they are looking for something fairly easy to jump into, this may be it.

I'd rate the solution seven out of ten.