What does Expert Integrated System really mean?

One of the key characteristics of IBM PureSystems is that it is an expert integrated system. Do you agree with that? Have you ever wondered why IBM emphasizes this keyword? Do you really feel and understand why PureSystems is an expert integrated system? If you would like to get practical examples, you’ve come to right place.

If you are working as a database administrator or DB2 technical supporter, I bet you are wary of the problems related to transaction logs. Well, so am I!  I have experienced those kind of problems many times and really do not want to get involved with the situation again. For example, this problem can happen in many of the following cases:

Removing transaction log files by mistake or whatever unknown reasons
Crash recovery failure which complains some log file pages corruption
Problems in log file disk subsystems
Rollforward failure during database recovery
These cases are really horrible. In the worst case, DBA has to rebuild their database system for a couple of weeks with losing some amount of data.

On the other hand, customers took many days designing database file systems and a storage LUN map. Sometimes they have to get recommendations or best practices from the database, operating system and storage experts and mediate between experts due to different opinions among them. These working patterns happen recursively whenever they make new database systems. In addition to this, they have to decide to select an idea and take the responsibility. It’s another pressure for most DBAs and system administrators.

With IBM PureData System for Transactions, at least you can be free from all above concerns.  Let me give you just three simple examples:

1. Transaction log mirroring.  Are you using a mirror log path in your DB2 LUW (Linux, Unix and Windows) systems?  In a mainframe DB2 environment, this configuration is popular for most systems. However, I did not realize that many customers of DB2 LUW do not tend to use mirror log because they do not think is as critical and feel like saving storage usage.  Even though the transaction log corruption problem is very rare case, once it happens to you, mirror log may give you critical recoverability.  For those who worry about performance impact, I would like to tell them that one of my customer’s DB2 system processes 28,000 select and 1,900 update/insert/delete per second with mirror log configuration.  In IBM PureData System for Transactions, mirror log is mandatory for system availability.

2. Storage Failures.  In storage design of IBM PureData systems for Transactions, mirror log and tablespace data use different V7000 storage enclosures. The objective of this is to increase the database recoverability in case of major storage failures like disk array failures, V7000 enclosure failures, accidental tablespace data removal or tablespace corruption.  In such events, a reconstruction is necessary for the affected database during restore and rollforward steps.  Isolating the primary log from permanent tablespaces allows for restore on event of one V7000 enclosure total failure.

01_v7000.png

3. Maximizing I/O for logs.  Following picture shows the disk I/O amounts during peak time of a customer in very demanding OLTP workload environment. As you can see, transaction logs I/O is usually much higher than tablespace I/O for data processing.

02_log_io.png




And it is the key best practice recommendation to separate the transaction logs and DB2 data, or tablespaces, onto separate spindles and onto separate LUNs.  In typical systems that use one big high-end storage with many database systems, it’s not an easy thing unless administrators thoroughly plan to divide storage chunks for future use. Furthermore, SSD disks are used for transaction log file system internally. In each V7000 enclosure, IBM PureData systems for Transaction provides six SSD disks. Hot data automatically moves to this area for significant I/O performance enhancement. From benefits of V7000 storages and architectural design, you can configure your system following these best practices on IBM PureData System for Transactions by default.

What I really want to say is that it is possible you do not have to consider the above things with IBM PureData System for Transactions. With hitting some buttons, your database will be created and configured automatically. You do not need to waste your time any more designing a storage LUN diagram. You don’t need to have many meetings with many experts and let them visit you for creating new instances and databases.  The expertise is already there. So how about trying to calculate how much time you can save?



Recent Stories
An Introduction to IBM Data Studio

The Basics of SQL Performance and Performance Tuning

Index Decluttering Opportunities in DB2 for Linux, UNIX, and Windows