From my colleague, Jim Herrmann:

The Central Ohio DB2 Users Group (CODUG) no longer exists, but we are taking action to bring it back as a tremendous resource for the community and an amazing opportunity for leadership. CODUG is going to be a great DB2 regional users group because the members of the central Ohio DB2 community are going to make it so.

We are going to start out with all of you being a valuable contribution to your community by completing the RSVP for the June 25th, where you will have the ability to choose the presentations that you want to see from our amazing speakers. Use the URL below:

http://goo.gl/mpWT0

The short URL above links to a Google Docs form, which some company firewalls block, in which case you will need to make the extra effort of forwarding and filling out the form from home. Your input is essential to the success of the group. Whether you are planning to come on 6/25 or not, please fill out the form with your information and your vote. It’s free and it puts you in direct communication with the new CODUG!

You would be a further contribution to your friends and coworkers who have built their careers around DB2, on any platform, if you forward this message to them to make certain that they know about this amazing kickoff meeting. Don’t worry about them getting multiple copies, worry about them getting none. Forward this message now, while you’re thinking about it. If you wait, you will forget to do it later, and you will have missed the chance to connect someone to their community.

The meeting will be formatted with a single track in the morning and two tracks in the afternoon, one for DB2 z/OS and one for DB2 LUW. We will actually physically split the room at the lunch break. We have three well known names in the world of DB2 who will be presenting at the meeting. The bios of these three awesome individuals you can find after the attached agenda.

We are building towards an amazing day. Fill out the form, share it, and we will be one step closer to creating something powerful in our lives.

Thank you for your time and your commitment to DB2,
Please don’t forget to join us at Facebook and Linkedin to get to know about future activities at CODUG.
Linkedin group:  http://www.linkedin.com/groups/CODUG-Central-Ohio-DB2-Users-5014603/about
Facebook page: https://www.facebook.com/CODUG
Agenda

09:00 – 09:30    CODUG Possibility (Jim Herrmann)
09:30 – 10:00    IBM Announcements (Monte Bauman)
10:00 – 10:15    Break
10:15 – 11:30    “DB2 101” or “I didn’t know IBM Information Management could do that!” (Frank Fillmore)
11:30 – 12:45    Lunch
12:45 – 14:15    First afternoon presentation block (Scott Hayes and Robert Catterall)
14:15 – 14:30    Break
14:30 – 16:00    Second afternoon presentation block (Scott Hayes and Robert Catterall)

Frank C. Fillmore, Jr., DB2 Gold Consultant and IBM Champion, is the Founder and President of The Fillmore Group, Inc., a Premier IBM Business Partner that specializes in Information Management (IM) software sales, consulting, and training.  Frank has appeared on the IDUG Experts Panel and frequently presents to customers and local DB2 users groups.  Franks 25 years of field experience spans IBMs Information Integration, Data Governance, Data Warehousing, and Big Data portfolios. Read More…

A few weeks ago a customer was confronted with a common challenge.  They had to move terabytes of data – billions of rows – from DB2 for LUW to DB2 for z/OS.  I suggested a “cursor-based load” (aka the “cross-loader”).  This DB2 for z/OS DBA team is top-notch, with centuries of collective experience, but I mostly was met with blank stares.  So here’s the brief refresher (or introduction) I gave them on the cross-loader.

The common method for moving data from DB2 for LUW tables to DB2 for z/OS could be a serial process where the data is

1. extracted from DB2 for LUW
2. transported to the z/OS platform
3. loaded into DB2 for z/OS

This can be done as three discrete steps in a variety of ways.  The problem with three discrete steps is the I/O overhead of landing the data to disk three times: to the local extract file, FTPed to z/OS, loaded into DB2.  In addition, the steps are serial (e.g. the extract must complete before the FTP can begin).

 An alternative is using a cursor-based LOAD (aka the “cross-loader”).  The cross-loader has been available in DB2 for z/OS since v7.

 Steps to enable the cross-loader:

1. Set up DRDA definitions in the DB2 Communications Database (CDB) in the DB2 for z/OS subsystem that will be running the loads (i.e. the “target”).
2. Create DB2 for z/OS nicknames for the tables to be loaded from the DB2 for LUW source.

In the example below the table PAOLOR7.DEPT is a nickname.  The LOAD utility jobs can be scheduled to minimize the impact on production workloads.

