63

The internals of DB2 and the way it is used have changed over the years although sometimes the methods and rules of thumb we use to monitor it haven’t kept pace. This session will take a look at some of the metrics we should be monitoring, explain why and, where appropriate, suggest credible thresholds you should be implementing to help you proactively monitor your subsystems and data sharing groups. Helping you catch issues before they turn into real pain.

The majority of the data stored in many OLTP systems is relatively old. It doesn’t change much and may be referenced only rarely but must be retained for many years, usually to satisfy compliance or regulatory requirements. Keeping this data in the main database tables can cause Performance problems as well as an increase in Storage costs. We all know it should really be archived or at least moved to different tables than the more active rows. However the drive to implement new systems quickly usually means that implementing an archiving policy is either simply dropped or at best relegated to a later phase of Development which frequently never gets funding as it doesn’t show immediate and obvious value to the business. Up to now apart from a few products nothing has been available to assist, but in the last year or two DB2 has provided two alternative solutions to the Archiving problem. This session will describe how the DB2 Transparent Archiving feature introduced in DB2 11 for z/OS and the High Performance Storage Saver feature of the DB2 Accelerator for z/OS 3.1 and 4.1, both of which support DB2 10 for z/OS, can be used to automate the archiving of old data. Depending on what you need to do and how your data is organized it may even be possible to implement archiving into an existing system with little or no changes to the application code.

• DB2 tracing mechanism
• Most useful trace data and related use cases
• New trace information in DB2 11

Dynamic SQL dominates modern applications and ensuring its optimal execution is very high on the list of DBA tasks. Of course, successful tuning of dynamic SQL depends on efficient monitoring. This presentation provides a deep insight into available monitoring techniques offered by DB2 for z/OS. The attendees will learn numerous hints and tips about how to monitor dynamic SQL, what are the most relevant performance indicators and how to collect them in the most efficient way.

The attendee will get a deep dive into all the DDL changes needed in order to exploit DB2 V10 Temporal tables as well as the limitations. A case study scenario using a live DB2 V10 system will be used to illustrate how the data is versioned and how the application needs to understand what to request in order to get the desired data. Finally we will look at which currently implemented solutions can be modified to use Temporal tables 

• Native vs. external SQL procedures
• Description of external procedures
• Description of native SQL procedures
• Language construction
• Other RDBMS
• Ways of defining a native SQL procedure
• Versioning
• Execution of a native SQL procedure (Performance considerations)
• Invoking / Calling, testing, nesting
• Error handling and debugging
• Migrating external to native SQL procedures
• Sum up

This is an updated session from one I gave a couple of years ago at SQLAdria. It will provide a refresher outlining the benefits, and potential pitfalls, of Big Data along with a look at some of the latest ways that DB2 is getting in the Big Data act. It will cover the latest advances in the DB2 Accelerator Engine as well as delve intp how DB2 11 has simplified the use of JSON to open DB2’s horizons to further data sources.