_docs_ja.utf8.txt

非常棒的java数据库

@advanced_1129_td
Data Source

@advanced_1130_td
H2 Test

@advanced_1131_td
ODBCデータソースの名称

@advanced_1132_td
Database

@advanced_1133_td
test

@advanced_1134_td
データベース名。現時点では簡易な名前のみサポートされています;

@advanced_1135_td
相対パス、または絶対パスはデータベース名にサポートされていません。

@advanced_1136_td
デフォルトでは、-baseDir 設定が使用された時を除き、

@advanced_1137_td
データベースはサーバーが起動された現在作業中のディレクトリに保存されます。

@advanced_1138_td
名前は少なくとも3文字でなければなりません。

@advanced_1139_td
Server

@advanced_1140_td
localhost

@advanced_1141_td
サーバー名、またはIPアドレス

@advanced_1142_td
デフォルトでは、リモート接続のみ許可されています。

@advanced_1143_td
User Name

@advanced_1144_td
sa

@advanced_1145_td
データベースのユーザー名

@advanced_1146_td
SSL Mode

@advanced_1147_td
disabled

@advanced_1148_td
現時点で、SSLはサポートされていません。

@advanced_1149_td
Port

@advanced_1150_td
5435

@advanced_1151_td
PGサーバーが傾聴しているポート

@advanced_1152_td
Password

@advanced_1153_td
sa

@advanced_1154_td
データベースパスワード

@advanced_1155_p
この後、このデータソースを使用できます。

@advanced_1156_h3
PGプロトコルサポートの制限

@advanced_1157_p
現時点では、PostgreSQLネットワークプロトコルのサブセットのみ実装されています。また、カタログ、またはテキストエンコーディングでのSQLレベル上の互換性問題がある可能性があります。問題は発見されたら修正されます。現在、PGプロトコルが使用されている時、ステートメントはキャンセルされません。

@advanced_1158_p
#PostgreSQL ODBC Driver Setup requires a database password, that means it is not possible to connect to H2 databases without password. This is a limitation of the ODBC driver.

@advanced_1159_h3
セキュリティ考慮

@advanced_1160_p
現在、PGサーバーはchallenge response、またはパスワードの暗号化をサポートしていません。パスワードが読みやすいため、アタッカーがODBCドライバとサーバー間でのデータ転送を傾聴できる場合、これは問題になるでしょう。また、暗号化SSL接続も現在使用不可能です。そのため、ODBCドライバはセキュリティが重視される場面においては使用されるべきではありません。

@advanced_1161_h2
ACID

@advanced_1162_p
データベースの世界では、ACIDとは以下を表しています:

@advanced_1163_li
Atomicity (原子性) : トランザクションはアトミックでなければならず、全てのタスクが実行されたか、実行されないかの どちらかであるという意味です。

@advanced_1164_li
Consistency (一貫性) : 全てのオペレーションは定義された制約に従わなくてはいけません。

@advanced_1165_li
Isolation (独立性 / 分離性) : トランザクションはそれぞれ独立 (隔離) されていなくてはなりません。

@advanced_1166_li
Durability (永続性) : コミットされたトランザクションは失われません。

@advanced_1167_h3
Atomicity (原子性)

@advanced_1168_p
このデータベースでのトランザクションは常にアトミックです。

@advanced_1169_h3
Consistency (一貫性)

@advanced_1170_p
このデータベースは常に一貫性のある状態です。 参照整合性のルールは常に実行されます。

@advanced_1171_h3
Isolation (独立性 / 分離性)

@advanced_1172_p
H2は、他の多くのデータベースシステムと同様に、デフォルトの分離レベルは "read committed" です。これはより良いパフォーマンスを提供しますが、トランザクションは完全に分離されていないということも意味します。H2はトランザクション分離レベル "serializable"、"read committed"、"read uncommitted" をサポートしています。

@advanced_1173_h3
Durability (永続性)

@advanced_1174_p
このデータベースは、全てのコミットされたトランザクションが電源異常に耐えられるということを保証しません。全てのデータベースが電源異常の状況において、一部トランザクションが失われるということをテストは示しています (詳細は下記をご覧下さい)。トランザクションが失われることを容認できない場面では、ノートパソコン、またはUPS (無停電電源装置) を使用します。永続性がハードウェア異常の起こり得る全ての可能性に対して必要とされるのであれば、H2クラスタリングモードのようなクラスタリングが使用されるべきです。

@advanced_1175_h2
永続性問題

@advanced_1176_p
完全な永続性とは、全てのコミットされたトランザクションは電源異常に耐えられる、ということを意味します。 いくつかのデータベースは、永続性を保証すると主張していますが、このような主張は誤っています。 永続性テストはH2、HSQLDB、PostgreSQL、Derbyに対して実行されました。これらの全てのデータベースは、 時々コミットされたトランザクションを失います。このテストはH2ダウンロードに含まれています。 org.h2.test.poweroff.Test をご覧下さい。

@advanced_1177_h3
永続性を実現する (しない) 方法

@advanced_1178_p
失われなかったコミット済みトランザクションは、最初に思うよりもより複雑だということを理解して下さい。 完全な永続性を保障するためには、データベースは、コミットの呼び出しが返ってくる前に ログレコードがハードドライブ上にあることを確実にしなければなりません。 これを行うために、データベースは異なったメソッドを使用します。ひとつは "同期書き込み" ファイルアクセスモードを使用することです。Javaでは、RandomAccessFile はモード "rws" と "rwd" を サポートしています:

