CONTROL-M and Sybase 12 disk fragmentation & performance Target Audience

This technical document target audience is CONTROL-M customers running CONTROL-M with a Sybase ASE suffering from either data fragmentation problems or long elapsed time of the CONTROL-M new day procedure.

Table of Contents
Sybase disk space fragmentation .......................................................................1 Sybase fragmentation theoretical explanation.....................................................1 CONTROL-M and Sybase fragmentation.................................................................2 Fragmentation - Solution ...................................................................................3 Weak performance during new day .................................................................3 Sybase I/O mechanism........................................................................................4 Options for the I/O mechanism ...........................................................................4 Setting the dsync attribute................................................................................5

Sybase disk space fragmentation

As every data management system, a Sybase RDBMS (Relational Database Management System) commercially referenced as Sybase ASE (Adaptive Server Enterprise) may suffer from data fragmentation problems. The purpose of this section is to describe the problem, explain why sometimes it may become an issue with CONTROL-M implementations and provide a workaround to deal with the disk fragmentation problem.

Sybase fragmentation theoretical explanation

Starting Sybase ASE 11.9.2 release, the options of data isolation levels have been increased and they include in addition to the page level locking mode a new mode called row level locking. The purpose of this mode is to avoid a scenario in which 2 (or more) sessions access the database asking for different rows but lock each other because the these rows are located on the same physical page.

As the core engine of Sybase ASE has not been re-designed, the implementation of this ability is the cause for a possible data fragmentation. When a given database object (a table or index for example) is set to row level locking mode and 2 (or more) sessions try accessing 2 different rows located on the same page Sybase ASE assures these 2 sessions access 2 different rows and then duplicates that page giving a copy of it to these 2 sessions. In addition, physical pointers between these 2 pages are created in order to maintain data consistency between these copies. When such a logical conflict occurs on data pages which are part of an index the data fragmentation ratio gets higher as these two copies of the same page should be located accordingly within the binary tree structure of an index, which may lead to a lot of data pages splits. These splits are required in order to maintain the logical order within the index binary tree. It may also lead to a scenario that some pages are not occupied with data completely as they were split by one of the data updates. Before this row level locking mode was introduced, Sybase ASE used to select one of the sessions trying to access the same data page, choose it as a deadlock victim and abort its transaction. This new isolation level mode now dramatically decreases the probability of facing deadlocks but does cause a potential data fragmentation as a result of the technical implementation of this feature.

CONTROL-M and Sybase fragmentation

CONTROL-M Starting release 6.1.0x, which uses Sybase ASE 12 by default, is configured to create all its database objects having the row level locking isolation level set. The positive effect of it is that CONTROL-M performance has improved. Before this design improvement, the following scenario was likely to happen: A given CONTROL-M process tried to access a record Another process was already accessing another record located on the same page The process got a deadlock victim message after a certain timeout Then, the process has tried to perform the same operation over and over again until a successful completion of it

This can sometimes cause delays in the on going operation of CONTROL-M. By changing the isolation level from page level locking to row level locking the described scenario can no longer occur. Both processes now get a copy of the relevant page without disturbing each other. The negative effect of it is that sometimes this Sybase ASE behavior may lead to some data fragmentation, because of these page splits.

Fragmentation - Solution
The following section describes a technical solution that can be implemented in order to minimize the disk fragmentation and to re-organize the disk used by Sybase ASE on a periodical basis. The workaround is based on Sybase utilities that can defrag Sybase indexes while regular transactions are executed. There is no need to freeze any processing or applications while this workaround is executed. Technically, the solution includes a set of stored procedures permanently stored within the Sybase ASE and an external shell script executed periodically that activates these stored procedures. In order to implement the suggested solution, perform the following steps: 1. Place the stored procedures at the Sybase ASE repository. The stored procedures can be found in the attached file named: reorg.sql. In order to load them into the Sybase ASE repository, perform the following command line using the CONTROL-M/Server Unix account: isql U{dbo} P{dbo password} ireorg.sql where: {dbo} - is the name of the database owner used by CONTROL-M (see the value of the environment variable $CONTROLM_OWNER) {dbo password} - is the password of this database owner Ensure the file reorg.sql exist in the current directory. 2. Place the attached file ctmreindex at the $HOME/ctm/scripts directory and assign the execute permission to it.

From now on, scheduling a periodical task that executes the script ctmreindex will perform a disk space re-organization at the Sybase ASE level, dramatically decreasing the disk fragmentation. It is highly recommended to avoid executing this workaround during CONTROL-M new day process as both processes perform massive reads & writes from and to the database and it may end up having some fragmentation immediately after the workaround execution completes.

Weak performance during new day

As part of the design changes that are part of Sybase ASE 12 addition there is a change to the default caching behavior of logical database devices. A logical database device is some disk space allocated exclusively for Sybase ASE usage and formatted in a way
3

readable only by Sybase. This disk portion is assigned a logical name that can be used by a Sybase database (based on privileges and volume allocation) in order to store objects. The following section describes the interaction between the Sybase 12 I/O mechanism and the file system, the available options of this mechanism and the advantages and disadvantages of each mode and a technical description how to set this option if needed.

Sybase I/O mechanism

Starting Sybase ASE 12 each I/O write operation is performed by default directly on the underlying physical disk, the disk the file being part of the Sybase logical device is located. In previous Sybase releases, that was not the case. Instead, each I/O operation was confirmed from Sybase ASE point of view once it was stored in the file system cache, leaving the actual physical write at the file system responsibility that later on applies it to the relevant physical disk. As the default behavior in this Sybase release has changed compared to previous release, Sybase introduces a new parameter named dsync (Disk Synchronization) that controls the method Sybase ASE verifies each I/O write operation. Note that this flag is only relevant to database devices implemented using O/S files (and not raw devices).

Options for the I/O mechanism

The dsync device flag has two possible values: On Sybase ASE opens a database device file using the Unix DSYNC flag assuring that all write operations are performed directly on the physical media with no buffering or caching procedures. Off Sybase ASE performs a nave writes to any database device file, placing the updated/new data buffers on the file system cache, leaving the actual physical write to the file system.

When the database device dsync flag is set to on the consistency and survivability of the data is much higher as each transaction is written directly to the physical disk protecting the data from any electricity breakdown. However, I/O response time is slower as each write is physically performed synchronously, without caching any data. When the database device dsync flag is set to off performance is better as data changes are stored within the file system cache and only later physically written to the disk. However, the data vulnerability is higher when using this mode as in case of electricity breakdown when there is a miss-match between the file system cache and the physical disk, Sybase ASE might refuse to start and mark the database as suspect in terms of data consistency. Going back into production requires restoring a backup that may take time. The bottom line is that there is a tradeoff between performance (dsync is set to off) and survivability (dsync is set to on).

Changing the value of this device attribute may sometimes have an effect of dozens of percents on the new day procedure elapsed time as this procedure involves a lot of I/O operations.

Setting the dsync attribute

In order to configure the dsync attribute of a Sybase database device, perform the following steps: 1. Login to the Sybase database using the sa (System Administrator) account 2. For each device (data or log) that you want to change the dsync attribute execute the following Sybase command: sp_deviceattr {logical device name}, dsync, {value} where: {logical device name} The name of the device you want to change its dsync attribute. {value} true to set the dsync attribute to on, false to set the dsync attribute to off 3. Reboot the Sybase ASE for the change to take effect