Re: Errors -242 and -106
And if you have "intelligent :-)" daemon processes (that check if the
database is alive and re-connect to it if it is) connecting to the database
and your table that you want to drop, then it may be a good idea to revoke
permissions from all users but informix (or a database DBA user), go to
quiescent mode to kill the connections and go back online, do the drop, and
regrant the permissions.
Sujit
"Art S. Kagel" <kagel@bloomberg.net> on 03/23/99 07:04:05 AM
Please respond to kagel@bloomberg.net
To: informix-list@iiug.org
cc: (bcc: Sujit Pal)
Subject: Re: Errors -242 and -106
Ken V. Broezell wrote:
>
> On-Line 5.03
>
> I have a database chunk that is out of space:
>
> Chunks
> address chk/dbs offset size free bpages flags pathname
> 8178a4 1 1 0 100000 78511 PO-
/dev/inf_root_dbs
> 81793c 2 2 0 184000 0 PO-
/dev/inf_iprdbs <--
> 8179d4 3 3 0 21000 8986 PO-
/dev/inf_oosdbs
> 817a6c 4 4 0 39000 14107 PO- /dev/inf_bhdbs
> 817b04 5 5 0 75000 11061 PO-
/dev/inf_dsumdbs
> 817b9c 6 6 0 50000 48992 PO-
/dev/inf_usrdbs
> 817c34 7 7 0 222000 90659 PO-
/dev/inf_tmmdbs
> 817ccc 8 8 0 125000 22709 PO-
/dev/inf_rscdbs
> 817d64 9 9 0 60000 3318 PO-
/dev/inf_unodbs
> 817dfc 10 10 0 15000 5130 PO-
/dev/inf_smextdbs
> 817e94 11 11 0 10000 342 PO-
/dev/inf_unologdbs
>
> In trying to delete the table ipr_log from the chunk iprdbs I get the
> following errors:
>
> 242: Could not open database table (root.ipr_log).>
> 106: ISAM error: non-exclusive access.
> Error in line 1> Near character position 17
>
> Could someone tell me what needs to be done to work around/resolve the
> non-exclusive access problem?
>
> I am not manually doing this. Our developers of this database created
> a shell script called recluster that is trying to do this.
>
> Any assistance would be much appreciated.
To drop a table you have to be able to obtain an exclusive lock on the
table and on some of the system catalog pages/rows. The errors you got
indicate that the table is being accessed by another user session.
This can be an open cursor or just a prepared statement.
The solution is to close down all user applications that may be
accessing the table. You can be brutal if you can afford to kill off
all user apps. To do this you can run onmode -uy then onmode -m to get
back to multipuser mode then reorg the table.
If you cannot be so predatory you will just have to make sure all user
apps that may access that table are exited before attempting to reorg.
Art S. Kagel