Item: Db2
Rating: 10
Author: Ricardo Viegas

Overall Satisfaction with Db2

Use Cases and Deployment Scope

I support the product IzPCA ("IBM z Performance and Capacity Analytics").

DB2 have a symbiotic relation with IZPCA! Without DB2, IzPCA is nothing.

IzPCA continuously insert/alter/update data in 600+ DB2 tables, inside each one of the IzPCA DB2 databases.

That data contains important technical information about a lot of products/processes in the mainframe environment (eg, CPU, storage, DASD, channels, MVS, TSO, DB2, CICS, IMS, DCOLLECT, WLM, Applications, Job accounting, System Performance, System Capacity Planning (Forecast and Simulation), z/VM, zLinux, z/TPF, and many others).

People from the many teams supporting these products/processes, use that data to execute fundamental, and complex analysis/studies about how the products are performing, about how the systems, as a whole, are performing too, as well as forecast studies, and simulation studies ("what if" analysis).

These studies/processes, are fundamental and critical for the installation.

The support teams needs to execute them continuously, in order to have mainframes environments always in a good shape.

By consequence, DB2 is too, fundamental and critical, to allow the execution of all these important processes/analysis.

Pros and Cons

Pros

INSERTs/ALTERs/DELETEs of rows in a table.
SQL queries
Many checks, before insering a row in a table (row duplication, data characteristics, data range, nuls, etc, etc, etc...

Cons

Maybe the SQL Reference manual have a chapter or an appendix, clarifying for each one ot the comands/functions/processes/etc at which level they act, row, table, tablespace, indexspace, stogroup, database, DB2 sub-system, etc
But if not, here goes the suggestion: Add it!
I do not know if the SQL Reference, or any other manual have this kind of information.
If not, I suspect it will be a good idea to have it.
The correlation between the various types of DB2/SQL data and the types in all languages available at the mainframe
I suspect a chapter, in SQL Ref manual, explaining in detail the operands working over two or more tables, will be of great help.
I remember the JOIN operand, but have a vague recall there are others.
You see, there is not even an small section about JOIN, with a corresponding entry in the CONTENTS list at the beginning of the manual. :(
Making a search for the word, we only see texts on how to use JOIN in such and such situations/conditions, but NO explanation at all about it
I made, too, a global search in most of the DB2 manuals. There are lots of rows with the word JOIN, but apparently again only to inform how to use JOIN in some situation.
Maybe in a good class of SQL they will explain the JOIN,
Unfortunately when I started to support IzPCA, I neede to learn DB2/SQL by myself, reading the manuals, and testing :(
A chapter or a major section explaining in detail the JOIN (and similar operands, if they exist), certainly will be of great help.
For me, and for the people starting now with DB2/SQL :):)
If that chapter or section, by any chace really exists, please, inform me the manual name. Thx :)

Return on Investment

I am in the DB2 technical side only, now way do add any info here :(

Scalability

By
using DB2 only to support my IzPCA activities, my knowledge here
is somewhat limited.

Anyway,
from what I was able to understand, DB2 is extremely scallable.

Maybe the information below could serve as an example of scalability.

Customer have an huge mainframe environment, 13x z15 CECs, around
80 LPARs, and maybe more than 50 Sysplexes (I am not totally sure about this
last figure...)

Today
we have 7 IzPCA
databases, each one in a distinct Syplex.

Plans
are underway to have, at the end, an small LPAR, with only one DB2 sub-system,
and with only one database, then transmit the data from a lot of other LPARs,
and then process all the data in this only one database.

The
IzPCA collect process (read the data received, manipulate it, and insert rows
in the tables) today is a huge process, demanding many elapsed
hours, and lots of CPU.

Almost
100% of the tables are PBR type, insert jobs run in parallel, but in 4 of the 7
database, it is a really a huge and long process.

Combining
the INSERTs loads from the 7 databases in only one will be impossible.......,,,,

But,
IzPCA recently introduced a new feature, called "Continuous
Collector".

By
using that feature, small amounts of data will be transmited to the central
LPAR at every 5 minutes (or even less), processed immediately,in
a short period of time, and with small use of CPU,
instead of one or two transmissions by day, of very large amounts of data and
the corresponding collect jobs occurring only once or twice a day, with long
elapsed times, and huge comsumption of CPU

I
suspect the total CPU seconds consumed will be more or less the same in
both cases, but in the new method it will occur in small bursts
many times a day!!

Reliability and Availability

When needed, DB2 was always available, with only one exception in 6+ years, an interruption of +- 10 minutes.

It must be noted that IzPCA databases by no means are accessed in a stressing/continuous mode.

It is extremely distinct from a customer application, with thousands (or even millions?) of transactions by minute/second.

Alternatives Considered

only DB2 knowledge/esperience

Key Insights

Do you think Db2 delivers good value for the price?

Not sure

Are you happy with Db2's feature set?

Yes

Did Db2 live up to sales and marketing promises?

I wasn't involved with the selection/purchase process

Did implementation of Db2 go as expected?

I wasn't involved with the implementation phase

Would you buy Db2 again?

Yes

Likelihood to Recommend

As I mentioned in previous questions I learned by myself all DB2/SQL subjects needed to execute my support for the IzPCA.

So, the only thing I can say here is, "DB2 is totally suited for IzPCA"

As a matter of fact, without DB2, IzPCA is useless. :)

Comments

Please log in to join the conversation

DB2/SQL being used together with another IBM product, IzPCA

Software Version