2012-11-08

SQL Server 2000 を FileMaker 11で使う

　FileMakerが公式サポートしているMicrosoft SQL Server のバージョンはMS SQL Server 2008 R2/MS SQL Server 2008 SP2/MS SQL Server 2005 SP3のみです。

　が、10年程前に SQL Server 2000 と ASP で作成したシステムのデータをちょこちょこ弄る必要がでてきました。
　これを Active Server Page でやるのは大変すぎるので、FileMaker Pro 11でSQL-Server 2000のDBを扱えないものかと無謀にも思い立ち、試してみました。

　本記事は、その備忘録となります。

　例によって「システムDSN」を登録。
　環境は Windows 32bit、ODBCドライバは「SQL Server 6.00」。
　問題なく登録できる。



　次に FileMaker Pro 11 Advanced を起動してFileMakerデータベースを作成。
　上記で登録したDSNをFileMakerの外部データソースとして登録する。



　さらに、リレーションシップのウインドウで、上記で登録した SQL Server データベースのテーブルをTO（Table Occurrence）として現出させ、リレーションとかもしてみる。問題なし。



　FileMaker では TO 毎にレイアウト（フォーム）が自動作成される。ブラウズモードにして、表示方法を「表形式」を選択すると、以下のような表が表示される。



　ここまで、慣れていれば5分程度で作成できる。
　いまのところ、照会/検索は普通にできている。



　最後に躓いた点のメモ：

　上記のFileMakerデータベースを Windows Server 2008 x64 の FileMaker Server で運用する場合、普通にDSN登録をすると、上記のリレーションシップのところでエラーが起こると思われる。
　この場合、SysWoW64フォルダの odbcad32.exeを起動して、DSN登録を行うこと。

参考リンク
http://social.msdn.microsoft.com/Forums/ja/sqlserverja/thread/7bec5ba8-3164-402f-8050-1ce4a0acaa8e


（土屋）


【IWP関連記事】

【弊社のIWP関連製品・サービス】


By 時刻: 0 件のコメント:
ラベル: ,

2012-07-18

QNAP障害発生時のマイグレーション

今回発生したQNAPの障害を機に、ハードディスクではなく、QNAP本体で障害が発生した場合のマイグレーション（Migration）をシミュレートしてみた。　ここでいうマイグレーションとは、障害が発生した元QNAPのハードディスクを新QNAPに移動し以後QNAP2で運用することを言う。
以下、今回行ったシミュレーションの手順・注意点を記録しておく。

1.障害はハードディスクかQNAP本体かを見分ける
ハードディスクの障害であればマイグレートしてもしかたがない、というか余計症状が悪化する可能性もある。ハードディスク障害の症状、チェック方法、復旧方法については、以下を参照。

QNAPで恐怖のエラーがぁぁぁぁああああ

本体のHDDのLEDが赤く点滅していればHDD障害の可能性大。LEDが緑（点滅）であっても、PCからアクセスできない、ブラウザからQNAP管理画面の左ペインの（いくつかの）リンクにアクセスしようとすると「Loading Driver Please Wait... 」と表示されたままになりアクセス不能、RAID情報を見ると理由もないのに「Sychronizing...」していてHDDのLEDが緑点滅している、という状況があればHDDが疑わしい。

今回のようにHDDが中途半端に生きている場合、「Sychronizing...」（十数時間）→アクセス障害→手動再起動→アクセス復旧→「Sychronizing...」（十数時間）→アクセス障害→手動再起動…　をHDDが完全に死んでLEDが赤点灯するまで何十時間も繰り返すことがあるので、障害原因がハードディスクかQNAP本体かをいかに早く見極めるかが、腕の見せ所。



3.事前確認
今回のシミュレーションでは、「元QNAP（いままで運用中のQNAP）本体が障害を起こしたと仮定し、元QNAPの4台のHDDを新しいQNAPに移し（マイグレーション）、ネットワーク上のマシンから問題なくアクセスできることを確認、その後4つのHDDを元QNAPに戻して運用を再開する」という一連の作業を行う。　かなり不安な作業なので、QNAPサポートにこれを実行して問題ないかを問い合わせたところ、「問題ない筈だが、マイグレーションに関する以下のURLを読んでみろ」とのこと。

曰く、「After the migration has finished, all the settings and data will be kept and applied to the new NAS. However, the system settings of the source NAS cannot be imported to the destination NAS via “System Administration” > “Backup/Restore Settings”. Configure the NAS again if the settings were lost.」
つまり、元QNAPの設定とデータは新しいQNAPに継承される。が、“System Administration” > “Backup/Restore Settings”を利用しても、元の設定を取り込めないこともあるので、その時は手動で設定してね、と怖いことが書いてある。　元QNAPで行った設定はすべてスクリーンショットを取っておき、万が一の場合は手動設定する準備をしておく必要がある。


4.元QNAPのファームウェアのアップグレード
実際にQNAP本体に障害発生した場合、ファームのアップグレードはできないが、今回はシミュレーションなので、マイグレーション前に元QNAP機のファームをアップグレードした。　

まず、アップグレード前にファームの更新履歴をみて、アップグレードの可否の判断を行う。　QNAPファームは頻繁にアップグレードされバグも多いようなので、この判断は慎重に行うこと。　今回は3.5.0→3.7.1へとアップグレードを行った。

