We ran a tsql command from a script file of ours (activated via a cron job), and it seems to have exited prematurely. Is there a logfile which might hold the error, if any, which occured in the tsql command? monitor.log, maybe? Thanks.
logging for tsql errors?
logging for tsql errors?
Tsql is a tool for ad-hoc queries and maintenance. It doesn't log to any file. Capture standard output and standard error to see everything it might say. Errors would generally be printed on standard error. Cron will generally mail uncaptured output to the owner of the cron job. Check that user's mailbox.
logging for tsql errors?
OK-- thanks.
No mail delivered or errors from the standard output (we're redirecting it to the log file), but maybe you've seen this problem before?
If we create an index like so:
tsql "create index myindex on mytable(field01)"
it gets created quickly enough.
However, any metamorph index command, such as
tsql "create metamorph inverted index myindextwo on mytable(field01)"
starts up, peaks at around 20% of CPU, then descends down to something like 0.1% of CPU after about a minute.
The tsql command still appears in "ps" listings, but the .tok file stops growing after precisely 1572864 bytes. No T* files appear in the directory, either.
This happens on any metamorph index we try to create in this database (all fields are of the varchar variety, some varchar(255), others varchar(1000)), but not in any other databases we have on this box. We've reindexed this database often enough in the past and have never seen this problem.
Have you ever seen this before or have an idea on what might be going on?
We're on Solaris 2.8, texis version 04.00.1019027849.
No mail delivered or errors from the standard output (we're redirecting it to the log file), but maybe you've seen this problem before?
If we create an index like so:
tsql "create index myindex on mytable(field01)"
it gets created quickly enough.
However, any metamorph index command, such as
tsql "create metamorph inverted index myindextwo on mytable(field01)"
starts up, peaks at around 20% of CPU, then descends down to something like 0.1% of CPU after about a minute.
The tsql command still appears in "ps" listings, but the .tok file stops growing after precisely 1572864 bytes. No T* files appear in the directory, either.
This happens on any metamorph index we try to create in this database (all fields are of the varchar variety, some varchar(255), others varchar(1000)), but not in any other databases we have on this box. We've reindexed this database often enough in the past and have never seen this problem.
Have you ever seen this before or have an idea on what might be going on?
We're on Solaris 2.8, texis version 04.00.1019027849.
logging for tsql errors?
How many rows are in the table (select count(*) from mytable)? I'm guessing 196608. Are there any other processes attempting to create regular indexes on this table at the same time as the Metamorph index?
logging for tsql errors?
It turns out there was a vortex script running at the same time as my tsql commannd, doing a TIMPORT (or trying to) into the database. I'm guessing this would cause the behavior I described above?
What's that old saying about too many chefs in the kitchen?
There were actually about 208,000 rows in the table when the indexing began.
One more thing, if I could-- a few days ago I posted a question, asking if it's possible to put a database into "read-only" mode?
The idea is to stop write activity on the db, ftp it over to a secure location for backup, then allow full access to it again. Ideally, we'd still allow users to search the database while the ftp was in progress, but I'm not sure if that's possible. If you have suggestions on a good way to do this, I'm all ears...
What's that old saying about too many chefs in the kitchen?
There were actually about 208,000 rows in the table when the indexing began.
One more thing, if I could-- a few days ago I posted a question, asking if it's possible to put a database into "read-only" mode?
The idea is to stop write activity on the db, ftp it over to a secure location for backup, then allow full access to it again. Ideally, we'd still allow users to search the database while the ftp was in progress, but I'm not sure if that's possible. If you have suggestions on a good way to do this, I'm all ears...
logging for tsql errors?
The timport would cause lots of write locks; since the index process needs lots of read locks, its CPU would go down some as it waits occasionally. It's a bit suprising that it drops so low after a minute though, but then that depends exactly what the other timport script is doing and when. Is this an update or a first-time create for the Metamorph index?
logging for tsql errors?
There's currently no simple way to read lock the entire database.
Applications that end users would be using that required writing would likely timeout or cause the user to get very upset if the database were locked for any length of time. It would generally be better if the app was aware of what's going on and could tell the user to try later or some such.
Applications that end users would be using that required writing would likely timeout or cause the user to get very upset if the database were locked for any length of time. It would generally be better if the app was aware of what's going on and could tell the user to try later or some such.