Oracle NoSQL Database変更ログ

リリース12cR1.3.2.5 Enterprise Edition

アップグレード要件

既存のストアをリリース3.2にアップグレードするには、2.0リリース以降でストアを実行する必要があります。2.0より前のリリースで作成されたストアでリリース3.2を使用する場合には、3.2リリースにアップグレードする前にストアを2.0リリースにアップグレードしてください。ストアを3.2にアップグレードした後は、以前のリリースにダウングレードできません。

管理者ガイドの既存のOracle NoSQL Databaseデプロイの更新に関する項を参照してください。

リリース3.2はJava SE 7以降との互換性があり、Oracle JDK 7u67に対してテストおよび認証されています。最新の不具合修正およびパフォーマンス改善を利用するために、最新のJavaリリースにアップグレードすることをお薦めします。

Java 7より前のバージョンのJavaとともにこのリリースを使用しようとすると、次のようなエラー・メッセージが表示されます。

Exception in thread "main" java.lang.UnsupportedClassVersionError:
  oracle/kv/impl/util/KVStoreMain : Unsupported major.minor version 51.0

12cR1.3.2.5 Enterprise Editionでの変更点

新機能

  1. 表および索引の宣言的な作成および管理を可能にする宣言データ定義言語が定義されています。言語リファレンスは、表のためのデータ定義言語にあります。言語は、JavaのAPIと新しいCドライバを介してアクセスできます。管理コマンド・ライン・インタフェース(管理CLI)の新しい"execute"コマンドを使用して実行することもできます。
  2. コマンド・ライン・インタフェース(管理CLI)には、データ定義言語(DDL)文の実行に使用できる新しい"execute"コマンドがあります。JavaまたはC APIは、表を定義するための優先メカニズムですが、管理CLIを介して表を定義および管理する場合は、以前の"table"コマンドよりも"execute"コマンドが優先されます。
  3. Oracle NoSQL Databaseの表および索引を操作する新しいCドライバが作成されました。これは、このディストリビューションと同じページで別途ダウンロードできる製品です。これはソース・コードであり、依存ライブラリとともにコンパイルする必要があります。詳細な手順はディストリビューションに含まれています。
  4. マップのキー文字列に対する索引およびマップの値に対する索引を作成して、これらの索引を様々なデータ・モデルに対してはるかに有用にできるように、マップに対する索引の実装が拡張されました。これらの索引により、特定の行の複数の索引エントリがマップ・エントリ数まで作成されます。これらの索引の使用に役立つAPIが追加されています。
  5. 管理CLIを対話的に使用する場合は、バックスラッシュを使用して、コマンドを複数行に入力できるようになりました。たとえば、次のように入力できます。
    kv-> show events -type stat
     or
    kv-> show events \
    > -type stat
    
  6. Oracle NoSQL DBクラスタのトラブルシューティングをサポートする新しい診断コマンド・ライン・ユーティリティが使用可能です。現在、"収集"機能により、ユーザーはクラスタ内の各ノードのログファイルを簡単に取得してパッケージ化し、詳細に解析できます。追加機能も徐々に公開されます。新しいユーティリティは次の方法で起動します。
    java -jar kvstore.jar diagnostics
    
    diagnostics-> help
    Oracle NoSQL Database Diagnostic Utility Commands:
    	setup
    	collect
    	exit
    	help
    
    diagnostics-> 
    

APIの変更点

  1. データ定義言語(DDL)文を実行するoracle.kv.table.TableAPI.execute(String)およびoracle.kv.table.TableAPI.executeSync(String)が追加されました。
  2. TableAPIに対する新しい文実行メソッドの結果を処理する新しいインタフェースoracle.kv.table.StatementResultおよびoracle.kv.table.ExecutionFutureが追加されました。
  3. 新しいマップ索引を処理するためのoracle.kv.table.MapValue.putNull(String)および定数oracle.kv.table.MapValue.ANONYMOUSが追加されました。
  4. 新しいマップ索引のFieldRangeインスタンスを作成するoracle.kv.table.Index.createMapKeyFieldRange(String)およびoracle.kv.table.Index.createMapValueFieldRange(String)が追加されました。
  5. メソッドoracle.kv.table.TableAPI.execute(List<TableOperation>, WriteOptions)は、oracle.kv.OperationExecutionExceptionをスローしていました。一方、OperationExecutionExceptionは、oracle.kv.tableの表APIではなくoracle.kvパッケージのキー値APIに適用される情報を提供します。メソッドは、表APIに適した情報を提供する新しい例外oracle.kv.table.TableOpExecutionExceptionをスローするように変更されました。

    これは非互換のAPI変更です。TableAPI.execute(List<TableOperation>, WriteOptions)を呼び出したアプリケーションは、OperationExecutionExceptionではなくTableOpExecutionExceptionを処理するように変更する必要があります。