This would be relatively easy to set up and test in a development environment.   This is the fastest, easiest, simplest way to move the data to z/OS.  This method will also use the least machine resources.

References for cursor-based load

DB2 10 for z/OS Information Center “Loading data by using the cross-loader function”

Redbook “Moving Data Across the DB2 Family”

Read More…

Frank is attending IDUG in Orlando this week to present on one of our favorite new IBM Information Management solutions, Query Capture Replay (QCR).  If you are heading to Florida this week, please say hi to Frank and join him on Thursday, May 2nd, from 3:30pm – 4:30pm in Bonaire 7&8 for his session.  

“Don’t Guesstimate! Migration Testing with Query Capture Replay”

This presentation focuses on several migration use cases for IBM’s new InfoSphere Optim Query Capture and Replay tool, announced in 2012. Query Capture and Replay (QCR) enables users to capture database activity on a production database and run it to analyze and evaluate the performance when changes – to SQL, hardware, operating system software and even the underlying database – are completed. It’s a great new migration tool.

Thank you to all of the customers, colleagues, and IBMers who joined The Fillmore Group on April 11, 2013 at Cinghiale in Baltimore, USA to discuss IBM’s Data Strategy – which we call “DB2 101″.  As it happens, many DB2 customers don’t realize the strength and depth of the IBM Information Management portfolio.  And many non-DB2 customers don’t know about the governance and management tooling available in InfoSphere and Optim (e.g. Guardium) which IBM provides for Oracle, SQL Server, Teradata, and other-vendor database servers.

Prominently featured were the highlights of IBM’s April 3rd announcement held at Almaden Lab which my colleague, Kim May, and I attended.

• PureData System for Hadoop
• DB2 for LUW V10.5 with BLU Acceleration

Also of note is the bundling of functionality in DB2 Advanced Enterprise Server Edition (AESE).

1. pureScale – shared-disk clustering
2. Data Partitioning Feature (DPF) – shared-nothing hash partitioning
3. DB2 for LUW v10.5 columnar compression database

The presentation is available at DB2 101 – IBM Information Management Software Portfolio Overview 2013-04  The audio-video recorded delivery can be viewed here.

Friend, colleague, and DB2 Gold Consultant Sheryl Larsen is joining IBM on April 22, 2013 and will become the “new Roger Miller” according to an IBM executive.  Best wishes to Sheryl in her new gig!

Separated at birth?

IBM has bundled its replication technology into a single package: IBM InfoSphere Data Replication (IIDR).  IIDR combines three components:

• SQL Replication (heritage DataPropagator- Relational)
• Easy to set up
• Staging tables
• InfoSphere Replication Server (IRS – heritage Q Replication)
• High volume, low latency
• Native Oracle and DB2 sources and targets
• WebSphere MQ transport layer
• InfoSphere Change Data Capture (ICDC – heritage DataMirror)
• Broadest set of heterogeneous sources and targets
• TCP/IP transport layer

There are a few of important take-aways.

1. IBM substituted an implementation decision for a buying decision.  For quite a while SQL Replication was bundled free with DB2 for LUW.  ICDC and IRS were separately purchasable technologies with a lot of functional overlap.  In 2010 my colleague, Kim May, delivered an IBM Information on Demand (IOD) presentation distinguishing between the three.  Now you purchase the IIDR bundle and determine which technology is best suited for a particular use case.  As with most IBM software on distributed platforms, the cost is based on Processor Value Units (PVUs).
2. New feature/functionality will be built into IIDR rather than the former heritage ICDC and IRS packaging.
3. There will be a convergence of the technologies over time.  Many of the prospective changes are still IBM Confidential, but IBM is looking to consolidate components where it makes sense to do so.  There is a long-term roadmap that I hope IBM be sharing shortly.
4. Upgrading and migration paths are a work-in-progress.  If you currently own ICDC or IRS and want to move up to IIDR, contact The Fillmore Group for pricing and implementation assistance.

A couple months ago I was the lucky winner of an IBM contest for Information Management Business Partners.  The prize was space in the IBM Data Management magazine (now online at www.ibmdatamag.com) and assistance writing an article on a topic of interest.  The article is being published today and can be viewed here.

