728x90


Problem(Abstract)

When running a select query that contains COUNT(*) the following errors are returned:
> echo "select count(*) from customer;" | dbaccess stores_demo

Database selected.

252: Cannot get system information for table.

113: ISAM error: the file is locked.
Error in line 1
Near character position 61


Database closed.

Symptom

Errors -252/-113 are returned:

252: Cannot get system information for table.

113: ISAM error: the file is locked.

Cause

Isolation level Committed Read or Last Committed is used and there is an exclusive lock on the table

Diagnosing the problem

Using 'onstat -g sql' check the isolation level that sessions are using:

> onstat -g sql

IBM Informix Dynamic Server Version 11.70.FC3 -- on-Line -- Up 00:52:17 -- 182532 Kbytes

Sess SQL Current Iso Lock SQL ISAM F.E.
Id Stmt type Database Lvl Mode ERR ERR Vers Explain
39 - stores_demo CR Not Wait 0 0 9.24 Off
27 sysadmin DR Wait 5 0 0 - Off
26 sysadmin DR Wait 5 0 0 - Off
25 sysadmin DR Wait 5 0 0 - Off

In the above example session #39 is using an isolation level of Committed Read (CR).

Then check the table for exclusive locks. To do so, first get the partnum of the table. This can be done by running the 'oncheck -pt <dbname:tabname>' command:

> oncheck -pt stores_demo:customer

TBLspace Report for stores_demo:informix.customer

Physical Address 2:678
Creation date 08/05/2011 15:55:41
TBLspace Flags 802 Row Locking
TBLspace use 4 bit bit-maps
Maximum row size 134
Number of special columns 0
Number of keys 0
Number of extents 1
Current serial value 129
Current SERIAL8 value 1
Current BIGSERIAL value 1
Current REFID value 1
Pagesize (k) 2
First extent size 8
Next extent size 8
Number of pages allocated 8
Number of pages used 3
Number of data pages 2
Number of rows 28
Partition partnum 1049059
Partition lockid 1049059
<...>

Next, convert the partnum value into HEX: 1049059 = 0x1001e3

Finally, grep the partnum value (without the leading 0x) from 'onstat -k' output:

> onstat -k | grep 1001e3
4ebef028 0 4b85c418 4ebeed28 HDR+X 1001e3 102 0 D
4ebef328 0 4b85c418 4ebef228 HDR+X 1001e3 103 0 D
4ebef528 0 4b85c418 4ebef428 HDR+X 1001e3 104 0 D
4ebef728 0 4b85c418 4ebef628 HDR+X 1001e3 105 0 D
4ebef828 0 4b85c418 4ebeefa8 HDR+X 1001e3 106 0 D
4ebefa28 0 4b85c418 4ebef9a8 HDR+X 1001e3 107 0 D
4ebefb28 0 4b85c418 4ebefaa8 HDR+X 1001e3 108 0 D
4ebefd28 0 4b85c418 4ebefca8 HDR+X 1001e3 109 0 D
4ebeff28 0 4b85c418 4ebefea8 HDR+X 1001e3 10a 0 D
4ebf0128 0 4b85c418 4ebf00a8 HDR+X 1001e3 10b 0 D
4ebf0328 0 4b85c418 4ebf02a8 HDR+X 1001e3 10c 0 D
4ebf0528 0 4b85c418 4ebf04a8 HDR+X 1001e3 10d 0 D
4ebf0728 0 4b85c418 4ebf06a8 HDR+X 1001e3 10e 0 D
4ebf0928 0 4b85c418 4ebf08a8 HDR+X 1001e3 201 0 D
4ebf0b28 0 4b85c418 4ebf0aa8 HDR+X 1001e3 202 0 D
4ebf0ca8 0 4b85c418 4ebf0c28 HDR+X 1001e3 203 0 D
4ebf0ea8 0 4b85c418 4ebf0e28 HDR+X 1001e3 204 0 D
4ebf10a8 0 4b85c418 4ebf1028 HDR+X 1001e3 205 0 D
4ebf12a8 0 4b85c418 4ebf1228 HDR+X 1001e3 206 0 D
4ebf1428 0 4b85c418 4ebf13a8 HDR+X 1001e3 207 0 D
4ebf1628 0 4b85c418 4ebf15a8 HDR+X 1001e3 208 0 D
4ebf1828 0 4b85c418 4ebf17a8 HDR+X 1001e3 209 0 D
4ebf1a28 0 4b85c418 4ebf19a8 HDR+X 1001e3 20a 0 D
4ebf1c28 0 4b85c418 4ebf1ba8 HDR+X 1001e3 20b 0 D
4ebf1e28 0 4b85c418 4ebf1da8 HDR+X 1001e3 20c 0 D
4ebf2028 0 4b85c418 4ebf1fa8 HDR+X 1001e3 20d 0 D
4ebf2228 0 4b85c418 4ebf21a8 HDR+X 1001e3 20e 0 D
4ebfeda8 0 4b85c418 4ebfee28 HDR+X 1001e3 101 0 D
4ebfee28 0 4b85c418 44452788 HDR+IX 1001e3 0 0

