728x90

Technote (FAQ)


Question

How to determine which tables require dummy updates in order to eliminate outstanding in-place alters before reversion to an earlier version?

Cause

In IBM Informix 11.70 there is a requirement for migration reversion: "In-place ALTER TABLE statements performed in the new version of the server must not be outstanding against any table."

Answer

1) Run 'oncheck -pt' command to identify which tables were altered in the current version. Qualifying tables must have tblspace flag 0x800000 set. For example:


    # oncheck -pt tdb:tab1 
    TBLspace Report for tdb:dmitriyr.tab1 

     Table fragment partition par1 in DBspace dbs1 

        Physical Address               2:5 
        Creation date                  06/25/2012 11:58:16 
        TBLspace Flags                 800802     Row Locking 
                                                  TBLspace use 4 bit bit-maps 
    <...>

As an alternative to 'oncheck -pt' you may run the following query against the Informix sysmaster database to find all qualifying tables: 
    SELECT ta.dbsname, ta.tabname, pt.partnum, HEX(pt.flags) flag 
    FROM sysmaster:systabnames ta, sysmaster:sysptnhdr pt 
    WHERE ta.partnum = pt.partnum 
    AND BIT_AND(HEX(pt.flags),'00800000'::BINARYVAR) = '00800000';

Sample result: 
    dbsname       tdb 
    tabname       tab1 
    partnum       2097154 
    flag          0x00800802

In above examples tblspace flag value is 0x800802. It is clear that value 0x800000 is set here. 

2) Run 'oncheck -pT <database>:<table>' against those tables identified in p.1 to find which tables have outstanding in-place alters. 

You must look at "Home Data Page Version Summary" section. For example: 
    <...> 
        Home Data Page Version Summary 

                     Version                                 Count 

                           0 (oldest)                           25 
                           1 (current)                          15 

    <...>

In the above example there are 25 pages to be altered to a new version. That means that a dummy update is required to be executed against that table. The steps to perform a dummy update is explained in detail within the migration guide:


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

728x90
728x90

Technote (FAQ)


Question

How do you identify outstanding in-place alters in order to resolve them?

These are sometimes call incomplete, or "unrealised" in-place alters.

This document is specifically for IDS version 11 and later. For IDS versions 7 to 10,
see http://www-01.ibm.com/support/docview.wss?uid=swg21226410

Cause

Since version 7.24, some ALTER TABLE statements have been done as "fast alters", where rows are only altered to fit the new schema when the data page they are on is next written to. If there are many alters done, this can lead to the data pages for a table being a variety of versions. When migrating to a later version (or just for the performance benefit) it is a good idea to "complete" the outstanding in-place alters.

Answer

The first step is to work out which tables have data pages at old versions:

There are several documented ways to determine altered tables, including:

  • The migration guide has SQL to identify all tables with in place alters (chapter 3, page 52). However, some versions of the manual have SQL like this:

      -- first set OPTCOMPIND to 0 in onconfig and restart instance 
        set isolation to dirty read; 

      select pg_partnum + pg_pagenum - 1 partn 
          from sysmaster:syspaghdr, sysmaster:sysdbspaces a 
         where pg_partnum = 1048576 * a.dbsnum + 1 
           and pg_next != 0 
          into temp pp with no log ; 

      select b.dbsname database, b.tabname table 
          from sysmaster:systabnames b, pp 
         where partn = partnum ; 
    which shows all tables that ever had an in-place or fast alter, and does not exclude those even where every data page has been rewritten (and therefore updated) since the ALTER TABLE was run.
  • The oncheck -pT utility prints a table showing all current versions on data pages, and page counts for each version, but it runs serially, locking the whole table, and takes a long while to run because it reports on many other things as well.


As these methods have drawbacks, the following steps can be used to obtain a more specific list of outstanding in-place alters: 

1. Set OPTCOMPIND to 0 in the onCONFIG configuration file and restart the instance. 

2. Set isolation to dirty read. 

3. Find every partnum in the tblspace tbspace of each non-temp dbspace where pg_next (pointer to extended partition page) is set to something other than zero. These tablespaces have been altered, and pg_next points to the pnvers (partition version) page. 

