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.
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.
One of the best explanations I've heard of a feature of IBM i that most of us take for granted.
ReplyDeleteWhat a powerful concept.
Thanks for the reminder, Mike!
An easy to understand explication of these concepts. A link I can point to in discussions with DBAs on other databases. Quite often those DBAs sniff at the DB2 for i whith comments like: "We cannot optimize DB2 for i because table spaces, buffers are not supported, indexes cannot be reorganized and access plans cannot be maintained".
ReplyDeleteTwo weeks ago we had some discussions about this topic at the POWER IT UNIVERSITY Conference in Dublin. There were several sessions about "Why to use Oracle Databases on a Power System" or "How to optimize Oracle Databases on Power Systems". I talked with some participants of this conference, whose companies planned or already realized to move off the i and to migrate to Oracle databases, because DB2 for i is "outdated".
We need much more blogs like this (and much more additional marketing from IBM) to make the IBM i more attractive.
Birgitta
Why would we let a computer do all this when we can do it manually? Ah that's why computers were invented, did no-one tell Oracle. It is still a "future system" it's day may yet come, lets hope so. The rumours of its death are much exaggerated.
ReplyDeleteThanks for this post, Mike! I’ve been looking for articles about data storage and this will be of great help to my study. The concepts here are easy to understand and the process of data storage was clearly stated. I hope to find more blogs like this. :D
ReplyDeleteManda Maldanado
As the technology advances, more data storage systems are invented and introduced to every computer user and owner. With this, we already have a wide variety of systems to choose from, but only a few of them are explained clearly to the public. This post clearly states about the Crown Jewels which can be very beneficial to those who are thinking of using this storage system. You can still consult the help of professional data admins if you still have more questions about data storage systems. :)
ReplyDeleteWilliamsDataManagement.com
It's better to have a thorough understanding of different databases to easily understand the concept of online backup and cloud storage. We really have to pay close attention to the time, energy, and attention required for certain data to prevent hacking and unnecessary access. Online administrators must take note that their client's files are strictly confidential, which is why it should be secured properly.
ReplyDeleteTony Shannon