After the server hung during a Microsoft update application it was hard booted. At first the problem was that alerts designed to be presented to a single 7925 WiFi phone were being presented to all phones in the IPSession page group. Then I found the stattap.exe application (the "Status Solutions TAP Interface" service) was crashing shortly after startup. Several pending alerts could be sent and then the stattap.exe would crash. A symptom was that the IPCelerate SAM web GUI would display a "Got error 134 from table handler", rather than a grid of recent alerts.
Ultimately, the issue was a corrupted alarm_device table in the MySQL statsol database.
You can gain access to the MySQL database by running:
c:\ipcelerate\statsol\mysql\bin\mysql -u root -pstatsoldb statsol
You can see the tables in the statsol database by using:
SHOW TABLES;
The output should look similar to the following:
+-----------------------------+
| Tables_in_statsol |
+-----------------------------+
| action |
| alarm |
| alarm_device |
| alarm_device_image |
| alarm_device_type |
| alarm_log |
| alarm_log_2000_q1 |
The list continues but it's not shown here...
With that, wanting to check tables without being potentially destructive and having the most control during the process, I started checking tables by running:
CHECK TABLE ;
Given the number of tables in the list, I was happy to find the alarm_device table was an offender. The check, repair and recheck output is shown below:
The bad check...
mysql> check table alarm_device;
+----------------------+-------+----------+-------------------------------------
---------------------+
| Table | Op | Msg_type | Msg_text
|
+----------------------+-------+----------+-------------------------------------
---------------------+
| statsol.alarm_device | check | warning | 3 clients are using or haven't close
d the table properly |
| statsol.alarm_device | check | error | Unexpected byte: 0 at link: 179536
|
| statsol.alarm_device | check | error | Corrupt
|
+----------------------+-------+----------+-------------------------------------
---------------------+
3 rows in set (0.05 sec)
The repair...
mysql> repair table alarm_device;
+----------------------+--------+----------+------------------------------------
------+
| Table | Op | Msg_type | Msg_text
|
+----------------------+--------+----------+------------------------------------
------+
| statsol.alarm_device | repair | warning | Number of rows changed from 1645 to
1644 |
| statsol.alarm_device | repair | status | OK
|
+----------------------+--------+----------+------------------------------------
------+
2 rows in set (0.09 sec)
A good check...
mysql> check table alarm_device;
+----------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+----------------------+-------+----------+----------+
| statsol.alarm_device | check | status | OK |
+----------------------+-------+----------+----------+
1 row in set (0.01 sec)
After some discussions with Status Solutions support staff, they confirmed that the alarm_device table is a common issue after unclean reboots. They also indicated running mysqlcheck should not cause any issues while MySQL is running.
A much more efficient command is then:
C:\IPcelerate\statsol\mysql\bin\mysqlcheck --repair --check-only-changed -uroot -pstatsoldb statsol
The output should be similar to this:
statsol.action Table is already up to date
statsol.alarm OK
statsol.alarm_device OK
statsol.alarm_device_image Table is already up to date
statsol.alarm_device_type OK
statsol.alarm_log OK
statsol.alarm_log_2000_q1 Table is already up to date
The list continues below but is not shown...
mysqlcheck appears to run the manual check and appropriate repair in one process, as shown here:
http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html
No comments:
Post a Comment