table won't respond

Post Reply
jkj2001
Posts: 142
Joined: Fri Mar 29, 2002 1:39 pm

table won't respond

Post by jkj2001 »

Hi,

We have a large table (18 GB blob file) that we're recently having trouble with. If we try selecting any column in it via tsql, the session simply sits there, even if we're running a select statement without an order by clause.

We don't see any errors, but after the select statement (and the enter key) we see the column headers flash by (as they always do), but things just there afterwards-- no data returns. A tsql command with the -V flag tells us: "999 Handling a table project in the function dotree," but then it too just sits there.

A similar problem happens if we try indexing a field. We can drop the old index, but a tsql command to reindex does nothing but sit around.

We have another table in this directory, and it works just fine. It is 1/10th the size, however....

Any ideas what we can try to get moving again, or suggestions on what's happening here? We're using your Linux flavor of texis, version # 4.04.1067366033.
User avatar
mark
Site Admin
Posts: 5519
Joined: Tue Apr 25, 2000 6:56 pm

table won't respond

Post by mark »

"flash by"? I would expect them to sit there if it wasn't doing anything. Is it printing blank lines?

Another possibility, there are a huge number of deleted records in the beginning of the table and it's taking a while to skip them before returning the first real data.

What does ltest show as the lock status for that table while it's sitting (set refresh to 1 or 0 (by hitting 1 or 0) to see more rapid activity)?
jkj2001
Posts: 142
Joined: Fri Mar 29, 2002 1:39 pm

table won't respond

Post by jkj2001 »

Maybe I misspoke-- nothing flashes by except for the column names. They remain at the top of the screen while the telnet window sits there. No blank lines fill the screen, if that's what you were asking.

I ran ltest and saw my table listed in there with (18) listed in parentheses. ltest also revealed a process ID that was running an update statement against the table (a one-record update, in fact). I killed the PID, and now I can select from the table again, so many thanks. No locks now on that table.

ltest also reveals a PID that relates to your monitor daemon, but I suppose killing that or running monitor -k isn't suggested here?
User avatar
mark
Site Admin
Posts: 5519
Joined: Tue Apr 25, 2000 6:56 pm

table won't respond

Post by mark »

The monitor will just restart if you kill it. No point to killing it if it's not doing something wrong.

Maybe your update wasn't using an indexed field as the key and had to linearly scan?
Post Reply