In the above example, the table has an intent-exclusive lock on the whole table (HDR+IX) and some exclusive locks on its rows (HDR+X).

Resolving the problem

Set the isolation level to Dirty Read at the session level before running the query:

> echo "set isolation to dirty read; select count(*) from customer;" | dbaccess stores_demo

Database selected.

Isolation level set.


(count(*))

28

1 row(s) retrieved.

Database closed.

Another option is to set lock mode to wait in order to allow the query to wait until the lock is released:

> echo "set lock mode to wait; select count(*) from customer;" | dbaccess stores_demo


728x90
728x90

Question

What is the recommended way of running UPDATE STATISTICS in a database so that the optimizer will have the information it needs to run the most efficiently? This article includes a utility to produce an SQL command file that runs all of the UPDATE STATISTICS command recommended for a particular database.

Answer

You can make sure that the optimizer has all of the data it needs to make your queries more efficient by running the SQL command UPDATE STATISTICS on your database. 

    1. Run UPDATE STATISTICS LOW on all tables in the database. 

    2. Run UPDATE STATISTICS MEDIUM on all columns which are in an index, but are not the first column of any index. 

    3. Run UPDATE STATISTICS HIGH on all columns which are the first column in an index. 

    4. Run UPDATE STATISTICS on all stored procedures.

This should be done any time that there are significant changes made to the distribution of the data. 

To make the task of running all of these UPDATE STATISTICS statements easier you could put them into a single SQL command file. 


makeupdate.sql 

Here is a command file named makeupdate.sql that can be used to generate an SQL command file that runs the recommended UPDATE STATISTICS commands for your particular database. 

To use the makeupdate.sql script follow these steps: 
    1. Copy the file makeupdate.sql.txt to a working directory and change the name to makeupdate.sql

      makeupdate.sql.txt

    2. Run the makeupdate.sql command file using dbaccess.

      Example: 

      If your database is named mydb and the makeupdate.sql command file is in your current directory then you can run it by entering this at the command line:

        dbaccess mydb makeupdate.sql

The SQL commands in makeupdate.sql produce an SQL command file named update_stats.sql in the current directory. 

To complete the UPDATE STATISTICS process you must run this SQL command file using dbaccess. 

    Example: 

    If your database is named mydb and the update_stats.sql command file is in your current directory then you can run it by entering this at the command line:
      dbaccess mydb update_stats.sql

You may also consider the Auto Update Statistics (AUS) maintenance system available in IBM™ Informix Dynamic Server version 11.50 and later. Refer to the topic "Automatic statistics updating" in the System Administration section of the Informix 11.50 information center (see Related URL section)


출처:

http://www.ibm.com/support/docview.wss

728x90
728x90

Question

This article provided details of how to write an awk script that can collect information about all active SQL sessions running on an IBM® Informix® Dynamic Server 7.31 database.

Answer

INTRODUCTION