select (p.pg_partnum + p.pg_pagenum - 1) as partn, a.name as dbspace 
 from sysmaster:syspaghdr p, sysmaster:sysdbspaces a 
 where p.pg_partnum = 1048576 * a.dbsnum + 1 
  and a.is_temp = 0 and a.is_blobspace = 0 and a.is_sbspace = 0 
  and p.pg_next != 0 
into temp altpts with no log ; 


4. Get the database and table names, minimum and maximum possible page versions, plus row and data page numbers for all those partnums. 

  select b.dbsname database, b.tabname table, a.dbspace dbspace, 
          hex(a.partn) partnum, i.ti_nrows nrows, i.ti_npdata datapages, 
          p.pta_oldvers as oldvers, p.pta_newvers as newvers, 
          -1 as mindver, 999 as maxdver 
  from altpts a, outer sysmaster:sysactptnhdr p, 
       outer sysmaster:systabnames b, outer sysmaster:systabinfo i 
  where a.partn = b.partnum 
    and a.partn = i.ti_partnum 
    and a.partn = p.partnum 
   into temp tabvers with no log ; 


5. Scan all non-empty home data pages for each altered tablespace and get the 
minimum and maximum versions: 

  update tabvers set mindver = 
        ( select (min(pg_next)) / 16777216 
            from sysmaster:syspaghdr p, altpts a 
           where p.pg_partnum = a.partn 
             and tabvers.partnum = a.partn 
             and sysmaster:bitval(pg_flags, '0x1') = 1   
             and sysmaster:bitval(pg_flags, '0x8') <> 1 
             and pg_frcnt < (2020 - 4*pg_nslots) 
        ) 
   where 1 = 1 ; 

  update tabvers set maxdver =   
        ( select (max(pg_next)) / 16777216 
            from sysmaster:syspaghdr p, altpts a 
           where p.pg_partnum = a.partn 
             and tabvers.partnum = a.partn 
             and sysmaster:bitval(pg_flags, '0x1') = 1 
             and sysmaster:bitval(pg_flags, '0x8') <> 1 
             and pg_frcnt < (2020 - 4*pg_nslots) 
        )   
    where 1 = 1 ; 


6. Display the tablespaces which require updating to complete the in-place alters: 

   select database, table, dbspace, nrows, datapages, 
          oldvers as oldestv, mindver, maxdver, newvers as newestv 
     from tabvers 
    where newvers > mindver 
    order by 1, 2; 


The second step is to do a dummy update on at least one row on each of those pages not updated to the current version. 

For all tables which have been altered, but are not yet "complete" , you can run a "dummy update" statement, setting the primary key column to itself (or other "change" that changes nothing). This will bring all of the pages to the most current version: 

update TABNAME set PKEY = PKEY where 1 = 1 ; 


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

728x90
728x90

Technote (FAQ)


Question

How do you identify outstanding in-place alters in order to resolve them?

This document is specifically for IDS versions 7 to 10. For IDS version 11 and later,
see http://www-01.ibm.com/support/docview.wss?uid=swg21389693

Cause

Since version 7.24, some ALTER TABLE statements have been done as "fast alters", where rows are only altered to fit the new schema when the data page they are on is next written to. If there are many alters done, this can lead to the data pages for a table being a variety of versions. When migrating to a later version (or just for the performance benefit) it is a good idea to "complete" the outstanding in-place alters.

Answer

The first step is to work out which tables have data pages at old versions:

There are several documented ways to determine altered tables, including:

  • The 9.4 migration guide has SQL to identify all tables with in place alters (chapter 5, page 5):
    first set OPTCOMPIND to 0 in onconfig and restart instance
     set isolation to dirty read;

    select pg_partnum + pg_pagenum - 1 partn
       from sysmaster:syspaghdr, sysmaster:sysdbspaces a
      where pg_partnum = 1048576 * a.dbsnum + 1
        and pg_next != 0
       into temp pp with no log ;

    select b.dbsname database, b.tabname table
       from sysmaster:systabnames b, pp
      where partn = partnum ;

    Unfortunately, this shows all tables that ever had an in-place or fast alter, and does not exclude those even where every data page has been rewritten (and therefore updated) since the ALTER TABLE was run.
  • The oncheck -pT utility prints a table showing all current versions on data pages, and page counts for each version, but it runs serially, locks the whole table, takes a long while to run, and reports on many other things as well.

    This SQL will report the minimum and maximum version page version for a table (or by default, all tables) with incomplete alters. Dirty reads mean no locks, and it reports which dbspaces are involved too. It runs faster than oncheck -pT.

