Informix

Informix

Connect with Db2, Informix, Netezza, open source, and other data experts to gain value from your data, share insights, and solve problems.

 View Only
  • 1.  Upgrade IDS

    Posted Tue February 18, 2020 03:46 AM
    Hello everybody,

    during inplace upgrade of the database
    IBM Informix Dynamic Server version 12.10.UC4
    to
    IBM Informix Dynamic Server Version 12.10.UC13

    the following error -530 is written to the log file:

    ================================================================================================
    01/22/20 11:30:26  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Pl
    og used 139, Llog used 53

    01/22/20 11:30:26  The restore point ended and related data in directory /opt/informix/tmp
    /9 were removed.
    01/22/20 11:30:27  Auto Registration is synced

    01/22/20 11:30:27  SCHAPI: SQL Error -530, ISAM Error 0 in file /opt/informix/etc/sysadmin
    /low_memory_mgr.sql at line 19

    01/22/20 11:30:27  SCHAPI: 'sysadmin' database setup is incomplete.
    01/22/20 11:30:28  Installing patch to upgrade ph_task code. version(13.10)
    01/22/20 11:30:28  SCHAPI: Started 2 dbWorker threads.
    01/22/20 11:30:28  Defragmenter cleaner thread now running
    01/22/20 11:30:28  Defragmenter cleaner thread cleaned:0 partitions
    ================================================================================================

    I cannot determine in the sql file why the error occurs.
    Does anyone have experience with the error message?
    Operating system:
    SUSE Linux Enterprise Server 11 (i586)
    VERSION = 11
    PATCHLEVEL = 1

    Thank you in advance
    Heinz

    ------------------------------
    Heinz Weitkamp
    ------------------------------

    #Informix


  • 2.  RE: Upgrade IDS

    Posted Tue February 18, 2020 05:49 AM
    Heinz:

    Not a problem. The upgrade of sysadmin sometimes fails when you are jumping many versions. The fix is to drop and recreate sysadmin from scratch. Here is what you need to do:

    1. Put the server into single user mode (onmode -j)
    2. Note any changes you have made to the ph_task table such as scheduling tasks or turning tasks on or off that is different than the defaults (you can just unload the table for checking later if you want).
    3. If you didn't unload ph_task in step 1 but have any tasks you created yourself, unload those rows at least.
    4. Unload the ph_threshold table if you have changed any threshold parameters from their defaults.
    5. Unload the storagepool table if you are using storage pools.
    6. Unload the tenant table if you are using tenants.
    7. Use dbschema or myschema to save any stored procedures you have created or modified in sysadmin to .sql file(s). Do not save any built-in procedures!
    8. Drop the sysadmin database.
    9. Follow the directions here to recreate it:
      https://www.ibm.com/support/pages/rebuilding-sysadmin-database-manually
    10. Apply the changes you have saved.
    Art

    Art S. Kagel, President and Principal Consultant
    ASK Database Management


    Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference.  Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.








  • 3.  RE: Upgrade IDS

    Posted Tue February 18, 2020 06:04 AM
    I have encountered that error before, also during an upgrade to Informix version 12.10.XC13 ( from version 12.10.XC7 ).
    What I think that is happening is that there is a correction to the ph_threshold table, in the check constraints:

    DBSCHEMA Schema Utility INFORMIX-SQL Version 12.10.FC13
    { TABLE "informix".ph_threshold row size = 4652 number of columns = 6 index size = 269 }

    create table "informix".ph_threshold
    (
    id serial not null ,
    name varchar(254),
    task_name char(36),
    value lvarchar,
    value_type varchar(254)
    default 'STRING',
    description lvarchar,

    check (((UPPER(value_type ) MATCHES 'STRING' ) OR (UPPER(value_type ) MATCHES
    'NUMERIC' ) ) OR (UPPER(value_type ) MATCHES 'NUMERIC(*,*)' ) )
    ) extent size 16 next size 16 lock mode row;

    revoke all on "informix".ph_threshold from "public" as "informix";

    create unique index "informix".ix_ph_threshold_01 on "informix"
    .ph_threshold (id) using btree in imon_dbs;
    create index "informix".ix_ph_threshold_02 on "informix".ph_threshold
    (name) using btree in imon_dbs;

    The check constraint in the value_type column is expecting  a comma for the decimal separator ( MATCHES 'NUMERIC(*,*)' ), but in previous versions of Informix, this threshold values for the low memory manager were defined using a period ( . ). When the script tries to copy the old values, the new corrected check constraint prevents it.

    I opened a defect with IBM/HLC regarding the issue, but don't know if is already fixed in more recent versions ( 14.10.X versions ).

    If you still have have Informix version 12.10.xC4 around, you can confirm that the threshold values for the low memory manager use a period instead of a comma:

    dbaccess sysadmin
    select * from ph_threshold where task_name = 'Low Memory Manager';

    One of the workarounds is to restart the Informix instance again. It will re-apply the low memory manager update, this time without errors. I don't know if it will reset the thresholds for the low memory manager ( I don't make use of the low memory manager ).

    Best regards,
    Luis Marques







    ------------------------------
    Luis Marques
    ------------------------------



  • 4.  RE: Upgrade IDS

    Posted Tue February 18, 2020 08:20 AM

    Thanks Art and Luis for the competent and quick answer.

     

    Now I know what happened and what I have to do.

     

    Have a good time.

     

    Heinz




    WESTFLEISCH SCE mit beschränkter Haftung, Hauptsitz: Brockhoffstr. 11, 48143 Münster
    Amtsgericht Münster: Gen.-Reg. 448

    Aufsichtsratsvorsitzender: Josef Lehmenkühler
    Vorstand: Dirk Niederstucke (Vorsitzender); Peter Piekenbrock; Gerhard Meierzuherde; Carsten Schruck, Johannes Steinhoff, Steen Sönnichsen (Geschäftsführer)





  • 5.  RE: Upgrade IDS

    Posted Wed February 19, 2020 03:53 AM
    Yes - I have also encountered this in two different 12.10 upgrade projects, but just rerunning that one SQL script afterwards recreated missing objects with no apparent ill effects.

    ------------------------------
    Doug Lawry
    ------------------------------



  • 6.  RE: Upgrade IDS

    Posted Wed February 19, 2020 04:01 AM
    Thank you very much Doug
    for your answer.
    That calms me down a lot and I can sleep better now :-)
    
    greeting
    Heinz


    ------------------------------
    Heinz Weitkamp
    ------------------------------



  • 7.  RE: Upgrade IDS

    Posted Wed February 19, 2020 09:10 AM

    Doug / et al:

    My company run IDS on Windows I too have run into issue upgrading to IDS12.10.FC13.  As I have not had time to track down the cause of the problems.  I no longer use 12.10.FC13 but instead have standardized on 12.10.FC12W1 until I can fully test my company's software under IDS 14.10..  I have not had any issues with upgrades to 12.10.FC12 either as a point upgrade from another version of IDS12.10 or an in-place migration from earlier versions (e.g. 11.70.FCx).



    ------------------------------
    Best regards,
    Martin Graney
    Queues Enforth Development, Inc.
    Stoneham, MA 02148
    ------------------------------



  • 8.  RE: Upgrade IDS

    Posted Wed February 19, 2020 09:23 AM

    Or if you are doing a lot upgrade/testing then just edit the error out of the script. I am seeing a lot TS virtual table 'failures' in one of my upgrade to 14.10.FC3 cycles, as we don't use TS then I can just tweak the SQL

     

    Cheers

    Paul

     






  • 9.  RE: Upgrade IDS

    Posted Wed February 19, 2020 10:25 AM
    Probably the first run fixed the threshold values and the rerun fixed the check constraints.