IBM® Informix® Dynamic Server (IDS) version 9.x introduced the ability to collect information for all active SQL sessions by using the command onstat -g sql 0. This functionality can be replicated for IDS version 7.31 databases by using the following awk script.

STEPS

Create an awk script that contains the following text:

BEGIN {system(":> onstat_g_sql_0")}
{
if ($NF > 0) {
my_string= onstat -g sql " $1 "  >> onstat_g_sql_0; echo \"----------------\" >> onstat_g_sql_0"
system(sprintf(my_string))
}
}
END {}


Note: This script directs the SQL information to a file called onstat_g_sql_0 in the current working directory. 

Run this script using the command 

onstat -g sql|tail +6|awk -f <scriptname> 

where scriptname is the name of the awk file created in the previous step. To improve usability, this command could be written as a shell script (with execute permissions) and located in a directory referenced by your PATH environment variable. 

Display the contents of the output file to view the details of all the sql in execution in the database. 

Example 

SQL running on database server
IBM Informix Dynamic Server Version 7.31.UD8     -- on-Line -- Up 00:10:54 -- 8912 Kbytes
Sess  SQL            Current            Iso Lock       SQL  ISAM F.E.
Id    Stmt type      Database           Lvl Mode       ERR  ERR  Vers
13    SELECT         informix_log       CR  Not Wait   0    0    7.31
11    -              informix_log       CR  Not Wait   0    0    7.31


Sample output from awk script

IBM Informix Dynamic Server Version 7.31.UD8     -- on-Line -- Up 00:10:20 -- 8912 Kbytes
Sess  SQL            Current            Iso Lock       SQL  ISAM F.E.
Id    Stmt type      Database           Lvl Mode       ERR  ERR  Vers
13    SELECT         informix_log       CR  Not Wait   0    0    7.31
Current statement name : slctcur
Current SQL statement :
  select * from test2
Last parsed SQL statement :
  select * from test2
----------------
IBM Informix Dynamic Server Version 7.31.UD8     -- on-Line -- Up 00:10:20 -- 8912 Kbytes
Sess  SQL            Current            Iso Lock       SQL  ISAM F.E.
Id    Stmt type      Database           Lvl Mode       ERR  ERR  Vers
11    -              informix_log       CR  Not Wait   0    0    7.31
Last parsed SQL statement :
  UPDATE   test2 set str1="bbb" where key=0
----------------


http://www-01.ibm.com/support/docview.wss?

728x90
728x90

Question

How to increase performance by monitoring when the optimizer chooses to sequential scan a table instead of another alternative access method and then changing the table so that the optimizer selects the optimal method.

Answer

INTRODUCTION

In some circumstances small mistake in managing an IBM® Informix® Dynamic Server™ (IDS) can generate significant performance problems. A common mistake is to not monitor the number of sequential scans in an instance.

Often the Database Administrator (DBA) analysis the tables when they are created but does not continue to monitor their usage, so new users or new applications can query the tables using a different WHERE condition that is not optimized. This can generate sequential scans and in some circumstances can create significant performance problems. The sequential scan is the slowest way to query a table. 

An example is an update or a delete with WHERE conditions. If the table involved in this operation uses an index scan, the rows will be read directly and a lock will be put only on the rows or pages that satisfies the conditions. 

If the optimizer, instead of using an index scan, chooses to perform a sequential scan for the rows that satisfy the conditions, the following problems can arise:

  • Unnecessary pages are read from disk. This mean a lot of I/O operations, loss of hardware resources that can impacts the instance performance.
  • Increase in the number of locks used. If the table is very large and this operation is executed during the peak time, the lock requests can rise until the maximum limit allowed is reached. Other users that are executing operations in different tables will not be able to execute operations that request locks and they will receive an error message.

The most common reasons that can force the optimizer to choose a sequential scan instead of an index scan are listed below: 
  • Lack of appropriate indexes on large tables.
  • Statistics are missing or are not updated correctly using UPDATE STATISTICS.

