IBM Db2 Database Reviews

It's not the Db2 LUW, which is Linux, Unix, Windows. It's the mainframe. It's the active-active, high availability environment that we need for the aggressive SLAs that we've got here in Saudi Arabia.

I like that its true active-active. For example, if there are two instances within a cluster, we can take one of them down and there's no failover or switch over. There's no primary and secondary, it's true active-active. We can take one side down and we can upgrade that with new maintenance or a new version, obviously testing coexistence beforehand, without impacting the business.

In a distributed world, you've got lots of different prerequisites you've got to be managing here. Not just the database - possibly the VMs that the database is in and the OS that the database is running on, Linux or Windows, as well as the storage.

I like its high availability. It's well supported by IBM. It's used by a lot of the larger business organizations globally within banking, finance, credit cards, insurance, retail, and government.

We're proving that it's got that high availability and robustness. We can prioritize the workloads that are coming into that database management system, using the features of the IBM z/OS environment. That way, if this transaction's coming in off the network that is in and out, they will be given priority over somebody doing a lengthy query that's coming in from the network that you would consider to have more batch-like tendencies. 

We like that it's using separate specialized CPU engines to manage the locking and the sharing of data via a coupling facility. This stays on the CPU that we would be licensed for. We call them specialized engines that you don't license. They're not paying your licensing costs. Whereas, for example, in other database management environments for high availability, they communicate between themselves over an IP network. The CPU would be higher for them. There's no special process or capability that allows taking that CPU and that communication between them. It has to, if you've got four nodes of a database management system, one of them would have to lock on a row in a table or whatever, it's going to have to propagate that information to the other three nodes on the mainframe side. It would just put it into what we call a coupling facility, and the other Db2 members or instances in the same cluster would be able to check that and see that, no, we can't update that yet, we'll have to wait.

There are lots of different things we use it for. We use it for data replication, which means that we've got an always-on alternate Sysplex cluster several thousand miles away that is propagating the data to that Db2 over there using replication services at the software level rather than, if you physically replicate data and the Db2 or the Oracle environment, physically using storage replication, you've in effect got a cloned copy of that environment. It's going to fire up at the remote site, looking for the network that's at the local site. There are lots of things you would have to do there to do that. Plus the RTO time to actually get that alternate Db2 at the DR side could be 40-45 minutes depending. Whereas we can do this capability and we call it always on, where the RTO is about a minute.

In my current project, where we're taking information from an old IBM mainframe and using Db2 to convert those checkups into GRP (Government resource planning solution).

We have a transaction server, Db2, that already exists in one place. We have our own solution using Oracle. So, from this transaction, we're taking information from Db2. We're running about the engine, that is, the various queries. And they're taking the information into our Oracle server. That's the way we're cleaning and fine-tuning the information taken from one system to our system. And that system is Db2.

We are using our own developed workflow management system. We're working mainly for IMF and World Bank with Asian Development Bank. Based on the aids, they're giving in that particular workflow, we define the process needed for any country receiving aid.

We provide the solution to any government's finance department in any country. So, in team mode, they previously had the IBM solution. We're using our GRP solution, which is a public finance government resource planning solution. We need to use the existing system. On top of that, we're providing the vendors and information to the public regarding the aid they're getting from that department.

So it's like a combination of solutions using various components to provide the solution in GRP from the existing IBM solution.

This is the solution developed for IMF, where whatever funds they're giving to a particular country, all the grants are coming from the IMF using the Db2 server. So once they transfer the amount, the information comes into Db2 against a particular project, like for education or healthcare. 

So, the IMF grants a specific amount for a specific project in a country. Now, that country likely has various projects running under that department. Our GRP system manages those projects for that particular country. We take the base information – what money is coming in – and based on daily transactions, we update Db2 database to report back to the IMF. This report details all expenditures, including who approved them and which ministry was involved.

So, IBM Db2 database has been particularly effective for the data management requirements.

IBM Db2 for zOS serves as the central database for all the core business applications in the two banks I work with. All applications use Db2 as a data server. We fully implement and utilize most of Db2's functionalities and capabilities for core banking business applications.

IBM Db2 has integrated well with open systems and additional applications on the zOS platform, providing a robust DB service for all core business applications. It offers great stability and scalability, which has positively impacted the operations.

The IBM Db2 Database in our organization is used for diverse industry clients, including the banking and entertainment sectors. The solution has been used for OLTP and warehousing in our company. 

The optimizer plan feature of IBM Db2 Database offers great value. At our company, whenever we check access to a particular query, the aforementioned features assist us internally by providing a suitable plan. The newly added feature of ALSM is one of the top features of IBM Db2 Database. 

The primary uses for this product have to do with the card management system for banks. We are working mostly in the financial sector and banking sector, so there are some card management systems there that we often work with. There are some databases for which we see value in using Db2, so we are working with this solution.  

One of the things I like most about Db2 is that it is almost maintenance-free. I do not have to maintain it, unlike a modal database. I have been using modal databases for a long time and those are more sensitive. It is almost 15 years now that I have been using modal databases and it is almost tedious to use modal databases by comparison. I have been using the Db2 more recently and both database types are in use in my company. With a modal database, I have to check to see how or if the data is coming through. But in Db2, it is not as much of a headache. It is also easier to understand than modal database structures.  

We continued with our existing mainframe Db2 solution due to its high availability and the ability to maintain an active configuration across multiple servers or LPARs.

There are two versions of Db2. One is Db2 for z/OS. The other is Db2 LUW—LUW stands for Linux, Unix, and Windows. From an availability perspective, it's not on the same level as the z/OS version, which I consider superior. This is why major airlines, banks, insurance companies, and retailers worldwide rely on mainframes and Db2.

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.

I am currently using IBM Db2 for z/OS. It is used to manage a huge amount of structured business data and provides DB services for many different applications.

Its performance is great. In my case, half a million transactions per second are using the DB services of the Db2 mainframe. So, it provides a great ability to support logical units of work.

For every big organization or big site, such as a bank or a credit card company, the most important asset is data. An organization puts all its business data and manages it in Db2 because it trusts that Db2 will be able to provide all the necessary services, such as:

• Business continuation
• The ability to process a large amount of data
• The ability to maintain a large amount of data
• The ability to execute DB services in a fraction of a second