The Emergence of IMDB Technology

Businesses as well as consumers demand that more information be placed at their fingertips. When using mobile devices such as iPhone and Android, people expect answers to their questions in seconds rather than minutes. This reality is driving the emergence of in-memory database (IMDB) technology.

With the low cost of memory, data is increasingly being moved to IMDBs, which can provide up to 10 times faster data access than traditional disk storage devices.

Until I glanced at the above Wikipedia link, I hadn't realized that IBM acquired solidDB in 2008. The solidDB database supports both IMDB technology and disk storage access. It's used in consumer hand-held devices as well as on UNIX, AIX, Linux and Windows servers.

Once the application connects to solidDB, a subset of data from the back-end database is stored in memory. That's the role of solidDB Universal Cache, which supports DB2 for z/OS as well as DB2 for LUW, Informix, SQL Server, Oracle and Sybase. Updated data is kept in sync using IBM Infosphere CDC (Change Data Capture).

For details on solidDB 7.0, check out these links:

* The list of products included with solidDB 7.0

* An overview of the architecture

* A list of supported back-end data servers 

Another good solidDB resource is the IBM Redbook, "IBM solidDB: Delivering Data with Extreme Speed" (published May 2011).

Is your company taking advantage of IMDB technology? Please share your experiences in comments.

Supporting USS on DB2 for z/OS

A reader recently told me about installing DB2 for z/OS and setting up UNIX Systems Services (USS) components. He wanted to understand more about the archictectural differences between DB2 on USS and DB2 for z/OS.

I found some DB2 manuals and IBM Redbooks that address the topic. For starters, there's "The ABCs of z/OS System Programming: Volume 9" (update May 2011).

Of course when working with DB2 installs, you should review the DB2 Installation guide, but when working with distributed applications like USS components, you need to understand DB2 distributed functions (DDF). While "DB2 9 for z/OS: Distributed Functions" obviously doesn't cover the latest in DB2, it does provide a good introduction to DDF.

The reader who contacted me was hoping to find a diagram showing the DB2 for z/OS components that run on USS. Unfortunately, I couldn't turn up anything. As a visual person myself, I think a diagram showing how Java applications running on USS communicate with DB2 for z/OS would be great. However, I did find the "DB2 9 for z/OS Application Programming Guide and Reference for Java." This manual explains how IBM Data Server Driver for JDBC and SQLJ are used to make the connection from your application to DB2 for z/OS.

Have you found other resources that have helped you understand the DB2 for z/OS architecture in supporting applications that run on USS? Please share your tips in Comments.

DB2 Performance Stored Procedures

Last week I posted a lengthy list of stored procedures that can be used to help with administrative tasks. What follows is a much shorter list of some stored procedures that are used to manage performance. For more about these procedures and how to use them, see the IBM manual, "DB2 10 for z/OS: Managing Performance."

• DSNACCOX (DB2 realtime statistics) issues recommendations for maintaining DB2 databases. These recommendations include when to reorganize, image copy, or update statistics for table or index spaces. SDNACCOX also indicates when a data set has exceeded a specified threshold for the number of extents it occupies and when an object is in a restricted state.
• DSNACCOR has been deprecated and replaced by DSNACCOX.
• DSNAEXP (DB2 EXPLAIN) allows database operators to issue EXPLAIN statements within certain simple SQL statements without the authorization that's typically required to execute such statements. DSNAEXP was deprecated with DB2 10. The EXPLAIN privilege or SQLADM authority should now be used instead.

These stored procedures, which are new with DB2 10, help with automating statistics maintenance (ADMIN_UTL_MONITOR, ADMIN_UTL_EXECUTE, ADMIN_UTL_MODIFY). The "Managing Performance" manual also has details on these procedures.

• SYSPROC.ADMIN_UTL_MONITOR provides functions that enable analysis of database statistics. These functions include issuing alerts for out-of-date, missing or conflicting statistics as well as summary and detailed table-level reports that describe generated RUNSTATS statements.

• SYSPROC.ADMIN_UTL_EXECUTE solves alerts stored in the SYSIBM.SYSAUTOALERTS catalog table. The maintenance windows for these alerts are defined by the SYSIBM.SYSAUTOTIMEWINDOWS catalog table.

• SYSPROC.ADMIN_UTL_MODIFY maintains the SYSIBM.SYSAUTORUNS_HIST and SYSIBM.SYSAUTOALERTS catalog tables, removing all entries in these tables that are older than a configurable threshold. This procedure also removes all entries in SYSIBM.SYSAUTOALERTS that are in COMPLETE state.

