• TAPEBLK is set too low in the onCONFIG to take full advantage of the device's I/O throughput potential.
• The actual I/O speed is lower than the expected I/O speed of the devices used.
  
• Not enough resources available on computer like CPU, memory, and so on. The system might be busy.

• Run a timed test to determine approximate speed of I/O from a chunk to the backup device . Run the dd command with a block size (bs) equal to the block size value for TAPEBLK in the onCONFIG. Try to use a chunk that is at least 2 GB.
  
  Note: This test might not work on a running instance because of an OS lock on the chunk that will not allow the dd command to run. If you cannot run the dd command on an actual chunk then you must use or create a file which resides in the same location as the chunks ( the same directory, same disk, same NFS mount, same SAN, and so on ). This is critical for this test to yield accurate timings.
  
  Here is the command:
  
  timex dd if=/full/path/to/informix/chunk of=/full/path/to/backup_directory/timetest.out bs=128k
  
  
  Here is an actual example:
  
  timex dd if=/informix/chunks/rootdbs of=/informix/backups/timetest.out bs=256k
  586+1 records in
  586+1 records out
  
  real 7.76
  user 0.00
  sys 0.48
  
  This dd test shows the speed for this backup would be about 18.9 MB/second or 66.4 GB/hour. This would be the approximate speed of ontape I/O with some consideration for ontape overhead.

• Capture and review the ontape function stacks to find out exactly what ontape is doing. Soon after you start the ontape backup you should see these 3 threads listed in the onstat -g ath output:
  
  ontape
  arcbackup1
  arcbackup2
  
  The output will be similar to this:
  
  ...
  213  41dac918  40347be0  1   cond wait  netnorm  1cpu   ontape
  214  41980a28  40348c50  1   IO Wait             1cpu   arcbackup1
  215  41980c88  40344a90  2   sleeping secs: 1    1cpu   arcbackup2 
  
  To get the stack trace from each thread you will need to 3 separate commands. The first column of the onstat -g ath output is the thread id. Using the example output from above you would run these commands to continuously capture stack information for each of the 3 threads every 5 seconds:
  
  onstat -g stk 213 -r > ontape.out
  onstat -g stk 214 -r > arcbackup1.out
  onstat -g stk 215 -r > arcbackup2.out
  
  You can run these in the background or in 3 separate windows. Stop them when the backup is complete.

• Increase the value of the onCONFIG configuration parameter TAPEBLK. If using a tape device, then use the device's suggested maximum block size. If writing the backup to disk, then continue increasing TAPEBLK on subsequent backups until you reach the point where increasing TAPEBLK does not decrease time to complete the backup ( you could start at 128 then go to 256, 512, 1024, and so on ).

• Use faster backup device or find ways to increase I/O of that device. Some examples:
  
  • use a faster tape drive or a tape that can handle higher I/O speeds
  • backup to local disk then ftp the backup to a SAN

• Collect ontape thread stack traces and analyze or send to technical support for analysis.

With IBM® Informix® Dynamic Server™ 11.10, it is possible to apply filters during a backup and restore with both ontape and onbar. These filters basically are external programs which are called before the data is written or read either to or from disk or the storage manager. The filter programs expect data from stdin and will send their output, the processed data, to stdout. The most common example for that is to call a compression program, but it can also be used for encryption or other changes to the data. 
If you want to use a filter to compress the data of your backup, you can define a backup filter in the Informix Configuration file like below

Example

For UNIX platforms:
BACKUP_FILTER /usr/bin/compress

For Microsoft® Windows platforms:
BACKUP_FILTER c:\cygwin\bin\gzip.exe

RESTORE_FILTER /usr/bin/uncompress

RESTORE_FILTER 'c:\cygwin\bin\gzip.exe -d'

When computer name is changed the global registry entries for groups DB2ADMNS and DB2USERS remain unchanged and are not updated, (호스트 이름이 변경되었거나 영문이 아닌 경우에도 발생할 수 있다)

The only way to diagnose this issue is to take a DB2 trace.

The trace will show that the we fail to get the SID for group <old computer name>\DB2USERS

Update the global registry entries with the new name for groups DB2ADMNS and DB2USERS

db2extsec -a <new computer name>\DB2ADMNS -u <new computer name>\DB2USERS

This is a mandatory requirement after a computer name change

Unable to sign the Optim Exit.

Corrupted ".mw" directory

Resolving the challenge module issue requires re-creating the corrupted ".mw" directory.
Here are the suggested steps.

1. Delete a hidden folder named ".mw" located at the logged in user's default Optim home directory.
2. At the home directory, run "ls -la" from command prompt to locate the folder.
3. Remove the ".mw" folder by issuing "rm -r .mw".
   Note: Mainwin will create a new .mw folder after steps are done.
4. Re-sign the Optim exit using "pr0sign -d" with the same user id that installed Optim, and the id that is in a plan to run the Optim server.

Starting with Oracle 11gR2 clients will no longer contain the 32bit libraries. For that reason, a 32bit Oracle client has to be installed, to be able to use Optim on Linux x64 as server.

To get the full functionality of Optim, use the "Administrator" installation type. This type contains all libraries needed and the binaries, for example, sqlldr, the Oracle SQL Loader, sometimes needed.

see also:
Oracle® Database Client Installation Guide
11g Release 2 (11.2) for Linux
1.2.3 Separate 32-Bit Client Shiphome for 64-Bit Ports


The supported database versions of Oracle with a current Oracle client you can find at Oracle directly:
Note:207303.1 "Oracle Client / Server Interoperability Support"

For 11.1-clients that means: 
Server must have 9.2.0.4 or higher, 9.2.0.1 is not supported.

Starting with Oracle 11gR2 clients will no longer contain the 32bit libraries. For that reason, a 32bit Oracle client has to be installed, to be able to use Optim on Linux x64 as server.

To get the full functionality of Optim, use the "Administrator" installation type. This type contains all libraries needed and the binaries, for example, sqlldr, the Oracle SQL Loader, sometimes needed.

see also:
Oracle® Database Client Installation Guide
11g Release 2 (11.2) for Linux
1.2.3 Separate 32-Bit Client Shiphome for 64-Bit Ports


The supported database versions of Oracle with a current Oracle client you can find at Oracle directly:
Note:207303.1 "Oracle Client / Server Interoperability Support"

For 11.1-clients that means: 
Server must have 9.2.0.4 or higher, 9.2.0.1 is not supported.