db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Cook (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-7043) DROP SCHEMA results in ERROR XSAI2
Date Thu, 02 May 2019 23:10:00 GMT

     [ https://issues.apache.org/jira/browse/DERBY-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Cook updated DERBY-7043:
-----------------------------
    Description: 
DROP SCHEMA schemaname RESTRICT results in:

    *{color:#d04437}ERROR XSAI2: The conglomerate (1,024) requested does not exist.{color}*

Prior to DROP SCHEMA, I did drop all tables in that schema.

I realize that 1,024 conglomerate number translates into c400.dat file in Derby seq0 directory,
and that c400.dat file is indeed missing, and I neither know why nor for how long.

I ran consistency checks on database using SQL commands from [https://wiki.apache.org/db-derby/DatabaseConsistencyCheck] to
find the bad table(s):

    *{color:#14892c}I isolated the 1,024 conglomerate error to the SYS.SYSSEQUENCES table.{color}*

And I used the following SQL to identify the conglomerate name:  {color:#654982}*SYSSEQUENCES_HEAP*{color}

SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME  FROM SYS.SYSCONGLOMERATES
C, sys.sysschemas s  WHERE CONGLOMERATENUMBER = 1024 AND s.schemaid = C.schemaid

In fact, I cannot even SQL SELECT on SYS.SYSSEQUENCES table without getting the same conglomerate
error as the DROP SCHEMA schemaname RESTRICT command.

In other words, I cannot DROP SCHEMA schemaname RESTRICT until SYS.SYSSEQUENCES corruption
is resolved.

I was wondering if anyone knew how to resolve this easily with either SQL command(s) or any
UNIX style java commands that I can run from QSH environment on our IBM Power9 (a.k.a. AS400).

P.S.  Keep in mind, that I am not an IJ expert, as I have been using a simple front-end Derby
tool created by our manufacturer to run SQL statements on Derby DB, without all the complexity
of using IJ and setting up IJ with environment variables, classpaths, etc.

  was:
DROP SCHEMA schemaname RESTRICT results in:

    *{color:#d04437}ERROR XSAI2: The conglomerate (1,024) requested does not exist.{color}*

Prior to DROP SCHEMA, I did drop all tables in that schema.

I realize that 1,024 conglomerate number translates into c400.dat file in Derby seq0 directory,
and that c400.dat file is indeed missing, and I neither know why nor for how long.

I ran consistency checks on database using SQL commands from [https://wiki.apache.org/db-derby/DatabaseConsistencyCheck] to
find the bad table(s):

    *{color:#14892c}I isolated the 1,024 conglomerate error to the SYS.SYSSEQUENCES table.{color}*

And I used the following SQL to identify the conglomerate name:  {color:#654982}*SYSSEQUENCES_HEAP*{color}

SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME  FROM SYS.SYSCONGLOMERATES
C, sys.sysschemas s  WHERE CONGLOMERATENUMBER = 1024 AND s.schemaid = C.schemaid

In fact, I cannot even SQL SELECT on SYS.SYSSEQUENCES table without getting the same conglomerate
error as the DROP SCHEMA schemaname RESTRICT command.

In other words, I cannot DROP SCHEMA schemaname RESTRICT until SYS.SYSSEQUENCES corruption
is resolved.

I was wondering if anyone knew how to resolve this easily with SQL command(s)?

P.S.  Keep in mind, that I am not an IJ expert, as I have been using a simple front-end Derby
tool created by our manufacturer to run SQL statements on Derby DB, without all the complexity
of using IJ and setting up IJ with environment variables, classpaths, etc.


> DROP SCHEMA results in ERROR XSAI2
> ----------------------------------
>
>                 Key: DERBY-7043
>                 URL: https://issues.apache.org/jira/browse/DERBY-7043
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.8.2.2
>         Environment: OS/400
>            Reporter: Rick Cook
>            Priority: Minor
>
> DROP SCHEMA schemaname RESTRICT results in:
>     *{color:#d04437}ERROR XSAI2: The conglomerate (1,024) requested does not exist.{color}*
> Prior to DROP SCHEMA, I did drop all tables in that schema.
> I realize that 1,024 conglomerate number translates into c400.dat file in Derby seq0
directory, and that c400.dat file is indeed missing, and I neither know why nor for how long.
> I ran consistency checks on database using SQL commands from [https://wiki.apache.org/db-derby/DatabaseConsistencyCheck] to
find the bad table(s):
>     *{color:#14892c}I isolated the 1,024 conglomerate error to the SYS.SYSSEQUENCES
table.{color}*
> And I used the following SQL to identify the conglomerate name:  {color:#654982}*SYSSEQUENCES_HEAP*{color}
> SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME  FROM SYS.SYSCONGLOMERATES
C, sys.sysschemas s  WHERE CONGLOMERATENUMBER = 1024 AND s.schemaid = C.schemaid
> In fact, I cannot even SQL SELECT on SYS.SYSSEQUENCES table without getting the same
conglomerate error as the DROP SCHEMA schemaname RESTRICT command.
> In other words, I cannot DROP SCHEMA schemaname RESTRICT until SYS.SYSSEQUENCES corruption
is resolved.
> I was wondering if anyone knew how to resolve this easily with either SQL command(s)
or any UNIX style java commands that I can run from QSH environment on our IBM Power9 (a.k.a.
AS400).
> P.S.  Keep in mind, that I am not an IJ expert, as I have been using a simple front-end
Derby tool created by our manufacturer to run SQL statements on Derby DB, without all the
complexity of using IJ and setting up IJ with environment variables, classpaths, etc.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message