Database administrators are always looking for ways to improve application performance. Do you use any of these stored procedures? Have you found them helpful? Please share your experiences in Comments.

DSNTIJNH and Catalog Conversions

This question was recently posted on Linkedin's DB2 10 for z/OS group: “Has anyone tried taking their time to going from DB2 V10 ENFM mode and has issues with vendor tools?”

Of course, all of the vendors in the group (including myself representing CA Technologies) responded by noting that our individual products are tested in ENFM and all other conversion modes. What I found interesting though was IBM's response.

The IBM representative said that install job DSNTIJEN starts the catalog conversion process, converting each of the different catalog table spaces to the DB2 10 format. I'd always considered this a scary step, because you may have a limited window for making catalog. However, the IBM rep noted that you can stop the catalog conversion job at any time by submitting DSNTIJNH, and then resume it where it left off by submitting DSNTIJEN again. The rep further explained that IBM has tested against the catalog by stopping jobs at all phases, and it works fine. So you shouldn't worry about your applications if you need to interrupt a catalog conversion. Just pick it up later when it's convenient.

The install guide (see below) isn't clear on DSNTIJNH's capabilities, so I'm grateful to IBM for making this public comment on Linkedin.

Nonetheless, the DB2 10 for z/OS Installation and Migration Guide does list the various modes that are central to the migration process.

Here are the mode names for DB2 V8-to-DB2 V10 migrations:

• CM8: Conversion mode from Version 8.
• CM8*: Conversion mode* from Version 8.
• ENFM8: Enabling-new-function mode from Version 8.
• ENFM8*: Enabling-new-function mode* from Version 8.
• NFM: New-function mode.

Here are the mode names for DB2 V9-to-DB2 V10 migrations:

• CM9: Conversion mode from Version 9.
• CM9*: Conversion mode* from Version 9.
• ENFM9: Enabling-new-function mode from Version 9.
• ENFM9*: Enabling-new-function mode* from Version 9.
• NFM: New-function mode.

zEC12 and zIIP Processors

Following up on last week's post about the zEnterprise EC12, IBM has just come out with a new Redbook, the "IBM zEnterprise EC12 Technical Guide."

As the title suggests, this publication is technical. However, even if you're not a hardware or OS guru, I think you'll get something out of it, if only for the pictures. No, that's not a putdown of you less technical folk; the illustrations and images that explain the zEC12 technology are really quite interesting. They allow you to see -- as I did -- just what an amazing machine the zEC12 is.

The zEC12 is designed to run z/OS, z/VM, z/VSE, z/TPF, Linux on System z (SUSE Linux and RedHat). On the zBX blades you can run POWER7 hardware with AIX, PowerVM, Linux on System x (SUSE SLES and Red Hat), Windows Server 2008 R2 and Windows Server 2008 SP2 (Datacenter Edition) 64-bit.

Since I work with z/OS and DB2, I’m very interested in specialty processors such as zAAP, zIIP and IFL. The zAAP processor is designed to offload Java workload, zIIP for DB2 workloads (such as DRDA access over TCP/IP, JDBC, ODBC, parallel queries, XML parsing and some DB2 utilities) and IFL for Linux workloads. 

I recently learned that zAAP workloads can run on a zIIP specialty engine if you don't have a zAAP processor. I wasn't sure this has been supported on z/OS, but I searched around and found this great cheat sheet about zAAP and zIIP parameters. Looking at this document I see that z/OS 1.11 provides this support using the parameter, ZAAPZIP=YES. By applying APAR OA27495, you can use parameter zz=YES on 1.9 and 1.10.

All this made me wonder why a customer would buy a zAAP specialty engine when both Java and DB2 workloads can now run on a zIIP. The answer comes in this IBM statement of direction:

"IBM zEnterprise EC12 is planned to be the last high-end System z server to offer support for zAAP specialty engine processors. IBM intends to continue support for running zAAP workloads on zIIP processors (zAAP on zIIP). This is intended to help simplify capacity planning and performance management, while still supporting all the currently eligible workloads. In addition, IBM plans to provide a PTF for APAR OA38829 on z/OS V1.12 and V1.13 in September 2012 to remove the restriction that prevents zAAP-eligible workloads from running on zIIP processors when a zAAP is installed on the server. This is intended only to help facilitate migration and testing of zAAP workloads on zIIP processors."

I’m sure this will greatly help customers plan their hardware upgrades, because it removes the need to guess how much new workload will be Java or how much will be DB2 for z/OS work. Instead of having to purchase another zAAP engine or a zIIP engine, now customers can just buy zIIP engines and know they'll handle both Java and DB2 workloads.