The command onstat -p can be used to monitor the number of sequential scans that occurred in the instance check the value of " seqscans". If you discover that the number of sequential scans is quite high you need to do the following performance tuning activities: 
  • Query the partition table to identify which tables have a large amount of sequential scans.
  • Understand why the optimizer is not choosing an index scan when accessing those tables.

BEFORE YOU BEGIN

  • If TBLSPACE_STATS configuration parameter in your ONCONFIG is set to 0, the partition profiles is disabled then all columns in the sysptntab will contain the value 0, therefore the methods shown above will not return any useful info.
  • The command onstat -z will reset all the statistical information. If this command was executed recently this can generate false results.
  • When the database instance is started or restarted all the statistical information is reset.


STEPS

To find the name of the tables with a high number of sequential scans and to improve the performance you follow the following steps:

1. Query the partition table to find the tables with a high number of sequential scans

From dbaccess connect to sysmaster then execute the following select:

      SELECT  dbsname,tabname,b.partnum,pf_dskreads,pf_dskwrites,pf_seqscans
      FROM    systabnames as a, sysptntab as b
      WHERE   pf_seqscans > 200 AND a.partnum=b.partnum



This select will display only the tables that had more than 200 sequential scans performed since the database instance was started or since the last onstat -zwas executed. 

Example


dbsname       databasename
tabname       tablename
partnum       2097154
pf_dskreads   265432456
pf_dskwrites  543678954
pf_seqscans   34000



2. Check pf_dskreadspf_dskwrites, this number represents the number of pages read and write from the disk per table. If those numbers are low then it could mean that it is of no great importance to optimize the access method for this table. 

3. If pf_dskreadspf_dskwrites,are quite high then the DBA need to analyse the activity on this table. Try to discover which users are using this table and analyse the SQL statements that they have submitted. 
The command onstat -g sql 0 > file.out can help the DBA to obtain all the sql queries that are being executed in a particular moment. In version 7.x the command onstat -g sql 0 doesn't exist. However you can have the same result executing an awk script, for more information regarding awk look at the Related Information section at the bottom of this article.

4. once you have found the query that you think may generate a sequential scan you can use the sql command SET EXPLAIN on to obtain the path that the optimizer has chosen to execute the query. If the explain output shows a sequential scan try to improve the performance with one of the following actions:

  • Create the appropriate indexes for these queries.
  • Execute UPDATE STATISTICS (medium or high) for these tables. To generate the proper update statistics for your database, have a look at the Article Update statistics script. There is a link to the article at the end of this page.

Alternative methoin Unix or Linux only

The DBA can use a different approach that will avoid part of the activity in the sysmaster. The following command will read directly from the shared memory reducing the impact of the previous select on sysmaster:

1. Execute the following command from prompt:

onstat -g ppf|awk '{ if ($12 > 200) print }' -

where $12 is the twelfth columns that in 7.31, 9.40 and 10.00 represent the column "seqsc" that contain the number of sequential scans executed by the partition. Note that in other informix versions the position of this column "seqsc" can change.

2. Check “isrd” “iswrt” that represent the number of pages read and write related to this table. If those numbers are low it could mean that it is not important to optimize the sequential scan for this table.

3. Transform the partnum into decimal form. 

4. To find the name of the table, from dbaccess connect to sysmaster then execute the following select:


SELECT dbsname, tabname 
FROM systabnames 
WHERE partnum= xxxx    
</code>
where xxxx is the partnum transformed in decimal. 


5. once you have found the query that you think may generate a sequential scan you can use the sql command  SET EXPLAIN on to obtain the path that the optimizer has chosen to execute the query. If the explain output shows a sequential scan try to improve the performance with one of the following actions:

  • Create the appropriate indexes for these queries.
  • Execute UPDATE STATISTICS (medium or high) for these tables.



http://www-01.ibm.com/support/docview.wss?uid=swg21156390

728x90
728x90
Question

Can we add a DBSERVER entry dynamically to the SQLHOSTS file without bouncing the database server?

Cause

A need exist to add a new connection to the instance dynamically without any down time.