As these methods have drawbacks, the following steps can be used to obtain a more specific list of outstanding in-place alters: 

1. Set OPTCOMPIND to 0 in the onCONFIG configuration file and restart the instance. 

2. Set isolation to dirty read. 

3. Find every partnum in the tblspace tbspace of each non-temp dbspace where pg_next (pointer to extended partition page) is set to something other than zero. These tablespaces have been altered, and pg_next points to the pnvers (partition version) page. 

select (p.pg_partnum + p.pg_pagenum - 1) as partn, a.name as dbspace 
 from sysmaster:syspaghdr p, sysmaster:sysdbspaces a 
 where p.pg_partnum = 1048576 * a.dbsnum + 1   
           -- Tblspace tblspace partnums have format 0xnnn00001 
  and a.is_temp = 0 and a.is_blobspace = 0 and a.is_sbspace = 0 
           -- exclude tempspaces, blobspaces and smart blob spaces 
  and p.pg_next != 0 
           -- non zero = altered 
into temp altpts with no log ; 

4. Get the database and table names, plus row and data page numbers for all those partnums. 

select b.dbsname database, b.tabname table, 
       a.dbspace dbspace, hex(a.partn) partnum, 
       i.ti_nrows nrows, i.ti_npdata datapages, 
       -1 as minver, 999 as maxver 
  from altpts a, outer sysmaster:systabnames b, 
    outer sysmaster:systabinfo i 
  where a.partn = b.partnum and a.partn = i.ti_partnum 
into temp tabvers with no log ; 

5. Scan all non-empty home data pages for each altered tablespace and get 
the minimum and maximum versions: 

update tabvers set minver = ( 
  select (min(pg_next)) / 16777216 
  from sysmaster:syspaghdr p, altpts a 
  where p.pg_partnum = a.partn 
  and tabvers.partnum = a.partn 
  and sysmaster:bitval(pg_flags, '0x1') = 1  -- data page 
  and sysmaster:bitval(pg_flags, '0x8') <> 1 -- not remainder page 
  and pg_frcnt < (2020 - 4*pg_nslots)        -- with some data on it. 
) where 1 = 1 ; 

update tabvers set maxver = ( select (max(pg_next)) / 16777216 
  from sysmaster:syspaghdr p, altpts a 
  where p.pg_partnum = a.partn 
  and tabvers.partnum = a.partn 
  and sysmaster:bitval(pg_flags, '0x1') = 1 
  and sysmaster:bitval(pg_flags, '0x8') <> 1 
  and pg_frcnt < (2020 - 4*pg_nslots) 
)  where 1 = 1 ; 

Note the use of 2020 above is based on a dbspace with a 2KB pagesize, less the 24 byte header and 4 byte timestamp. For a 4KB pagesize use 4096 - 28 = 4078, for 8KB pagesize use 8192 - 28 = 8164, and so on. 

6. Display the tablespaces which require updating to complete the in-place alters: 

select database, table, dbspace, nrows, datapages, minver, maxver, 
 decode(maxver - minver, 0, "Maybe Needs Update", "Definitely Needs Update") 
 from tabvers 
order by 1, 2; 

The output of this SQL provides a list of which tablespaces (tables or fragments of tables) where in-place alters exist. If there are some data pages at a lower version from other data pages, then a dummy update is definitely required. If minver = maxver, then if there was an alter table statement run and no data pages have been written to since then (i.e. no inserts, updates, or deletes), then a dummy update may still be required. Prior to IDS version 11, it is not possible to determine from the sysmaster database what the potential maximum version of a data page is for a table. In version 11 there is a new sysmaster table called sysactptnhdr that does give this information. 


The second step is to do a dummy update on at least one row on each of those pages not updated to the current version. 

For all tables which have been altered, but are not yet "complete" , you can run a "dummy update" statement, setting the primary key column to itself (or other "change" that changes nothing). This will bring all of the pages to the most current version: 

update TABNAME set PKEY = PKEY where 1 = 1 ; 


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

728x90

+ Recent posts