 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 商用とOSSの互換性 | ||||||||||
|
商用DBの無償版の提供については、OSSのDBが急速にシェアを拡大してきたことに対して、マイクロソフトやオラクルが対抗しようとしているように見える。一方、OSSのDB用に開発されたツールの中には、Oracleからデータを移植する（移行する）ためのツールがある。 このように、互いが既存ユーザや見込みユーザを失わないようにするだけでなく、他から容易に乗換えできるような工夫を施している。 そこで問題になるのが、DB間の互換性だ。DBのデータだけを移植するのであれば、それほど難しい作業ではないだろう。だがDBシステムには、JavaやSQLで書かれたプログラムが必ず存在する。先のストアドプロシージャも含めて、こうしたプログラムも一緒に移植する必要があるのだ。 DBにアクセスするためのSQLは、DBによって少しずつ異なっている。つまり、接続するDBによってプログラムを変更することのないよう考慮されていない限り、DBが変わればプログラムを修正する必要が生じる。 そこで、登場するのがO/Rマッピングツールだ。ただし、以前からさまざまなO/Rマッピングツールがリリースされているが、完全互換の製品はまだない。各DB間でユーザの囲い込みが激しくなればなるほど、O/Rマッピングツールのような製品が注目されるかもしれない。 |
||||||||||
| 設定・管理運用を簡素化するツールの整備に期待 | ||||||||||
|
今回解説した2つのOSSのDBMSの業務システムへの可用性だが、結論は使えるといっていいだろう。 ただし、今までWindowsしか使ったことのないユーザは、Linuxの操作方法などの基本的な知識がないと、はじめは混乱するかも知れない。 現在のWindowsは、コンピュータに関する特別な知識を持たないユーザでも簡単に使えるように設計されている。だが、以前のバージョンのWindowsには、config.sysやautoexec.batといった環境設定のためのファイルがあって、ユーザがテキストエディタを使ってこれらのファイルを編集し環境を設定していた。これと同等の作業がLinux上でOSSを使う場合は必要になるわけだ。 現在は、インターネット上に多くの情報が掲載されているので簡単に情報を収集できるだろう。インストールからDBを起動するまでは、それほど多くの専門知識を必要としない。DBやテーブルの作成も、マニュアルを見るだけで進められるだろう。SQLに関する知識があれば、さらに理解できる。 とはいえ、何かクリティカルな問題が発生したときには、Linux、DB、ネットワークなど広範囲な知識が必要になる。外部のヘルプデスクやOSSのコミュニティからサポートを受ける場合も、これらの知識がないとコミュニケーションできない。また、自分で解決方法を探すとしても、すぐに英語が出てくるので、英文の読解力があれば心強い。次では、その解決方法をあげる。 |
||||||||||
| トラブル対応時のコツを示す | ||||||||||
|
何かクリティカルな問題が発生したときには、LinuxやDB、ネットワークなど広範囲な知識が必要になる。 また、問題を解決するための調査には、コツがある。まず、エラーが発生してシステムが正常に動作しないといったトラブルに対応する場合はこうだ。 はじめに、トラブルの現象から判断して、それが既知のものか否かを、各製品のリリースノートに該当するドキュメントや、WebサイトのFAQを参照して確認する。 そのトラブルが既知のものでなければ、次にWeb上のメーリングリストから過去の情報を検索する。キーワード検索ができるので、エラー番号やエラーメッセージを条件にして検索すると効率的だろう。 それでも解決につながる情報が、得られないこともある。その場合は、再現手順を明確にして、さらにそのトラブルがどこで、たとえば、アプリケーションなのか、それともOS、ネットワーク、DBで発生しているのか、切り分ける必要がある。 具体的には、2つの実行結果を比べる方法がある。実例をあげて説明しよう（図1）。  図1：トラブル原因の切り分けを実施したネットワークとシステムの概要 あるシステムでは、使用中にDB接続が勝手に切れてしまうトラブルが発生していた。初期の調査で、この現象が既知のトラブルではないことがわかった。さらに、このシステムの利用者に聞いたところ、インターネットを経由してシステムを起動したあと、しばらく放置するとこの現象が発生することがわかった。 ここで、「しばらく放置すること」と「インターネットを経由すること」が原因なのかを切り分けることにした。そのため、しばらく放置しなければどうなるのか、また、インターネットを経由しなければどうなるのかテストをした。テストパターンとその結果は次の通り。
表2：テストパターン この結果から、原因がプログラムやOS、DBの設定などに依存する可能性は低いと考えられる。 ここで、インターネットを経由してシステムを使用するとき、どのようなS/W、H/Wが介在するか順番に整理して、それらがインターネットを経由する場合としない場合で異なる点を列挙したところ、インターネット回線とファイアウォール機能が付いたルータしかなかった。そして、ルータの機能を検証したところ、セッションを保持する時間の設定があり、デフォルトの設定では60分となっていた。 当初は、DBのタイムアウトの設定を疑ったが、関係はなかった。また、インターネットへの接続を検証するため、「しばらく放置するプログラム」と「1分ごとにデータ検索をするプログラム」を1台のPCで同時に動かしてテストした。 その結果、前者はエラーになったが、後者はエラーにならなかった。この結果から、ルーターのセッション管理に依存する問題だろうと推測できたのだ。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
-
-
連載
