Turn the "page" with SQL on IBM i.

After a much too busy summer, I've returned to put pen to paper and write another "What's New in DB2 for i" article. Between my time working directly with our development and test teams in Rochester, Minnesota, and Beijing, China, I have had an opportunity to be a speaker at different user groups. While I disdain the preparation required for these trips, the events themselves are fun and enlightening. It's great to hear firsthand what customers and software providers think of the many and frequent enhancements to database. Even better, I usually leave with one or two shiny gems of an idea for the next Technology Refresh (TR) cycle.

With the announcement of IBM i 7.1 Technology Refresh (TR) 11 and IBM i 7.2 Technology Refresh (TR) 3, IBM has attempted to answer some basic questions:

• Why should I care?
• What can I do differently?
• How does this help me?

These questions might seem painfully vapid, but they're actually an essential part of achieving our goal of having you adopt these new and improved technologies. I am willing to be reasonable and accept that not every enhancement you're about to discover below will amaze you. Hopefully, your time investment of reading this article will result in some interest or curiosity to explore the latest and greatest from DB2 for i. All of the enhancements are being delivered to both IBM i 7.1 and 7.2, so the lion's share of clients should be able to use these soon.

How do you take the next step? Utilize the IBM i TR11 and TR3 landing pages within the IBM developerWorks - IBM i Technology Updates wiki to see the technical and software delivery details:

• http://www.ibm.com/developerworks/ibmi/techupdates/i72-TR3
• http://www.ibm.com/developerworks/ibmi/techupdates/i71-TR11

For those who read my article on database enhancements delivered with TR2, have you tried out CREATE OR REPLACE TABLE or the DB2 JSON Store? Drop me a line if you have comments, compliments, or other.

Similar to previous TR cycles, there's an eclectic mix of enhancements. I'll cover a subset of the enhancements in this article. Full details can be found on developerWorks.

Figure 1: Here's the DB2 for i enhancement timeline (updated for TR3/TR11).

LIMIT and OFFSET

The best practice for using SQL is to embrace "Set at a time" processing, where you make one trip to the database and ask the SQL Query Engine (SQE) a complete question. Typically, the assumption is that you intend to consume every row returned from a complete query. With the addition of the offset clause, the SQL programmer can skip some number of rows in the query result before having rows returned. The offset clause is optional and the default behavior is equivalent to OFFSET 0 ROWS, which simply means that zero rows are skipped.

By having this skip control, it becomes simple to logically page through a result set without keeping the result set open over a long and comprehensive processing cycle. Even though the offset row count can be specified by a literal value, the more likely use case would be to supply the value at runtime via a declared variable, host variable, or parameter marker. This support gives the SQL programmer a means to page through rows of data. How big is a page? You get to decide the page size through the use of the fetch-first clause, which now supports LIMIT x as a syntax alternative to FETCH FIRST x ROWS ONLY. Just like OFFSET and LIMIT, the FETCH FIRST x ROWS ONLY will now accept a declared variable, host variable, or parameter marker. Figure 2 shows the syntax alternatives that are permitted.

We have a couple restrictions in our delivery of this support:

• Neither LIMIT, OFFSET, nor FETCH FIRST x ROWS ONLY allow a global variable to be used for the value.
• The offset clause can be used only as part of the outer fullselect.
• LIMIT and OFFSET are not supported on the green-screen STRSQL interface.

Figure 2: LIMIT and OFFSET are added to DB2 for i.

Whether you're coding in a stateless, mobile, or traditional model, look to use OFFSET (and LIMIT) to produce advanced SQL solutions. Figure 3 includes a working example of using OFFSET and LIMIT within an SQL procedure with dynamic SQL and parameter markers. The procedure is constructed to allow the caller to determine the number of rows that are skipped via OFFSET. Further, the LIMIT clause controls the number of rows that are returned, after offsetting to the appropriate row.

Figure 3: This is an example of LIMIT and OFFSET.

We have other SQL programming enhancements, but in the interest of brevity, I'll press on to the next topic area.

