October 26th, 2007

The *** service could not be started.

When I tried to start my Apache Tomcat application server’s Windows Service, this morning, I was greeted with a lovely error message:

$ net start tomcat5
The Apache Tomcat service is starting.....
The Apache Tomcat service could not be started.

More help is available by typing NET HELPMSG 3523.

Naturally, I wanted to know more about why it failed, so I typed the command that it suggested. The results were not quite what I’d consider “more help”:

$ NET HELPMSG 3523

The *** service could not be started.

Now, this is the point where I’d usually go into a thoroughly-researched, in-depth explanation of the root cause of the error. But, I didn’t bother investigating it any further, because I noticed shortly afterwards that the service actually DID start–just not immediately.

Looking at my Tomcat application debug log, I saw this:

25-Oct-2007 09:16:48 AM: [INFO] Server startup in 30124 ms

Usually, the numbers are a little smaller:

24-Aug-2007 12:08:08 PM: [INFO] Server startup in 15822 ms
24-Aug-2007 01:51:25 PM: [INFO] Server startup in 16736 ms

So, I’m guessing that the Windows Services controller got impatient, when Tomcat took 30 seconds to start instead of only 16 seconds. If I ever get this error message again, though, you’d better believe I’ll post a follow-up with a full explanation. :)

September 4th, 2007

Sybase UPDATEs taking forever/timing out? Time to dump tran!

I’m a programmer, not a DBA, but I do have to be able to perform basic database configuration and maintenance tasks. One thing that’s come up, a couple times, over the past few years, is a transaction log getting full.

There are a couple of reasons this can happen:

  • poorly written queries that run for a very long time
  • applications neglecting to end transactions, when they encounter error conditions

Here are a few useful commands I’ve found that deal with transaction logs (Note: I’m using Sybase ASE 12.5.1):

check for long-running transactions (found here):
use master;

SELECT * FROM syslogshold
WHERE dbid = db_id(’MyDbName’);

transaction log space free:
SELECT CONVERT(CHAR,
(lct_admin('logsegment_freepages', 4) -
lct_admin('reserved_for_rollbacks', 4)) * 2)

transaction log space total:
SELECT SUM(size)
FROM master..sysusages
WHERE dbid = db_id('MyDbName')
AND segmap & 4 = 4 -- logsegment

dump the transaction log (clears it out, so things can get moving again!):
***WARNING*** Use this command at your OWN RISK! Please do some additional reading before executing the following statement, so that you fully understand the implications. The transaction log is there for a reason, and, from what I understand, you should not tamper with it unless you know what you’re doing. On the occasions that I’ve used this, it was a last resort. It solved my problems, with no ill effects, but it might not solve yours!

dump tran myDbName with truncate_only;
commit;

For additional information/reference, Sybase’s online books sometimes come in handy. When trying to find out how to dump transaction logs, I referred to their dump transaction page.

Another site I’ve found useful*, on numerous occasions, is Sybase 101. I found a related tip, there, for tips, there, for Dealing With Server Failure, which addresses what to do when your log fills up completely, such that you can’t even restart the server.

*Beware: I just noticed that Sybase 101 has become less useful than it used to be, because useful pages are automatically redirecting to one main start page. If they were just trying to prevent deep linking from the outside world, I could understand this behavior a little more; but it’s even happening when I click other links from their own site! Navigation works fine with javascript disabled, though.

June 3rd, 2005

Sybase ASE 12.5 error message about ’select into’ option needing to be enabled

Sybase (ASE 12.5) error message I was getting when trying to modify a column’s metadata/attributes:
The ’select into’ database option is not enabled for database ‘myDbName’. ALTER TABLE with data copy cannot be done.
Set the ’select into’ database option and re-run.

Solution that worked for me (including the column-altering command in the middle):

USE master;
EXEC sp_dboption “myDbName”,”select into/bulkcopy”,true;
COMMIT;
USE myDbName;
ALTER TABLE myTableName
MODIFY myColumnName varchar(60) NOT NULL;
USE master;
EXEC sp_dboption “myDbName”,”select into/bulkcopy”,false;
COMMIT;

References:

Ed Barlow’s “fix_db.pl” script, which I happened to find the solution in when grepping my local machine.
http://www.edbarlow.com/document/utilities/readme.htm This page, where I stumbled across the solution eventually, as one of many google search results. I had result pages open in several windows, and was looking through them when I noticed the grep results.
http://www.devx.com/vb2themax/Tip/18583