|
|
|
|
|
MOVEit DMZ uses a database server to store information about everything from organization settings, to user account information, to folder and file information. Normally, this database operates silently, behind the scenes of MOVEit DMZ, and requires no active maintenance on the part of the administrator to operate.
Rarely, however, one or more database tables can become corrupted and will cause part of the MOVEit DMZ application to stop functioning. These corruptions are often caused by unexpected reboots, such as during a power failure. They can also occur when backup programs make copies of database table files while the database server is running. (See also Alternate Backup Suggestions below.) When a database table is corrupted, it can no longer be accessed by the database server until it has been repaired.
If you think you have had, or may be having a database corruption problem, the first thing to check is the DMZ debug log. MOVEit DMZ accesses the database server several times during a typical session, and when serious database problems occur, they are always logged to the debug log. For more information about debug logs, see the Debug Logs manual page. Here are some examples of table corruption errors that would be found in the debug log:
[TCX][MyODBC]Can't open file: 'folderperms.MYD'. (errno: 145)
[TCX][MyODBC]Got error 134 from table handler
The problems that can be encountered with databases are sometimes specific to the brand of database engine in use. Most of the suggestions here apply when MySQL is being used as the database engine.
Recent versions of MOVEit DMZ have enabled a MySQL database option which automatically repairs tables that it finds corrupted, meaning most of these occurrences come and go with hardly any notice by end users. Though no action on the part of the administrators is required in these cases, administrators may wish to keep informed of any such happenings. Information is logged by the database server when such corruptions occur, and when they are automatically repaired. Look for this log information in the \mysql\data directory of your MOVEit DMZ server. It will be stored in a file named HOSTNAME.err, where HOSTNAME is the name of the server. A typical corruption detection and repair event will be logged like this:
041122 1:13:58 read_const: Got error 134 when reading table ./moveitdmz/folderperms
041122 1:14:00 read_const: Got error 134 when reading table ./moveitdmz/folderperms
041122 1:41:46 Warning: Checking table: './moveitdmz/folderperms'
041122 1:41:46 Warning: Recovering table: './moveitdmz/folderperms'
In the very rare case that the automatic table repair functionality fails, you will need to repair the table manually. It is not necessary to stop any MOVEit DMZ services during the manual repair process. (For the purposes of this discussion MOVEit DMZ services include FTP, SSH, IIS, Windows Scheduler, MySQL and SysStat.) In fact, the MySQL service MUST be running for this sequence of commands to succeed.
To manually repair a database table, open a command-prompt on your DMZ system and log in to the MySQL server using the root account created during the DMZ installation. To log onto the MySQL server using root, cd to your \mysql\bin directory and issue this command:
mysql --user=root --password=YOUR_ROOT_PASSWORD moveitdmz
Once logged in, execute the CHECK TABLE command against the table you believe has been corrupted, like so:
CHECK TABLE folderperms;
This command will typically generate several lines of information. The last line will tell you the status of the table. If the CHECK response indicates the table needs to be repaired, issue the repair command like so:
REPAIR TABLE folderperms;
This may take several minutes, depending on the size of the table, and generate several lines of output. If the repair was successful, the last line of output will contain a status message of OK.
If the manual repair process was unsuccessful after several tries, contact MOVEit support for assistance.
Many backup programs (Veritas, for example) often corrupt open database or configuration files; this behavior is somewhat platform-specific. To avoid these problems, try one or both of these field-tested suggestions:
For additional help, you may want to consult the Knowledge Base on our support site at http://ipswitchft.force.com/kb/knowledgeProduct?c=MOVEit_DMZ.