2015-02-09

ハードディスクの不良ブロックとメーカーサポート


Windows Server 2008 のイベントログに、イベントID:7、「デバイス \Device\Harddisk0\DR0 に不良ブロックがあります。」が記録されていることに気づいた。普段はでないのだが、毎金曜の真夜中に開始されるフルバックアップを実行する度に出ていた。

ググると、CHKDSK /F を行えとか、ディスクのプロパティを選択して、 ツール→エラーチェック を行え、とか書いてある。 CHKDISK単独ならエラーは出ない。 が、パラメータに /F や /R を付けると、サーバ稼働中は実行できない旨のメッセージが出る。サーバなので、そう簡単には落すわけにはいかぬ。
ネット上には、ハードディスクに問題がある可能性があるので交換したほうが良い、という書き込みも散見された。

ということで、メーカーのDELLのサポートに電話をかけるとすぐに繋がる。 DELLはいろいろ言われているが、"サーバ"のサポートはいつも良い。 担当に現象を説明すると、原因を精査するには、以下の3つの方法(いずれもプログラム)があると言う。
  1. Server Asministrator
  2. DSET
  3. Diagnostics
上記1と3はサーバを一旦は停止しなければならないため、 「2.DSET」(ディーセット、と読むらしい)という診断プログラムを送付してもらい、実行した。終了すると、ZIPファイルが出来上がるので、それを返送する。
夜も更けてきても電話が来ないので、こちらから電話をしてみると別の担当者が出て、送ったファイルを見てもらう。と、即「ディスクに異常がある」とのこと(ふーん、そんな簡単に解るのか!?)で、ディスク交換となった。

なにが言いたいかというと、重要なハードはやはりハード屋に任せるのが良いということ。トラブル発生時、イベントログをチェックし、CHKDSK を行い、ググる、位までのところはなんとかなる。 そこで見当をつけてHDDやらの部品を調達して交換とかも、クライアント機であればなんとかなる。が、ダウンタイムを最小限にしなければならないサーバとなると、ソフト屋には厳しい。オンサイト契約料は高いがケチってはいけないと、今日だけは改めて思ったのだった。


後日談(15/4/14追記)
ハードディスクを交換してもらって10時間位かけてリビルド、しかし上記のエラーは解消されず。
サポートにDSETを再度送ると、「(RAID1の)ディスクが両方壊れている」という。ちょっと待った! いまさらそれは反則だ。もしそうなら、全部再インストールすることになる。 とりあえず、前回交換しなかったもう一方のドライブだけ交換してもらうことになったが、同時に不吉な記事を見つける。

Double Faults and Punctures in RAID Arrays


とっとも厭な予感。いい予感はあたったことはないが厭な予感はとっても良く当たる。
数日後メンテの人が来てもう一方のドライブを交換、当然リビルド=10時間。で、やっぱりエラーは解消されない。 結局、一旦Windows Server Backup を実行し、ディスクを初期化後にリストア。以後2か月強、このエラーは発生していない。


(土屋)


【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)

2015-02-04

MySQL 5.1 から 5.6 にデータベースを移行する際、source コマンドを使うとエラーが発生することがある

MySQL 5.1 のデータベースのバックアップを取り、別のサーバ機の MySQL 5.6 にインストールする際、source コマンドを使ってデータベースの復元を行うと、以下のようなエラーが発生することがあります。

ERROR 1146 (42S02): Table 'test.蜃コ蠎ォ' doesn't exist

この文字化けしたテーブル名は日本語表記になっており、データベースの文字コードは utf8 です。

このような場合は、source コマンドの代わりに  mysql コマンドでデータベースの復旧を試みると解決することがあります。


例:
mysql -uroot -ppassword  < test.sql


【注意点】

mysql コマンドを使って大規模データベースを復旧する際、以下のようなエラーが発生して処理が停止してしまうことがあります。

MySQL server has gone away.

これを回避するには、 my.ini(my.conf) の max_allowed_packet の数値を増やします。

max_allowed_packet = 64M
(デフォルトは 4M)


2015-02-03

Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one


The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:


Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.


  1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
  2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
  3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.


Common Model BTHM Remarks
Fast development Yes No
Ease of operation Good No so good
Performance for big tables Very poor Good
Weird behaviors Many Minimum
Records order Weird OK Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya