DB2 for i › One of the Crown Jewels: Single Level Storage
November 5th, 2012
Last month the fine folks at System i Developer hosted the Fall 2012 RPG & DB2 Summit conference in Minneapolis. It was a really good event by the way; in part because they invited Steve Will - IBM i Chief Architect to deliver the keynote address. Steve’s presentation “Why i” covered many of the features and benefits of running IBM i on POWER systems. One of these advantages is Single Level Storage. At the very same Summit conference, a participant came up to me during one of the database sessions and stated he had never heard of single level storage. He wanted to know more, and wondered aloud if it had anything to do with database. I promised an answer – and here it is…
IBM i Single Level Storage
In my opinion, one of the crown jewels of IBM i (and OS/400 before it) is the ability to provide a view of all the storage – memory, solid state and spinning disk – as a single address space. In effect, the operating system only sees a very large set of virtual addresses (64 bits worth since 1991 and 48 bits worth since 1978!). It means system administrators and application developers do not have to worry about the physical storage mechanism. If you believe 1970’s computer science
fiction, IBM researchers stated that future computer systems would be based on large amounts of “main storage” (otherwise known as memory) and not require magnetic disk. As such, the need to assign and make use of a large list addresses for the vast amount of information resident in memory came to be an important consideration. Imagine a computer with ALL of the data in memory, and only in memory. Each piece of data would require a unique address so that it could be referenced unambiguously.
While hindsight is always 20/20, it seems early Rochester Minnesota engineers were looking way ahead. Even though computer systems based on large quantities of memory and no spinning disk were decades away, IBM’s “future system” was implemented with an addressing and storage scheme assuming everything - data, programs, all of it would reside in memory.
To complete the single level storage concept, IBM i enjoys another valuable mechanism known as “integrated storage management”. Simply put, storage management is responsible for persisting objects on disk, and handling the movement of bits and bytes between memory and disk. Obviously, there are many benefits to this unique approach of addressing and storage. Especially if you compare IBM i to virtually any other operating system (anyone remember storage and memory management in DOS and Windows?).
How about DB2 for i?
The integrated database management system known as DB2 for i takes full advantage of both single level storage and storage management. And the benefits can be experienced in many ways.
When creating database objects such as tables and indexes the definition specifies an object name, not a physical location. The actual data spaces are created automatically by DB2 for i. For example, there is no need (and no way) for the developer to create a tablespace and specify the actual location and physical attributes of the table. All that is needed by DB2 for i is the CREATE TABLE statement.
Preventing and/or solving database performance issues by manipulating the tablespace storage attributes are unheard of. How is this possible?
Technically speaking, IBM i storage management will automatically spread the database objects across all available disk units. As a database object grows or shrinks IBM i will handle the requirement for more or less space. The combination of single level storage and automatic storage management relieves the database engineer / developer from the burden and responsibility of storage administration. Life is simpler. Life is easy. Life is good.
Given that all systems have both disk and memory, DB2 for i teams up with IBM i storage management to move data between main storage and auxiliary storage (aka memory and disk) in a way only an integrated database could.
DB2 for i objects share the same memory as the application, optimally balanced by storage management, to simplify operations and gain performance advantage with adjacent memory usage.
The supervisory nature of IBM i coupled with the concept of referencing only “one copy of data” via unique virtual address (VA) allows for some very clever I/O capabilities. I/O can be scheduled and performed asynchronously (i.e. no waiting) allowing for just-in-time arrival of information. Data can be cached in memory and transparently accessed given the fact that it’s always referenced by VA.
There are no buffer pools or database subsystems to define, configure or manage. If the table and/or index are brought into memory ahead of the query, the application does not have to wait on the relatively slower physical I/O mechanism.
When doing physical I/O, the query optimizer can request parallel I/O be used to get data into memory faster. Remember, this is all accomplished without database administration or configuring the data space for parallelism.
Asked and Answered
While not talked about openly enough, DB2 for i embodies very sophisticated algorithms and computing techniques for solving data centric problems. Single level storage and integrated storage management are a couple that explain why IBM i running on POWER can be high performing, scalable AND cost effective.
If you happen to know an Oracle, SQL Server or Sybase DBA, ask them about database storage and data access concepts. Pay close attention to the time, energy and attention required – then give a nod of thanks to IBM i for handling this for you.
Read the original at DB2 for i.