You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Cook (JIRA)" <ji...@apache.org> on 2019/05/03 19:09:00 UTC
[jira] [Closed] (DERBY-7043) DROP SCHEMA results in ERROR XSAI2
[ https://issues.apache.org/jira/browse/DERBY-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Cook closed DERBY-7043.
----------------------------
Resolution: Workaround
Oldest Derby backup we had was from 8/8/2018, and did not contain the c400.dat file. Do not know how or when the c400.dat file was deleted from seg0 directory. A missing c400.dat file never created a problem with application software--just when I wanted to drop a unused schema.
Workaround:
1) Re-downloaded Derby version 10.8.2.2.
2) Created a new database
3) Restored c400.dat from that new database to my other Derby database.
> 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.
> 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)