IBM Db2 Database Valuable Features

reviewer1715946

Mainframe Technical Manager/Service Integration Lead at a tech services company with 10,001+ employees

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.

IBM Db2 Database Reviews

IBM Db2 Database Valuable Features