Answer

Starting with Informix version 11.50.xC6 we have the ability to Dynamically Start, Stop and Restart Listen threads with the onmode -P command or by using the SQL Admin API. 

This feature allows a new listener thread to be started on a port without the need to restart the database server. Adding new entries in to the sqlhosts file and the DBSERVERALIAS parameter of the onconfig file and executing the onmode -P or SQL API commands will allow new connections to utilize the new server name.

Steps:


1. Modify the sqlhosts to add the new connection:

      new_test_tcp onsoctcp myhost 4567 

2. Modify the DBSERVERALIAS parameter of the onconfig file: 

      DBSERVERALIASES main_prim_shm:new_test_tcp 

3. Start a listener thread for the new alias:

       onmode -P start new_test_tcp

OR use the sysadmin SQL API :

      execute function admin("start listen","new_test_tcp");


728x90
728x90

Problem(Abstract)

connections mysterious dropping from client applications


Symptom

connects/sessions dropping from a client application with no indication


Cause

“Idle Tiimeout” task enabled on Operating System


Resolving the problem

Disable the Idle Tiimeout on your operating System.

728x90
728x90

Question

Changing hostname of the DB2 server. What updates in DB2 need to be made?

Cause

Changing the DB2 server's hostname.

Answer

Perform the following on the DB2 server:


1) Login as the dasadm user on UNIX/Linux or Local Administrator on Windows. Stop the DB2 Administration Server (DAS):

    db2admin stop

2) Login as the instance owner on UNIX/Linux or Local Administrator on Windows. Stop the DB2 instance:
    db2stop

3) Change the server's hostname. on a Windows system, a reboot is required before this change will take effect. Do not reboot the Windows Server at this time - you must make the DB2 Configuration changes first. 

4) Login as user ROOT if DB2 is on UNIX/Linux and Local Administrator on Windows. Update the DB2SYSTEM registry variable while in the instance home directory:
    • UNIX/Linux
      db2iset -g DB2SYSTEM=<new hostname> 
    • Windows 
      db2set -g DB2SYSTEM=<new hostname>

5) Locate db2nodes.cfg in one of the following directories:
  • UNIX/Linux:
    <db2 instance home directory>/sqllib/db2nodes.cfg

  • All Windows flavors running DB2 v8 and v9.1: 
    Program Files\IBM\SQLLIB\DB2\db2nodes.cfg 

  • Windows XP and 2003 running DB2 v9.5: 
    Documents and Settings\All Users\Application Data\IBM\DB2\<DB2COPY>\DB2\db2nodes.cfg

    NOTE: Application Data is a hidden folder

  • Windows Vista and later operating systems: ProgramData\IBM\DB2\<DB2COPY>\DB2\db2nodes.cfg
Note that only DB2 ESE has a db2nodes.cfg. If you are running other editions (WorkGroup Server, or Personal Edition) then you can skip this step and the next.

6) In the db2nodes.cfg file change <current hostname> to <new hostname>. 


7) Run the following command to list the current hostname/system name that is cataloged:
    db2 list admin node directory show detail 

    If there are no Admin Node Directory entries then you can skip the next 2 steps. It simply means that you haven't started the Control Center. The Admin Node Directory will get updated the next time the Control Center is started, based upon the current hostname. 
8) Uncatalog the current hostname using this command:
    db2 uncatalog node <nodename> 

