Submit a ticketCall us

WebinarUpcoming Webinar: Know What’s Changed – with NEW Server Configuration Monitor

Change management in IT is critical. But, even with a good change management process, changes are too often not correctly tracked, if at all. The configuration of your servers and applications is a key factor in their performance, availability, and security. Many incidents can be tracked back to an authorized (and sometimes unauthorized) configuration change, whether to a system file, configuration file, or Windows® Registry entry. Join SolarWinds VP of product management Brandon Shopp to discover how the new SolarWinds® Server Configuration Monitor is designed to help you.

Register now.

Home > Success Center > Storage Manager (STM) > STM - Knowledgebase Articles > Manually Run a myisamchk in STM - Linux

Manually Run a myisamchk in STM - Linux

Table of contents


MyISAM is the default storage engine for MySQL databases. However, MyISAM tables get corrupted very easily because of any of the following reasons:

  • common wear and tear (If your DB is 10 GB in size or greater, then you probably want to automate this pruning task to occur something like once a month, if your DB is 20 GB in size then you want to probably automate this pruning taks to occur every other week)
  • AV software is trying to read/write the DB at the same time
  • another software is actively scanning the same subdirectory as <install>\mariadb\data\storage\ subdir</install>


STM v5, v5.6.2 and v5.7.2


To avoid and/or resolve this issue, manually run a myISAMCHK in Linux STM by doing the following steps:


  1. Connect to the Linux box/appliance via any of the following means:

    a. Remote Desktop Protocol

    b. SSH

    c. Telnet

    d. Terminal Session

    e. Others

  2. Login with ROOT and its accompanying ROOT level password.

  3. Navigate to /etc/init.d/ and stop all SW related services aka : stop storage manager service.

  4. Navigate to /opt/Storage Manager Server/mariadb/bin/.

  5. Run the following syntax: ./myisamchk --defaults-extra-file=../my.cnf --check --analyze -r -v ../data/storage/*.MYI

    As there are about 920 odd tables in the MYSQL db, the MYISAMDBCHK will scan the tables and look for the existence of crashed tables. If it finds any, the following steps will be performed automatically:

    a. Temporarily copy the crashed table and place it side by side next to the original table. 

    b. Repair the indexes in the copy and do an outright replacement. It will then dump the original table indexes, reloading it with the newly repaired table index.

    Note:  You will know when it is done when the cursor is sitting at the XioMon tables.

  6. Search for the existence of any TMD files (or any files with the TMD file extension). MYISAMDBCHK temporarily outputs a TMD file when it creates temporary indexes. 

    If any TMD files exist, it means that for whatever reason, the MYISAMDBCHK couldn't fix a particular table's indexes. Another search should be done in this case.

  7. Press the up arrow and re-run ./myisamchk --defaults-extra-file=../my.cnf --check --analyze -r -v ../data/storage/*.MYI.

  8. After ensuring that there are no more TMD files, navigate back to /etc/init.d/.

  9. Turn on the SW STM Services from etc/init.d/ aka: restart Storage Manager Server.

Last modified