IDS Forum

SQL 212/ISAM 131 Errors in dbimport

Posted By: DAVID GROVE
Date: Thursday, 6 October 2016, at 6:05 p.m.

I am attempting to do a dbimport into a newly created Informix instance. It fails with an SQL Code 212 "Cannot add index", and an ISAM Code 131 "ISAM error: no free disk space".

There are only two dbspaces (rootdbs and tempdbs) and two sbspaces (blobsbs and erqsbs) in this instance.

Previously, this exact same dbexport was successfully dbimported into the original Informix instance on the same box. At the time of that earlier successful import, all four of the spaces in that first instance had less space remaining in them than the new spaces in the new instance.

Actually, I first tried to do the import with a tempdbs that was only about half the size of the tempdbs in instance #1. About 1 hour 20 minutes into the import, it failed with the 212/131 errors. I doubled the size of the tempdbs and tried again. Same failure, at the same time (about 1 hr 20 min), and same place in the dbimport script. I increased the tempdbs a little more (to make absolutely certain that it is now larger than the tempdbs on the first instance), and, again, failure. Same time duration, same place in the dbimport script.

Here is the tail of dbimport.out:

{ TABLE "informix".omp_update_events row size = 32030 number of columns = 5 index size = 18 }

{ unload file name = omp_u02866.unl number of rows = 64500 }

create table "informix".omp_update_events
(

upid serial not null ,

omp_id integer not null ,

updt datetime year to fraction(5) not null ,

upusr char(8) not null ,

changes lvarchar(32000),

primary key (upid)
);

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

{ TABLE "informix".omp_update_compare row size = 31303 number of columns = 10 index size = 265 }

{ unload file name = omp_u02867.unl number of rows = 1170120 }

create table "informix".omp_update_compare
(

serialnum serial not null ,

omp_id integer not null ,

fldname varchar(255) not null ,

intval1 integer,

intval2 integer,

dateval1 datetime year to fraction(5),

dateval2 datetime year to fraction(5),

strval1 lvarchar(15000),

strval2 lvarchar(15000),

changedesc lvarchar(1000),

primary key (omp_id,fldname)
);
*** execute sqlobj
212 - Cannot add index.

131 - ISAM error: no free disk space

BTW, the column "fldname" is NOT NULL; its max length is 22, and its min is 3.

I am assuming that the error messages are actually appearing at the point in the code where the problem is. Hence, I am assuming that there is some problem with the "omp_update_compare" table, probably in the attempt to build the primary key index.

I would ask for any suggestions to aid in getting this file to import. Space wouldn't really seem to be the issue, since, as I mentioned, all the dbspaces and sbspaces in this current instance are larger than the space that was available in those same spaces in the first instance (in which the import was successful). Currently, immediately after the failure termination, Server Studio shows rootdbs at 50% used, blobsbs at 26%, erqsbs at 22%, and tempdbs at 0%. (This is after a post-termination refresh of the Server Studio storage display screen, so those are the actual final values.) During occasional spot checks during the import, I never observed the tempdbs to go above 0%.

I don't know what's wrong, or how to fix it.

Thank you for any comments or suggestions.

Regards,

DG

P.S. In the past, when I have had issues with dbimport, it was always after the table imports. Thus, I could fix whatever the problem was, and then "pick it up again" by running the remainder of the dbimport script as an sql file from DBaccess. However, I don't know how to resume the dbimport while it is still in the table portion of the script. Perhaps, I could strip out the remaining table portion, and run it as a new dbimport of a new database with a different name. I would keep chopping away until I could isolate the problem table (thinking it is the table indicated above, in the tail of dbimport.out) If I can get the tables into Informix, I think I can "brute force" the rest of the way. If I have to manually import a small number of tables, that is OK, too.

Messages In This Thread

• SQL 212/ISAM 131 Errors in dbimport
  DAVID GROVE -- Thursday, 6 October 2016, at 6:05 p.m.
  • Re: SQL 212/ISAM 131 Errors in dbimport
    Art Kagel -- Thursday, 6 October 2016, at 6:25 p.m.
    • Re: SQL 212/ISAM 131 Errors in dbimport
      DAVID GROVE -- Friday, 7 October 2016, at 2:20 a.m.
      • Re: SQL 212/ISAM 131 Errors in dbimport
        DAVID GROVE -- Friday, 7 October 2016, at 2:23 a.m.
      • Re: SQL 212/ISAM 131 Errors in dbimport
        Petr Pomykacek -- Friday, 7 October 2016, at 2:42 a.m.
        • Re: SQL 212/ISAM 131 Errors in dbimport
          DAVID GROVE -- Friday, 7 October 2016, at 3:00 a.m.
          • Re: SQL 212/ISAM 131 Errors in dbimport
            DAVID GROVE -- Friday, 7 October 2016, at 3:21 a.m.
            • Re: SQL 212/ISAM 131 Errors in dbimport
              Cliff Burton -- Friday, 7 October 2016, at 4:11 a.m.
            • Re: SQL 212/ISAM 131 Errors in dbimport
              Cliff Burton -- Friday, 7 October 2016, at 4:14 a.m.
              • Re: SQL 212/ISAM 131 Errors in dbimport
                DAVID GROVE -- Friday, 7 October 2016, at 5:02 a.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.