Month: March 2011

The hard worker is always behind the scene. In the case of Online Transaction Processing (OLTP) and Decision Support Systems (DSS), what’s not seen in the naked eye, the hard worker is the disk subsystem which always remains unnoticed.   ~ Chic Pencil

A customer relationship management system will always contain and maintain our records once we become a member or a customer of the business entity. Customer records is always the basis of customer analytics as well as customer loyalty campaigns.

When you want your records to be retrieved, what you know is to input your personal details when it is done via online portal or a customer service officer will retrieved it for you.

Say for example you input your details as the following via the online portal:

• Firstname      :     John
• Lastname       :     Smith
• Date of birth  :     12/08/1980
• National ID   :     589001122

In the backend processing, the CRM system will get your records via passing of your inputs to the CRM database. As such, the CRM system will pass the query using the following SQL statement (the language of most databases):

> begin tran

> select * from customer where fname = ‘John’ and lname = ‘Smith’ and DOB = ’12/08/1980′ and NID = 589001122

> end tran

> go

Once the database receives your request, it will be placed in the queue. And when it is your request’s turn for the database to process, well the database will do the following:

1. The database will parse the SQL statement received. The parsing process involves checking of syntaxes and if there are violations, the database will return the errors to the CRM system.
2. Once the parsing completes and there’s no violations found, the database will refer to its query processing engine to build the algorithm that will retrieve the data. We call this stage, the building of the query plans.
3. Based on the query plans generated, the database will choose which plan will fit to retrieve the data. The query plan is one of they key workers of a database system. It is essential that the database administrator (DBA) performs the necessary maintenance in order to keep the database system at optimal health.
4. The chosen query plan will be performed by the database engine. This time, the database engine will perform the coordination with the last worker in the hierarchy — the disk subsystem.
5. When the disk subsystem receives the database request, it will place it in a queue. And the queue management and control is handled by spindle. The spindle will tell the disk to get the requested data basing from RPM (speed) of the physical disk.
6. Once the spindle completes the requested operation, it will pass it back to the database with the data in it.
7. The database will then relay the requested data to the CRM system.
8. The CRM system will display the data requested. In this case it will validate based on the input if the customer does exists in the customers table.

The above example is only looking for data in one table. When you want to know the purchases you made or any transactions you done in the past, the database system will look for your query in different tables and indexes. The more requests you do translates to more operations to the last worker in the hierarchy and that is the disk subsystem.

Though the role of the disk subsystem is sometimes forgotten. It does play a major role in any IT needs from personal to enterprise requirements.

The disk spindle holds the key role in letting the IT system administrators know the input – output (I/O) speed — MB/sec of the subsystem it manage. It is the benchmark of the system administrators if there is a need to increase or upgrade the current disk subsystem when new business requirements arise.

Most often than not, the importance of the having the best disk subsystem is limitedly appreciated by the hardware vendors. Most software vendors does not put emphasis that by having a best disk subsystem their system will perform par better than their expected speed.

The disk subsystem is the database’s best friend. When the database is fast in getting user queries, the disk subsystem should be able to response fast as well otherwise, choking on the disk system will occur. Disk choking occurs when the disk spindle is not able to meet up with the transactions that is passed on to it. Remember that the transactions not only comes from database requests but also from the operating system side as well.

As such, for OLTP requests, a higher disk RPM and a higher disk spindle is an excellent fit. This requirement is universal regardless of database brand. These days, 10K or 15K RPM SAS disk is readily available in the market.

For DSS or OLAP requirements, you will need to consider the database architecture and technology. Since user queries especially ad-hoc queries requires huge amount of I/O operations as data retrieval is being done in bulk method, parallelism inclusive of disk spindle would be an excellent fit. Well the database technology for this requirement will be discussed in a separate article.

For Unix system, you can view the disk spindle (operations) via these commands

• vmstat
• sar

It is important to monitor the health of the disk. Once this component fails, a RAID configuration should be handy otherwise precious data will be completely loss as a backup system may not be able to do an up-to the minute backup.

So, if you’re not taking care of your disks better start checking it now. It is the worker who wiggles and spindles in order to retrieve your important data and files and everything in your system.

Exposure 1/60 sec. F/4.5. Focal 70 mm. ISO 400. Nikon D200.

Title: Simply happy. A symbol of a happy customer.

A happy customer is a loyal customer. Keeping customers happy not only entails business processes but also the IT system as well. As such, everything in the equation has to be balanced. And the last worker in the hierarchy shouldn’t be forgotten.

Til next time. Au revoir.