suche 36x36
  • Admin-Scout-small-Banner
           

    CURSOR Admin-Scout

    get the ultimate tool for Informix

    pfeil  
Latest versionsfixlist
14.10.xC10 FixList
12.10.xC16.X5 FixList
11.70.xC9.XB FixList
11.50.xC9.X2 FixList
11.10.xC3.W5 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

Informix - Problem description

Problem IT18280 Status: Closed

CONCURRENT READERS AND ALTER FRAGMENT ONLINE STATEMENTS CAN LEADTO
PERSISTENT ISAM -135 ERRORS

product:
INFORMIX SERVER / 5725A3900 / B70 - IDS 11.70
Problem description:
Using an interval fragmented table in an unlogged database with
1 process doing inserts to add new fragments, and then looking
for fragments to detach via the alter fragment online command to
detach and then dropping the detached fragment while another
reader process is just hammering the table with select
statements can cause the following scenario:

It's possible for the in memory data dictionary to get out of
sync with the information in the system catalogs.  It appears
that information for a detached and dropped fragment can either
persist or incorrectly be place into a fresh copy of the data
dictionary.  At that point, the insert statements and selects
can fail with isam -135 errors (until such time as the data
dictionary gets refreshed because the current in memory copy is
either purged when it gets marked dirty, or if somehow table
activity goes to 0 and it would be removed because the
dictionary is too full).

If this were to occur, you would see something like the
following.  In onstat -g dic  if you looked at the
fragment information for the table the number of fragments is
reported in this section:

Dictionary entry for table:  [hashes to list#: 17]

ddt_tabfullname: 
ddt_partnum:    0   ddtab-address:  4df2e858
ddt_fextsize:   4346    ddt_nextsize:   1088    ddt_locklevel:
2
...
ddt_reftabs:    0   ddt_next:   0   ddt_prev:   0
ddt_refcount:   2   ddt_frags:  4dfe5070
lf_nfrags:  34  lf_strategy:    128 (interval)
lf_afrag:   4e00bd20    lf_fragpart:    4dfe5fd8    lf_collist:
4dfe5768

So in the above the 'lf_nfrags' indicates that the in memory
dictionary believes there should be 34 data fragments.

But if you were to then run the following query on sysfragments
for the table in database where the table resides you would get
a different result on the number of fragments:

select count(*) from sysfragments where tabid =  and partition != 0 and fragtype = "T";

It would usually be off by 1 and it would be 1 fewer then
reported in the onstat -g dic output.
Problem Summary:
****************************************************************
* USERS AFFECTED:                                              *
* all users                                                    *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* See Error Description                                        *
****************************************************************
* RECOMMENDATION:                                              *
* Update to IBM Informix Server 11.70.xC9                      *
****************************************************************
Local Fix:
Solution
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
06.12.2016
09.06.2017
09.06.2017
Problem solved at the following versions (IBM BugInfos)
11.70.xC9
Problem solved according to the fixlist(s) of the following version(s)
Informix EditionsInformix Editions
Informix Editions
DocumentationDocumentation
Documentation
IBM NewsletterIBM Newsletter
IBM Newsletter
Current BugsCurrent Bugs
Current Bugs
Bug ResearchBug Research
Bug Research
Bug FixlistsBug Fixlists
Bug Fixlists
Release NotesRelease Notes
Release Notes
Machine NotesMachine Notes
Machine Notes
Release NewsRelease News
Release News
Product LifecycleProduct Lifecycle
Lifecycle
Media DownloadMedia Download
Media Download