2.1 このリリースでの新機能

Oracle Reports 11gリリース1（11.1.1）は、Oracle Fusion MiddlewareおよびOracle WebLogic Serverに統合されています。これによって表2-1（表1-1「11gの機能と10gの機能との比較」の一部）に示すようにアーキテクチャが強化されています。

表2-1 11gのアーキテクチャの機能と10gの機能との比較

11gの新機能	10gにおける同等機能
サーバー安定性
データベースでバックアップされたジョブ・キュー・リポジトリ:データベースをジョブ・リポジトリとして使用すると、Reports ServerのDATファイルが破損する状況の防止に役立ち、スケジュールされているジョブが喪失しません。データベースにあるジョブの管理も容易になります。	ファイル・システムをベースにしたDATファイル・リポジトリのみです。
新しいコマンドライン引数のJOBRETRY:この値を指定すると、`job`要素の`retry`属性のエントリよりも優先されます。すべての不測エラーが発生したジョブは再試行されます。詳細は、第A.6.15項「JOBRETRY」を参照してください。	`job`要素の`retry`属性を使用すると、失敗したジョブの再試行回数をサーバー構成ファイルで指定できます。これを実行しないと、スケジュールされているジョブのみコマンドラインによりエンジンのクラッシュ障害が発生した場合にのみジョブの再試行が行われます。
高可用性
データベースでバックアップされたジョブ・キュー・リポジトリ:データベースをジョブ・リポジトリとして使用すると、次の高可用性（HA）メリットが実現されます。 Oracle Enterprise ManagerでReports Serverの完全なグループに対する統合ジョブを表示して、その統合ジョブに対する操作を実行する機能。第7.15.2項「統合されたジョブ・キューの表示」を参照してください。ジョブがスケジュールされているReports Serverが停止した場合でも、スケジュールされているジョブは失われません。	管理者は、各Reports Serverのジョブ・キューを個別に表示する必要があります。ジョブがスケジュールされていたReports Serverが停止すると、そのジョブが失われます。
共有ジョブ・リポジトリおよびJavaオブジェクト・キャッシュなどのキャッシュを備えたOracle Reports Serverクラスタ。Reports Serversではジョブを管理するためにpeer-to-peerメカニズムにより通信を行い、手動による管理を最小限に抑え、ジョブを自動的にフェイルオーバーします。マスター・ジョブを処理したReports Serverが使用できない場合でも、キャッシュされている出力にアクセスします。	Oracle Reportsのキャッシュ・メカニズムを使用します。キャッシュは複数のReports Servers間では共有されません。Reports Serverのキャッシュが停止すると、キャッシュされている出力は、他のサーバーでは使用できません。独自のクラスタリングとHAメカニズム
高可用性の詳細は、第2.5項「高可用性環境の設定」を参照してください。