Performance

My development team works on database performance every day. Sometimes, we can make changes to allow existing workloads to run faster, with no changes needed by the customer. Other times, we create an improvement that is something you need to "choose to use." In this TR, we have two examples of the latter.

In Figure 4, you see some of the details begin to appear.

• EVI Only Access is an improvement to how the IBM patented Encoded Vector Indexes (EVIs) can be costed and used by SQE. More on that topic in a moment.
• Improved code generation pertains to LANGUAGE SQL procedures, functions and triggers. With this enhancement, we have more SQL statements that can be implemented using inlined ILE C code, instead of making a full-fledged trip to the database for that SQL statement. In general, it can be worthwhile to periodically rebuild your performance critical SQL routines and triggers. What do you risk in rebuilding? Nothing, as long as you have a stable build process.

Figure 4: This TR offers database performance and availability enhancements.

There's also an availability improvement delivered for SAP on i clients. Any SAP client that has encountered SQL package (*SQLPKG) full conditions has the option of using a new QAQQINI control to direct the database to expunge the access plans for low use/no reuse SQL statements. QUSRSYS is shown in the example because that's the version of the QAQQINI file that will be used by any SAP activity that doesn't have a dedicated QAQQINI file.

EVI Only Access

Encoded vector index (EVI) support is extended to allow these types of indexes to be eligible to be used in not only selection of rows, but also projection of column values. We coined the term "EVI Only Access" because with this enhancement, SQE has more options for index "only" implementation. Such implementations tend to perform better because they don't have to touch as many pages in storage.

If you're responsible for the indexing strategy, you should consider using a couple resources to help you along the way.

• White paper: "IBM DB2 for i indexing methods and strategies"
• DB2 for i SQL Performance Workshop: ibm.biz/SQLPerfWorkshop

Figure 5 provides the first bits of information you need about EVI Only Access. Of course, there's more information to share, and we'll have that in developerWorks. As you can see from the slide, we were able to use traditional EVIs (for selection in the WHERE clause) in combination with EVIs created over the columns referenced in the SELECT (for projection). In some workloads, this resulted in a noteworthy performance improvement. Like everything related to performance, there are many factors to consider and results vary.

Figure 5: EVI Only Access is a new enhancement.

Governance of Data

The burden of knowledge usually corresponds with some sort of additional action. Since business-critical data resides upon DB2 for i and sensitive data access needs to be closely monitored, IBM i clients should be embracing a model of continual investment for governance of data. This is a topic where "more" can always be done. For you decision-makers out there, do you have a data governance strategy? If anyone answered no, connect with me at a conference or directly via email.

I've worked with friends and colleagues on the Guardium team for a good number of years to build and promote IBM Security Guardium for DB2 for i clients. Why? Because the solutions that have been created and extended contain unique value. Is Guardium a good fit for your business? The answer depends on your strategy and requirements.

With the latest TR, Guardium on IBM i makes some noteworthy strides forward:

• First and foremost, a new version of Guardium is available. With V10, Guardium's user interface is enhanced and new features are delivered.
  Do you have five minutes for an elevator pitch on this topic? If so, listen to Kathy Zeidenstein's overview video.
• If you're specifically focused on Guardium for Database Activity Monitoring (DAM), the V10 enhancements are explained in depth here.
• DAM customers get a variety of improvements. Improved filtering and multiple policy capabilities are available from a native IBM i configuration. Also supported are solutions for encrypted communication with the Guardium collector, load balancing of activity data across collectors. and failover configuration capability to handle unexpected outages.
• Last, but certainly not least, V10 contains the delivery of Guardium Vulnerability Assessment (VA) for IBM i. VA provides a set of security assessments that are uniquely constructed for the IBM i client.

Figure 6: Guardium and DB2 for i are great together.

New (and Enhanced) IBM i Services

The drum continues to beat on IBM i Services. While some clients don't have a use for this capability, many others are jumping on board and using these services to achieve solutions in short time. We had a fun summer working on new services. With some new team members arriving, it seemed like a natural fit to build one or two new services. By the end of the summer, we realized that one or two had turned into 15 new services and 5 enhanced services!

