IBM Db2 Warehouse Review

If you have good people designing how the data is stored, this is a marvelous tool


What is our primary use case?

We called our primary use case for this solution a data warehouse. It was data tapped from many, many different applications and mostly put into star schemas for historical reporting.

What is most valuable?

I think it scales really well and as long as you take enough time to learn a little bit about it, it works really well. If you have good people designing how the data is stored, it's a marvelous tool. If you have really, really bad designs, well, the tool might still be good, but it doesn't perform as well. But that's going to be true for anything.

What needs improvement?

The biggest problems we have is when the backup solution is failing or slow and we run out of log space, which has happened probably a couple of times in the last four years. It's traced back to something that changed on Tivoli Storage Management.

For how long have I used the solution?

We started using this solution probably around 20 years ago, but we're migrating away from that now to SAP HANA and Azure. 

What do I think about the stability of the solution?

The stability is pretty good.

What do I think about the scalability of the solution?

This product is scalable. 

How are customer service and technical support?

Well, I think my partner and I would say different things. I found them to be pretty responsive. I did have a couple of occasions to open things and it troubled me how long it took to get action on those. Sometimes if I opened it in the morning, it might be fine. But if I opened it in the afternoon, it might be quite a long time, certainly next day, sometimes late the next day. But that's the service agreement we pay for, so that's what we get. I just wish it was faster.

Most of the time, I think they're great. Once in a while, they don't do as well as we'd like.

How was the initial setup?

Most of our initial setups were straightforward. One of our data warehouse analytics platforms, which is our first implementation amongst all of our data, is now 16 partitions on four servers. And we have one large customer-facing application, that is 16 partitions on four servers. But everything else is around four partitions I'd say. But other than that, they're all pretty straightforward. We have a few, but they are in query in a production ward group cluster where I used them for Db2 with 40 or 50 databases in it. But each database is pretty straightforward.

What other advice do I have?

For any database project, I really like to see good thought going into design upfront and use the standards so that people know what things mean about having to rediscover it when you go from one application to the next. So I believe in at least a place to share the vocabulary, if not a controlled vocabulary defining things, which is pretty old-fashioned I'm afraid. I also believes that companies need to pick a direction and stick with it and support it. And if they're going to go with this solution for a couple of years or if you had to have several solutions happening in parallel, you need to have really good criteria about when you go from one to one or when you go to another because sometimes it's challenging. It doesn't help the business if we're not being consistent.

**Disclosure: I am a real user, and this review is based on my own experience and opinions.
Find out what your peers are saying about IBM, Microsoft, Oracle and others in Data Warehouse. Updated: June 2021.
509,570 professionals have used our research since 2012.
Add a Comment
Guest