Just a short blog today to promote the upcoming IBM Information on Demand conference. This is one of the biggest data-focused conferences of the year - certainly the biggest for users of IBM data management technology. Last year, over 10,000 folks attended the show and expect for that number to grow this year.
The theme of the event is "Big Data. Unique perspectives." so you can expect some timely information from IBM on their Big Data and analytics offerings. And as those of you who are mainframe DB2 users know, IBM launched a new version of DB2 for z/OS - Version 11 - just last week. So there should be a lot of good new information about the latest and greatest version of DB2.
The event is composed of four forums focusing on 1) business analytics, 2) information management, 3) enterprise content management, and 4) business leadership.
I'm looking forward to attending the conference - as well as delivering a presentation on Wednesday, November 6th titled Understanding the rolling four hour average to control DB2 costs.
If you're not planning on being there, you should reconsider! And if you are planning on being there, hunt me down and say "Hi!"
Here is the web page for more information on the Information on Demand 2013 conference.
Thursday, October 31, 2013
Friday, October 25, 2013
Say "Hello" to DB2 11 for z/OS
DB2 11 for z/OS
Generally Available Today, October 25, 2013
As was announced earlier this month (see press release) Version 11 of DB2 for z/OS is officially available as of today. Even if your
company won’t be migrating right away, the sooner you start learning about DB2
11, the better equipped you will be to embrace it when you inevitably must use
and support it at your company.
So let’s take a quick look at some of the highlights of this
latest and greatest version of our favorite DBMS. As usual, a new version of
DB2 delivers a large number of new features, functions, and enhancements, so of
course, not every new DB2 11 “thing” will be addressed in today’s blog entry.
Performance Claims
Similar to most recent DB2 versions, IBM boasts of
performance improvements that can be achieved by migrating to DB2 11. The
claims for DB2 11 from IBM are out-of-the-box savings ranging from 10 percent
to 40 percent for different types of query workloads: up to 10 percent for complex
OLTP and update intensive batch – up to 40 percent for queries.
As usual, your actual mileage may vary. It all depends upon things
like the query itself, number of columns requests, number of partitions that
must be accessed, indexing, and on and on. So even though it looks like
performance gets better in DB2 11, take these estimates with a grain of salt.
The standard operating procedure of rebinding to achieve the
best results still applies. And, of course, if you use the new features of DB2
11 IBM claims that you can achieve additional performance improvements.
DB2 11 also offers improved synergy with the latest
mainframe hardware, the zEC12. For example, FLASH Express and pageable 1MB
frames are used for buffer pool control blocks and DB2 executable code. So keep
in mind that getting to the latest hardware can help out your DB2 performance
and operation!
Programmer Features
Let’s move along and take a look at some of the great new
features for building applications offered up by DB2 11. There are a slew of
new SQL and analytical capabilities in the new release, including:
- Global variables – which can be used to pass data from program to program without the need to put data into a DB2 table
- Improved SQLPL functionality, including an array data type which makes SQLPL more computationally complete and simplifies coding SQL stored procedures.
- Alias support for sequence objects.
- Improvements to Declared Global Temporary Tables (DGTTs) including the ability to create NOT LOGGED DBTTs and the ability to use RELEASE DEALLOCATE for SQL statements written against DGTTs.
- SQL Compatibility feature which can be used to minimize the impact of new version changes on existing applications.Support for views on temporal data.
- SQL Grouping Sets, including Rollup, Cube
- XML enhancements including XQuery support, XMLMODIFY for improved updating of XML nodes, and improved validation of XML documents.
The first new capability is
the addition of the APREUSE(WARN) parameter. Before we learn about the new
feature, let’s backtrack for a moment to talk about the current (DB2 10)
capabilities of the APREUSE parameter. There are currently two options:
- APREUSE(NONE): DB2 will not try to reuse previous access paths for statements in the package. (default value)
- APREUSE(ERROR): DB2 tries to reuse previous access paths for SQL statements in the package. If the access paths cannot be reused, the operation fails and no new package is created.
So you can
either not try to reuse or try to reuse, and if you can’t reuse when you try
to, you fail. Obviously, a third, more palatable choice was needed. And DB2 11
adds this third option.
- APREUSE(WARN): DB2 tries to reuse previous access paths for SQL statements in the package, but the bind or rebind is not prevented when they cannot be reused. Instead, DB2 generates a new access path for that SQL statement.
DBA and Other
Technical Features
There are also a slew of new in-depth technical and DBA-related
features in DB2 11. Probably the most important, and one that impacts
developers too, is transparent archiving using DB2’s temporal capabilities first
introduced in DB2 10.
Basically, if you know how to set up SYSTEM time temporal
tables, setting up transparent archiving will be a breeze. You create both the table
and the archive table and then associate the two. This is done by means of the ENABLE
ARCHIVE USE clause. DB2 is aware of the connection between the operational
table and the archive table, so any data that is deleted will be moved to the
archive table.
Unlike SYSTEM time, only
deleted data is moved to the archive table. There is a new system defined
global variable MOVE_TO_ARCHIVE to control the ability to DELETE data without
archiving it, should you need to do so.
Of course, there are more details to learn about this
capability, but remember, we are just touching on the highlights today!
Another notable feature that will interest many DBAs is the
ability to use SQL to query more DB2 Directory tables. The list of DB2
Directory tables which now can be accessed via SQL includes:
- SYSIBM.DBDR
- SYSIBM.SCTR
- SYSIBM.SPTR
- SYSIBM.SYSLGRNX
- SYSIBM.SYSUTIL
Another regular area of improvement for new DB2 version is
enhanced IBM DB2 Utilities, and DB2 11 is no exception to the rule. DB2 11
brings the following improvements:
- REORG – automated mapping tables (where DB2 takes care of the allocation and removal of the mapping table during a SHRLEVEL CHANGE reorganization), online support for REORG REBALANCE, automatic cleanup of empty partitions for PBG table spaces, LISTPARTS for controlling parallelism, and improved switch phase processing.
- RUNSTATS – additional zIIP processing, RESET ACCESSPATH capability to reset existing statistics, and improved inline statistics gathering in other utilities.
- LOAD – additional zIIP processing, multiple partitions can be loaded in parallel using a single SYSREC and support for extended RBA LRSN.
- REPAIR – new REPAIR CATALOG capability to find and correct for discrepancies between the DB2 Catalog and database objects.
- DSNACCOX – performance improvements
DB2 11 also delivers a bevy of new security-related enhancements,
including:
- Better coordination between DB2 and RACF, including new installation parameters (AUTHEXIT_CHECK and AUTHECIT_CACHEREFRESH) and the ability for DB2 to capture event notifications from RACF
- New PROGAUTH bind plan option to ensure the program is authorized to use the plan.
- The ability to create MASKs and PERMISSIONs on archive tables and archive-enabled tables
- Column masking restrictions are removed for GROUP BY and DISTINCT processing
An additional online schema change capability in DB2 11 is
support for online altering of limit keys, which enables DBAs to change the
limit keys for a partitioned table space without impacting data availability.
Finally, in terms of online schema change, we have an
improvement to operational administration for deferred schema changes. DB2 11
provides improved recovery for deferred schema changes. With DB2 10, when the REORG
begins to materialize pending change it is no longer possible to perform a recovery
to a prior point in time. DB2 11 removes this restriction, allowing recovery to
any valid prior point.
In terms of Buffer Pool enhancements, DB2 11 offers up the new
2GB frame size for very large BP requirements.
In terms of Data Sharing enhancements, DB2 11 offers faster
CASTOUT, improved RESTART LIGHT capability, and automatic recovery of all pages
in LPL during a DB2 restart.
Analytics and Big
Data Features
There are also a lot of features added to DB2 11 to support
Big Data and analytical processing. Probably the biggest is the ability to
support Hadoop access. If you don’t know what Hadoop is, this is not the place
to learn about that. Instead, check out this link.
Anyway, DB2 11 can be used to enable applications to easily
and efficiently access Hadoop data sources. This is done via the generic table
UDF capability in DB2 11. Using this feature you can create a variable shape of
UDF output table.
This capability allows access to BigInsights, which is IBM’s
Hadoop-based platform for Big Data. As such, you can use JSON to access Hadoop
data via DB2 using the UDF supplied by IBM BigInsights.
DB2 11 also adds new SQL analytical extensions, including:
- GROUPING SETS can be used for GROUP BY operations to enable multiple grouping clauses to be specified in a single statement.
- ROLLUP can be used to aggregate values along a dimension hierarchy. In addition to aggregation along the dimensions a grand total is produced. Multiple ROLLUPs can be coded in a single query to produce multidimensional hierarchies in a result set.
- CUBE can be used to aggregate data based on columns from multiple dimensions. You can think of it like a cross tabulation.
- The ability to store 1.3 PB of data
- Change Data Capture support to capture changes to DB2 data and propagate them to IDAA as they happen
- Additional SQL function support for IDAA queries (including SUBSTRING, among others, and additional OLAP functions).
- Work Load Manager integration
Of course, there are additional features and functionality
being introduced with DB2 11 for z/OS. A blog entry of this nature on the day
of GA cannot exhaustively cover everything. That being said, two additional
areas are worth noting.
- Extended log record addressing – increases the size of the RBA and LRSN from 6 bytes to 10 bytes. This avoids the outage that is required if the amount of log records accumulated exhausts the capability of DB2 to create new RBAs or LRSNs. To move to the new extended log record addressing requires converting your BSDSs.
- DRDA enhancements – including improved client info properties, new FORCE option to cancel distributed threads, and multiple performance related improvements.
Tuesday, October 15, 2013
Using the DISPLAY Command, Part 5
Today’s entry in our series on the DB2 DISPLAY command is the
fifth – and final – edition of the series. We’ll wrap up coverage by briefly discussing the
remaining features of DISPLAY. And, just as a reminder:
- Part 1 of this series focused on using DISPLAY to monitor details about you database objects;
- Part 2 focused on using DISPLAY to monitor your DB2 buffer pools;
- Part 3 covered utility execution and log information;
- And Part 4 examined using the DISPLAY command to monitor DB2 stored procedures and user-defined functions.
Additional
Information that DISPLAY Can Uncover
Distributed
Information
The DISPLAY command can be quite useful in distributed DB2 environments.
You can use DISPLAY DDF to show DDF configuration and status information, as
well as statistical details on distributed connections and threads. An example of the output from issuing DISPLAY
DDF:
DSNL081I
STATUS=STOPDQ
DSNL082I
LOCATION LUNAME GENERICLU
DSNL083I
STLEC1 -NONE.SYEC1DB2 -NONE
DSNL084I
TCPPORT=446 SECPORT=0 RESPORT=5001 IPNAME=-NONE
DSNL085I
IPADDR=NONE
DSNL086I
SQL DOMAIN=-NONE
DSNL090I
DT=A CONDBAT= 64 MDBAT= 64
DSNL092I
ADBAT= 0 QUEDBAT= 0 INADBAT= 0 CONQUED= 0
DSNL093I
DSCDBAT= 0 INACONN= 0
DSNL105I
DSNLTDDF CURRENT DDF OPTIONS ARE:
DSNL106I
PKGREL = COMMIT
DSNL099I DSNLTDDF DISPLAY DDF REPORT
COMPLETE
Additionally, DISPLAY LOCATION can be used to show
information about distributed threads.
Data Sharing
Information
For data sharing, the DISPLAY GROUP command can be used to
display information about the data sharing group (including the version of DB2
for each member); and DISPLAY GROUPBUFFERPOOL can be used to show information
about the status of DB2 group buffer pools.
Profile
Information
If you have started using PROFILEs in DB2 10 (or later), the
DISPLAY PROFILE command allows you to determine if profiling is active or inactive.
The status codes that can be returned by this command are as follows:
- ON Profiling is active.
- OFF Profiling is inactive.
- SUSPENDED Profiling was active, but is now suspended due to error conditions.
- STARTING Profiling is being started, but has not completed.
- STOPPING Profiling has been stopped, but has not completed.
Resource
Limit Information
If you use the Resource Limit Facility, the DISPLAY RLIMIT
command can be used to show the status of the RLF, including the ID of the
active RLST (Resource Limit Specification Table).
Thread
Information
To display information about a DB2 thread connection or all
connections, use the DISPLAY THREAD command. A DB2 thread can be an allied
thread, a database access thread, or a parallel task thread. Threads can be
active, inactive, indoubt, or postponed.
There are a number of options for displaying thread
information, and you can narrow or expand the type and amount of information you
wish to retrieve based on:
- Active threads, inactive threads, indoubt threads, postponed threads, procedure threads, system threads, or the set of active, indoubt, postponed, and system threads (see the descriptions under the TYPE option for more information)
- Allied threads, including those threads that are associated with the address spaces whose connection names are specified
- Distributed threads, including those threads that are associated with a specific remote location
- Detailed information about connections with remote locations
- A specific logical unit of work ID (LUWID)
Tracing
Information
And finally, the DISPLAY TRACE command can be used to list
your active trace types and classes along with the specified destinations for
each.
Summary
The DB2 DISPLAY command is indeed a powerful, yet simple tool
that can be used to gather a wide variety of details about your DB2 subsystems
and databases. Every DBA should know how to use DISPLAY and its many options to
simplify their day-to-day duties and job tasks.
Wednesday, October 09, 2013
Using the DISPLAY Command, Part 4
In this fourth entry of our series on the DISPLAY command, we take a look at using the DISPLAY command to monitor DB2 stored procedures and user-defined functions. Part 1 of this series focused on using DISPLAY to monitor details about you database objects; Part 2 focused on using DISPLAY to monitor your DB2 buffer pools. And Part 3 covered utility execution and log information.
If your organization uses stored procedures and/or user-defined functions
(UDFs), the DISPLAY command once again comes in handy.
Stored Procedures
You can use the DISPLAY PROCEDURE command to monitor stored procedure statistics. The output will consist of one line for each stored procedure that a DB2 application has accessed. You can qualify stored procedure names with a schema name.
DISPLAY PROCEDURE returns the following information:
Here is an example of what will be output by the DISPLAY PROCEDURE command:
DSNX940I = DSNX9DIS DISPLAY PROCEDURE REPORT FOLLOWS
PROCEDURE STATUS ACTIVE QUED MAXQ TIMEOUT FAIL WLM_ENV
CUSTPROC STARTED 0 0 1 0 0 WLMDB21
SAMPPRC1 STOPQUE 0 5 5 3 0 WLMSAMP
SAMPPRC2 STARTED 2 0 6 0 0 WLMSAMP
GETDATA1 STOPREJ 0 0 1 0 0 WLMDB21
DSNX9DIS DISPLAY PROCEDURE REPORT COMPLETE
DSN9022I = DSNX9COM '-DISPLAY PROC' NORMAL COMPLETION
Keep in mind that the information returned by DISPLAY PROCEDURE is dynamic. By the time the information is displayed, it is possible that the status could have changed.
User-Defined Functions (UDFs)
For UDFs, you can use the DISPLAY FUNCTION SPECIFIC command to monitor UDF statistics. This command displays one output line for each function that a DB2 application has accessed. Similar to what is shown for stored procedures, the DISPLAY FUNCTION SPECIFIC command will show:
Summary
When using stored procedures and/or user-defined functions, be sure to use the DISPLAY command to keep track of their status.
Stored Procedures
You can use the DISPLAY PROCEDURE command to monitor stored procedure statistics. The output will consist of one line for each stored procedure that a DB2 application has accessed. You can qualify stored procedure names with a schema name.
DISPLAY PROCEDURE returns the following information:
- The status, that is, whether the named procedure is currently started or stopped
- How many requests are currently executing
- The high-water mark for concurrently running requests
- How many requests are currently queued
- How many times a request has timed out
- How many times a request has failed
- The WLM environment in which the stored procedure executes
Here is an example of what will be output by the DISPLAY PROCEDURE command:
DSNX940I = DSNX9DIS DISPLAY PROCEDURE REPORT FOLLOWS
PROCEDURE STATUS ACTIVE QUED MAXQ TIMEOUT FAIL WLM_ENV
CUSTPROC STARTED 0 0 1 0 0 WLMDB21
SAMPPRC1 STOPQUE 0 5 5 3 0 WLMSAMP
SAMPPRC2 STARTED 2 0 6 0 0 WLMSAMP
GETDATA1 STOPREJ 0 0 1 0 0 WLMDB21
DSNX9DIS DISPLAY PROCEDURE REPORT COMPLETE
DSN9022I = DSNX9COM '-DISPLAY PROC' NORMAL COMPLETION
Keep in mind that the information returned by DISPLAY PROCEDURE is dynamic. By the time the information is displayed, it is possible that the status could have changed.
User-Defined Functions (UDFs)
For UDFs, you can use the DISPLAY FUNCTION SPECIFIC command to monitor UDF statistics. This command displays one output line for each function that a DB2 application has accessed. Similar to what is shown for stored procedures, the DISPLAY FUNCTION SPECIFIC command will show:
- Whether the named function is currently started or stopped, and why
- How many requests are currently executing
- The high-water mark for concurrently running requests
- How many requests are currently queued
- How many times a request has timed out
- The WLM environment in which the function executes
When displaying information about stored procedures and UDFs using the
DISPLAY PROCEDURE and DISPLAY FUNCTION SPECIFIC commands, a status is returned
indicating the state of the procedure or UDF. A procedure or UDF can be in one
of four potential states:
STARTED
|
Requests for the function can be processed
|
STOPQUE
|
Requests are queued
|
STOPREJ
|
Requests are rejected
|
STOPABN
|
Requests are rejected because of abnormal termination
|
When using stored procedures and/or user-defined functions, be sure to use the DISPLAY command to keep track of their status.
Tuesday, October 01, 2013
Using the DISPLAY Command, Part 3
In this third entry of our series on the DISPLAY command, we take a look at using the DISPLAY command to monitor DB2 utility execution and log information. Part 1 of this series focused on using DISPLAY to monitor details about you database objects; Part 2 focused on using DISPLAY to monitor your DB2 buffer pools.
By monitoring the current phase of the utility and matching this information with the utility phase information, you can determine the relative progress of the utility as it processes.
Of course, this works only on IBM's utilities. If you are using another vendor's DB2 utilities (e.g. BMC, CA, CDB) you will need to work with the parameters and monitoring capabilities provided by your particular vendor of choice.
For the IBM COPY, REORG, and RUNSTATS utilities, the DISPLAY UTILITY command also can be used to monitor the progress of particular phases. The COUNT specified for each phase lists the number of pages that have been loaded, unloaded, copied, or read.
You also can check the progress of the CHECK, LOAD, RECOVER, and MERGE utilities using DISPLAY UTILITY. The number of rows, index entries, or pages, that have been processed are displayed by this command.
Log Information
Utility Information
So without further ado, let's see how DISPLAY can help us manage the execution of IBM DB2 utilities. Issuing a DISPLAY UTILITY command will cause DB2 to display the status of all active, stopped, or terminating utilities. So, if you are working over the weekend running REORGs, issuing an occasional DISPLAY UTILITY allows you to keep up-to-date on the status of the job. Of course, you can issue DISPLAY UTILITY any time you wish, not just over the weekend...By monitoring the current phase of the utility and matching this information with the utility phase information, you can determine the relative progress of the utility as it processes.
Of course, this works only on IBM's utilities. If you are using another vendor's DB2 utilities (e.g. BMC, CA, CDB) you will need to work with the parameters and monitoring capabilities provided by your particular vendor of choice.
For the IBM COPY, REORG, and RUNSTATS utilities, the DISPLAY UTILITY command also can be used to monitor the progress of particular phases. The COUNT specified for each phase lists the number of pages that have been loaded, unloaded, copied, or read.
You also can check the progress of the CHECK, LOAD, RECOVER, and MERGE utilities using DISPLAY UTILITY. The number of rows, index entries, or pages, that have been processed are displayed by this command.
Log Information
You can also use the DISPLAY LOG command to display information about the number of logs, their current capacity, and the setting of the LOGLOAD parameter. This information pertains to the active logs. DISPLAY ARCHIVE will show information about your archive logs.
Of course, to be able to issue either of these commands requires either specific DISPLAY system authority or one of system DBADM, SYSOPR, SYSCTRL, or SYSADM authorities.
Subscribe to:
Posts (Atom)