The new IBM i Services come in two forms: Views and User-Defined Table Functions (UDTFs). If you care about any of the following IBM i topics, take some time to evaluate our services and find ways to utilize them:

• Group PTF
• TCP/IP
• Work Management
• License Information
• Spool

With 20 services to cover, I can touch on only a couple in this article. Refer to Figure 7 to see the most of the new services. The names ending with "()" are UDTFs; all the others are views. For full details, look here.

If you want a DB2 for i poster for your desk, see me at a conference for free signage or print your own by looking here.

Figure 7: New IBM i Services abound!

Figure 8 shows a combination of old and new. The SYSTOOLS.GROUP_PTF_CURRENCY view is something you already have, and it uses DB2 for i to query the IBM Preventative Service Planning live webpages and SQE to compare the IBM live detail with the PTF Group detail for the partition where the query is executing. The result is a simple and useful assessment of PTF Group levels versus what IBM has available.

The new service is SYSTOOLS.GROUP_PTF_DETAILS, and it takes the insight to the next level. Like the other service, live XML feeds are interrogated real-time and compared against the individual PTF details on the current partition. The result is a comprehensive assessment of PTF currency. This could be particularly useful when determining whether a partition has the latest Java, Security, HIPER, or other PTF Group installed.

Figure 8: The new Group PTF service is very handy.

One indication of customer adoption is to measure the number of requests for incremental enhancement. As Figure 9 illustrates, we have a number of enhancements to existing services. I'll mention only the service below the line on the figure. The SET_SERVER_SBS_ROUTING() service provides something that cannot be accomplished through other interfaces. Through a simple call to this procedure, you can configure users or groups to utilize subsystems of your choice for Database server (QZDASOINIT), DRDA and DDM (QRWTSRVR), and now Remote Command (QZRCSRVS) server jobs.

Figure 9: The new TR offers many enhanced IBM i Services.

The last services example I'll share with you is QSYS2.LICENSE_INFO. This view returns live data that would normally be found by using the Work with License Information (WRKLICINF) command. This command does not include Output file support, making it harder to consume programmatically. The example in Figure 10 shows that SQL can take this interaction to the next level through the use of time arithmetic. It's very simple to assess the license expiration posture on a partition using SQL, now that you have LICENSE_INFO.

Figure 10: QSYS2.LICENSE_INFO provides licensing information.

My last topic for this article comes in the form of IBM i Navigator for the database user. With this TR cycle, the IBM i Access Client Solutions (ACS) product is extended to include some database functionality formerly found only in IBM i Access for Windows.

In Figure 11, you get the first glimpse of what's new. We've established a new "Database" section within ACS. In that section, you'll find two features:

• Run SQL Scripts
• SQL Performance Center

Figure 11: DB2 for i and Navigator have new enhancements too.

Run SQL Scripts in ACS is exciting because it brings a Java-based solution to our customers. The fun doesn't stop there because Run SQL Scripts in ACS has some unique features, like color highlighting, faster start-up, and other usability features.

Figure 12: Run SQL Scripts is new in ACS.

The SQL Performance Center contains tabs to access DB2 for i performance artifacts:

• SQL Performance Monitors trace database applications.
• SQL Plan Cache Snapshots contain a point-in-time capture of queries executed.
• SQL Plan Cache Event Monitors contain details for those queries that have been removed (pruned) from the plan cache.

For all three of these payloads, you can use ACS to analyze the contents and details. ACS does not contain all the functionality yet (e.g., Visual Explain), but see what you think. So far, I love the improved performance, rendering, sorting, column customization, and more.

Figure 13: Check out the SQL Performance Center in ACS.

Turn the Page…

Now I need to turn the page and move onto other tasks. I hope you do the same by using our new OFFSET support. As always, I'm interested in hearing from you. If you've had success using DB2 for i enhancements, drop me a note with an example. Until next time, Scott.