As The Fillmore Group was recently asked to begin delivering IBM Authorized Education on IBM’s big data solutions, BigInsights and InfoSphere Streams, we decided to leverage the article to promote our upcoming classes.

There is always terrific content in the magazine.  I hope you enjoy the article and consider taking a formal class to learn more about IBM’s big data solutions.

Frank is putting the final touches on his DB2 101 presentation for Thursday, incorporating last week’s Big Data announcements from IBM (great stuff; visit the IBM Big Data Hub to learn more) along with his fast-paced presentation on the solutions in the IBM Information Management portfolio.  We are expecting a great turnout but as always, we are happy to make room for more.  If you are in the Baltimore area and interested in joining us, please read my post on the event here, register here and join us.

Frank and I were invited to the IBM Almaden Research Center, where the magic really happens for IBM’s data solutions, for the Big Data announcements yesterday.  We had the opportunity to meet with a group of super-sharp analysts and members of the IBM technical leadership teams for the BLU Acceleration, Big Data and Hadoop appliance announcements. 

Most fun for me, though, was getting to spend some time with Crysta Anderson, the IBM Social Media Strategist for Information Management.  Crysta, along with Susan Visser, coordinated the efforts of (or perhaps more accurately, herded) literally hundreds of DB2 community members, including DB2 Gold Consultants, analysts, and Information Champions, to get us to tweet, blog and spread the word to the IT community about IBM’s incredible advancements.  The fingers were flying during yesterday’s announcements!

I am back in Baltimore today planning some upcoming events to make sure we share what we learned…and I’m sure Crysta is exhausted.  And thrilled, I hope – congratulations on a successful launch!

One of the challenges of Big Data is, well, its bigness.  There are two approaches you should consider – one fairly new, the other not yet delivered – for your data volume issues on DB2 for z/OS.

The first technique exploits the IBM DB2 Analytics Accelerator (IDAA).  IDAA is a Netezza (now PureData System for Analytics) appliance lashed together with DB2 for z/OS using a high-speed connection.  The same data typically resides in both DB2 and Netezza.  The DB2 optimizer determines if a particular dynamic query can be addressed at a lower cost by offloading that query to Netezza.

Until November 2012, all of the data needed to be present on both Netezza and DB2.  In IDAA version 3, that restriction has been removed.  The attached presentation describes offloading older data to the Netezza and eliminating it from DB2.  In a common use case the most current data (say, the last 30 days) remains in DB2, but older data (days 31 to the preceding 2 years) reside *only* in Netezza.  This is called the High Performance Storage Saver (HPSS).  IDAA HPSS

Based on the cost of mainframe DASD storage and other factors, it might be less expensive to store stale data in a “hot” back-end like the Netezza part of an IDAA than to continue to store that data natively in DB2 for z/OS.  From an API standpoint, you run your queries as if all of the data resides locally in DB2 for z/OS.  That way you can change which data reside in each of the IDAA components with out impacting applications or SQL changes.

The second technique exploits temporal data functionality delivered in DB2 10 for z/OS.  Temporal tables enable you to see values for attributes of a particular business object (account, part, employee, customer, etc.) at a specific point-in-time (PIT).  As SQL UPDATEs are processed against a transaction table, deltas are recorded in a history table associated with the transaction table.  That way you can issue a query like:

SELECT coverage_amt FROM policy FOR SYSTEM_TIME AS OF '12-01-2010' WHERE id = 111

and see the coverage_amt at a point-in-time regardless of any intervening changes.  DB2 11 for z/OS – not yet Generally Available (GA), but in beta with Early Support Program (ESP) customers – builds on this technology by extending it to “archive” data.  The use case is the same as the one described above: for processing efficiency you want the last 30 days of transaction data to reside in one DB2 table and older data (days 31 to the preceding 2 years) to be stored in another.  Think insurance claims: most activity regarding a claim occurs within the first 30 days of a loss.  But for business and compliance reasons, you want to retain up to 2 years of data on spinning disks; even older data might be kept on offline storage.  Using this technique, all of the data resides natively in two different DB2 for z/OS tables (current and archive).  The benefit this time is segregating commonly accessed data for processing efficiency.  As was the case with IDAA/HPSS, the location of the data is transparent to the SQL.  You write the query for the data you want and DB2 determines whether it resides in the current data table, archive table, or both.

In summary