バグとパフォーマンスの修正

  1. CLIのverboseおよびhiddenコマンドが拡張され、以前の切替えタイプ機能に加えてon/offパラメータを使用して指定できるようになりました。[#23245]
  2. デフォルトで非推奨コマンドを表示しないように管理CLIのヘルプが変更されました。新しい-includeDeprecatedフラグがCLI helpコマンドに追加されました。このフラグが使用されている場合、非推奨コマンドは他のコマンドとともにリストされます。[#23365]
  3. java -jar kvstore.jar loadユーティリティは、操作でエラーが発生した場合に正しいフィードバックを提供せず、間違ってLoad succeededを返しました。現在は、エラーが見つかった場合のゼロ以外のステータス・コードと正確なステータス・メッセージの両方を返します。[#23681]
  4. RN間でトポロジ変更を伝播するときに変更されたトポロジを指定することで、任意の認証済クライアントがストアのトポロジを変更できるというセキュリティの脆弱性が修正されました。これを防ぐために署名ベースのトポロジ整合性チェックが採用されています。[#23709]
  5. 基礎となる表への更新が行われているときにストアが展開された場合、セカンダリ索引が間違ってエントリを失うウィンドウが存在しました。このウィンドウは閉じられました。[#23724]
  6. 現在のユーザーに対してロールを付与または取り消すことで行われた変更を有効にするために、ユーザーにストアの再認証を要求していた問題が解決されました。既存のログイン・セッションが再認証なしでロール変更を即時に反映できるようにするリアルタイム・セッション更新メカニズムが導入されました。[#23839]
  7. 管理パラメータが変更されているときに、中断されたchange-parametersプランの再実行が阻害されることがあるというバグが修正されました。[#23880]
  8. ストアを読み取る権限なしで安全なストアに対して並列スキャンを実行しているクライアントに対し、スキャンで値が返されないかわりにタイムアウト例外が発生するという問題が解決されました。この問題は、管理CLIでget kv -allコマンドを使用している場合に発生することがあります。
    kv-> get kv -all
    Error handling command get kv -all: Failed to iterate records :
    Parallel storeIterator Request Queue take timed out.
    (12.1.3.1.3) Timeout: 5000ms
    
    StoreIteratorConfigを提供するKVStore.storeIteratorまたはstoreKeysIteratorメソッド・オーバーロードを使用してスキャンがAPIを介して実行された場合、この問題が原因でメソッド・コールがRequestTimeoutExceptionをスローすることがありました。これらすべてのケースで、繰返しは要素を返さなくなりました。[#23881]
  9. 完全な主キーが指定されている場合にHadoop APIから重複値が返されるという問題が解決されました。[#23958]
  10. 結果セットがバッチ・サイズ(デフォルトは100)より大きい場合に配列索引に対する繰返しで正しくない結果が返されるかハングするというバグが修正されました。[#23977]

12cR1.3.1.7での変更点

新機能

  1. 表名の単一リストおよびオプションのFieldRangeからMultiRowOptionsインスタンスを作成するために表インタフェースに便利なメソッドが追加されました。[#23807]
  2. FieldRangeオブジェクトの作成に使用されていたFieldDefインスタンスを返すためにFieldRange.getField()が追加されました。[#23908]

バグとパフォーマンスの修正

  1. 空の表の索引作成で完了に最大10分かかる原因となっていた問題が解決されました。[#23826]
  2. CLI deleteコマンドでのパフォーマンス低下が解決されました。一部の削除ケースに対する最適化が問題であったため、この修正により一部のdeleteコマンドが低速になりますが、一般的なケースでは、削除はリリース3.0.5と同じパフォーマンスになります。[#23918]
  3. レプリカ・レプリケーション・ノードへの不要な非トポロジ・メタデータ・ブロードキャストが削除されました。マスター・レプリケーション・ノードのみがshardのメタデータを更新できるため、レプリカの更新試行には意味がありません。この変更により、メタデータ・ブロードキャストを制御する新しい2つの管理パラメータが追加されました。
    この修正は、表およびセキュリティ・メタデータのブロードキャストにのみ影響します。トポロジ・ブロードキャスト・パラメータおよび動作は変更されないままです。[#23362]

12cR1.3.1.5での変更点

新機能

  1. APIと管理CLIの両方にロールベース認可のサポートが追加されました。認可は、リリース3.0に導入された認証メカニズムに基づいています。KVStoreの各認証済ユーザーには、ユーザーがアクセスできるAPIおよびCLIコマンドを決定するロールを付与できます。このリリースでは、データ・アクセス制御用の"read"および"write"ロールを含む組込みロールと、システムおよびデータベース操作制御用にそれぞれ"sysadmin"および"dbadmin"ロールがサポートされます。この機能の詳細は、『Oracle NoSQL Databaseセキュリティ・ガイド』で説明されています。

    KVStoreロギング・システムは、セキュリティの影響を受けるイベントをログに記録するように拡張されました。SEC_WARNINGおよびSEC_INFOという2つの新しいロギング・レベルが導入されています。SEC_WARNINGレベルでログに記録されたメッセージは、CLIでクリティカル・イベントを生成します。失敗したログイン試行や不正な操作などの上位レベルのセキュリティ・イベントは、SEC_WARNING KVStoreイベントとして記録されます。sysadminまたはdbadminロールを必要とするCLIコマンドの実行は、SEC_INFOイベントとして記録されます。セキュリティの影響を受けるすべてのイベントのロギング・メッセージには、grepとフィルタリングを簡単にするための接頭辞として"timestamp KVAuditInfo"があります。[#23423]

  2. makebootconfigコマンドは、すべてのパラメータの妥当性チェックを行うように拡張されました。必要に応じてユーザーがデフォルトの妥当性チェックを手動でオーバーライドできる-forceフラグが追加されました。[#23422]

バグとパフォーマンスの修正

  1. plan change-parametersコマンドが失敗することがあり、プラン履歴でNullPointerExceptionがレポートされる原因となっていたバグが修正されました。この状況は、パラメータ変更にすべてのノードの再起動が必要な場合に、使用可能でないノードがある状況でのみ発生しました。[#22673]
  2. 場合によってヒープ・サイズを削減して圧縮済オブジェクト参照の使用を可能にするために、レプリケーション・ノードのヒープ・サイズ計算が変更されました。

    サポートされるJava環境では、ヒープ・サイズが特定のサイズ(現在は実装に応じて25から32GBの間)より小さい場合に圧縮済オブジェクト参照を使用できます。圧縮済参照により節約される領域は大きいため、より大きなヒープ・サイズを使用すると、ヒープ・サイズが圧縮済参照をサポートする最大サイズよりも50%以上大きい場合を除き、通常は使用可能領域が少なくなります。

    memoryMBストレージ・ノード・パラメータの値により、圧縮済参照をサポートするには大きすぎるが使用可能領域を増やすほどには大きくないヒープ・サイズが生成される場合、システムはレプリケーション・ノードのヒープ・サイズを自動的に削減するようになりました。アプリケーションで、非圧縮参照または最大ヒープ・サイズを明示的に指定するjavaMiscParamsレプリケーション・ノード・パラメータが指定される場合、ヒープ・サイズは削減されません。memoryMBパラメータが明示的に指定されていないか、ゼロに設定されている場合、システムにより、ホストで使用可能な物理メモリー量に設定され、memoryMBがゼロ以外の値に明示的に設定されている場合と同じようにヒープ・サイズを削減します。[#22695]

  3. Version.getVersionメソッドは非推奨になり、公開ドキュメントから削除されました。おそらく、将来のリリースで完全に削除されます。getVersionメソッドは、特定のshardに関してのみ意味のある内部バージョン番号を返します。このため、任意のバージョンのメソッド結果の比較は安全ではないため削除されました。アプリケーションは、IDのバージョンを比較するために引き続きequalsメソッドを使用できますが、現在、どちらの方が新しいかを判断するためにバージョンを比較する正式な方法はありません。アプリケーションでニーズがある場合は、将来この機能を追加する可能性があります。[#23526]
  4. plan add-indexコマンドは、索引作成ステータスをよりすばやくチェックするように変更されたため、コマンドはより迅速に終了します。[#23568]
  5. JSON入力を使用してRowおよびPrimaryKeyインスタンスを作成する場合の型検証が追加されました。以前は、表スキーマに基づいて適切な型に警告なしでキャストされていた正しくない型が提供される可能性があり、その結果、情報が失われることがありました。[#23765]
  6. IBM J9 JVM環境にホストされているNoSQL Databaseクラスタの構成中に発生する可能性のあった問題が修正されました。オプションのmemory_mbパラメータに明示的な値を指定せずにストレージ・ノードがデプロイされた場合、そのSNにホストされたレプリケーション・ノードに対する使用可能メモリーの計算は間違っており、plan deploy-topologyコマンドの実行時にそのレプリケーション・ノードで"OutOfMemoryError"が発生する原因となることがありました。この状況は、J9 JVMでのみ発生する可能性がありましたが、解決されました。[#23737]
  7. HadoopとOracle外部表の両方が、ストアからデータを並列に読み取る独立プロセスを採用します。これらのプロセス間に作業を分散する方法が変更されました。新しいアルゴリズムでは、ストア間の並列度を最大化しながら単一レプリケーション・ノード上の競合を最小化する方法で作業を分散しようとします。shardの数、レプリケーション要因および要求される一貫性が計算に対する入力です。この変更は、Hadoopプロセスの数、または生成される分割数にも影響することがあります。作業の分散の変更に加えて、Hadoopおよび外部表の両方のプロセスが並列スキャンAPIを使用でき、複数のスレッドが単一のプロセスで動作できます。[#23749]
    Direction.UNORDEREDのみがサポートされているため、パブリック・メソッドoracle.kv.hadoop.KVInputFormatBase.setDirection(Direction)は非推奨になりました。
  8. 索引が配列または配列内のフィールドに作成され、配列自体がRow内でnullの場合、サーバー・ノードでの索引キー抽出時にClassCastExceptionがスローされることがありました。[#23757]
  9. JARファイルをビルドするデフォルト・ターゲットがCommunity Editionに対して動作するようにAntビルド・スクリプトが変更されました。ソース・コードに変更を行った後で、antを使用してJARファイルの新しいバージョンをビルドできるようになりました。[#23764]
  10. クライアント・プログラムがストレージ・ノードの信頼されるログイン・サービスに対して予期せず安全でないコールを行った場合、サービス実装の欠陥により、サービスがハングし、その後のユーザー・ログインが失敗する原因となりました。このバグは修正されました。[#23786]
  11. 複数の索引イテレータが短期間に連続してオープンおよびクローズされた場合のクライアント・スレッドのランナウェイ数の問題が解決されました。具体的には、イテレータのclose()メソッドは、戻る前にスレッドの終了を待機するようになります。この動作は、並列スキャン・イテレータと同じですが、ドキュメントには待機しないと記載されています。ドキュメントは修正されました。[#23797]
  12. 索引イテレータがクローズされるときにデッドロック状況を引き起こす可能性のあったバグが修正されました。この修正の一部として、oracle.kv.KVStoreおよびoracle.kv.table.TableAPIインタフェースのJavadocが更新され、外部的に同期していないかぎり、これらのインタフェースにより返されるイテレータが一度に1つのスレッドでのみ安全に使用できることが明確化されました。[#23799]
  13. R2.XからR3.xへの一連のNoSQLクラスタのアップグレードでは、最初のストレージ・ノード・アップグレードの発生時に、それがホストするレプリケーション・ノードは"STARTING"ステータスに遷移し、他のノードがアップグレードされるまで待機します。ユーザーがこの時点で"verify upgrade"コマンドを実行した場合、次の誤解されやすいエラーが表示されます。
       kv-> verify upgrade
       Unknown Exception: class oracle.kv.impl.rep.admin.RepNodeAdminFaultException
       RepNode is not RUNNING, current status is STARTING (12.1.3.1.2)
       oracle.kv.impl.rep.admin.IllegalRepNodeServiceStateException:
       RepNode is not RUNNING, current status is STARTING
      
    これは修正されました。[#23859]
  14. NoSQL Database内で使用されているBerkeley DB JEストレージ・エンジンで使用される次のパラメータが変更され、このリリースで使用されるJEの更新済バージョンの変更が反映されました。
  15. チェックポイントの所要時間が10秒を超える場合に、stopユーティリティ・コマンドにより不完全なチェックポイントが発生するというパフォーマンスの問題が解決されました。不完全なチェックポイントにより、レプリケーション・ノードの再起動が完全なチェックポイントの場合より長時間かかることがありました。stopコマンドも変更され、シャットダウンされているストレージ・ノードにホストされているすべてのレプリケーション・ノード間でチェックポイントが並列に初期化されるようになり、コマンドの実行が高速になりました。
  16. 場合によって3.0より前のリリースからのアップグレードが失敗し、管理ログに次のスタック・トレースが記録される原因となっていた問題が解決されました。[#23879]
    com.sleepycat.persist.evolve.IncompatibleClassException: (JE 6.2.5) Changes to the fields or superclass were detected when evolving class:
    oracle.kv.impl.admin.plan.task.StopAdmin version: 1 to class: oracle.kv.impl.admin.plan.task.StopAdmin version:
    1 Error: A new higher version number must be assigned
    ---
    (Note that when upgrading an application in a replicated environment, this exception may indicate that the Master was mistakenly upgraded
    before this Replica could be upgraded, and the solution is to upgrade this Replica.)
        at com.sleepycat.persist.impl.PersistCatalog.init(PersistCatalog.java:512)
        at com.sleepycat.persist.impl.PersistCatalog.initAndRetry(PersistCatalog.java:268)
        at com.sleepycat.persist.impl.PersistCatalog.<init>(PersistCatalog.java:228)
        at com.sleepycat.persist.impl.Store.<init>(Store.java:202)
        at com.sleepycat.persist.EntityStore.<init>(EntityStore.java:190)
        at oracle.kv.impl.admin.Admin.initEstore(Admin.java:2126)
    

12cR1.3.0.14での変更点

新機能

  1. 表APIを使用する場合、レコード、マップおよび配列のフィールドに索引を作成できるようになりました。[#23091]
  2. Oracle NoSQL DatabaseとOracle Coherenceの統合が更新され、Coherence 12c (12.1.2)がサポートされるようになりました。Coherence 12.1.2より、キャッシュ構成パラメータはカスタムXMLのネームスペース内で指定され、実行時にNoSQL Databaseのネームスペース・ハンドラによって処理されるようになりました。この更新されたモジュールはCoherenceバージョン3.7.1でも使用できますが、Coherenceは最新バージョンにアップグレードすることをお薦めします。Coherence 12.1.2または以前のCoherence 3.7.1を使用してNoSQL Databaseでサポートされるキャッシュを構成する方法の詳細は、oracle.kv.coherenceパッケージのjavadocを参照してください。[#23350]
  3. Oracle外部表を使用して、表APIによって作成されたOracle NoSQL Database表にアクセスできるようになりました。通常必要なプロパティに加えて、ユーザーは外部表構成ファイルで表名を指定する必要があります。詳細は、KVHOME/examples/externaltables/cookbook.htmlを参照してください。[#23605]
  4. 指定された表のインメモリー・サイズを見積もるために、管理CLIのtableコマンドに"size"オプションを新たに追加しました。sizeコマンドの結果は、ストアのリソース要件を計画する際の入力として使用できます。[#23444]
  5. Oracle Enterprise ManagerでOracle NoSQL Databaseのインスタンスを監視できるようになりました。詳細は、管理者ガイドのOracle Enterprise ManagerとOracle NoSQL Databaseの統合に関する項を参照してください。
  6. Hadoop MapReduceジョブ内から表APIを介してOracle NoSQL Databaseに書き込まれたデータにアクセスできるようになりました。通常必要なプロパティに加えて、ユーザーはMapReduceジョブの初期化に使用される表名をコマンド・ラインで指定する必要があります。詳細は、クラスのjavadoc、KVHOME/examples/hadoop/table/CountTableRows.javaを参照してください。[#23714]
  7. 表APIを介してOracle NoSQL Databaseに書き込まれたデータに対してHive問合せを実行できるようになりました。この機能を採用するには、Oracle NoSQL Database表が作成されたフィールドに似たフィールド、つまり同じ数とタイプのフィールドで、新しいoracle.kv.hadoop.hive.table.TableStorageHandlerクラスによって'STORED BY'が実行されているHive外部表を作成する必要があります。また、Hive TBLPROPERTIESでは、ストア名、ヘルパー・ホストとポート、および表名(Hive表名と同じである必要はありません)を指定する必要があります。[#23714]

バグとパフォーマンスの修正

  1. サニティ・チェックをさらに追加し、securityconfig add/remove-securityコマンドのエラー・メッセージを改善しました。[#23311]
  2. ストレージ・ノード・パラメータ"mgmtClass"に無効な値を指定すると管理サービスのクラッシュが引き起こされるバグを修正しました。[#23227]
  3. oracle.kv.RequestLimitConfigコンストラクタを修正して限度チェックを改善し、整数オーバーフローの問題を解消しました。[#23244]
  4. 管理者がホストしているSNAがリブートされるまで管理パラメータが有効にならないことがあるバグを修正しました。[#23429]
  5. レプリケーション・グループ内でのRepNodeのメンバーシップの状態を示すために、JMXを介して提供されるRepNode MBeanに新しい属性(String replicationState)を追加しました。通常、この値は"MASTER"または"REPLICA"を示しますが、"DETACHED"または"UNKNOWN"もレポートします。この同じ値は、nosql.mibに定義されたとおり、SNMPを介してrepNodeReplicationStateオブジェクト内でレポートされます。[#23459]
  6. Durability、RequestLimitConfigおよびVersionクラスを修正してSerializableを実装し、すでにシリアライズ可能なoracle.kv.KVStoreConfigのインスタンスのシリアライズを許可しました。[#23474]
  7. 2次索引が入力されている場合にレプリケーション・ノードのフェイルオーバーがあったときに、表APIを使用する操作でSecondaryIntegrityExceptionが表示されるバグを修正しました。[#23520]
  8. これ以前のリリースでは、Loadユーティリティを使用して、セキュリティが有効なストアまたは表APIを使用するストアに対して取得されたスナップショット・ファイルから新しいストアを作成することはできませんでした。これは修正されました。この場合に使用する-security、-username、-load-adminおよび-forceフラグがloadユーティリティに追加されました。詳細は、管理者ガイドを参照してください。[#23528]
  9. 管理CLIで"history"コマンドを呼び出す際に、"-last"オプションと、ストア内で実行されたコマンドの合計数よりも大きい値を使用すると、java.lang.ArrayIndexOutOfBoundsExceptionが発生するバグを修正しました。[#23579]
  10. 管理サービスが次の例外とともに終了するバグを修正しました。この修正の前は、管理機能は別の管理サービスにシームレスにフェイルオーバーしましたが、プロセスの終了は不必要なもので、アラート可能イベントとして現れていました。
    com.sleepycat.je.rep.UnknownMasterException:
    Transaction -XXX cannot execute write operations because this node is no longer a master
    
    [#23580]
  11. 表APIのバグを修正して、enumフィールドにアンダースコアで始まる名前を使用できるようにしました。
  12. まれに、1を超える容量のストレージ・ノードを使用してストアがデプロイされた場合に、同時削除操作、表反復操作、およびシャード内でマスター権限ロールの移動があると、反復操作においてイテレータによって返される値が誤ってスキップされる可能性がありました。これは修正されました。[#23608]
  13. Java GCのCMSフェーズが繰り返し実行され、本来アイドルであるRepNodeのCPUリソースを消費する原因となるGCの構成の問題を修正しました。この修正は、デフォルトのJVM CMSInitiatingOccupancyFractionを77から80に変更しました。テストでは、幅広いアプリケーション・アクセス・パターンにおいてこの構成がより適切なものであることが示されています。しかし、一部の特殊な状況においてこの新しい構成をオーバーライドする必要がある場合は、管理者のchange-policyコマンドを、それが既存のストアである場合は、plan change-parameterコマンドを次のように使用できます。
    change-policy -params "javaMiscParams=-XX:CMSInitiatingOccupancyFraction=77"
    plan change-parameters -all-rns -params "javaMiscParams=-XX:CMSInitiatingOccupancyFraction=77"
    
    [#23652]
  14. セキュリティが有効なストア内で発生する可能性のある次のバグを修正しました。
  15. 弾力性の変更の直後にアプリケーション・リクエストが不必要に短時間タイムアウトするバグを修正しました。[#23705]

パッケージおよびドキュメントの変更点:

  1. Oracle NoSQL DatabaseにバンドルされたOracle Coherenceライブラリのバージョンが最新のCoherence 12.1.2にアップグレードされました。このため、NoSQL Databaseでサポートされるキャッシュ用にキャッシュ構成パラメータを指定する必要があります。
  2. ラージ・オブジェクトAPIの使用方法に関する新しいドキュメントが追加されました。索引ページおよびOracle NoSQL Database Large Object APIを参照してください。

12cR1.3.0.9での変更点

新機能

  1. 管理CLIのコマンドライン履歴がファイルに保存されるように修正され、再起動後に使用できるようにしました。この機能を無効にする場合は、runadminの実行中に次のJavaプロパティを設定する必要があります。
    java -Doracle.kv.shell.jline.disable=true -jar KVHOME/kvstore.jar runadmin -host <hostname> -port <portname>
    

    CLIは、KVHOME/.jlineoracle.kv.impl.admin.client.CommandShell.historyファイルに履歴を保存するよう試みます。このファイルは、自動的に作成およびオープンされます。デフォルトで保存される履歴は500行です。履歴ファイルをオープンできない場合は、サイレント状態で失敗し、履歴を保存せずにCLIを実行します。

    デフォルトの履歴ファイルのパスは、Javaプロパティoracle.kv.shell.history.file=pathを設定することでオーバーライドできます。

    ファイルに保存されるデフォルトの行数は、Javaプロパティoracle.kv.shell.history.size=int_valueを設定することで変更できます。[#22690]

  2. 管理CLIのaggregateコマンドを修正して、キー/値の入力用のサブコマンドを使用できるようにしました。aggregate tableサブコマンドは表の数値フィールドに対する単純なデータ集計操作を実行し、aggregate kvサブコマンドはキーに対する集計操作を実行します。[#23258]

バグとパフォーマンスの修正

  1. 弱参照を使用するように索引イテレータの実装を修正し、ガベージ・コレクタが未使用の索引イテレータに関連付けられたリソースを削除できるようにしました。[#23306]
  2. メタデータ伝播の処理およびその他の内部操作を改善しました。[#23355] [#23368] [#23385]
  3. 外部表の統合を修正して、同時処理の負荷をプロセス間により均等に配分するようにしました。[#23363]
  4. 索引のあるストアのトポロジ再配分の際に実行されたパーティション移行中の失敗により、移行が再開されたときにSecondaryIntegrityExceptionがスローされるという問題を修正しました。[#23392]
  5. FieldRange.setEndDateメソッドを削除し、既存のsetEndメソッドを使用するようにしました。[#23399]
  6. 異なるタイプを使用する古いフィールドを復活させる可能性がある変更を避けるために、スキーマ展開を修正しました。このような変更により、現行の表で古いデータが読取り不可になることがあります。この修正は、以前の定義に厳密に一致しないかぎり、フィールド名の復活を回避します。[#23403]
  7. ネットワーク・タイムアウトの処理の問題を修正し、タイムアウトの発生時にRequestTimeoutではなく、KVStore操作からFaultExceptionがスローされることがないようにしました。次にスタック・トレースの例を示します。
    Caused by: oracle.kv.FaultException: Problem during unmarshalling (12.1.2.1.24)
    Fault class name: java.rmi.UnmarshalException
        at oracle.kv.impl.api.RequestDispatcherImpl.faultIfWrite(RequestDispatcherImpl.java:968)
        at oracle.kv.impl.api.RequestDispatcherImpl.handleRemoteException(RequestDispatcherImpl.java:883)
        at oracle.kv.impl.api.RequestDispatcherImpl.handleDispatchException(RequestDispatcherImpl.java:736)
        at oracle.kv.impl.api.RequestDispatcherImpl.execute(RequestDispatcherImpl.java:572)
        at oracle.kv.impl.api.RequestDispatcherImpl.execute(RequestDispatcherImpl.java:1031)
        at oracle.kv.impl.api.KVStoreImpl.executeRequest(KVStoreImpl.java:1251)
        at oracle.kv.impl.api.KVStoreImpl.putIfVersion(KVStoreImpl.java:990)
        at oracle.kv.impl.api.KVStoreImpl.putIfVersion(KVStoreImpl.java:968)
        [...]
        ... 41 more
    Caused by: java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is:
        java.net.SocketException: Socket closed
        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:228)
        at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
        at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
        at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
        at com.sun.proxy.$Proxy21.execute(Unknown Source)
        at oracle.kv.impl.api.RequestHandlerAPI.execute(RequestHandlerAPI.java:94)
        at oracle.kv.impl.api.RequestDispatcherImpl.execute(RequestDispatcherImpl.java:560)
        ... 46 more
    Caused by: java.net.SocketException: Socket closed
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1822)
        at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:718)
        at sun.rmi.transport.StreamRemoteCall.releaseOutputStream(StreamRemoteCall.java:114)
        at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:212)
        ... 52 more
    
    [#23411]
  8. 表の反復を修正して、すべての一致するエントリが1つのシャードに含まれる場合のパフォーマンスを最適化しました。[#23412]
  9. 別のシャードからのレコードと等価のレコードがある場合に、索引スキャン・イテレータがシャードからレコードを返すことに失敗する問題を修正しました。この状況は、ストアに複数のシャードがあり、指定された索引と等価の索引エントリが両方のシャードにある場合に発生します。これは、索引の反復で予想より少ない行が返される症状です。[#23421]
  10. 表パッケージにいくつかのインタフェースを追加しました。 関連するjavadocも、これら(および類似のインタフェース)から返されるリストおよびマップが不変であることを示すように更新されました。[#23433]
  11. データ・コマンドライン・インタフェース(CLI)には、JSON記法によるファイルから表の行を入力するメソッドがあります。この入力メソッドには、空白行が原因で入力パスに無限ループが発生する問題がありました。これは、空白行およびコメント行(最初の非空白文字が"#"の行)をサイレントにスキップする方法で修正されました。[#23449]
  12. 索引付きフィールドおよびIndexKeyのnull値の処理を修正しました。これまで、索引付きフィールドのnull値はサーバー側の例外の原因となっていました。putの間、索引付きフィールドのnull値が原因で、そのフィールドが参加する索引に対する索引エントリがなくなります。さらに、IndexKeyインスタンスではnull値が許可されていません。IndexKeyにnull値を設定しようとすると、IllegalArgumentExceptionがスローされます。[#23588]
  13. ホスト上のすべてのインタフェースをリッスンするように管理サービスを修正しました。この変更により、異機種間ネットワーク環境におけるKVStoreのデプロイメントが可能になりました。この場合、ホスト名を異なるIPアドレスに解決し、使用可能なネットワーク・ハードウェアを最大限に利用できます。[#23524]

12cR1.3.0.5での変更点

新機能

  1. 一連のデータ型およびこれらのデータ型を使用した表形式データ・モデルが含まれる新しいクライアント・インタフェースが追加されました。この表形式データ・モデルにより、表内のフィールドで定義されている2次索引がサポートされます。このモデルについては、Tableスタート・ガイドで説明されています。

    表および索引は、管理CLIを使用して定義され、プログラムAPIを介してアクセスされます。データCLIが拡張され、表および索引に対しても操作を実行できるようになりました。APIについてはOracle NoSQL Database javadocで説明されており、主にoracle.kv.tableパッケージ内にあります。

    NoSQL DBリリース2を使用して作成されたデータが、準拠するAvroスキーマを使用して作成されたものである場合、このデータをオーバーレイする表を定義できます。準拠するリリース2のデータで2次索引を作成するには、このオーバーレイが必要です。

    既存のキー/値インタフェースは引き続き使用可能です。

  2. レコードに対して2次索引を定義できるようになりました。表に関する前述の変更ログ・エントリを参照してください。特定のレコードの索引エントリには、対応するプライマリ・レコードとのトランザクション一貫性があります。索引の反復操作は、新しい表APIの一部です。索引スキャン操作を使用すると、RAW索引に対して3通りの方法(正順、逆順および順序付けなし)で反復できるようになります。索引に対して完全一致および範囲スキャンを定義できます。索引は、単一フィールドに対して定義することも、表内の複数のフィールドに対する複合索引として定義することもできます。
  3. ユーザー名/パスワード認証およびセキュアなネットワーク通信のサポートが追加されました。この機能を必要としない既存のアプリケーションはこの影響を受けません。ただし、必須の引数(-store-security)が新しく追加されている、makebootconfigに対する変更は除きます。新機能の使用を希望するユーザーは、次の変更領域に注意する必要があります。

    ユーザーは、セキュリティ・プロパティ・ファイルについてもよく理解している必要があります。これらのファイルは、セキュアなストアに対してKVStoreコマンドライン・ユーティリティ・プログラムを使用する際に必要であり、セキュアなストアに対してアプリケーションを実行する際にも役立つ場合があります。

    この機能は、『Oracle NoSQL Databaseセキュリティ・ガイド』や管理者ガイドおよび製品のJavadocでさらに詳しく説明されています。

  4. 管理CLIが、データ・センターに言及するのに新しい用語を使用するように変更されました。データ・センターはゾーンと呼ばれるようになりました。新しい用語は、これらのノード・グループが物理データ・センターと必ずしも一致するとは限らないことを明らかにすることを目的としています。ゾーンは、ネットワークの相互接続性が良好であり、他のゾーン内のノードとある程度物理的に分離されているノードの集合です。この物理的な分離とは、各ゾーンが異なる物理データ・センター・ビルに配置されていることを意味する場合がありますが、特定のデプロイメントに応じて異なるフロア、ルーム、ポッドまたはラックを表す場合もあります。

    "datacenter"という単語が含まれるコマンドは非推奨となり、"zone"という単語を使用したコマンドに置き換わりました。このリリースでは、以前のコマンドもそのまま機能します。新しいコマンドは、次のとおりです。

    ゾーンを指定するコマンド・フラグは、ゾーンIDの場合は-znに、ゾーン名の場合は-znnameに変更されました。以前の-dcおよび-dcnameフラグは非推奨となりましたが、このリリースではそのまま機能します。また、ゾーンIDはzn接頭辞を使用して指定できるようになりましたが、以前のdc接頭辞も現在サポートされています。

    管理GUIが、この新しい「ゾーン」という用語を使用するように変更されました。[#22878]

  5. 現在、ゾーンには2つのタイプがあります。プライマリ・ゾーンには、選択可能なノードが含まれます。これは、マスターまたはレプリカとして機能し、マスター選択に参加できます。以前のリリースで作成されたゾーン(またはデータセンター)はすべてプライマリ・ゾーンであり、新しいゾーンはデフォルトではプライマリ・ゾーンとして作成されます。セカンダリ・ゾーンには、新しいセカンダリ・ノード・タイプのノードが含まれます。これは、レプリカとしてのみ機能し、マスター選択には参加しません。セカンダリ・ゾーンを使用して、離れた場所で使用可能なデータのコピーを作成したり、データの余分なコピーを維持し、冗長性や読取り能力を向上させることができます。[#22483]
  6. show planコマンドで、移行の完了時間の見積りが示されるようになりました。次に例を示します。
    Plan Deploy Topo (12)
    State:                 RUNNING
    Attempt number:        1
    Started:               2014-01-14 17:35:09 UTC
    Ended:                 2014-01-14 17:35:27 UTC
    Total tasks:           27
     Successful:           12
     Incomplete:           15
    Incomplete tasks
       3 partition migrations queued
       1 partition migrations running
       11 partition migrations succeeded, avg migration time = 550164 ms.
    Estimated completion:  2014-01-14 19:57:37 UTC
    
    [#22183]
  7. このリリースで、新しい読取り一貫性オプションが追加されました。oracle.kv.Consistency.NONE_REQUIRED_NO_MASTERを使用して、目的の読取り操作が必ずマスターではなくレプリカによって処理されるよう指定できるようになりました。読取りの負荷が高いアプリケーション(分析など)の場合、マスターに対する負荷を軽減するために、読取り要求を分離し、これらがマスターではなくレプリカに対してのみ実行されるようにした方がよい場合があります。この種の読込みの分離を実現する上で望ましいメカニズムが、新しいセカンダリ・ゾーン機能です。この目的のためにはこの機能を採用することをお薦めします。ただし、セカンダリ・ゾーンの使用が望ましくない場合や現実的でない場合は、oracle.kv.Consistency.NONE_REQUIRED_NO_MASTERを使用すると、セカンダリ・ゾーンの場合に必要となる可能性があるリソースの追加なしで同様の効果を上げることができます。[#22338]
  8. 次のメソッドが追加されました。

    これらのメソッドを使用すると、指定したゾーン内にあるノードについてのみ読取り操作が実行されるよう要求できるようになります。

  9. show plansコマンドが変更され、プラン履歴の範囲を指定できるようになりました。show plansでは、引数なしで、最近作成された10のプランのみが表示されるようになりました。ただし、新しい引数を使用して、作成時間やプランID別に範囲を選択することもできます。すべてのオプションの一覧を確認するには、コマンドshow plans -helpを発行します。
  10. makebootconfigユーティリティに、新しい-runadminコマンドライン引数がオプションとして用意されました。これを使用すると、-adminの値が0に設定されている場合でもSNAでブートストラップ管理を強制的に起動できます。

    管理CLI内のplan deploy-adminのオプション-portが変更され、管理Webサービスの起動を制御できるようになりました。デプロイで-portが0に設定されている場合、管理のWebサービスは起動されません。

    ユーザーは、管理CLIのplan change-paramコマンドを介してデプロイメント後に管理のHTTPポートを変更し、管理によるWebサーバーの実行の有無に関する設定を変更することもできます。[#22344]

  11. plan change-paramコマンドが変更され、単一管理サービスのパラメータを変更できるようになりました。[#22244]
  12. NoSQLトポロジ情報は管理サービスとストレージ・ノードの両方に格納されますが、deploy-topologyやmigrate-snなどのトポロジ変更プランが完了前に取り消されると、この情報の一貫性がなくなる可能性があります。不整合は、ターゲット・トポロジの再デプロイによって修復できます。このリリースでは、トポロジの不整合を修復する別の方法としてplan repair-topologyコマンドも用意されています。verify configurationコマンドでは、repair-topologyの使用が役立つタイミングに関する推奨が生成されるようになりました。[#22753]

バグとパフォーマンスの修正

  1. makebootconfigコマンドで、既存の構成ファイルの上書きが拒否されたときにメッセージが出力されるようになりました。[#23012]
  2. plan remove-adminで、実行されていないストレージ・ノードによってホストされている管理を削除できるようになりました。[#23061]
  3. ストレージ・ノードのconfig.xmlファイル内の管理セクションが重複する原因となる場合があった不具合を修正しました。そのため、このような不規則な構成がある管理サービスに対してplan change-parametersコマンドを適用しても、予期せずこのコマンドの効果がない可能性があります。この不具合は、すでにデプロイされている管理をデプロイしようとしたときに発生する可能性がありますが、失敗したplan migrate-storagenodeコマンドを再実行したときに発生する可能性もあります。[#23152]
  4. 新しいレプリケーション・ノードの作成時にtopology redistributeコマンドでストレージ・ディレクトリの設定が無視される原因であった問題を修正しました。[#23161]
  5. 以前は、レプリケーション・ノードのメトリック収集期間(statsInterval)中にアクティビティがなかった場合、前の期間のメトリック値がJMXおよびSNMPによってレポートされていました。この動作は変更され、すべての間隔でメトリックが更新されるようになりました。[#22842][#22537]
  6. NoSQL DBによってマスター・アイデンティティが自動的に調整されるため、マスター・ノードがストア全体にわたって配分され、最適なパフォーマンスが得られます。マスターのバランス調整が複数のゾーンにわたって実行される妨げとなっていた問題を修正しました。[#22857]
  7. InputStream.skipに対するコールによってゼロ以外の値が返されるかぎり、入力ストリームを開始位置に配置するためにこのコールを必要に応じて繰り返すようLOB実装を変更しました。コールによってストリームが必要な開始位置に移動されない場合、IllegalArgumentExceptionがスローされます。

ユーティリティの変更点:

  1. 管理コマンドライン・インタフェース(CLI)とデータ・コマンドライン・インタフェースが単一プログラムにマージされました。マージされたCLIの使用方法には、最も古い使用方法との互換性がありますが、管理操作、データ操作あるいはその両方に対して有効化するための追加オプションが用意されています。この変更により、データ操作用としてkvstore.jarの使用が必要となりました。前のリリースでは、データCLIには、kvclient.jarに依存するkvcli.jarのみが必要でした。
  2. CLIが、表、索引、セキュリティ情報およびゾーンの管理に必要なコマンドにより拡張されました。

ドキュメントの変更:

  1. 表形式データ・モデルおよび2次索引の導入により、新しいTable APIスタート・ガイドが追加されました。
  2. 新しいセキュリティ機能の導入により、新しいセキュリティ・ガイドが追加されました。

パッケージの変更:

  1. Oracle NoSQLデータベースに同梱されているAvroおよびJacksonライブラリのバージョンが最新のAvro 1.7.6およびJackson 1.9.3にアップグレードされました。これらのバージョンは以前のAPIバージョンと互換性があります。

12cR1.2.1.57での変更点

新機能

  1. 新しいメソッドKVStore.appendLOB()では、既存のLOB (ラージ・オブジェクト)への追加が許可されるようになりました。この変更の一環として、メソッドPartialLOBException.isPartiallyDeleted()が非推奨となり、新しいメソッドPartialLOBException.getPartialState()が推奨となります。この新機能の詳細な説明は、これらの新しいメソッドに付属のJavadoc、およびインタフェースKVLargeObjectに関して更新されたドキュメントを参照してください。

    このリリースには、以前のリリースで作成されたLOBに対する下位互換性があります。ただ、これには1つの例外があり、これ以降のリリースで作成されるLOBのみが追加操作をサポートします。以前のリリースで作成されたLOBに対して追加操作を使用しようとすると、メソッドによりUnsupportedOperationExceptionがスローされます。

    このリリースで作成されたLOBは、以前のリリースを使用しているクライアントから読取りや削除を行うことはできません。通常、このような操作は失敗し、ConcurrentModificationExceptionがスローされます。新しいLOBを作成する前にすべてのクライアントをこのリリースに更新するようにしてください。[#22876]

  2. 管理サービスおよびレプリケーション・ノード・サービス用のGCログ・ファイルがデフォルトで生成され、KVROOT/<storename>/logディレクトリ(NoSQLに関するすべてのロギング情報用の標準の場所)に配置されるようになりました。このデフォルトの動作は、JDKリリース1.7以降のリリースを使用している場合のみ適用されます。これは、GCログのローテーションは最新のJDKでのみサポートされるためです。ロギングによるリソースのオーバーヘッドは最小限です。これらのログ・ファイルを即座に使用できるようにしておくことは、本番Javaアプリケーションのデプロイメントに関するベスト・プラクティスに準拠しています。これにより、必要な場合に、GC問題をより簡単に診断できるようになります。[#22858]

バグとパフォーマンスの修正

  1. 多数の変更が行われたストアの操作時における管理サービスのヒープ要件が削減されました。[#21143]
  2. プラン履歴レポートからのパーティション移行タスクに関する情報が省略される原因となった管理CLIのshow plan -id <id>コマンドの不具合を修正しました。現在、このコマンドには、パーティションの移行に関する情報が正しく含まれています。[#22611]
  3. マスターとレプリカ間のネットワーク接続に関連する内部タイムアウト値が削減され、ネットワーク・ハードウェアに障害が発生した場合にマスターをより速くフェイルオーバーできるようになりました。[#22861]
  4. 3968KBより大きいLOBで失敗したPut操作を再開しようとすると、状況によっては不正なConcurrentModificationExceptionが生じる可能性がありました。この不具合はこのリリースで修正されました。[#22876]
  5. プランを管理のメモリーに表示する方法が変更されました。以前は、現在アクティブなプランと履歴プランのインメモリーに表示可能なサイズに制限はありませんでした。この修正により、アクティブなプランのみがメモリー内に保持されるようになりました。[#22963]
  6. 管理におけるプラン管理のデッドロックが解消されました。[#22992]
  7. setterメソッドStoreIteratorConfigの引数チェックの不具合が修正されました。[#23010]
  8. makebootconfigコマンドで、既存の構成ファイルの上書きが拒否されたときにメッセージが出力されるようになりました。[#23012]
  9. レプリケーション・ノード構成が変更され、レプリケーション・ノードのキャッシュが必要な量より少ない場合、キャッシュの退去が行われ、CPU使用率が削減されるようになりました。[#23026]
  10. remove-adminコマンドでは、実行されていないストレージ・ノードによってホストされている管理を削除できるようになりました。[#23061]
  11. show plansコマンドでは、メモリーの消費が大きすぎるために管理CLIがクラッシュする場合がありました。これは修正されました。[#23105]

12cR1.2.1.54での変更点

新機能

  1. Oracle NoSQL Databaseのクライアント専用パッケージが提供されるようになりました。Oracle NoSQL Databaseクライアント・ソフトウェア・ライブラリのライセンスは、Apache 2.0ライセンス(Apache 2.0)に準じて提供されます。NoSQL DBクライアント・ソフトウェア・ライブラリのApacheライセンスおよびサード・パーティの通知については、この場所またはダウンロードしたソフトウェアで確認できます。
  2. KVStore.storeIterator()およびKVStore.storeKeysIterator()の新たなオーバーロードには、パラレル・スキャンが導入されています。その他のstoreIterator()メソッドでは、すべてのシャードとレプリケーション・ノードをシリアルにスキャンします。新しいパラレル・スキャン・メソッドでは、レプリケーション・ノードをパラレルにスキャンする際に使用するクライアント側のスレッド数を指定できます。[#22146]

バグとパフォーマンスの修正

  1. データ・コマンドライン・インタフェース(kvshell)のエラー・メッセージを改善しました。たとえば、putコマンドに無効な入力を指定すると、以前は次のようなエラー・メッセージが返されていました。
    kvshell-> put -key /test -value ./emp.insert -file -json Employee
      Could not create JSON from input:
      Unable to serialize JsonNode
    
    現在は、次のような有用な応答が生成されます。
    kvshell-> put -key /test -value ./emp.insert -file -json Employee
    Exception handling command put -key /test -value ./emp.insert -file -json Employee:
      Could not create JSON from input:
      Expected Avro type STRING but got JSON value: null in field Address of Employee
    
    [#22791]
  2. plan deploy-adminコマンドを使用した際のバグを修正しました。管理サービスの起動時にエラーが発生すると、プロセスが応答不能になる場合がありました。正しい動作では、プロセスは停止した後、所有するストレージ・ノードから再起動します。[#22908]

12cR1.2.1.25での変更点

バグ修正

  1. シャットダウン中にストレージ・ノード・エージェント・プロセスがマスター調整に関連したリモート・リクエストを受信すると、リクエストを開始したストレージ・ノード・エージェントのマスター調整機能を無効にする例外がまれにスローされる可能性があります。この問題は、リクエストを開始したストレージ・ノード・エージェントのログの次の(または類似の)出力を介して特定できます。
    
    2014-03-28 12:13:34.544 UTC SEVERE [sn2] MasterRebalanceThread thread exiting due to exception.
    null (12.1.2.1.24) java.lang.NullPointerException
        at oracle.kv.impl.sna.StorageNodeAgentImpl$27.execute(StorageNodeAgentImpl.java:838)
        at oracle.kv.impl.sna.StorageNodeAgentImpl$27.execute(StorageNodeAgentImpl.java:831)
        at oracle.kv.impl.fault.ProcessFaultHandler.execute(ProcessFaultHandler.java:119)
        at oracle.kv.impl.sna.StorageNodeAgentImpl.getMDInfo(StorageNodeAgentImpl.java:829)
        at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        ...
        at com.sun.proxy.$Proxy1.getMDInfo(Unknown Source)
        at oracle.kv.impl.sna.StorageNodeAgentAPI.getMDInfo(StorageNodeAgentAPI.java:492)
        at oracle.kv.impl.sna.masterBalance.RebalanceThread.orderMSCNs(RebalanceThread.java:580)
        at oracle.kv.impl.sna.masterBalance.RebalanceThread.candidateTransfers(RebalanceThread.java:485)
        at oracle.kv.impl.sna.masterBalance.RebalanceThread.run(RebalanceThread.java:301)
    2014-03-28 12:13:34.546 UTC INFO [sn2] Master balance manager shutdown
    2014-03-28 12:13:34.546 UTC INFO [sn2] MasterRebalanceThread thread exited.
    
    
    [#23419]

12cR1.2.1.24での変更点

バグとパフォーマンスの修正

  1. レプリケーション・ノードが停止する直前またはマスターからレプリカ状態に遷移している途中などの特定の状況において、未処理リクエストのクリーン・アップ時に問題が発生することがありました。ノードは自動的に再起動して操作が再試行されるため、この問題はアプリケーションに対して透過的でしたが、ノードのフェイルオーバーを不必要に発生させる可能性がありました。これは修正されました。
    java.lang.IllegalStateException: Transaction 30 detected open cursors while aborting
        at com.sleepycat.je.txn.Txn.abortInternal(Txn.java:1190)
        at com.sleepycat.je.txn.Txn.abort(Txn.java:1100)
        at com.sleepycat.je.txn.Txn.abort(Txn.java:1073)
        at com.sleepycat.je.Transaction.abort(Transaction.java:207)
        at oracle.kv.impl.util.TxnUtil.abort(TxnUtil.java:80)
        at oracle.kv.impl.api.RequestHandlerImpl.executeInternal(RequestHandlerImpl.java:469)
        at oracle.kv.impl.api.RequestHandlerImpl.access$300(RequestHandlerImpl.java:122)
        at oracle.kv.impl.api.RequestHandlerImpl$2.execute(RequestHandlerImpl.java:301)
        at oracle.kv.impl.api.RequestHandlerImpl$2.execute(RequestHandlerImpl.java:290)
        at
    oracle.kv.impl.fault.ProcessFaultHandler.execute(ProcessFaultHandler.java:135>
    
    [#22152]
  2. NoSQL DBの以前のリリースでは、レプリケーション・ノードがマスターからレプリカ状態に遷移する場合、その遷移過程でデータベース環境をクローズして再オープンする必要がありました。現在の遷移は効率化されているため、多くの場合データベース環境に混乱が生じることはありません。遷移が必要とするリソースは少なくなり、ノードの可用性が向上しました。[#22627]
  3. plan deploy-topologyコマンドに保護手段が追加され、トポロジのバランス再調整とプランの再配分における信頼性が向上しました。レプリケーション・ノードを別のストレージ・ノードに移動する場合、操作を行う前に、操作対象のストレージ・ノードが起動され実行中であることをコマンドによってチェックするようになりました。[#22850]
  4. 特定の状況において、レプリケーション・ノードがシャードに参加するときに古くなったマスター・アイデンティティ情報を使用する可能性がありました。これによって、ターゲット・ノードが使用不可である場合に遅延が生じることがありました。これは修正されました。[#22851]
  5. 特定の状況において、操作が完了前にoracle.kv.impl.fault.TTLFaultExceptionで終了しました。現在、この例外はサーバーとクライアントのライブラリによって内部的に処理され、操作が再試行されます。障害状態が継続する場合、操作は最終的にoracle.kv.RequestTimeoutExceptionで失敗します。[#22860]
  6. 以前は、レプリケーション・ノードが起動してシャードに参加するためにシャード・データのコピーの転送を要する場合がありましたが、これは不必要でした。これは修正されました。[#22782]
  7. Oracle NoSQL DBデプロイメントに新しいストレージ・ノードが追加され、新しいトポロジがデプロイされる場合、ストアではパフォーマンスを最適化するためにマスター・ロールが再配分されます。フェイルオーバーやマスター変更などの他のイベントが発生するまで、ストアが新しいストレージ・ノードを通知しない場合があり、マスターのバランス調整に遅れが生じることがありました。これは修正されました。[#22888]
  8. ストアで使用するJE構成パラメータje.evictor.criticalPercentageの設定が修正されました。これは105に設定されていましたが、20に変更されました。この新しい設定値によって、データ・セットのサイズがメモリー設定の最適値を超える場合のキャッシュ管理動作が改善されます。[#22899]

ユーティリティとドキュメントの変更点

  1. CLIのpingコマンドの出力にタイムスタンプが追加されました。[#22859]

12cR1.2.1.19での変更点

ドキュメントの変更点

  1. このリリースには、新しいドキュメント『Oracle NoSQL Database可用性およびフェイルオーバー』が含まれます。ここでは、Oracle NoSQL Databaseを使用する際のデータの可用性に関する一般的な概念と問題を説明しています。このドキュメントの対象読者は、システム・アーキテクトと開発者です。ドキュメントの索引ページにある開発者向けの項に、新情報が記載されています。
  2. <KVHOME>/examples/avroにあるAvroバインディングを例にした、.avscファイルをクラスパスに追加する手順を明確化しました。.avscファイルが適切に使用可能になっていない場合のエラー・メッセージを改善しました。

バグとパフォーマンスの修正

  1. ロック・タイムアウトの内部パラメータを500ミリ秒から10秒に増やしました。NoSQL DBではデータ・アクセスにデッドロックが発生しないため、小さい値のタイムアウト値は必要ありません。これによって一時的なネットワーク障害の際に疑似エラーが発生することがありました。[#22583]
  2. 一時的なネットワーク障害が発生している場合、またはレプリケーション・ノードの移動に数秒以上かかる場合にplan deploy-topologyコマンドを使用してストアのトポロジを変更すると、次のエラーが発生することがあります。ストア状態の整合性が失われておらず、コマンドを手動で再試行できるとしても、コマンドは通信の不調からより速やかに回復できる必要があります。
    ... [admin1] Task 2/RelocateRN ended in state ERROR with
    java.lang.RuntimeException: Time out while waiting for rg4-rn1 to come
    up on sn1 and become consistent with the master of the shard before
    deleting the RepNode from its old home on sn4 2/RelocateRN failed.
    
    java.lang.RuntimeException: Time out while waiting for rg4-rn1 to come
    up on sn1 and become consistent with the master of the shard before
    deleting the RepNode from its old home
    

    コマンドの待機時間が調整され、再試行が適切に行われるようになり、レプリケーション・ノードの移動が完了したかどうかを確認できるようになりました。[#22596]

  3. データ・ファイルを持つディレクトリが削除された場合、またはデータ・ファイルが破損した後に修復された場合に、レプリケーション・ノードが自動的に再起動しないバグを修正しました。[#22626]
  4. セグメント化されたネットワークのスプリット・ブレイン・シナリオにおいて、クライアントの書込みリクエストが権限のあるマスターに向かうという従来の正しい動作を補強するため、さらにテストを追加しました。[#22636]
  5. java -jar kvstore.jar pingコマンドを使用すると、ストア内で有効ではなくなったコンポーネントに関する疑似メッセージが生成される場合がありました。
    Failed to connect to service commandService
    
    Connection refused to host: 10.32.17.12; nested exception is:
      java.net.ConnectException: Connection refused
            SNA at hostname:localhost registry port: 6000 has no available
            Admins or RNs registered.
    
    これらのメッセージは特に、デプロイされた管理サービスをホストしていないストレージ・ノードのブートストラップ管理に対して発生します。ストアの整合性はとれているため、混乱をまねくエラー・メッセージは削除されました。[#22639]
  6. レプリケーション・ノードのマスター移動時に表示される小さなタイミング・ウィンドウを修正しました。アプリケーションの負荷が高い状態でマスターの移動が発生した場合、移動トランザクションのキャッチ・アップ・ポイントの後戻りがこのウィンドウによって誤って引き起こされる可能性がありました。その結果、シャード・マスターの移動にかかる時間が長すぎることや短すぎることがありました。移動時間が短すぎると、ターゲット・マスターの最適なキャッチ・アップが行われない可能性があります。シャードの第3のメンバーによってこれが検知されると、例外がスローされます。[#22658]
  7. ノードがマスターからレプリカに遷移する際に、レプリケーション・ノードの停止と再起動を優先的に行います。これにより、データベース環境の更新の際のGCコストが軽減されます。[#22658]
  8. 元のターゲットが使用可能でないことが検知された場合に、データ・リクエストがすぐに再試行または転送されるよう、NoSQLクライアント・ライブラリを変更しました。これによって、レプリケーション・ノードの障害により速やかに適応できるようになりました。[#22661]
  9. トポロジ変更の実行中に、NoSQLデプロイメントで一時的なエラーが表示される場合がありました。ストアの整合性はとれていましたが、このエラー・メッセージによって混乱が生じ、plan deploy-topologyコマンドが誤って失敗する可能性がありました。これは修正されました。
     ... INFO [rg1-rn1] Failed pushing entire topology push to rg1-rn3
    updating from topo seq#: 0 to 1001 Problem:Update to topology seq#
    1001 failed ... oracle.kv.impl.fault.OperationFaultException:
      Update to topology seq# 1001 failed
        at oracle.kv.impl.rep.admin.RepNodeAdminImpl$6.execute(RepNodeAdminImpl.java:261)
        at oracle.kv.impl.fault.ProcessFaultHandler.execute(ProcessFaultHandler.java:169)
        at oracle.kv.impl.rep.admin.RepNodeAdminFaultHandler.execute(RepNodeAdminFaultHandler.java:117)
    
     ...INFO [rg1-rn3] Topology update skipped. Current seq #: 1001 Update seq #: 1001
    
    [#22678]
  10. メモリー不足エラーが発生したレプリケーション・ノードが自動的に再起動しないバグを修正しました。[#22679]
  11. ストレージ・ノードがブートストラップのmemory_mbパラメータの値なしで構成されている場合に行われる、ストレージ・ノードの使用可能メモリーのデフォルトの計算を修正しました。以前は、MBではなく10進法のメガバイト単位を使用して計算していたため、レプリケーション・ノードの適正なヒープ・サイズを高く見積りすぎていました。このデフォルトの計算は、ストアがmemory_mbプロパティのブートストラップ値なしで構成されていて、memory_mbストレージ・ノード・パラメータが設定されたことがない場合にのみ使用されます。[#22687]
  12. ストレージ・ノードがホストするレプリケーション・ノードのレプリカ/マスター状態を、より速やかに更新します。この修正は、1より大きい容量値を持ち、複数のレプリケーション・ノードをホストできるストレージ・ノードが含まれるストアでplan deploy-topologyコマンドを実行する場合に適用されます。ストレージ・ノードに対するレプリケーション・ノードの状態の通知が遅れると、マスター職責の最適な配分が保てなくなります。[#22689]
  13. plan deploy-topologyコマンドを実行すると管理サービスが応答しなくなるバグを修正しました。この間、管理サービスのプロセスはアイドル状態になり、時折1~2秒のCPU時間を消費するだけで、管理CLIを使用して新しい接続を試みても応答しませんでした。この問題は、数百コンポーネントが含まれるような大規模なクラスタでのみ発生すると考えられます。[#22694]
  14. plan deploy-topologyでトポロジが変更されると、レプリケーション・ノードが別のストレージ・ノードに移動します。この際に一時的なネットワーク障害が発生した場合の回復方法が改善されました。移動に関連するシャードとストレージ・ノードが使用可能で変更を受け入れる準備ができていることを確認するための事前チェック追加されました。移動の途中でネットワーク障害が発生した場合に、再試行のためにシステム管理者が発行するコマンドが使いやすくなりました。[#22722]
  15. ストアにおいてトポロジの変更が実行されており、これに高負荷状態でのパーティション移行が必要とされている場合に、アプリケーション・リクエストの処理が失敗するバグを修正しました。[#22778]
  16. レプリケーション・ノードのガベージ・コレクションのデフォルト・パラメータを調整してさらに最適化しました。これにより、CPUの使用率が軽減される場合があります。[#22779]
  17. ダウンタイムまたはネットワークの通信障害によってレプリカのレプリケーション・ノードが大幅に古くなった場合に、これを最新にしてアプリケーションのリクエストを処理できるようにするまでにかかる時間を短縮しました。以前はキャッチ・アップ・ステージを開始する前にプロセスを終了して再起動していましたが、現在は再起動をスキップするようになりました。[#22783]
  18. リソースを使用できない場合などにレプリケーション・ノードの再起動が繰返し失敗し、ストレージ・ノードの内部キューがいっぱいになってしいまうバグを修正しました。この場合はストレージ・ノードでレプリケーション・ノードを自動的に再起動できなくなるため、リブートを行う必要があります。[#22786]
  19. リソースの不足などによるエラーの繰返しで停止したレプリケーション・ノードが、plan start-serviceコマンドで再度有効化されても再起動しないバグを修正しました。[#22828]
  20. 再起動中のレプリケーション・ノードで次のnullポインタ例外が発生するバグを修正しました。これは一時的に発生した問題です。
       INFO [sn1] rg2-rn2: ProcessMonitor: startProcess
       INFO [sn1] rg2-rn2: ProcessMonitor: stopProcess
       SEVERE [sn1] rg2-rn2: ProcessMonitor: Unexpected exception in
    MonitorThread:
            java.lang.NullPointerExceptionjava.lang.NullPointerException
            at oracle.kv.impl.sna.ProcessMonitor$MonitorThread.run(ProcessMonitor.java:404)
    
    [#22830]
  21. クライアント・ライブラリのUnknownHostExceptionとConnectIOExceptionの解析を改善したことで、より速やかにネットワークの問題を検出し、使用できないレプリケーション・ノードのセットを更新できるようになりました。[#22841]

12cR1.2.1.8での変更点

新機能

  1. このリリースには、ストアをオフラインにせず、また進行中の操作に大きな影響を与えずにNoSQL DBソフトウェア(クライアントまたはサーバー)をアップグレードするためのサポートが含まれます。また、アップグレードは増分的に実行できるため、すべてのコンポーネントで同時にソフトウェアを更新する必要はありません。このサポートには、クライアントおよびサーバーのコード変更と、新しいコマンドライン・インタフェース(CLI)コマンドが含まれます。[#22421]

    新しいCLIコマンドは、アップグレード・プロセスをサポートする管理者ツールとなります。これらのコマンドを使用した汎用のアップグレード手順は次のとおりです。

    1. 管理サービス1を実行するストレージ・ノードに新しいソフトウェアをインストールします。
    2. 新しいクライアントをインストールしてストアに接続します。
    3. verify prerequisiteコマンドを使用し、ストア全体がアップグレード対象として適切なソフトウェア・バージョンであることを確認します(すべてがNoSQL DBバージョン2.0であれば前提条件として適格です)。
    4. show upgrade-orderコマンドを使用して、アップグレードするノードの順序付きリストを取得します。
    5. ストレージ・ノードに新しいソフトウェアをインストールします(個別に、または順序付きリストに基づいてグループで)。
    6. verify upgradeコマンドを使用して、進行状況を監視し、アップグレードが成功したことを確認します。

    1今後のリリースではこの手順が不要になる予定です。

    アップグレード手順を中断した場合は、必要に応じて手順4から6を繰り返してアップグレードを完了してください。

バグとパフォーマンスの修正:

  1. アプリケーションによって意図的に構成される場合を除き、NoSQL DBはレプリケーション・ノード・プロセスごとに-XX:ParallelGCThread jvmフラグを指定して、プロセスが使用するガベージ・コレクタ・スレッドの数を示します。以前は、使用されるアルゴリズムによって最小値1のスレッドが生成されていました。テストを重ねた結果、最小値はmin(4, <ノード上のコア数>)にまで引き上げられました。[#22475]

APIの変更点

  1. 管理コマンドライン・インタフェース(CLI)に、次のコマンドが追加されます。[#22422]

    verify prerequisite [-silent] [-sn snX]*

    このコマンドは、ストアの一連のストレージ・ノードが現行バージョンへのアップグレードに必要な前提条件を満たしていることを確認し、前提条件を満たしていないコンポーネントや接続できないコンポーネントを表示します。また、インストールされているソフトウェアが現行バージョンより新しいマイナー・リリースであるという無効なダウングレード状況でないこともチェックしてレポートします。このコマンドで、現行バージョンとはコマンドライン・インタフェースを実行しているソフトウェアのバージョンのことです。ストレージ・ノードが指定されていない場合は、ストア内のすべてのノードがチェックされます。

    verify upgrade [-silent] [-sn snX]*

    このコマンドは、ストアの一連のストレージ・ノードが現行バージョンに正常にアップグレードされたことを確認し、まだアップグレードされていないコンポーネントや接続できないコンポーネントを表示します。このコマンドで、現行バージョンとはコマンドライン・インタフェースを実行しているソフトウェアのバージョンのことです。ストレージ・ノードが指定されていない場合は、ストア内のすべてのノードがチェックされます。

    show upgrade-order

    このコマンドは、ストアの可用性を維持するためにアップグレードする必要がある順序で、ストレージ・ノードのリストを表示します。このコマンドは、1つ以上のストレージ・ノードを1行に表示します。1行に複数のストレージ・ノードが表示される場合、スペースで区切られます。1行に複数のストレージ・ノードが表示されている場合、そのノードをまとめて安全にアップグレードできます。複数のノードをまとめてアップグレードする場合、すべてのノードのアップグレードが完了してからでなければ、リストの次のノードはアップグレードできません。

    verify [-silent]コマンドは非推奨となり、verify configuration [-silent]に置き換えられます。verify [-silent]コマンドは、このリリースでも引き続き動作します。

ユーティリティとドキュメントの変更点

  1. このリリースでは、ユーティリティ・クラス WriteOperations (examplesディレクトリにあります)によって提供されるサンプル・コードに、ラージ・オブジェクト(LOBKVLargeObjectを参照)に対する書込み操作を実行するメソッドが追加されました。このリリースで追加された新しいユーティリティ・メソッドは、 FaultExceptionが発生したときに、関連するLOB操作を正しく再試行します。このリリースより前には、WriteOperationsユーティリティはラージ・オブジェクトでないオブジェクトに対してしか再試行メソッドを提供していませんでした。[#21966]
  2. レプリケーション・ノードで使用されるJEロック表の数(JE構成パラメータのje.lock.nLockTablesを介して制御される)が、1から97に増やされました。この変更でロック競合が緩和され、きわめて高いレベルの同時更新を特徴とするアプリケーションのパフォーマンスが向上します。[#22373]
  3. 管理CLIで、複数のデータセンターを作成できるようになります。各データセンターがレプリカのクォーラムより少ない数を保持するようにデータセンター・レプリケーションの要素を選択すると、ストア・レイアウトを作成できるようになり、1つのデータベースで障害が発生してもストア内のどのシャードでも書込み可用性が損なわれません。現在のリリースでは、どのデータセンターのノードもマスター選択に関与でき、永続性の確認に貢献します。その結果、距離がかなり離れているデータセンターが関わる場合には、マスター・フェイルオーバーと永続性確認に時間が長くかかるようになります。今後のリリースでは、この部分の柔軟性が向上する予定です。[#20905]

11gR2.2.0.39での変更点

新機能

  1. Oracle Coherenceとの統合が実現し、Oracle CoherenceアプリケーションのキャッシュとしてOracle NoSQL Databaseを使用できるようになりました。また、アプリケーションはOracle NoSQL Databaseからキャッシュ・データに直接アクセスできます。この統合は、本製品のEnterprise Editionの機能であり、新しい独立のjarファイルとして実装されています。Oracle Coherence製品もインストールされている必要があります。この機能の詳細は、スタート・ガイドの他にjavadocも参照してください。[#22291]
  2. Enterprise Editionは、セマンティック・テクノロジをサポートするようになりました。具体的には、Resource Description Framework (RDF)、SPARQL問合せ言語、およびWeb Ontology Language (OWL)のサブセットがサポートされます。これらを総称して、Oracle NoSQL DatabaseのRDFグラフ機能と呼びます。RDFグラフ機能には、Oracle NoSQL Database Enterprise Editionでセマンティック・データを格納し問い合せるJavaベースのインタフェースがあります。この機能の詳細は、RDFグラフのマニュアルを参照してください。

バグ修正

  1. NoSQL DBのメモリー・リソースを設定するときに望ましいのは、makebootconfigユーティリティを実行するときSNごとにmemory_mbパラメータを指定し、理想的なレプリケーション・ノードのヒープおよびキャッシュ・サイズをシステムで計算させる方法です。ただし、レプリケーション・ノードのjavaMiscParamsパラメータとcacheSizeパラメータを使用して明示的にヒープおよびキャッシュ・サイズを設定すれば、標準のメモリー構成をオーバーライドすることもできます。以前のリリースでは、plan change-parametersコマンドを使用するときに明示的な値を設定すると正しく動作しましたが、change-policyコマンドを使用するときには正しく動作しませんでした。これが修正され、必要な場合には、javaMiscParamsとcacheSizeのパラメータがデフォルトのメモリー割当ての経験則をオーバーライドするようにchange-policyコマンドを使用できます。[#22097]
  2. ネットワークを利用できないノードで実行されるNoSQL DBのデプロイメントは、NoSQL DBのデモまたはチュートリアルを実行するとき発生するように、次のエラーを返すことがあります。
    java.net.InetAddress.getLocalHost() returned loopback address:<hostname> and
      no suitable address associated with network interfaces.
    
    これは修正されました。[#22252]

APIの変更点

  1. これ以前のリリースでは、書込み操作のときに基底となる永続ストアから例外が発生し、シャードのマスターでは書込みが完了したが、目的のレプリカ組合せでは所定の時間内に完了しなかったと示される場合、その例外は吸収され、クライアントには伝播されませんでした。もともと、この動作が望ましいとみなされていたのは、その例外がまれである(実装によって様々なチェックが先行して実行されるので)という理由に加えて、例外を吸収すると追加の例外やAPIレベルでの追加の通信を回避できるためAPIがシンプルになるという理由からです。検討と議論を重ねた結果、このような例外のために書込み操作が完了しなかったときにはクライアントに通知すべきであるという結論に至りました。その結果、書込み操作中にこのような条件が発生したときには、 RequestTimeoutExceptionがクライアントに伝播されるようになり、基底となる永続ストアからの当初の例外は原因としてラップされるようになります。この例外が発生したときに採用する戦略を含めた詳細は、RequestTimeoutExceptionJavadocを参照してください。

    これは修正されました。[#21210]

  2. 例外とエラー・メッセージでレコードの表示を制御する新しいパラメータが追加されました。hideUserDataをtrueに設定すると(これがデフォルトです)、サーバー側のログに出力される、またはCLIコマンドを通じて表示されるエラー・メッセージは、キー/値を"[hidden]"という文字列に置き換えます。エラーで実際のレコードの内容を見るには、パラメータをfalseに設定してください。[#22376]

ユーティリティとドキュメントの変更点

  1. 以前のリリースでは、NoSQL DBコンポーネントの起動中にplan deploy-topologyコマンドの結果として発生したエラーに関する情報は、NoSQL DBログ内部でしか表示されないことがあり、インストール時のトラブルシューティングを難しくしていました。このリリースでは、このような起動エラーを管理CLIのshow plan -id <id>コマンドで表示できるようになっています。[#22101]
  2. ストレージ・ノード・エージェントは、デフォルトでないMBeanServerインスタンスでMBeanを公開します。このリリースでは、デフォルトでないMBeanServerが標準JVMプラットフォームのMBeanと、Oracle NoSQL Databaseのみに関連するMBeanを公開するようになります。
  3. SNMPとJMX両方のインタフェースで、新しいtotalRequestsメトリックを使用できます。このメトリックは、サンプリング期間に発生するマルチ操作のシーケンスの数をカウントします。
  4. これ以前のリリースでは、製品のコンパイルとビルドは1.xバージョンのHadoop (CDH3)を想定して行われていました。そのため、以前のリリースを採用しているとき、2.xバージョンのHadoop (CDH4)に基づくクラスタに対してexamples.hadoop.CountMinorKeysサンプルを実行すると、そのサンプルによって開始されるMapReduceジョブがIncompatibleClassChangeErrorのために失敗していました。これは、Hadoop 1.xとHadoop 2.xの間でorg.apache.hadoop.mapreduce.JobContextに発生した非互換性が原因です。このエラーは、Hadoop 1.xとHadoop 2.xのどちらを基準にしてサンプルのコンパイルとビルドを行っても発生します。本製品のカスタマ・ベースで使用されているのはほとんどHadoop 2.xのみなので、このリリースではHadoop 1.xではなくHadoop 2.xをサポートしました。今後のリリースでは、Hadoopの両方のバージョン・パスが再度サポートされる可能性もありますが、その場合にはコードベースとそれに伴うリリース・アーチファクトのリファクタリングが必要となり、現在のビルド・プロセスについても大きな変更が必要になります。

    Hadoop 2.x (CDH4)のサポートを追加しました。[#22157]

  5. java -jar kvstore.jar makebootconfig -mountフラグが-storagedirに変更されました。plan change-mountpoints -path <storage directory>コマンドは非推奨となり、plan change-storagedir -storagedir <storage directory>が推奨されます。[#21880]
  6. ストレージ・ノード容量の概念について、管理者ガイドの記述を改めました。
  7. 管理者ガイドで、NoSQL DBデプロイの操作に必要なリソースの計算方法に関する項を改訂しました。

11gR2.2.0.26での変更点

新機能:

  1. このリリースでは、管理サービスのレプリカを削除する機能が追加されます。複数の管理をデプロイしている場合、次のコマンドを使用してその1つを削除できます。
    plan remove-admin -admin <adminId>
    

    1つの管理インスタンスのみが構成されている場合、その唯一の管理を削除することはできません。

    可用性と永続性の理由から、少なくとも3つの管理インスタンスを常に維持しておくことをお薦めします。そのため、削除の結果として3つを下回るような削除を行おうとした場合、-forceフラグを指定しないかぎりコマンドは失敗します。

    現在マスターである管理を削除しようとすると、マスター権限は別の管理に移動します。プランが中断され、後から新しいマスター管理で再実行できます。中断されたプランを再実行するには、次のコマンドを使用します。

    plan execute -id <planId>
    
  2. 管理CLIのverifyには、単一のストレージ・ノードにホストされているレプリケーション・ノードでメモリー設定がストレージ・ノードのメモリー容量に適合することを検証するチェックが追加されています。これは、システム管理者がデフォルトをオーバーライドして手動でレプリケーション・ノードのヒープサイズを設定している場合に起きうるエラーへの対策です。[#21727]
  3. 管理CLIのverifyコマンドは、検証の問題をすべて違反またはノートと分類します。違反の方が重大度が大きく、システム管理者はその問題に対処するためにシステムの調整方法を決定する必要があります。ノートは、これより重大度が低い警告です。[#21950]

バグ修正:

  1. レイテンシの統計について、いくつか修正を実施しました。修正が適用されるのは、管理コンソールにおけるサービス側統計、CLIのshow perfコマンド、.perfファイルと.csvファイル、そしてKVStore..getStatsによって返されるクライアント側統計です。ただし、95%から99%の値に対する修正はクライアント側統計には適用されません。これらの値はクライアント側APIには出現しないからです。 [#21763]
  2. -servicerange引数によってポート範囲がmakebootconfigユーティリティに指定されている場合に、ポート範囲からポートを割り当てるように管理プロセスを変更しました。引数を指定しない場合、管理プロセスは使用可能な任意のポートを使用します。Oracle NoSQL Databaseで使用されるポートの構成の詳細は、管理者ガイドを参照してください。[#21962]
  3. ローカルに格納されるトポロジが欠落するというまれなケースに対処するように、レプリケーション・ノードが変更されました。トポロジが欠落すると、TopologyManagerでjava.lang.NullPointerExceptionがスローされ、レプリケーション・ノードは開始できなくなります。[#22015]
  4. ストレージ・ノードで複数のレプリケーション・ノードをホストしている場合に、レプリケーション・ノードのメモリー計算が堅牢になっています。以前のリリースでは、plan change-paramsコマンドを使用して、複数のレプリケーション・ノードをホストしているストレージ・ノードの容量パラメータを小さくすると、レプリケーション・ノード・ヒープが極端に小さくなり、起動時にレプリケーション・ノードがエラーになっていました。トポロジのバランスを再調整する際にこの問題は修正されますが、そのときまでレプリケーション・ノードは使用できなくなっていました。デフォルトのメモリー・サイズ計算で、ストレージ・ノード上にあるレプリケーション・ノードの数が考慮されるようになり、deploy-topologyコマンドによってレプリケーション・ノードが再割当てされるとき、レプリケーション・ノード・ヒープ・サイズが調整されます。[#21942]
  5. レプリケーション・ノードの起動時に、次の例のようにNullPointerExceptionの原因になるバグを修正しました。例外がレプリケーション・ノード・ログに記録され、レプリケーション・ノードは起動に失敗します。この問題が発生する条件としては、複数の異常なレプリケーション・ノードのシャットダウンに伴うシャード間でのパーティション移行などがあります。このバグが発生しても、現在のリリースにアップグレードすれば修正され、データが失われることはありません。
    Exception in thread "main" com.sleepycat.je.EnvironmentFailureException: (JE
    5.0.XX) ...  last LSN=.../... LOG_INTEGRITY: Log information is incorrect,
    problem is likely persistent. Environment is invalid and must be closed.
        at com.sleepycat.je.recovery.RecoveryManager.traceAndThrowException(RecoveryManager.java:2793)
        at com.sleepycat.je.recovery.RecoveryManager.undoLNs(RecoveryManager.java:1097)
        at com.sleepycat.je.recovery.RecoveryManager.buildTree(RecoveryManager.java:587)
        at com.sleepycat.je.recovery.RecoveryManager.recover(RecoveryManager.java:198)
        at com.sleepycat.je.dbi.EnvironmentImpl.finishInit(EnvironmentImpl.java:610)
        at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:208)
        at com.sleepycat.je.Environment.makeEnvironmentImpl(Environment.java:246)
        at com.sleepycat.je.Environment.<init>(Environment.java:227)
        at com.sleepycat.je.Environment.<init>(Environment.java:170)
        ...
    Caused by: java.lang.NullPointerException
        at com.sleepycat.je.log.entry.LNLogEntry.postFetchInit(LNLogEntry.java:406)
        at com.sleepycat.je.txn.TxnChain.<init>(TxnChain.java:133)
        at com.sleepycat.je.txn.TxnChain.<init>(TxnChain.java:84)
        at com.sleepycat.je.recovery.RollbackTracker$RollbackPeriod.getChain(RollbackTracker.java:1004)
        at com.sleepycat.je.recovery.RollbackTracker$Scanner.rollback(RollbackTracker.java:477)
        at com.sleepycat.je.recovery.RecoveryManager.undoLNs(RecoveryManager.java:1026)
        ... 10 more
    
    [#22052]
  6. RN上のストレージ・エンジン・キャッシュで過剰なメモリーが使用され、キャッシュの退去とI/O増加のためにパフォーマンスが低下するバグが修正されました。この問題が発生するのは、KVStore.storeIteratorまたはKVStore.storeKeysIteratorを使用するときのみでした。[#21973]

パフォーマンスその他の一般的な変更点:

  1. シャードにおけるレプリカは、JEプロパティRepParams.REPLAY_MAX_OPEN_DB_HANDLESを動的に構成するようになります。これは、レプリケーション中にデータベース・ハンドルの保持に使用されるキャッシュのサイズを制御するプロパティです。キャッシュ・サイズは、現在シャードによってホストされているパーティションの数に基づいて動的に決定されます。このキャッシュ・サイズ改善によって、多数のパーティションをホストするシャードの書込みパフォーマンスが向上する可能性があります。[#21967]
  2. クライアントおよびサーバーJARファイルの名前に、リリース・バージョン番号は含まれなくなります。ファイル名は、次のようになります。
    lib/kvstore.jar
    lib/kvclient.jar
    

    この変更により、JARファイルの名前がリリースごとに変わらなくなるため、新しいリリースへの切替えに要する作業負荷が減ります。インストール・ディレクトリの名前には、引き続きリリース・バージョン番号が含まれます。[#22034]

  3. SEVEREレベルのメッセージがログに記録されるようになり、ストレージ・エンジンの平均的なログ・クリーナ(ディスクの再利用)バックログが一定期間で増加すると、管理警告が生成されます。メッセージ・テキストの例は次のとおりです。
    121215 13:48:57:480 SEVERE [...] Average cleaner backlog has grown from 0.0 to
    6.4. If the cleaner continues to be unable to make progress, the JE cache size
    and/or number of cleaner threads are probably too small. If this is not
    corrected, eventually all available disk space will be used.
    
    キャッシュ・サイズを適切に設定してこのような問題を回避する方法の詳細は、管理者ガイドのノード当たりのキャッシュ・サイズの決定に関する項を参照してください。[#21111]
  4. ストレージ・エンジンのログ・クリーナは、アプリケーションが書込み操作を実行していない場合であっても、ログの後半部分を削除するようになります。以前のバージョンでは、前回のアプリケーション書込みより後ろの部分のログを削除することは禁止されていました。ログ・クリーナ・バックログが存在するとき(たとえば、データ・セット・サイズや書込み速度と比較してキャッシュの構成が小さすぎるときなど)には、クリーナが連続的に動作し、ファイルの削除もそれ以降に進むこともできなくなります。[#21069]
  5. NoSQL DB 2.0.23では、R1.2.23に対するパフォーマンス・リグレッションが発生していました。kvstoreクライアント・ライブラリとレプリケーション・ノードが、システムCPU時間を大量に消費していました。このリグレッションは修正されました。[#22096]

11gR2.2.0.23での変更点

新機能:

  1. このリリースでは、デプロイ後にストレージ・ノードをシステムに追加できるようになります。システムのバランスが再調整され、操作を停止せずにデータは新しいノードに再配分されます。詳細は、管理者ガイドの第6章「ストアの構成の決定」を参照してください。
  2. 新しいoracle.kv.lobパッケージにより、音声ファイルや動画ファイルなどのラージ・オブジェクト(LOB)を読み書きできるようになります。一般に、1MBを超えるオブジェクトはすべてLOBとして表すことができます。LOB APIでは、このようなオブジェクトの読取りと書込みにストリーミングAPIを提供することにより、値全体をマテリアライズせずに大きな値にアクセスできます。
  3. C APIが追加されました。実装にはJava JNIが使用されるため、クライアントでJava仮想マシンが稼働している必要があります。これは別途ダウンロードして利用できます。
  4. 新しいremove-storagenodeプランを追加しました。このコマンドは、NoSQL Databaseコンポーネントをホストしていないストレージ・ノードをシステムのトポロジから削除します。これが役に立つ2つの例を次に示します。
    ストレージ・ノードが誤って構成されており、デプロイできない場合。
    ストレージ・ノードが以前はNoSQL Databaseの一部だったが、migrate-storagenodeコマンドですべてのコンポーネントがそこから移行され、ストレージ・ノードの停止が必要になった場合。
    [#20530]
  5. ストレージ・ノードに関して、次のような追加の物理構成情報を指定する機能が追加されました。 この情報は、システムがリソース割当てと消費についてさらにインテリジェントな選択を行うために使用されます。パラメータの設定および使用方法については、管理者ドキュメントを参照してください。[#20951]
  6. Avroサポートを追加しました。キー/値ペアの値は、Avroバイナリ形式で格納できるようになります。Avroスキーマは、格納されるデータのタイプごとに定義されます。Avroスキーマは、データを効率的かつコンパクトにシリアライズし、データがスキーマに準拠していることを保証して、スキーマの経時変化にあわせて自動的なデータの発展を実行します。AvroデータをPOJO (Plain Old Java Object)、JSONオブジェクト、または汎用のMap的なデータ構造を表すことのできるバインディングが導入されています。詳細は、スタート・ガイド第7章「Avroスキーマ」第8章「Avroバインディング」を参照してください。oracle.kv.avroパッケージについては、Javadocで説明されています。Avro形式を使用することをお薦めします。今後のNoSQL DBは、追加の機能を導入するためにAvroを利用する予定です。[#21213]
  7. Hadoop KVInputFormatクラスのサポートを追加しました。新しいoracle.kv.hadoop.KVAvroInputFormatクラスは、AvroのIndexedRecordをコール元に返します。このクラスをOracle Loader for Hadoopと組み合せて使用すると、HDFSにデータを格納するMap-Reduceジョブを暫定的に使用することなく、OLHを使用してNoSQL Databaseから直接データを読み込むことができます。[#21157]
  8. Oracle Databaseの外部表を使用してOracle NoSQL Databaseのレコードをアクセスできる機能を追加しました。詳細は、 oracle.kv.exttabパッケージのJavadocと、 examples/externaltablesディレクトリにあるcookbookサンプルを参照してください。[#20981]

パフォーマンスその他の一般的な変更点:

  1. 次のメソッドが追加されます。 これにより、クライアントはクライアント要求時のソケット・タイムアウトを構成できるようになります。詳細はJavadocを参照してください。

    前述のAPIをクライアントで使用するには、このリリースに付属しているアップグレード・ドキュメントの説明に従って、R1のインストールでストレージ・ノード上のソフトウェアがアップグレードされていることを確認する必要があります。[#20997]

  2. NoSQL Databaseによって作成されたソケットに関連するバックログを制御する新しいサービス・パラメータが追加されました。これらは、レプリケーション・ノードとストレージ・ノードの監視、管理、レジストリ・ハンドラの各インタフェースで制御できます。パラメータは、rnRHSOBacklog (デフォルトは1024)、rnMonitorSOBacklog (デフォルトは0)、rnAdminSOBacklog (デフォルトは0)、rnAdminSOBacklog (デフォルトは0)、snAdminSOBacklog (デフォルトは0)、snMonitorSOBacklog (デフォルトは0)およびsnRegistrySOBacklog (デフォルトは1024)です。[#21322]
  3. 以前のバージョンでは、ターゲットのKeyオブジェクトより小さいメジャーまたはマイナー・パスを含む引数を指定してKey.isPrefixをコールすると、特定のケースでIndexOutOfBoundsExceptionが発生していました。これは修正されました。
  4. KeyRange()コンストラクタは、最初のKeyが最後のKeyがより小さいかどうかをチェックします。これは最初と最後の両方が指定されている場合であり、指定されていない場合にはIllegalArgumentExceptionがスローされます。KeyRangeにも、KeyRangeインスタンスのエンコードとデコードに使用するtoString()fromString()の2つのメソッドがあります。これはKeyの同じメソッドに似ています。[#21470]

ユーティリティの変更点:

  1. CLIには多くのコマンドが新しく追加されています。詳細は、管理者ガイド付録A「コマンドライン・インタフェース(CLI)のコマンド・リファレンス」を参照してください。
  2. 管理コンソールは管理専用になります。
  3. CLIの管理コマンドは、トポロジ表示に使用されるIDにコンポーネントIDが一致するように変更されました。以前のバージョンでは、データセンター、ストレージ・ノード、管理インスタンス、レプリケーション・ノードがそれぞれ名前のみで識別されていました。たとえば、ストレージ・ノード17をストレージ・ノード・プールに追加する構文、または指定したレプリケーション・ノードのパラメータを表示する構文は、次のとおりでした。
    joinPool myStorageNodePool 17
    show repnode-params 5,3
    
    データセンターは、#またはdc#と表せるようになります。
    管理インスタンスは、#またはadmin#と表せます。
    ストレージ・ノードは、#またはsn#と表せます。
    レプリケーション・ノードは、groupNum,nodeNumまたはrgX-rnYと表せるようになります。

    上に示したコマンドは現在も有効ですが、次のように表すこともできます。

    joinPool myStorageNodePool sn17
    show repnode-params rg5-rn3
    
    [#21099]

ドキュメント、インストール、統合:

  1. Key.createKeyメソッドのJavadocが更新され、パラメータとして渡されるListインスタンスはメソッドのコール後にKeyオブジェクトによって所有されるという警告が追記されました。予期しない結果を避けるために、これは変更しないでください。[#20530]

11gR2.1.2.123での変更点

バグ修正:

  1. 以前のバージョンでは、管理サービスを実行している以外のノードでレプリケーション・ノード・パラメータを変更しようとしてchange-repnode-paramsプランを実行すると、エラーになりました。この操作が正常に処理されるようになります。[#20901]
  2. 新しいストレージ・ノードをデプロイしようとしてdeploy-storage-nodeプランで問題が発生すると、問題のあるストレージ・ノードがストアに残っていました。そのため、ユーザーは問題のあるストレージ・ノードを手動で削除するか、問題を修正してプランを再試行する必要がありました。便宜上、deploy-storage-nodeプランは現在、エラー発生時にクリーン・アップされるようになり、問題のあるストレージ・ノードは残らなくなっています。[#20530]

パフォーマンスその他の一般的な変更点:

  1. コマンドライン・インタフェースで、snapshot createコマンドの速度が大幅に向上しました。以前のバージョンでは、大量のデータがあるストアで実行すると数分間かかっていました。これが秒単位に短縮されています。[#20772]

ユーティリティの変更点:

  1. kvliteを起動して制御コマンドを実行する2つのスクリプト、bin/run-kvlite.shおよびbin/kvctlは、java -jar lib/kvstore-M.N.P.jarコマンドに置き換えられます。これにより、Windowsを含むすべてのJavaプラットフォームの移植性が実現します。2つのスクリプトは非推奨となりましたが、少なくとも1リリース・サイクルの間はサポートされます。

    古いスクリプト・コマンドから新しい-jarコマンドへの変換は、次のとおりです。

    古いスクリプト・コマンド新しい-jarコマンド
    bin/run-kvlite.sh args... java -jar lib/kvstore-M.N.P.jar kvlite args...
    bin/kvctl command args... java -jar lib/kvstore-M.N.P.jar command args...

    新旧のコマンドには、注意が必要な相違点がいくつかあります。