@advanced_1179_li
rwd: それぞれのファイル内容の更新は、元になるストレージデバイスと同時に書き込まれます。

@advanced_1180_li
rws: rwdに加えて、それぞれのメタデータの更新は同時に書き込まれます。

@advanced_1181_p
この特徴はDerbyで使用されています。それらのモードのうちのひとつは、テスト (org.h2.test.poweroff.TestWrite) において、毎秒およそ5万件の書き込み操作を実現します。オペレーティングシステムのライトバッファーが無効の時でさえも、 書き込み速度は毎秒およそ5万件です。この特徴はディスクを交換させるというものではありません。 なぜなら、全てのバッファーをフラッシュするのではないからです。テストはファイル内の同じバイトを何度も更新しました。 もしハードドライブがこの速度での書き込みが可能なら、ディスクは少なくても毎秒5万回転か、 または300万 RPM (revolutions per minute 回転毎分) を行う必要があります。 そのようなハードドライブは存在しません。テストで使用されたハードドライブは、およそ7200 RPM、または 毎秒120回転です。これがオーバーヘッドなので、最大書き込み速度はこれより低くなくてはなりません。

@advanced_1182_p
バッファーは fsync 関数を呼ぶことによってフラッシュされます。Javaでこれを行う二つの方法があります:

@advanced_1183_li
FileDescriptor.sync() ドキュメンテーションには、これは強制的に全てのシステムバッファーに基本となる デバイスとの同期を取らせる、と書かれています。このFileDescriptorに関連するバッファーのインメモリでの 変更コピーが全て物理メディアに書かれた後、Syncは返ることになっています。

@advanced_1184_li
FileChannel.force() (JDK 1.4 以来) このメソッドは、強制的にこのチャネルのファイルの更新は それを含むストレージデバイスに書き込まれることを行います。

@advanced_1185_p
#By default, MySQL calls fsync for each commit. When using one of those methods, only around 60 write operations per second can be achieved, which is consistent with the RPM rate of the hard drive used. Unfortunately, even when calling FileDescriptor.sync() or FileChannel.force(), data is not always persisted to the hard drive, because most hard drives do not obey fsync(): see <a href="http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252">Your Hard Drive Lies to You</a> . In Mac OS X fsync does not flush hard drive buffers, see <a href="http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html">Bad fsync?</a> . So the situation is confusing, and tests prove there is a problem.

@advanced_1186_p
ハードドライブバッファーを懸命にフラッシュしようと試みると、パフォーマンスは非常に悪いものになります。 最初に、ハードドライブは実際には全てのバッファーをフラッシュしているということを確かめることが必要です。 テストは信頼性ある方法でこれが行われていないことを示しています。その結果、トランザクションの最大数は毎秒およそ60件です。 これらの理由により、H2のデフォルト性質はコミットされたトランザクションの書き込みを遅らせることです。

@advanced_1187_p
H2では、電源異常の後、1秒以上のコミットされたトランザクションが失われます。 この性質を変更するためには。 SET WRITE_DELAY と CHECKPOINT SYNC を使用します。 多くの他のデータベースも同様に遅延コミットをサポートしています。パフォーマンス比較では、 遅延コミットは、サポートする全てのデータベースによって使用されました。

@advanced_1188_h3
永続性テストを実行する

@advanced_1189_p
このデータベースと他のデータベースの、永続性 / 非永続性テストを行うために、 パッケージ内 org.h2.test.poweroff のテストアプリケーションを使用することができます。 ネットワーク接続の二つのコンピューターがこのテストを実行するのに必要です。 ひとつのコンピューターは、他のコンピューター上でテストアプリケーションが実行されている間 (電源は切られています) ただ聞いています。リスナーアプリケーションのコンピューターは TCP/IP ポートを開き、 次の接続のために聞きます。二つ目のコンピューターは最初リスナーに接続し、データベースを作成して レコードの挿入を開始します。この接続は "autocommit" に設定されます。それぞれのレコード挿入後のコミットが 自動的に行われるという意味です。その後、テストコンピューターはこのレコードの挿入に成功したということを リスナーに通知します。リスナーコンピューターは10秒ごとに最後に挿入されたレコードを表示します。 電源を手動でOFFにしてコンピューターを再起動し、アプリケーションを再び実行します。 多くのケースで、リスナーコンピューターが知る全てのレコードを含むデータベースはないということがわかります。 詳細は、リスナーのソースコードとテストアプリケーションを参照して下さい。

@advanced_1190_h2
リカバーツールを使用する

@advanced_1191_p
リカバーツールはデータベースが破損している場合においても、 データファイルのコンテンツを復元するために使用されます。現段階では、ログファイルのコンテンツ、 または大きなオブジェクト (CLOB または BLOB) は復元しません。 このツールを実行するには、このコマンドラインをタイプして下さい:

@advanced_1192_p
現在のディレクトリのそれぞれのデータベースのために、テキストファイルが作られます。 このファイルには、データベースのスキーマを再び作成するために、行挿入ステートメント (データのための) と data definition (DDL) ステートメントを含んでいます。このファイルは、行挿入ステートメントが 正しいテーブル名を保持していないため、直接実行するこはできません。そのため、 ファイルは実行する前に手動で前処理を行う必要があります。

@advanced_1193_h2