アップグレードに要した時間は10分程度だったか。終了後は再起動を求めてきたので再起動。　ところが、再起動後にまた「Synchironizing...」が始まった。　これに要した時間が10時間強。QNAPのサポートにこの件を問い合わせたが、「通常、Synchironizeはそうそう起こるものではない。今回の原因はわからない」とのことだった。


5.マイグレーション、そして再度元のQNAPへ戻す
10時間強のSynchronizeが終わったところで、元QNAPの電源を落とし4台のHDDを抜き取り、新QNAPに移して電源をいれた。　数分で問題なく起動してきた。これでマイグレーション作業は終了。
ところがログをチェックしてみると、「The firmware versions of the system built-in flash (3.4.2 Build 0331T) and the hard drive (3.4.2 Build 20120615) are not consistent. It is recommended to update the firmware again for higher system stability.」と出ている。ファームウェアは、ハードディスクと本体フラッシュメモリの両方にあるらしい。マイグレーション先の新QNAPのフラッシュ内のファームが古いというのは当然だが、元QNAP内にあった4台のハードディスクのファームが3.4.2というのはおかしい。


一方、“Firmware Update”のリンク をクリックすると、「Current firmware version: 3.7.1 Build 20120615」と表示される。　よってthe hard drive (3.4.2 Build 20120615)　の表記はバグと思われる。

今回はシミュレーションなので新QNAPでのファームのアップグレードは見送り、この状態でブラウザのQNAP管理画面からチェックをおこなった。IPアドレス、その他は旧QNAPの設定がそのまま継承され、マシン名も旧QNAPと同様である。その他の設定も旧設定をそのまま継承している。ここで、旧QNAPを使用していた仮想/物理マシンを起動してみたが、問題なくアクセスできた。

一通りチェックが終わったところで、新QNAPの電源を落とし、4つのハードディスクを新QNAPから取り出し、元QNAPに戻した。　されに元QNAPの電源を入れてログをチェック。　問題がないことを確認後、各マシンから再びアクセスをさせたところ、問題なく動作した。

（土屋）







By 時刻: 0 件のコメント:
ラベル:

2012-07-12

ターミナルエミュレータを使って QNAP の状態を確認する

先日の QNAP の不具合でわかったことですが、QNAP 本体にトラブルが発生すると、Web ブラウザによる管理ツールで使えない部分が出てくることがあります。

たとえば、RAID 構成を表示させるページや、ISCSI の構成を表示させるページ等は読み込み中のまま、まともに動かなくなってしまったりします。

そういった場合に、エラーの発生したディスクカートリッジを交換したり修理に出したりする前に、直接 QNAP の OS にアクセスして状態の確認やログ参照を行うことにより、原因を特定しやすくなるかもしれません。

ここでは、PuTTY というターミナルエミュレータを使うことによって、QNAP にログインし、基本的なステータス確認コマンドを走らせる方法について説明します。

1. PuTTY のダウンロード

以下のページにアクセスし、適切なバージョンの PuTTY をダウンロードします。


PuTTY は実行ファイル単体で動作しますので、Windows ユーザの方は putty.exe をダウンロードすればまず問題ないでしょう。

2. PuTTY の起動

putty.exe を起動すると、PuTTY Configuration という画面が表示されます。


上図の青囲みのように Host Name に QNAP の IP アドレス、ポートに 22 (SSH) を指定してから、“Open”ボタンをクリックします。

3. QNAP へのログイン

接続に成功すると、以下のようなPuTTY のターミナル画面が開きます。



 ログインを求められますので、admin を指定し、正しいパスワードを入力して Enter キーを押します。


4. mdstat でメディアの状態をチェック

以下のコマンド入力して Enter キーを押すと、現在のメディアの状態を確認できます。

cat /proc/mdstat 




上記の黄色囲みに注目してください。
UUU_ と文字が並んでいますが、4 文字目がアンダースコア _ になってしまっています。
これは、4 番目のメディアに何らかの障害が発生しているため、mdstat では読み取り不能であることを示しています。

つまり、QNAP の 4 番目のディスクカートリッジに障害が起こっていることがこれでわかります。

6. klogd.sh dump でさらに状態を詳しくチェック

以下のコマンド入力して Enter キーを押すと、カーネルログデーモンで発生しているイベントのログを照会できます。

/etc/init.d/klogd.sh dump 

しかし、これではすべてのログが表示されてしまいますので、後尾に grep を付けてキーワードの絞り込みをすると場所の特定が容易になるでしょう。


たとえば、入出力のエラーを確認したいときは以下のように入力します。

/etc/init.d/klogd.sh dump | grep "I/O error"




I/O error ログのみが抽出されます。
上記の黄色囲みの部分を確認すると、sdd デバイスに入出力エラーが発生していることがわかりますね。


【補足】

メディア名をコマンドでチェックするには、以下のコマンドを入力します。

ls /dev/sdd*



sdd、sdd1、sdd2、sdd3、sdd4 とメディア名が定義されており、最初から順に QNAP のカートリッジと対応しています。上記 4. の mdstat で説明したとおり、今回は4 番目のデバイス sdd3 (QNAP 本体では物理的に 4 番目のカートリッジ)に障害が起こっています。

また、sdd4 は物理的には存在していないデバイスとして定義されているようですが、この部分は当方は未確認です。



その他、QNAP の不具合に関して具体的なサポートを受けたい方は、以下にお問い合わせください。


QNAP HELP DESK　（問い合わせは英語）


By 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)