9) Catalog the admin node with the new hostname using this command:
    db2 catalog admin tcpip node <nodename> remote <new hostname> system <new hostname> 

    <nodename> can be anything you want it to be (8 characters or less). It does not relate directly to the hostname itself.
    10) Update the admin configuration file using these commands:
      db2 update admin cfg using DB2SYSTEM <new hostname> 
      db2 update admin cfg using SMTP_SERVER <new hostname>

    11) At this time, you should restart your server if running Windows. Note that if your instances are set to auto-start, you may get error messages. These will occur if you have DB2_EXTSECURITY enabled. To correct this, you will need to update the DB2_ADMINGROUP and DB2_USERSGROUP registry entries using the db2extsec command. See the 'note' at the end of this technote for more details. 

    12) Login as the dasadm user on UNIX/Linux or Local Administrator on Windows. Start the DB2 Administration Server (DAS):
      db2admin start

    13) Login as the instance owner on UNIX/Linux or Local Administrator on Windows. Start the DB2 instance:
      db2start

    14) In Control Center find the old hostname under the "All Systems" folder and right click, choose Remove. 

    15) In Control Center add the new hostname. Right click on the "All Systems" folder and choose "Add". Click on "Discover" to locate the new hostname. 

    NOTE: 
    Starting in v9.1 FP2, DB2 supports the use of domain groups for extended security. Therefore, when you change the computer name and the computer groups DB2ADMNS and DB2USERS are local computer groups, you must update the DB2_ADMINGROUP and DB2_USERSGROUP global registries. Please see the Related URL for instructions on how to do this. 

    If Windows Extended Security has been enabled then you will need to tell DB2 to lookup the WIndows local groups DB2ADMNS and DB2USERS via the new hostname. For example if the hostname is changed to QASERVER then execute: 

    db2extsec /a QASERVER\DB2ADMNS /u QASERVER\DB2USERS 


    http://www-01.ibm.com/support/docview.wss?uid=swg21258834

    728x90
    728x90

    Problem(Abstract)

    You see errors like these on Windows when running ontape, oninit, starts, net start and so on as user informix:

    Only member of IXDBSA group (Informix-Admin, by default) can start IBM Informix Dynamic Server.
    Dynamic Server failed to start in Recovery Mode. Check Event Log for errors.
    System error 5 has occurred. Access is denied.

    Symptom

    • Only member of IXDBSA group (Informix-Admin, by default) can start IBM Informix Dynamic Server.
    • Dynamic Server failed to start in Recovery Mode. Check Event Log for errors.
    • System error 5 has occurred. Access is denied.

    Cause

    The behavior you are seeing is caused by one of these:

    • Windows User Account Controls (UAC) component is enabled
    • Lack of rights for user informix
    • The user is not part of the IXDBSA group (Informix-Admin, by default)

    Resolving the problem


    http://www-01.ibm.com/support/docview.wss?uid=swg21430794

    728x90
    728x90

    Problem(Abstract)

    Your IBM Informix server instance terminated unexpectedly. There is no message in server log file (online.log) indicating that it came offline.

    Diagnosing the problem

    Check your system for a file named olsrvice.log (not olservice.log). You may find the file in the Informix server directory, C:\WINDOWS\system32, or possibly another directory. If the file contains the message that follows, then the server was not brought offline by terminating the database server service.

    <timestamp>  Service was shut-down externally.

    You should be able to mimic this behavior by executing a taskkill command to kill oninit.exe:

    >taskkill /F /IM oninit.exe /T


    http://www-01.ibm.com/support/docview.wss?uid=swg21606530

    728x90
    728x90

    인포믹스 12.10이 출시되면서 인포믹스 모니터링 도구인 OAT가 Android와 iOS용으로도 공개되었습니다.

    Mobile OAT를 실행하려면 OpenAdmin Tool 3.11 버전이 설치되어 있어야합니다.

    아래는 제 iphone으로 실행한 화면을 캡쳐한 것입니다.

     

    OAT 주소, 언어, 모니터링 항목들을 설정하는 화면입니다.

     

    그룹 로그인에서는 OAT에 등록한 인스턴스 리스트를 간략하게 보여줍니다.

     

     

    아래와 같이 OAT의 주소를 직접 입력할 수 있습니다.

     

     

    DBSPACE 사용량에 대한 모니터링 내역입니다.

     

     

    아직은 모니터링 할 수 있는 영역이 다소 제한적이지만 현재로서도 상당히 유용한 툴인 것은 분명합니다.

    많은 관리자와 사용자가 사용하면서 개선이 이루어 진다면 좋겠습니다.

    728x90

    + Recent posts