以下、ODBC 5.1.5だと×、5.1.6だとOK
INSERT INTO estimates(customerNo) SELECT customerNo FROM estimates WHERE ID=5
これ、痛い。 この構文使えずに困っている人、結構いるんじゃなかろうか？ 回避方法も見つからないし。
参考サイト：Bug #42905
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-29
『売上猫くん on MySQL』開発日記 - 番外7 - FileMaker内にMySQLの一般ログを表示する
MySQL の一般ログをFileMakerで表示する方法。
1.MySQLのMySQLデータベースをDSN登録する。
2.my.ini に log-output=TABLE,FILE を指定。
3.以下をMySQLコマンドラインで実行。
mysql> SET @old_log_state = @@global.slow_query_log;
mysql> SET GLOBAL general_log = 'OFF';
mysql> ALTER TABLE mysql.general_log ENGINE = MyISAM;
mysql>ALTER TABLE `mysql`.`general_log` ADD COLUMN `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, ADD PRIMARY KEY (`id`);
mysql> SET GLOBAL general_log = @old_log_state;
4.MySQL を再起動。
5.FileMaker のリレーションシップで、上記1で作成したDSNのmysql.general_logテーブル選択。このとき、上記で作成した id を指定。（以下、略）
するとこんな感じでログを表示できる。
FMの自動発行SQLクエリで「？」が頭に点灯したら、ログをチェックするのがよろしいかと。
尚、FM標準コマンドでは general_log テーブルのログは削除できないので、truncate（テーブル内の全行削除） を使用する。以下はFMの「SQLを実行」ステップを使用して、truncate を実行。
参考サイト：一般クエリとスロー クエリのログ出力先の選択
2010/9/24 追記
ログが出力されない場合、mysqlコマンドで
SET GLOBAL general_log = 'ON';
を実行してみる。
2010/10/25 追記
id の属性に AUTO_INCREMENT を追加。
2010/10/15 追記
slow_query についても、上記の要領でFileMaker上に表示可能だが、ログ対象となるクエリ時間の閾値がデフォルトでは10(秒)になっている。この為、ログ書き込みされないと思いこんでしまう。このデフォ値は、my.ini で long_query_time = 1 とするか、set global long_query_time = 1 を実行することにより変更できる。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
1.MySQLのMySQLデータベースをDSN登録する。
2.my.ini に log-output=TABLE,FILE を指定。
3.以下をMySQLコマンドラインで実行。
mysql> SET @old_log_state = @@global.slow_query_log;
mysql> SET GLOBAL general_log = 'OFF';
mysql> ALTER TABLE mysql.general_log ENGINE = MyISAM;
mysql>ALTER TABLE `mysql`.`general_log` ADD COLUMN `id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, ADD PRIMARY KEY (`id`);
mysql> SET GLOBAL general_log = @old_log_state;
4.MySQL を再起動。
5.FileMaker のリレーションシップで、上記1で作成したDSNのmysql.general_logテーブル選択。このとき、上記で作成した id を指定。（以下、略）
するとこんな感じでログを表示できる。
FMの自動発行SQLクエリで「？」が頭に点灯したら、ログをチェックするのがよろしいかと。
尚、FM標準コマンドでは general_log テーブルのログは削除できないので、truncate（テーブル内の全行削除） を使用する。以下はFMの「SQLを実行」ステップを使用して、truncate を実行。
参考サイト：一般クエリとスロー クエリのログ出力先の選択
2010/9/24 追記
ログが出力されない場合、mysqlコマンドで
SET GLOBAL general_log = 'ON';
を実行してみる。
2010/10/25 追記
id の属性に AUTO_INCREMENT を追加。
2010/10/15 追記
slow_query についても、上記の要領でFileMaker上に表示可能だが、ログ対象となるクエリ時間の閾値がデフォルトでは10(秒)になっている。この為、ログ書き込みされないと思いこんでしまう。このデフォ値は、my.ini で long_query_time = 1 とするか、set global long_query_time = 1 を実行することにより変更できる。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-27
『売上猫くん on MySQL』開発日記 - 2 - 開発環境
『売上猫くん on MySQL』の開発環境は以下の通り。
アプリケーションファイル（NekoApp.fp7）は、FileMaker Server Advanced 10（以下、FMServerAdv)上に置き、開発PC1、2、3及び開発Mac 10.6 の FileMaker Pro Advanced 10(以下、FMPA)からそのファイルにアクセスして開発を行う。FMServerAdv を使用する理由には、複数人が開発を安定して行えること、オンラインバックアップがスケジュールできる、という2点が挙げられる。
サーバ側にODBCをインストールしておけば、クライアント（開発PC）にはODBCは不要である（例外は後述）。 アプリケーション/ODBCの配布・アップグレードの容易さを考えれば、この構成は運用においても一考の価値はあると思う。
なお、図の「開発PC3 Win2008/TS」は Terminal Service を載せたWindows Server 2008機で、各クライアントがリモートデスクトップ接続によりFMPAを起動し、FMServerAdv にアクセスできるようにしている。（もともと、FileMaker は Terminal Service との相性が良く、Ver5位より常用しているが、近年のTerminal Service はローカルプリンタへの印刷、ローカルディスクの利用も格段に簡単にできるようになり、加えて接続遮断時にも接続を自動で復旧してくれたりする）。
前述のように FMSA (FileMaker Server無印も同様)にODBCをインストールすればクライアントにODBCを入れる必要はないが、例外がある。それは「SQLを実行」スクリプトステップを使用する場合である。 FileMaker は通常、開発者自らSQLを記述する必要はないが、FileMaker が用意していないコマンドを実行する場合は「SQLを実行」を使用する。また、FileMaker の外部DBに対する処理の中には非常に遅いものがあり（激遅処理）、その典型的なものに多数のレコードに及ぶ一括処理がある。CSV等のファイル取込、全置換、ループ等がそれである。 その回避策として 「SQLを実行」スクリプトステップにSQL文を埋め込み実行すると直接外部データベースに素のSQLが送られるので、FileMakerのレコード取込やループ処理を使うのに比べれて、桁違いにパフォーマンスが向上する。尚、FileMaker の外部DB使用時の激遅処理については、機会を改めて書きたい。
さて、開発PC1、ここには予備用のMySQLを入れ、リストアやリカバリをテストを行うので、データベースを全部削除したりとか無茶をやる。無茶をやると「あー、なるほど」と新たな発見もあったりする。また、ローカルにアプリケーションファイル（NekoApp.fp7）を置いても、FMSAサーバの環境と同様に諸機能が動作するかのチェックも行う。
以上
サーバ側にODBCをインストールしておけば、クライアント（開発PC）にはODBCは不要である（例外は後述）。
なお、図の「開発PC3 Win2008/TS」は Terminal Service を載せたWindows Server 2008機で、各クライアントがリモートデスクトップ接続によりFMPAを起動し、FMServerAdv にアクセスできるようにしている。（もともと、FileMaker は Terminal Service との相性が良く、Ver5位より常用しているが、近年のTerminal Service はローカルプリンタへの印刷、ローカルディスクの利用も格段に簡単にできるようになり、加えて接続遮断時にも接続を自動で復旧してくれたりする）。
前述のように FMSA (FileMaker Server無印も同様)にODBCをインストールすればクライアントにODBCを入れる必要はないが、例外がある。それは「SQLを実行」スクリプトステップを使用する場合である。 FileMaker は通常、開発者自らSQLを記述する必要はないが、FileMaker が用意していないコマンドを実行する場合は「SQLを実行」を使用する。また、FileMaker の外部DBに対する処理の中には非常に遅いものがあり（激遅処理）、その典型的なものに多数のレコードに及ぶ一括処理がある。CSV等のファイル取込、全置換、ループ等がそれである。 その回避策として 「SQLを実行」スクリプトステップにSQL文を埋め込み実行すると直接外部データベースに素のSQLが送られるので、FileMakerのレコード取込やループ処理を使うのに比べれて、桁違いにパフォーマンスが向上する。尚、FileMaker の外部DB使用時の激遅処理については、機会を改めて書きたい。
さて、開発PC1、ここには予備用のMySQLを入れ、リストアやリカバリをテストを行うので、データベースを全部削除したりとか無茶をやる。無茶をやると「あー、なるほど」と新たな発見もあったりする。また、ローカルにアプリケーションファイル（NekoApp.fp7）を置いても、FMSAサーバの環境と同様に諸機能が動作するかのチェックも行う。
以上
『売上猫くん on MySQL』開発日記 - 番外6 - リモートのログを mysqlbinlog できない
市販のソフトウェアでログ（MySQLではバイナリログ）からのリカバリ機能を実装しているものはあまり無いような気がする。 以前、某有名財務ソフトのSEに、「ログからのリカバリはできるんですか？」と聞いたことがある。 答えは「そういうのが必要なときは、うちのSEがやりますよ」とのこと。 確かに、下手にユーザがリカバリを行うと大変なことになるので、こういう機能は組み込まないのが正解なのかもしれない。 また、小中規模のデータベースシステムなら、フルバックアップを日に何回か取って、障害発生時には最新のフルバックアップでリストアまでし、最終フルバックアップ以降の更新は、ユーザがせっせと入れる、というが実態なのかとも思う。 また、“ユーザがせってと”できないようなクリティカルなシステムは、自社のシステム管理者や外部のSI業者がしっかりリカバリする体制ができているのだろう。
さて、『売上猫くん on MySQL』には、一応、バックアップ、フルバックアップからのリストア、バイナリログからのリカバリ機能を実装する予定で、バイナリログからのリカバリをテストしている。 MySQLが載っているサーバ機を使用し、そのサーバ上のログによりリカバリ（mysqlbinlog）を実行するのは、マニュアル通りに動く。
ところが、ローカルPCからリモートサーバ上のログをリモートサーバに対してリカバリすべく下記を実行すると失敗する。
> mysqlbinlog --disable-log-bin --read-from-remote-server //remote-server/***/log-bin mysql --user=root --password=passord --host=remote-server --database=neko"
例によってググりながら、疑わしきところを弄りながら、異なる2台のサーバに対して試すこと数時間。 どうしても「Misconfigured master - server id was not set」 とか、「error reading packet from server: binary log is not open」みたいなエラーが出力される（この2つのエラーはレプリケーション絡みで出力されるようだが…）。
諦めかけたところ、いきなりプロンプト画面に正常な出力が行われる。データを見ると、確かに更新分が反映されている。そこで実行文を見直してみると、--read-from-remote-server を入れ忘れて実行していた。結果、成功。
--read-from-remote-server はマニュアルによると、「バイナリログをローカルファイルから読み取らずにMySQLサーバから読み取ります」とあるので、このオプションは必要と思ったのだが…
結局、半日以上を費やして、--read-from-remote-server の正しい使用方法は分からずじまいだが、目的は達したので良しとしよう。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
さて、『売上猫くん on MySQL』には、一応、バックアップ、フルバックアップからのリストア、バイナリログからのリカバリ機能を実装する予定で、バイナリログからのリカバリをテストしている。 MySQLが載っているサーバ機を使用し、そのサーバ上のログによりリカバリ（mysqlbinlog）を実行するのは、マニュアル通りに動く。
ところが、ローカルPCからリモートサーバ上のログをリモートサーバに対してリカバリすべく下記を実行すると失敗する。
> mysqlbinlog --disable-log-bin --read-from-remote-server //remote-server/***/log-bin mysql --user=root --password=passord --host=remote-server --database=neko"
例によってググりながら、疑わしきところを弄りながら、異なる2台のサーバに対して試すこと数時間。 どうしても「Misconfigured master - server id was not set」 とか、「error reading packet from server: binary log is not open」みたいなエラーが出力される（この2つのエラーはレプリケーション絡みで出力されるようだが…）。
諦めかけたところ、いきなりプロンプト画面に正常な出力が行われる。データを見ると、確かに更新分が反映されている。そこで実行文を見直してみると、--read-from-remote-server を入れ忘れて実行していた。結果、成功。
--read-from-remote-server はマニュアルによると、「バイナリログをローカルファイルから読み取らずにMySQLサーバから読み取ります」とあるので、このオプションは必要と思ったのだが…
結局、半日以上を費やして、--read-from-remote-server の正しい使用方法は分からずじまいだが、目的は達したので良しとしよう。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-26
『売上猫くん on MySQL』開発日記 - 番外5 - ポータルで検索できない
MySQL等の外部DBを使用し、複数のリレーションを設定したポータル内では、検索を実行できません。 たとえば、売上と売上明細のテーブルを［売上No］と［区分］という二つのフィールドでリレートし、ポータルに売上明細のフィールドを置き、これらで検索しても失敗します。
FMのバグでしょう。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
FMのバグでしょう。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-23
『売上猫くん on MySQL』開発日記 - 番外4 - mysqldump で文字化け？
mysqldumpで作成したテキスト(ｓｑｌ)ファイルを WordPad で開いてみる。 文字化けだらけ。
MySQLクライアントを使用しても、phpMyAdmin を使用しても結果は変わらず。ただ、phpMyAdminで実行結果を画面に出力するとちゃんと表示される奇怪。
「mysqldump 文字化け」でググってみるといろいろと記事があり、それを見ながら --default-character-set やら、my.ini やらでいろいろ試してみるが解決には至らず。
半日ほど頑張ってみたが埒があかないので、念のため、隣の人に聞いてみた。すると「WordPadを使ってませんか？」 。 「はぁ？」 、固まる小生。 WordPadって、NotePadの上位エディタじゃないの？ NotePadで 確かに、NotePadは UTF-8とUnicodeの保存オプションがあるのに、 WordPadにはUnicodeのみ。 読み込みできるキャラクタセットが違うらしい。 WordPad のUnicodeはUTF-16LE対応.
Notepadはこれに加えてUTF-8対応。 あー、とんんだ恥さらし記事だけど、小生の同類がいるかもしれないので、恥を忍んで上げておこう。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
MySQLクライアントを使用しても、phpMyAdmin を使用しても結果は変わらず。ただ、phpMyAdminで実行結果を画面に出力するとちゃんと表示される奇怪。
「mysqldump 文字化け」でググってみるといろいろと記事があり、それを見ながら --default-character-set やら、my.ini やらでいろいろ試してみるが解決には至らず。
半日ほど頑張ってみたが埒があかないので、念のため、隣の人に聞いてみた。すると「WordPadを使ってませんか？」 。 「はぁ？」 、固まる小生。 WordPadって、NotePadの上位エディタじゃないの？ NotePadで 確かに、NotePadは UTF-8とUnicodeの保存オプションがあるのに、 WordPadにはUnicodeのみ。 読み込みできるキャラクタセットが違うらしい。 WordPad のUnicodeはUTF-16LE対応.
Notepadはこれに加えてUTF-8対応。 あー、とんんだ恥さらし記事だけど、小生の同類がいるかもしれないので、恥を忍んで上げておこう。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-22
『売上猫くん on MySQL』開発日記 - 番外3 - 0を書き込みできない
売上明細テーブル（ vw_salesdtls）のInt型のフィールド（balanceFlg）に値を書き込もうとする。他の値は書き込みできるのだが、“0”の書き込みが実行できない。 ログで何が起こっているのか確認する。
Commitに失敗している場合はバイナリログには記録されないので、mysqlbinlog は使えない。 そこで、一般ログというものを、
mysql> set global general_log="ON";
で作成してみる。 以下、1を立てて成功したログと、0で失敗したログ（一部抜粋）。
【1立てで成功】
9 Query SELECT ID,`売上番号`,balanceFlg, ～略～ FROM vw_salesdtls WHERE ID=8340 FOR UPDATE
9 Query UPDATE vw_salesdtls SET balanceFlg=1 WHERE ID=8340
【0立てで失敗】
8 Query SELECT ID,`売上番号`,balanceFlg, ～略～ FROM vw_salesdtls WHERE ID=8341
失敗したほうでは、なぜか FOR UPDATE 以下が発行されず、当然これでは更新できない。 当初はInnoDB側に何か問題があるのかと疑ったが、FileMakerが適切なクエリを発行していないことがわかった。ちなみに、類似した他のテーブルでは、1、0の値に関係なく、更新(Update)は成功する。
いろいろとやってみた。FMのファイルを修復したり、レイアウトモードにして数字の書式を変更してみたり、フィールド定義を眺めてみたり。 そして、これが FileMaker のバグだと判明。 なんと、FileMaker は 空欄(null)→0 への変更は変更と認識しない、null=0 と認識するのである。 更新と認識しないので、 Update が発行されない。 恐ろしい。
結論
ということで、null と 0 を区別して扱う必要がある場合は、非常に注意が必要だ。 0 を参照キーするのは極力避けるべきた。 MySQL側で初期値を0に設定しておく、というのは一案かもしれない。
ちなみに、上述のように「null=0 と認識」するので、0→空欄lに変更を行っても、コミットすると 0 のままである。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
Commitに失敗している場合はバイナリログには記録されないので、mysqlbinlog は使えない。 そこで、一般ログというものを、
mysql> set global general_log="ON";
で作成してみる。 以下、1を立てて成功したログと、0で失敗したログ（一部抜粋）。
【1立てで成功】
9 Query SELECT ID,`売上番号`,balanceFlg, ～略～ FROM vw_salesdtls WHERE ID=8340 FOR UPDATE
9 Query UPDATE vw_salesdtls SET balanceFlg=1 WHERE ID=8340
【0立てで失敗】
8 Query SELECT ID,`売上番号`,balanceFlg, ～略～ FROM vw_salesdtls WHERE ID=8341
失敗したほうでは、なぜか FOR UPDATE 以下が発行されず、当然これでは更新できない。 当初はInnoDB側に何か問題があるのかと疑ったが、FileMakerが適切なクエリを発行していないことがわかった。
いろいろとやってみた。FMのファイルを修復したり、レイアウトモードにして数字の書式を変更してみたり、フィールド定義を眺めてみたり。 そして、これが FileMaker のバグだと判明。 なんと、FileMaker は 空欄(null)→0 への変更は変更と認識しない、null=0 と認識するのである。 更新と認識しないので、 Update が発行されない。 恐ろしい。
結論
ということで、null と 0 を区別して扱う必要がある場合は、非常に注意が必要だ。 0 を参照キーするのは極力避けるべきた。 MySQL側で初期値を0に設定しておく、というのは一案かもしれない。
ちなみに、上述のように「null=0 と認識」するので、0→空欄lに変更を行っても、コミットすると 0 のままである。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-16
『売上猫くん on MySQL』開発日記 - 番外2 - MySQLミラーサイト
MySQL サイトが今朝から落ちてる。 レファレンスマニュアルが見れない、つまり開発できない。Googleのキャッシュは遅すぎる。 MySQLの全機能を網羅し、信頼の置けるドキュメントはここにしかない（と思う）。「MySQLの開発者はこういうときどうしているのだろう？」等と思いつつ、、、ミラーサイトをみつけた。これタイの大学のサイト。Googleキャッシュよりはずっと早い。 この大学のトップページにはなぜか秋篠宮殿下が…
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-15
『売上猫くん on MySQL』開発日記 - 番外1 - 全データベース削除→リストア
あるサーバにあるデータベースダンプを別のサーバに移動。その後、MySQLのすべてのデータベースを削除し、リストアのテストを行おう思い、まず、
> drop database information_schema
（だったと思う）
を実行してみた。 すると、「information_schemaは削除できない」旨のメッセージが表示される。
その後、mysqlを再起動しようとするとエラーが出て起動しない。 データフォルダをみると、ｍｙｓｑｌを含むすべてのデータベースは削除されている。エラーログをチェック（←これ大事）すると、 mysql データベースは起動に必須らしい。そこで、元のサーバから無理やりこのmysql フォルダをコピーし（サーバ停止無、こんなことやっていいいのか？）、丸ごと、起動しなくなった別サーバ内にコピー。 その後は再起動できた（ここまで半日潰れる）。
そこで、
> show databases
を実行すると、やはり表示されるのは、mysql データベースのみ。 そこで、コマンドプロンプトからリストアを実行すると、以下のようなエラーが出る。
InnoDB: Error: table test/parent already exists in InnoDB internal
InnoDB: data dictionary. Have you deleted the .frm file
InnoDB: and not used DROP TABLE? Have you used DROP DATABASE
InnoDB: for InnoDB tables in MySQL version <= 3.23.43? InnoDB: See the Restrictions section of the InnoDB manual. InnoDB: You can drop the orphaned table inside InnoDB by InnoDB: creating an InnoDB table with the same name in another
InnoDB: database and moving the .frm file to the current database.
InnoDB: Then MySQL thinks the table exists, and DROP TABLE will
InnoDB: succeed.
参考サイト：トラブルシューティング
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
> drop database information_schema
（だったと思う）
を実行してみた。 すると、「information_schemaは削除できない」旨のメッセージが表示される。
その後、mysqlを再起動しようとするとエラーが出て起動しない。 データフォルダをみると、ｍｙｓｑｌを含むすべてのデータベースは削除されている。エラーログをチェック（←これ大事）すると、 mysql データベースは起動に必須らしい。そこで、元のサーバから無理やりこのmysql フォルダをコピーし（サーバ停止無、こんなことやっていいいのか？）、丸ごと、起動しなくなった別サーバ内にコピー。 その後は再起動できた（ここまで半日潰れる）。
そこで、
> show databases
を実行すると、やはり表示されるのは、mysql データベースのみ。 そこで、コマンドプロンプトからリストアを実行すると、以下のようなエラーが出る。
InnoDB: Error: table test/parent already exists in InnoDB internal
InnoDB: data dictionary. Have you deleted the .frm file
InnoDB: and not used DROP TABLE? Have you used DROP DATABASE
InnoDB: for InnoDB tables in MySQL version <= 3.23.43? InnoDB: See the Restrictions section of the InnoDB manual. InnoDB: You can drop the orphaned table inside InnoDB by InnoDB: creating an InnoDB table with the same name in another
InnoDB: database and moving the .frm file to the current database.
InnoDB: Then MySQL thinks the table exists, and DROP TABLE will
InnoDB: succeed.
InnoDB内部の記録と不整合があるらしいので、一旦、同名の空のデータベースを作成し、それを削除したあとにもう一度リストアをやってみるとやっと成功。 めでたし、めでたし参考サイト：トラブルシューティング
InnoDB データ ディクショナリ操作関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-03-03
SonicWALLの新製品テクニカルセミナー
先日、SonicWALLの新しいTotalSecure TZシリーズ（TZ100/TZ200/TZ210）のセミナーに行ってきた。
セミナーは2時間で最初の一時間がマーケ、後の一時間がテクニカルな内容であった。以下、その備忘録。
マーケ
2008年、UTM製品の国内の出荷台数シェアは、Juniper（NetScreen）、SonicWALL、Fortinet、Cisco、Checkpointの順。 同年の金額によるシェアは、Fortinet、Juniper、Cisco、SonicWALL、Checkpointの順。 Sonicは台数は出てるのに金額が低い、つまり、Sonicは中小向けの安いUTM製品に強みを持っている。
あと、営業さんが資料等で強調していたのは、「他社製品に比べ、コストパフォーマンスがいいですよ」ということ。
テクニカル---新製品の特徴
エンジニアは、TZより上位のシリーズはマルチコアCPUによりDPI（パケットのIPヘッダ部分だけではなく、データ部分を検査する機能）が高速化されていることを強調していた（が、今回のTZとは関係ないので、"マルチコアアーキテクチャ"と言いたかっただけと違うんかと）。
また、RFDPI(Reassembly Free Deep Packet Inspection)も強調。本機能は、他メーカー機と異なり、パケットをメモリ上に展開すること無く直接検査するため、非常に高速だとか。 こちらはTZシリーズでも採用している。
この2つの機能はSonicWALLの"売り"であるらしく、昨年のハイエンドのE-Class（ベンツかいな）のセミナーでも濃い説明があった。
尚、今回配布された「かんたんUTM導入ガイド」という小冊子(非売品)には、UTMのことがとてもよくまとめられている。 巻末の 文言によるとこの小冊子は、アスキーの「NETWORK MAGAZINE」の08/9月～09/2月号でSonicWALLのエンジニアが書いた記事を再編集したもの、とのこと。
以上
見つけモノ
SonicWALLのYouTube動画サイト（英語）
セミナーは2時間で最初の一時間がマーケ、後の一時間がテクニカルな内容であった。以下、その備忘録。
マーケ
2008年、UTM製品の国内の出荷台数シェアは、Juniper（NetScreen）、SonicWALL、Fortinet、Cisco、Checkpointの順。 同年の金額によるシェアは、Fortinet、Juniper、Cisco、SonicWALL、Checkpointの順。 Sonicは台数は出てるのに金額が低い、つまり、Sonicは中小向けの安いUTM製品に強みを持っている。
あと、営業さんが資料等で強調していたのは、「他社製品に比べ、コストパフォーマンスがいいですよ」ということ。
テクニカル---新製品の特徴
- TZ180以前の機種で標準付属していたSonicOS Standardが無くなり、全機種がEnhanced（5.ｘ） に統合された
- TZ180に比しUTMパフォーマンスが2.5～5倍Up（10Mbps→25Mbps～50Mbs）
- GAVシグネチャーが上位機種(NSA？)と同等に。 TZ100も？
- アプリケーションファイヤウォール（TZ210のみ）
- SSL-VPN（ユーザ数：1～10、機種/オプションにより異なる）
- 冗長構成 --- 予備機(同機種)を一台用意し、障害発生時に切り替えて運用
エンジニアは、TZより上位のシリーズはマルチコアCPUによりDPI（パケットのIPヘッダ部分だけではなく、データ部分を検査する機能）が高速化されていることを強調していた（が、今回のTZとは関係ないので、"マルチコアアーキテクチャ"と言いたかっただけと違うんかと）。
また、RFDPI(Reassembly Free Deep Packet Inspection)も強調。本機能は、他メーカー機と異なり、パケットをメモリ上に展開すること無く直接検査するため、非常に高速だとか。 こちらはTZシリーズでも採用している。
この2つの機能はSonicWALLの"売り"であるらしく、昨年のハイエンドのE-Class（ベンツかいな）のセミナーでも濃い説明があった。
尚、今回配布された「かんたんUTM導入ガイド」という小冊子(非売品)には、UTMのことがとてもよくまとめられている。 巻末の 文言によるとこの小冊子は、アスキーの「NETWORK MAGAZINE」の08/9月～09/2月号でSonicWALLのエンジニアが書いた記事を再編集したもの、とのこと。
以上
見つけモノ
SonicWALLのYouTube動画サイト（英語）
登録:
投稿 (Atom)