1 Oracle Databaseリリース19cの新機能

この章では、Oracle Databaseリリース19cのすべての新機能を説明します。

可用性

一般

Oracle Data Guard Brokerのファスト・スタート・フェイルオーバー・ターゲットの動的な変更

ファスト・スタート・フェイルオーバーを無効化せずに、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースをターゲット・リスト内の別のスタンバイ・データベースに動的に変更できます。

以前のリリースのOracle Databaseでは、新しいターゲット・スタンバイ・データベースに移動するにはファスト・スタート・フェイルオーバーを無効化する必要がありました。これによって、自動フェイルオーバーをまったく使用できない期間にブローカ構成が公開されます。SET FAST_START FAILOVER TARGETコマンドを使用して、ファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースを動的に変更します。

関連トピック

Oracle Data Guard Brokerにおけるデータベース・パラメータ管理の簡略化

Oracle Data Guard Broker構成でのデータベース・パラメータの管理は、SQL*Plusを介してすべてのパラメータ管理を実行できるようにすることで簡略化されます。データベースのData Guardパラメータ設定とData Guard Brokerのプロパティ設定の間の矛盾は解消されます。

SQL*PlusでALTER SYSTEMコマンドを使用するか、新しいEDIT DATABASE ... SET PARAMETERコマンドを使用したData Guard Brokerコマンドライン・インタフェース(DGMGRL)で、すべてのOracle Data Guard関連パラメータ設定を管理できるようになりました。DGMGRLでパラメータに変更を加えると、その変更はすぐにターゲット・データベースで実行されます。

関連トピック

Oracle Data Guard Brokerのファスト・スタート・フェイルオーバーの監視専用モード

監視専用モードでは、Oracle Data Guard Broker構成の本番データベースに影響を及ぼすことなく、自動ファスト・スタート・フェイルオーバーをテストできます。

ファスト・スタート・フェイルオーバーの構成時に、監視専用モードを使用して、通常の本番処理中にフェイルオーバーまたはその他の相互作用がいつ発生するかをチェックするためのテスト・モードを作成できます。このテストの情報を使用して、ファスト・スタート・フェイルオーバーのプロパティをより正確にチューニングできます。また、使用している環境で自動フェイルオーバーが発生する状況を確認することもできます。

関連トピック

プライマリからスタンバイ・サイトへのリストア・ポイントの伝播

プライマリ・データベースで作成されたリストア・ポイントは、フェイルオーバー操作後も使用できるようにスタンバイ・サイトに伝播されます。

論理破損が発生した場合に高速Point-in-Timeリカバリを有効にするために、通常のリストア・ポイントまたは保証付きリストア・ポイントがプライマリ・サイトで定義されます。これらのリストア・ポイントは、制御ファイルに格納されます。フェイルオーバーの際には、スタンバイ・データベースがプライマリ・データベースになります。ただし、リストア・ポイント情報は失われます。プライマリからスタンバイにリストア・ポイントを伝播すると、スタンバイ・データベースがプライマリ・データベースで作成されたリストア・ポイントで更新されるため、フェイルオーバー後のリストアおよびリカバリ処理の複雑さが簡略化されます。

プライマリ・データベースがフラッシュバックされた場合のフラッシュバック・スタンバイ・データベース

プライマリ・データベースでフラッシュバック操作が実行されるときに、Oracle Data Guard設定のスタンバイ・データベースを自動的にフラッシュバックできます。

プライマリ・データベースでフラッシュバック操作が実行されると、スタンバイはプライマリと同期されなくなります。以前のリリースでは、スタンバイをプライマリと同期するには、特定のステップを実行する必要がありました。この機能では、プライマリ・データベースでフラッシュバック操作が実行されるときに、スタンバイ・データベースが自動的にフラッシュバックされるようにする新しいパラメータが導入されています。これにより、時間、作業量および人為的エラーが減少するため、同期が速くなり、リカバリ時間目標(RTO)が短縮されます。

インメモリー列ストアと連携するOracle Data GuardマルチインスタンスのREDO適用

インメモリー列ストアおよびData GuardマルチインスタンスのREDO適用がActive Data Guardスタンバイで同時に有効化できるようになりました。以前は、この2つの機能は相互に排他的でした。

同じActive Data Guardスタンバイ上で最速のREDO適用テクノロジ(Data GuardマルチインスタンスのREDO適用)および最速の分析問合せテクノロジ(インメモリー列ストア)を使用して、両方の機能を最大限に活用できるようになりました。マルチインスタンスREDO適用は、Active Data Guardスタンバイのインメモリー列ストアの情報を使用して、可能な場合に適用速度を向上させます。

Active Data Guard DMLリダイレクション

偶発的なデータ操作言語(DML)操作をActive Data Guardスタンバイ・データベースで実行できます。これにより、なんらかの書込みが必要なときにActive Data Guardスタンバイ・データベースの使用からメリットを得られるアプリケーションが多くなります。

DMLリダイレクションは、プライマリ・データベースとスタンバイ・データベース間のロード・バランシングに役立ちます。Active Data Guardのスタンバイ・データベースで偶発的なDMLが発行されると、更新は実行場所のプライマリ・データベースに渡されます。制御がアプリケーションに戻された後に、トランザクションの結果REDOによってスタンバイ・データベースが更新されます。

PDBリカバリ・カタログ

ターゲット・データベースがプラガブル・データベース(PDB)の場合は、リカバリ・カタログへの接続がサポートされます。

Oracle Databaseリリース19cでは、マルチテナント・コンテナ・データベース(CDB)の完全なバックアップと柔軟なリカバリ、およびリカバリ・カタログのサポートを含むPDBレベルのバックアップとリストアを提供しています。仮想プライベート・カタログ(VPC)ユーザーを使用すると、PDBレベルでバックアップおよびリストア操作を実行するための権限を細かく制御できます。メタデータ・ビューも制限されるため、VPCユーザーは、ユーザーは権限が付与されたデータのみを表示できます。

高速リカバリ領域サイズの予測可能性を高めるための定期的なフラッシュバック・ログのクリア

保存期間を超えるフラッシュバック・ログを自動的に削除することによって、高速リカバリ領域管理およびデータベース状態が向上します。

高速リカバリ領域にはバックアップ、オンラインREDOログ、アーカイブREDOログおよびフラッシュバック・ログが格納されるため、高速リカバリ領域はデータベースにとって重要です。多くのデータベースで高速リカバリ領域を使用できるため、高速リカバリ領域が一杯になると、複数のデータベースが影響を受けます。フラッシュバックでは保存に必要な量より多くの領域は使用されないため、ストレージ管理の観点から、この機能によりフラッシュバック領域の使用量が予測可能になります。また、これによってフラッシュバック保存を調整して、累積領域不足を制御することもできます。

Oracle Data Guardを使用して自動停止解決をチューニングする新しいパラメータ

Oracle Data Guardの自動停止解決は、特定のニーズにあわせてチューニングできます。

Oracle Data Guardには、プライマリ・データベースおよびスタンバイ・データベース上にいくつかのプロセスがあり、これはネットワークを介して相互に通信してREDO転送およびアーカイブを管理します。特定の障害状況、ネットワークのハング、切断およびディスクI/Oの問題では、これらのプロセスがハングし、REDO転送およびギャップ解決の遅延につながる可能性があります。Oracle Data Guardには、これらのハングされたプロセスを検出して停止するための内部メカニズムがあるため、通常の停止解決を実行できます。DATA_GUARD_MAX_IO_TIMEおよびDATA_GUARD_MAX_LONGIO_TIMEの2つの新しいパラメータを使用して、ユーザー・ネットワークおよびディスクI/O動作に基づいて、特定のOracle Data Guard構成に対して待機時間をチューニングできるようになりました。

粒度の高いサプリメンタル・ロギング

粒度の高いサプリメンタル・ロギングでは、部分的なデータベース・レプリケーションのユーザーに不要な表のサプリメンタル・ロギングを無効化する方法が提供されます。これにより、サプリメンタル・ロギングがデータベース・レベルまたはスキーマ・レベルで有効化されていても、不要な表にサプリメンタル・ロギングのオーバーヘッドが発生しなくなります。

この機能を使用すると、データベースの一部の表のみにサプリメンタル・ロギングが必要な場合に(Oracle GoldenGate部分レプリケーション構成などで)、リソース使用率およびREDO生成に関するオーバーヘッドが大幅に削減されます。サプリメンタル・ロギングは、ロジカル・スタンバイ・データベースまたは完全なデータベース・レプリケーションの要件にあわせて設計および実装されていました。これにより、表のサブセットのみがレプリケートされる環境では不要なオーバーヘッドが発生します。

シャーディング

シャード・カタログ・スタンバイ・データベースでのマルチシャード問合せコーディネータのサポート

シャード・カタログのOracle Active Data Guardスタンバイ・データベースでマルチシャード問合せコーディネータを有効化できます。

シャード・カタログ・アクティブ・スタンバイ・データベースでマルチシャード問合せコーディネータを実行すると、マルチシャード問合せワークロードのスケーラビリティと可用性が向上します。一方、Oracle Database 19cより前は、マルチシャード問合せコーディネータとして使用できるのはプライマリ・シャード・カタログ・データベースのみでした。

シャード間の一意の順序番号の生成

順序オブジェクトがシャード・データベースのシャード全体で単一の論理オブジェクトであることが必要な場合に、シャード間でグローバルに一意な順序番号を生成できます。

この機能を使用すると、一意制約がある主キーではない列に対してグローバルな一意のIDを生成できます。この機能では、アプリケーションの特定の主キーではない列のグローバルな一意性を管理する必要はありません。

同じCDBでの複数のPDBシャードのサポート

特定の制限がありますが、シャードまたはシャード・カタログ・データベースのCDBで複数のPDBを使用できます。たとえば、この機能により、それぞれに個別のカタログ・データベースを持つ異なるシャード・データベースからのシャードPDBを1つのCDBに格納できます。

1つのCDBに複数のPDBを含めると、別々のシャード・データベースを必要とする顧客とアプリケーションが同じシステム・リソースを共有できるようになり、コストが削減されて管理が簡単になります。

システム管理のシャーディングに対する複数の表ファミリ・サポート

シャードされたデータベース内に複数の表ファミリを作成でき、各表ファミリは異なるシャーディング・キーを使用してシャードできます。

異なる表ファミリにアクセスする異なるアプリケーションを1つのシャードされたデータベースでホストできます。この機能はシステム管理のシャードされたデータベースにのみ適用されます。

シャード間のパラメータ設定の伝播

シャード・カタログからパラメータ設定をすべてのデータベース・シャードに集中的に伝播して管理できます。Oracle Database 19cより前は、シャード・データベースの各シャードでALTER SYSTEMパラメータ設定を個別に構成する必要がありました。

中央サーバーからすべてのシャードにパラメータ設定を自動的に伝播する機能により、時間を節約でき、エラーが発生しにくくなります。

アプリケーション開発

Application Express

改善されたアプリケーションの作成ウィザード

更新されたアプリケーションの作成ウィザードは、アプリケーションを作成するための新しいロー・コード・アプローチと、アプリケーションを作成するためのより簡易でモダナイズされたウィザードを備えています。

アプリケーションの作成ウィザードでは、ダッシュボードやマスター/詳細などの高度なページを作成する機能がサポートされるようになりました。ウィザードでは、アクセス制御、アクティビティ・レポート、テーマ選択などのアプリケーションの作成時に、共通フレームワークまたは機能の追加もサポートされます。さらに、改善されたウィザードでは、テーマ・スタイル、アプリケーション・アイコン、ページ・アイコンなどのユーザー・インタフェース・オプションをカスタマイズする機能もサポートされます。

また、アプリケーションの作成ウィザードに戻り、以前のウィザードから定義を取得し(ブループリント)、その定義を更新して別のアプリケーションを再生成することによって、以前のウィザード定義を調整することもできます。

REST対応SQLのサポート

共有コンポーネント内の名前、エンドポイントURLおよび認証情報を定義して、REST対応SQL参照を簡単に作成できます。

Oracle Application Expressは、RESTを介してSQLまたはPL/SQL問合せをORDSに渡し、自己記述型のJavaScript Object Notation (JSON)レスポンスを返します。JSONオブジェクトには、結果セットのメタデータ、結果データおよびページ区切りの詳細が含まれます。REST対応のSQL参照は、対話モード・レポートやクラシック・レポートなど、すべてのレポート・タイプのベースとして使用されますが、対話グリッド・リージョンは使用されません。参照は、カレンダ、Oracle JETデーダ・ビジュアライゼーション・コンポーネント(JETチャート)、ツリーおよびPL/SQLプロセスとともに使用することもできます。

各SQL文は、Oracle Databaseリンクを定義し、SQL*Net (またはクラウド環境のインターネット上)で動作し、実行されるSQLまたはPL/SQLごとに、リモート・データベース内でセッションを開く必要があります。これに対して、REST対応のSQL参照はOracle Application Expressワークスペース・レベルで定義され、HTTPおよびHTTPSを通じてJSONを扱います。このため、クラウド環境やインターネット上で簡単に使用できます。ORDSはリモート・データベースの接続プールを利用するため、参照も大幅に増やすことができます。

ソーシャル・サインイン認証

ソーシャル・サインイン認証スキームは、OpenIDConnect/OAuth2の標準をサポートする、Google、Facebookなどのソーシャル・ネットワークによる認証をサポートしています。

ソーシャル・サインイン認証は、主に、ソーシャル・ネットワークから未知の数のユーザーがアプリケーションを使用したり、Oracle Identity Cloud Service、内部OpenIDConnectまたはOAuth2システムなどの認証用のユーザー資格証明の検証を実行するシステムで企業が標準化されている場合に、インターネットに対応するアプリケーションで役立ちます。

Webソース・モジュール

Webソース・モジュールは、外部のRepresentational State Transfer (REST) APIおよび汎用JSONデータ・フィードへの参照を定義する宣言的メソッドを提供します。

以前のOracle Application Expressリリースでは、Simple Object Access Protocol (SOAP)およびREST Webサービスを定義して、これを制限されたOracle Application Expressコンポーネント内で利用することはできました。このようなサービスの定義は手動であり、時間がかかり、間違いやすいものでした。新しいWebソース・モジュールは、検出を使用してWebサービスの受信構造を認識および定義しているため、非常に宣言的です。

Webソース・モジュールにはレスポンス・データの解析方法に関する追加のメタデータが格納され、行および列を含む仮想表としてマップされます。1つのモジュールには、具体的な外部Webサービスへの参照であるWebソース操作を1つ以上含めることができます。モジュールには、Oracle Application Expressコンポーネントによって処理されるデータを変更する後処理SQLも含まれます。後処理SQLを使用して、ローカル表を使用した関数、集計または結合を適用できます。

Webソース・モジュールは、対話モード・レポートやクラシック・レポートなど、すべてのレポート・タイプのベースになりますが、対話グリッド・リージョンは使用されません。これらのモジュールは、カレンダ、Oracle JETデーダ・ビジュアライゼーション・コンポーネント(JETチャート)、ツリーおよびPL/SQLプロセスとともに使用することもできます。

改善されたページの作成ウィザード

更新されたページの作成ウィザードは、新規ページ・タイプ、既存のアプリケーションの共通フレームワークや機能、および電子メールとジョブ・レポートのサポートを備えています。

左右マスター・ディテール・ページには、マスター・レコードを検索するための左パネルと、値ペア・レポートを使用したマスター・レコード、およびクラシック・レポートを使用した最大4つの詳細レポートが表示される右パネルがあります。新しいダッシュボード・ページでは、サンプル・データに基づく様々なチャート・レイアウトから選択できます。生成されたチャートは、ページ・デザイナで生成後に簡単に更新できます。

ウィザードを使用すると、アクセス制御、アクティビティ・レポート、テーマ選択など、アプリケーションに新しい共通のフレームワークまたは機能を含めることができます(アプリケーションがユニバーサル・テーマを使用している場合)。ウィザードでは、電子メール・レポート、ジョブ・レポート(ジョブがデフォルト・スキーマに定義されている場合)、および機能を管理する管理ページを作成する機能もサポートされています。

新しいREST Workshop

Oracle Application ExpressでOracle REST Data Services (ORDS) 17.4以降を使用する場合、新しいREST WorkshopではORDSリポジトリが使用されます。

Oracle Databaseリリース18c、バージョン18.1より前は、Oracle Application Express内で作成したRESTfulサービス定義は、コアApplication Expressスキーマのメタデータ表内に格納されていました。RESTサービスのORDSリポジトリを利用すると、Application Express、SQL Developer、SQL Plus、Oracle SQL開発者コマンドライン(SQLcl)などの豊富なツールを使用して、RESTfulサービスを1つの場所で容易に管理できます。 

Oracle Application ExpressベースのRESTサービスは引き続き動作しますが、Oracle Application ExpressベースのRESTfulサービスを新規に作成したり、既存のものを編集することはできません。Oracle REST Data Services (ORDS)リポジトリにすべてのRESTfulサービスを移行することをお薦めします。

関連トピック

SQLワークショップ・ガイド

一般

Javaのアプリケーション・コンティニュイティ: 宣言リクエスト境界

Javaのアプリケーション・コンティニュイティがAUTOモード(サービスFAILOVER_TYPE=AUTO)で構成されている場合は、Java Database Connectivity (JDBC)ドライバによって、リプレイ・データ・ソースを使用したJDBC接続の作成後、実行時にbeginRequestコールが挿入されます。

この機能により、Javaアプリケーションおよびサード・パーティ接続プールのゼロ・ダウンタイムが確保され、コードを変更する必要がなくなります。

Java用のアプリケーション・コンティニュイティ: 新しい状態管理

この機能によって、AL8KW_ERR_OVLAPAL8KW_EDITIONAL8KW_SQL_TXLPおよびAL8KW_ROW_ARCHIVALなど、新しいセッション状態が導入されます。これらのセッション状態は標準アクティビティ中に保存され、FAILOVER_RESTOREが設定されてFAILOVERAUTOに指定された場合、フェイルオーバー時にリストアされます。

この機能により、Javaのアプリケーション・コンティニュイティにおける透過性が向上します

簡易接続プラス

アプリケーションがOracle Databaseへの接続に使用する簡易接続構文で、機能が向上しました。新しいバージョンは簡易接続プラスと呼ばれます。

簡易接続プラスでは、Oracle Databaseのアプリケーション構成と一般的なユースケースのデプロイメントが簡略化されます。簡易接続プラスでは、tnsnames.orasqlnet.oraなどのOracle Netパラメータ・ファイルを構成する必要がなくなりました。簡易接続プラスでは、TNS_ADMIN環境変数を設定する必要がなくなりました。

Oracleネットワークのログ・ファイルのセグメンテーション

この機能を使用すると、Oracle Net Listener、Connection Manager (CMAN )、グローバル・サービス・マネージャなど、Oracleネットワーク・コンポーネントのテキスト・ログ・ファイルの最大サイズと数を構成できます。

この機能により、特にクラウド環境でログ・ファイルの管理が向上します。

SQL*Net: バンド外ブレークのサポートの自動検出

この機能は、バンド外サポートのステータスを判別するためにクライアントとサーバー間のネットワーク・パスを自動的に調査し、自動的に有効化または無効化します。

バンド外ブレークは、過去のリリースではUNIXプラットフォームに対してデフォルトで有効になっていました。ただし、この構成では、クライアントとサーバー間のパス上のネットワーク・デバイスがバンド外のデータの通過を許可しない場合に多数の問題が発生します。このデータは、Transparent Network Substrate (TNS)エラーやデータ破損などサーバー側の問題が原因で、削除またはインライン化される場合があります。多くの場合、こうした問題は診断が非常に困難です。解決策は、sqlnet.oraパラメータを設定することで、手動でバンド外データの使用を無効にすることです。

JSON

マテリアライズド・ビューによるJSON_TABLEを含む問合せのサポート

JSON_EXISTSJSON_VALUEなどのファンクションを含む問合せが、JSON_TABLEファンクションを使用する問合せによって作成されたマテリアライズド・ビューを使用できるようになりました。

この機能は、列内のJavaScript Object Notation (JSON)ドキュメントに配列が含まれる場合に特に役立ちます。このタイプのマテリアライズド・ビューにより、そのようなJSON配列内のデータにアクセスする際のパフォーマンスを高速化できます。

JSON更新操作

新しいSQLファンクションJSON_MERGEPATCHを使用してJavaScript Object Notation (JSON)ドキュメントを更新し、1つの文で1つ以上の変更を複数のドキュメントに適用できるようになりました。

この機能により、JSON更新操作の柔軟性が向上します。

SQL/JSON構文の簡略化

フィールド投影、SQL/JSONパス式、およびSQL/JSON生成ファンクションJSON_OBJECTに対して、より単純な構文を使用できるようになりました。

JavaScript Object Notation (JSON)処理のSQLインタフェースは、特定の操作に対して容易に使用できます。

JSONオブジェクト・マッピング

JavaScript Object Notation (JSON)データを、SQLオブジェクト・タイプとコレクション・タイプ間でマッピングできるようになりました。

この機能を使用すると、SQLオブジェクトおよびコレクションを使用するプログラムでJSONベースのアプリケーションとの対話が容易になります。

新しいSQL/JSONファンクションJSON_SERIALIZEおよびJSONデータ・ガイドによるGeoJSONデータのサポート

新しいSQL/JSONファンクションJSON_SERIALIZEを使用して、JavaScript Object Notation (JSON)データをテキストにシリアル化できます。集計ファンクションJSON_DATAGUIDEでは、GeoJSON地理データを検出できるようになりました。

JSON_SERIALIZEを使用して、出力用または表示用のテキストとしてJSON値を抽出できます。SQLファンクションJSON_DATAGUIDEを使用して、SDO_GEOMETRYデータなどのデータを投影するビューを作成できます。

SQL

LISTAGG集計のDISTINCTオプション

LISTAGG集計ファンクションでは、新しいDISTINCTキーワードを使用した重複削除がサポートされるようになりました。

LISTAGG集計ファンクションは、ORDER BY式に従って問合せ内の各グループの行をソートし、値を1つの文字列に連結します。新しいDISTINCTキーワードを使用すると、1つの文字列に連結する前に、指定した式から重複する値を削除できます。これにより、集計LISTAGGファンクションを使用する前に、複雑な問合せ処理を作成して個別値を見つける必要がなくなります。DISTINCTオプションを使用して、LISTAGGファンクション内で重複値を削除します。

その結果、SQLはより単純で高速で効率的になります。

ビッグ・データおよびデータ・ウェアハウスのソリューション

一般

自動索引付け

自動索引作成機能では、アプリケーション・ワークロードの変化に基づいてOracle Database内の索引の作成、再作成、削除などの索引管理タスクが自動化されます。

この機能により、Oracle Databaseで索引を自動的に管理することで、データベース・パフォーマンスが向上します。

SQL診断および修復の拡張機能

SQLテスト・ケース・ビルダーやSQL修復アドバイザなどのSQL診断および修復ツールが拡張され、問題のあるSQL文を管理するための診断機能と修復機能が向上しました。

これらの拡張機能により、問題のあるSQL文の効率的な診断および修復が可能になります。

ビットマップ・ベースのカウントの個別SQLファンクション

新しいビット・ベクターSQL演算子は、SQL問合せ内でCOUNT DISTINCT操作を高速化するために使用します。数値式のCOUNT(DISTINCT)を計算するために、式のビット・ベクター表現を作成して最終ビットをカウントする前に集計します。結果として得られるビット・ベクターは、マテリアライズド・ビューなどでマテリアライズできます。

ターゲットの問合せよりも大きいセットのGROUP BYキーをさらにグループ化することで、ビット・ベクターを構築できます。これにより、ROLLUPを使用して、COUNT(DISTINCT)式で複数のGROUP BY問合せをリライトする際に1つのマテリアライズド・ビューを使用できます。

ほとんどのシナリオでは、ビット・ベクターSQLファンクションとマテリアライズド・ビューを組み合せることで、COUNT(DISTINCT)操作を使用した問合せが大幅に向上します。これはデータ・ウェアハウス環境で共通です。新しい演算子はパラレルに評価され、ハードウェア最適化のビットマップ操作を活用できます。下位レベルの集計レベルでビット・ベクターを持つマテリアライズド・ビューを作成すると、ROLLUPを使用して上位レベルの集計レベルで問合せをリライトするために、同じマテリアライズド・ビューを再利用できます。

インメモリー外部表のビッグ・データおよびパフォーマンスの向上

インメモリー外部表では、ORACLE_HIVEおよびORACLE_BIGDATAドライバ、パラレル問合せ、Oracle Real Application Clusters、Oracle Active Data Guardおよびオンデマンド移入のサポートが追加されています。

新しいビッグ・データ・ドライバを使用すると、インメモリー列ストア(IM列ストア)にデータを移入する前に、データのマテリアライズのコストと複雑さを回避できます。Oracle DatabaseおよびDatabase In-MemoryのSQL分析機能を使用すると、内部データと外部データの両方を分析できます。パラレル問合せおよびフル・スキャン移入のサポートは、データベースの外部にあるデータにアクセスする際にアプリケーションで制限が少なくなることを意味します。

SQL計画の自動管理

自動SQL計画管理は、ユーザーの介入なしで計画回帰を解決します。たとえば、負荷の高い文が最適に実行されていない場合、SQL計画管理の拡張アドバイザは文を自動的に特定し、最適な計画をテストして受け入れます。

SQL計画管理では、自動ワークロード・リポジトリ(AWR)でSQL文を検索します。負荷の高い順に使用可能なすべてのソースで代替計画が検索され、SQL計画ベースラインに適した実行計画が追加されます。また、Oracle Databaseでは、計画比較機能および改善されたヒント・レポートも提供されます。

SQL文のパフォーマンスの低下の影響は、自動化を使用することによって大幅に減少します。

リアルタイム統計

Oracle Databaseでは、従来のデータ操作言語(DML)操作中にオンライン統計が自動的に収集されます。

DBMS_STATS統計収集ジョブの実行中に統計が失効する可能性があります。DML操作時に統計を自動的に収集することで、DBMS_STATSによって収集された統計が増補されます。新鮮な統計情報により、オプティマイザは最適な計画を生成できます。

高頻度の自動オプティマイザ統計収集

失効オブジェクトのオプティマイザ統計を定期的に収集する軽量の高頻度自動タスクを構成できます。

統計はDBMS_STATSジョブの実行間に失効する可能性があります。統計をより頻繁に収集することで、オプティマイザはより最適な計画を生成できます。

ハイブリッド・パーティション表

ハイブリッド・パーティション表機能により、パーティションをOracle Databaseセグメントと外部ファイルおよびソースの両方に配置することで、Oracleパーティション化が拡張されています。この機能により、表の大部分が外部パーティションに存在する可能性があるビッグ・データSQLのパーティション化の機能が大幅に向上します。

ハイブリッド・パーティション表を使用すると、内部パーティションと外部パーティションを単一のパーティション表に統合できます。この機能を使用すると、非アクティブ・パーティションを、Oracle Data Pumpファイルなど、より安価なストレージ・ソリューションの外部ファイルにも移動できます。

Pythonの機械学習

Oracle Machine Learning for Python(OML4Py)

Oracle Machine Learning for Python(OML4Py)を使用すると、オープン・ソースのPythonプログラミング言語および環境で大規模にデータベース・データを操作できます。Pythonユーザーは、Oracle Databaseに格納されているデータに対する統計分析および機械学習のためにPythonコマンドおよびスクリプトを実行できます。

OML4Pyを使用して、次のことを実行できます。

  • 幅広いデータベース内機械学習アルゴリズムの使用
  • データ移動の最小化
  • データの探索および準備のための高性能なコンピュート・エンジンとしてのOracle Databaseの活用
  • 自動アルゴリズム選択、特徴選択およびモデル・チューニングへのAutoMLの使用
  • 非パラレル、データ・パラレルおよびタスク・パラレル方式でのユーザー定義Python関数の実行

関連トピック

データベース全般

自動インストール、構成およびパッチ適用

サイレント・モードのDBCAを使用してOracle Databaseの複製を作成する機能

サイレント・モードでDatabase Configuration Assistant (DBCA)のcreateDuplicateDBコマンドを使用して、Oracle Databaseの複製を作成できるようになりました。

この機能により、開発者はOracle Databaseの同一コピーで作業できます。

サイレント・モードのDBCAを使用してPDBを別のCDBに再配置する機能

サイレント・モードでDatabase Configuration Assistant (DBCA)のrelocatePDBコマンドを使用して、プラガブル・データベース(PDB)を別のマルチテナント・コンテナ・データベース(CDB)に再配置できるようになりました。

この機能により、サイレント・モードでDBCAを使用してPDBを再配置するPDBライフサイクル操作を自動化できます。

サイレント・モードのDBCAを使用してリモートPDBをクローニングすることでPDBを作成する機能

サイレント・モードでDatabase Configuration Assistant (DBCA)のcreatePluggableDatabaseコマンドのcreateFromRemotePDBパラメータを使用してリモートPDBをクローニングすることにより、プラガブル・データベース(PDB)を作成できるようになりました。

この機能により、サイレント・モードでDBCAを使用して、PDBをクローニングするPDBライフサイクル操作を自動化できます。

簡略化されたイメージベースのOracle Database Clientのインストール

Oracle Database 19c以降、Oracle Database Clientソフトウェアは、イメージ・ファイルとしてダウンロードおよびインストールできます。Oracle Database Clientインストールを開始するには、Oracleホームを配置するディレクトリにイメージ・ソフトウェアを抽出してから、runInstallerスクリプトを実行する必要があります。Oracle Database Clientインストール・バイナリは、イメージ以外のzipファイルとして従来の形式で引き続き使用できます。

Oracle DatabaseおよびOracle Grid Infrastructureのイメージ・ファイルのインストールと同様に、Oracle Database Clientのイメージ・インストールではOracle Database Clientのインストールが簡略化され、ベスト・プラクティスのデプロイメントが保証されます。

Oracle Databaseのインストールのためのrootスクリプトの自動化のサポート

Oracle Database 19c以降、データベース・インストーラまたは設定ウィザードには、データベースのインストール時に必要に応じて自動的にroot構成スクリプトを実行する権限を設定するオプションが用意されています。引き続き、root構成スクリプトを手動で実行するオプションもあります。

ユーザーの介入なくroot構成スクリプトを実行する権限を設定すると、データベースのインストールが簡素化され、不正な権限エラーを回避できます。

Oracle Clusterwareアップグレードの予行演習検証のサポート

Oracle Grid Infrastructure 19c以降、Oracle Grid Infrastructureインストール・ウィザード(gridSetup.sh)によって予行演習モード・アップグレードを実行して、システムのアップグレード準備状況を確認できます。

予行演習アップグレード・モードでは、インストール・ウィザードが実際のアップグレードで実行するすべてのシステム準備状況チェックを実行し、アップグレードの開始前にシステムのアップグレード準備が完了しているかどうかを確認できます。このモードでは、実際のアップグレードは実行されません。これは、システム設定に関する潜在的な問題を予測し、アップグレードの失敗を回避するために役立ちます。

AutoUpgradeとデータベース・ユーティリティ

Oracle DatabaseのAutoUpgrade

AutoUpgradeでは、単一のコマンドと単一の構成ファイルを使用して、コマンドラインで1つ以上のOracle Databaseインスタンスをアップグレードできます。

AutoUpgradeは、アップグレード前のタスクを実行し、必要に応じて自動修正を実行します。また、データベースのアップグレードを処理し、アップグレード後のタスクを完了してアップグレードを終了します。これには、自動再試行とフォールバック、将来の時刻用にアップグレードをスケジュールするオプション、そして必要に応じて初期化パラメータを設定、変更または削除する機能が含まれます。

AutoUpgradeによって、データベース・アップグレードに伴う手作業が大幅に軽減されます。同時に複数のデータベースをアップグレードできます。熟練したデータベース管理者によってアクティブに管理されていないデータベースに対する定期的なアップグレードも処理できます。アップグレードに必要な作業を減らし、アップグレード・プロセス中に推奨される処理を自動的に実装することで、AutoUpgradeは、データベース・アップグレード・プロセスの完了を容易にし、リスクを軽減します。

お薦めのLiveLabsワークショップ: 「Oracle Database 19cへのアップグレードに向けたヒッチハイク・ガイド」ワークショップ

インポート時にENCRYPTION句を除外するOracle Data Pump機能

新しい変換パラメータOMIT_ENCRYPTION_CLAUSEにより、暗号化された列を使用してオブジェクトに関連付けられたENCRYPTION句がデータ・ポンプによって抑制されます。

暗号化された列を持つ非クラウド・データベースでは、Oracle Cloudの移行が適切に実行できるようになりました。

TTSインポート時に表領域の読取り専用を維持できるOracle Data Pump

ファイルが読取り専用に設定されている場合、2つの異なるデータベースにマウントされている表領域ファイルをインポートできます。

新しいオプションにより、12.2以前のデフォルトの動作を復元できます。たとえば、トランスポータブル表領域インポート・プロセス時に表領域データファイルを読取り専用にできます。これには、表領域データファイルは読取り専用のままであるかぎり、2つのデータベースにマウントできるという利点があります。ただし、このオプションを使用するには、ソース・データベースとターゲット・データベースの夏時間(DST)が同じバージョンになっている必要があります。これは、インポート時にTIMESTAMP WITH TIMEZONEデータが調整されないためです。また、このパラメータを指定すると、データベースはインポート時に領域を再利用するための自動的な表領域ビットマップの再構築を実行しなくなります。これにより、インポート・プロセスは高速になりますが、その代価として表領域データファイル内で空き領域が回復されなくなります。

リソース使用率制限のOracle Data Pumpサポート

Oracle Data PumpパラメータMAX_DATAPUMP_JOBS_PER_PDBが更新され、パラメータMAX_DATAPUMP_PARALLEL_PER_JOBが追加されました。

MAX_DATAPUMP_JOBS_PER_JOBによって、マルチテナント・コンテナ・データベース環境で開始できるジョブの数をさらに制御します。デフォルト: 100、範囲: 0から250、またはAuto: SESSIONSの50%。MAX_DATAPUMP_PARALLEL_PER_JOBパラメータを使用すると、個々のData Pumpジョブに使用できるパラレル・ワーカーの数を詳細に制御できます。

これらのパラメータによって、データベース環境でData Pumpジョブを実行する複数のユーザーが存在する場合に、リソース使用率をより細かく制御できます。

トランスポータブル表領域のOracle Data Pumpテスト・モード

エクスポートの所要時間をより簡単に判断して、クローズ・チェックでレポートされない予期不能な問題を検出できます。

トランスポータブル表領域(TTS)のテスト・モードでは、TTSまたは完全トランスポータブル・エクスポート/インポートを使用して、メタデータのみのエクスポート・テストを実行します。また、ソース・データベース表領域を読取り専用モードにするという要件もなくなります。

Oracle Data Pumpで、保護されているロールの意図しない使用を防止

Oracle Data Pumpは、新しいコマンドライン・パラメータENABLE_SECURE_ROLESを使用して、保護されているロールがエクスポートおよびインポート時に誤って使用されるのを防止します。

一部のOracleロールには、認可が必要です。Oracle Data Pumpのエクスポートおよびインポートでこれらのロールを使用する必要がある場合は、明示的に有効にする必要があります。EXPDPおよびIMPDPクライアント、およびOracle Data Pump PL/SQL APIに、新しいENABLE_SECURE_ROLESパラメータを使用できます。Oracle Database 19c以降では、デフォルトはNOです。

Oracle Data Pumpがパーティション表データを1回の操作でロード

Oracle Data Pumpは、パーティションごとに別々の操作を行うのではなく、表のすべてのパーティションの表データを1回の操作でインポートできます。

インポートのDATA_OPTIONSコマンドライン・パラメータの新しい値GROUP_PARTITION_TABLE_DATAは、表のすべてのパーティションにある表データを1回の操作としてインポートすることで、Oracle Data Pumpのデフォルトの動作を変更します。このパラメータは、各表パーティションを別々の操作としてインポートするデフォルトのインポート動作が望ましくない場合に便利です。インポートではデフォルトが選択されます。たとえば、表をロードする一環として、表が別のパーティションに移動する可能性がある場合などに、このパラメータを使用できます。インポート操作で表が作成されなかった場合にもデフォルトが使用されます。

Oracle Data Pumpで、オブジェクト・ストアのダンプ・ファイルにワイルドカードを使用できる

Oracle Data Pumpでは、URLベースのダンプ・ファイル名にワイルドカードを使用できるため、Oracle Autonomous Databaseへの複数のダンプ・ファイルのインポートが簡単になります。

オブジェクト・ストア・サービスから複数のダンプ・ファイルをインポートする必要がある場合、URLベースのダンプ・ファイル名でワイルドカードを使用すると、Oracle Autonomous Databaseのインポート・コマンドを簡単に実行できます。入力が減るので、ダンプ・ファイル名のスペルを誤る可能性が少なくなります。ワイルドカード文字は、バケット名コンポーネントには使用しないでください。

Oracle Data Pumpのインポートが、より多くのオブジェクト・ストア資格証明をサポート

Oracle Data Pumpインポートでは、Oracle Autonomous Databaseに新しいCREDENTIALパラメータを追加して、DEFAULT_CREDENTIAL以外のオブジェクト・ストア資格証明がサポートされます。

Oracle Data Pumpのインポートは、Oracle Autonomous DatabaseでDEFAULT_CREDENTIALを使用するという制限がなくなりました。Oracle Database 19c (およびバックポートされたOracle Databaseリリース18c、バージョン18.3)以降では、新しいIMPDPクライアントのCLI CREDENTIALパラメータに、Oracle Autonomous Databaseで作成された任意のOracle Cloud Infrastructure (OCI)オブジェクト・ストレージ資格証明を指定できます。Data Pumpは、資格証明が存在するかどうかと、ユーザーが資格証明を読み取るためのアクセス権を持っているかどうかを検証します。エラーがある場合は、IMPDPクライアントに返されます。

診断能力

一般

通知に対して外部SMTPサーバーを使用するためのOracle Trace File Analyzerのサポート

Oracle Database 19cでは、外部Simple Mail Transfer Protocol (SMTP)サーバーを使用してOracle Trace File Analyzer通知を受信できます。

以前のリリースのOracle Trace File Analyzerでは、アラートの電子メール通知を配信する際に、ローカルsendmailまたはSMTPがサポートされたモニター対象ホストを構成する必要がありました。外部SMTPサーバー通知サポートによって、Oracle Trace File Analyzerデプロイメントでは完全な通知機能を活用できるため、ダウンタイムを最小限に抑えて可用性を最大化するのに役立ちます。

Oracle Cluster Health AdvisorのOracle Trace File Analyzerへの統合

Oracle Trace File AnalyzerがOracle Cluster Health Advisorと統合され、Oracle Cluster Health Advisorが検出する問題イベントを使用します。

Oracle Cluster Health Advisorが問題イベントを検出すると、Oracle Trace File Analyzerによって関連する診断収集が自動的にトリガーされ、電子メール通知が送信されます。標準のOracle Trace File Analyzer通知プロセスを介して電子メール通知を構成できます。

Oracle Cluster Health Advisorでは、Oracle Real Application Clusters (Oracle RAC)データベースおよびクラスタ・ノード関連のパフォーマンスの問題に対する早期警告を提供します。Oracle Trace File Analyzerでは根本原因分析および修正の推奨事項を記載した電子メール通知を送信するため、事前にアプリケーションのパフォーマンスまたは可用性の問題を防止できます。

Oracle Trace File AnalyzerのREST APIのサポート

Oracle Trace File AnalyzerにREpresentational State Transfer (REST)サポートが追加されたため、HTTPSを介した起動および問合せが可能になりました。

RESTサポートを容易にするために、Oracle REST Data Services (ORDS)がインストールに含まれています。RESTでは、詳細の出力、診断収集の開始および収集のダウンロードがサポートされています。

RESTインタフェースを使用すると、リモート管理を構成し、データ・センター操作を自動化できます。Oracle Trace File Analyzerでは、REST APIを介して操作するとき、ユーザー操作フレームワークへの容易な統合をサポートしています。これにより、診断効率が向上し、リカバリ時間を短縮できます。

メタデータ検索をサポートするように拡張されたOracle Trace File Analyzer検索

今回のリリースから、Oracle Trace File Analyzer索引に格納されているメタデータをtfactlで検索できるようになりました。

Oracle Trace File Analyzerでは、データ型とイベントを表すJavaScript Object Notation (JSON)形式の名前/値ペアを使用して、ログおよびトレース・ファイル・メタデータを検索します。

ログとトレース・ファイル・メタデータを検索できる機能は、ダウンタイムの最小化と可用性の最大化のためにも、問題(特にインスタンス間やノード間で繰返し発生する問題)を効率的に診断および判定するためにも不可欠です。以前のリリースのOracle Trace File Analyzerでは、検索機能はログおよびトレース・ファイル文字列に限定されていました。

Oracle ORAchkおよびOracle EXAchkのRESTのサポート

Oracle ORAchkおよびOracle EXAchkにREpresentational State Transfer (REST)サポートが追加されたため、HTTPSを介した起動および問合せが可能になりました。

RESTサポートを容易にするために、Oracle REST Data Services (ORDS)がインストールに含まれています。RESTインタフェースを使用すると、リモート管理を構成し、データ・センター操作を自動化できます。Oracle ORAchkおよびOracle EXAchkでは、REST APIを介して操作するとき、ユーザー操作フレームワークへの容易な統合をサポートしています。これにより、診断効率が向上し、リカバリ時間を短縮できます。

Oracle ORAchkおよびOracle EXAchkによる収集ファイルの暗号化のサポート

Oracle ORAchkおよびOracle EXAchkの診断収集ファイルには、機密データを含めることができます。今回のリリースから、診断収集ZIPファイルの暗号化および復号化と、パスワード保護が可能になりました。

Oracle ORAchkおよびOracle EXAchkの収集とそのレポートには、機密データを含めることができます。これらのレポートをリポジトリに電子メールで送信または転送する際、目的の受信者のみに機密データが表示されることが重要です。データの漏えい防止のために、診断収集を暗号化してパスワードで保護することで、機密データへのアクセスを制限します。この機能はLinuxおよびSolarisプラットフォームでのみ使用できます。

Oracle ORAchkおよびOracle EXAchkによるパスワードなしのSSHを必要としないリモート・ノード接続のサポート

今回のリリースから、リモート・ノードの秘密キー・ファイルを自動生成するようにOracle ORAchkおよびOracle EXAchkを構成できるようになりました。または、秘密キーを指定することもできます。

リモートで操作を実行して、多数のデータベース・サーバーまたはクラスタを集中管理できます。多くの場合、企業ポリシーではパスワードなしのSecure Shell (SSH)を構成しないようにしています。秘密キー認証を使用すると、これらのデプロイメントでOracle ORAchkおよびOracle EXAchkをリモートで実行できるようになり、操作の効率が向上します。以前のリリースのOracle ORAchkおよびOracle EXAchkでは、Oracle ORAchkまたはOracle EXAchkのリモートでの実行で、リモート・ノード間にパスワードなしのSSHを構成する必要がありました。

最もクリティカルなチェックのみをデフォルトで表示するようになったOracle ORAchkおよびOracle EXAchk

Oracle ORAchkおよびOracle EXAchkでは、レポートを生成し、最もクリティカルなチェックのみをデフォルトで表示します。

クリティカルなチェックとは、潜在的に最も重大な影響があるチェックです。Oracle ORAchkおよびOracle EXAchkでは、他のすべてのチェックを実行してレポートに含めます。チェックを表示するには、次のステータスのチェックの表示コントロールの下の適切なオプションを選択します。

以前のリリースのOracle ORAchkおよびOracle EXAchkでは、レポートに100以上のチェックが含まれていて、分析に時間がかかっていました。最もクリティカルなチェックを行うことで、レポートを効率的に分析し、クリティカルな問題を迅速に解決して、停止時間やパフォーマンスの問題を防止できます。

Oracle Trace File Analyzerによる新規サービス・リクエスト・データ収集のサポート

今回のリリースには、Oracle Automatic Storage Management (Oracle ASM)、Oracle Automatic Storage Management Cluster File System (Oracle ACFS)、リスナー、監査およびRecovery Manager (RMAN)などのインフラストラクチャで、より多くのORAエラーおよび問題に対応する追加のデータベースのサービス・リクエスト・データ収集(SRDC)が加えられています。

Oracleサポート・サービスを必要とする操作またはOracle Databaseの問題が発生した場合は、1つのコンパクトな完全アーカイブで、問題を診断および解決するために必要なすべてのデータおよびログを収集して送信することが重要です。SRDCでは、特定の問題に必要なログおよびデータの収集が簡素化されます。

パフォーマンス

一般

SQLの隔離

CPUおよびI/Oリソースを過剰に消費したために、Oracle Databaseリソース・マネージャによって終了されたSQL文は自動的に隔離されます。終了されたSQL文に関連付けられた実行計画は、再度実行されないように隔離されます。

この機能では、CPUおよびI/Oリソースを過剰に消費するSQL文が実行されないようにすることで、Oracle Databaseのパフォーマンス低下を防止します。

移入時のデータベース・インメモリーの待機

DBMS_INMEMORY_ADMIN.POPULATE_WAITファンクションは、指定した優先度のオブジェクトが指定した割合で移入されるまで待機します。

新しいファンクションにより、アプリケーション・アクセスを許可する前に、指定されたインメモリー・オブジェクトが移入されるようになりました。たとえば、データベースには様々な優先度設定を持つ多数のインメモリー表が含まれている場合があります。制限付きセッションでは、POPULATE_WAITファンクションを使用して、すべてのインメモリー表が完全に移入されるようにします。その後、アプリケーションが確実に表のインメモリー表現のみを問い合せるように、制限付きセッションを無効化できます。

データベース・インメモリーで自動的に有効になるリソース・マネージャ

INMEMORY_SIZE0より大きい場合、Oracle Database Resource Managerが自動的に有効になります。

インメモリー動的スキャンを利用するには、リソース・マネージャが必要です。データベース・インメモリーが有効な場合、リソース・マネージャが自動的に有効になるため、パフォーマンスが向上し、CPUリソース割当てが自動的に管理されるという利点があります。

Memoptimized Rowstoreの高速収集

Memoptimized Rowstoreの高速収集機能により、小さな大量のトランザクションを最小のトランザクション・オーバーヘッドで収集するIoT (Internet of Things)アプリケーションなどから、Oracle Databaseへの高速なデータ挿入が可能になります。高速収集を使用する挿入操作では、データを一時的にラージ・プールにバッファしてからディスクに一括して書き込みます(遅延のある非同期的な方法です)。

Oracle Databaseの豊富な分析機能を使用すると、高頻度データ・ストリーミング・アプリケーションからのデータを既存のアプリケーション・データに簡単に統合して、データ分析を効率的に実行できます。

自動データベース診断モニター(ADDM)によるプラガブル・データベース(PDB)のサポート

マルチテナント環境で、プラガブル・データベース(PDB)に対して自動データベース診断モニター(ADDM)分析を使用できるようになりました。

PDBレベルでのADDM分析により、パフォーマンス向上のためにPDBを効率的にチューニングできます。

データベース・インメモリーで自動的に有効になるリソース・マネージャ

INMEMORY_SIZE0より大きい場合、Oracle Database Resource Managerが自動的に有効になります。

インメモリー動的スキャンを利用するには、リソース・マネージャが必要です。データベース・インメモリーが有効な場合、リソース・マネージャが自動的に有効になるため、パフォーマンスが向上し、CPUリソース割当てが自動的に管理されるという利点があります。

高頻度SQL計画管理展開アドバイザのタスク

標準のメンテナンス・ウィンドウ以外に、自動SPM展開アドバイザのタスクを1時間ごとに実行するように構成できます。

SQL計画ベースラインをさらに頻繁に展開することによって、オプティマイザはパフォーマンスの低下をより迅速に修正し、より最適なSQL実行計画を実施できます。

PDBでのワークロードの取得およびリプレイ

Oracle Real Application Testingは、マルチテナント・データベースをルート・マルチテナント・コンテナ・データベース(CDB)レベルで取得およびリプレイするように設計されました。Oracle Databaseリリース19c以上では、個々のプラガブル・データベース(PDB)内からワークロードを取得してリプレイできます。

この拡張により、PDBレベルでワークロードを取得およびリプレイできます。これにより、テスト、ダウンタイムの削減、効率的で効果的な変更管理が可能になります。

MAX_IDLE_BLOCKER_TIMEパラメータ

MAX_IDLE_BLOCKER_TIMEには、必要なリソースを保持しているセッションが終了の候補となるまでアイドル状態を維持できる分数を設定します。

MAX_IDLE_TIMEはすべてのアイドル・セッションに対する制限を設定するのに対し、MAX_IDLE_BLOCKER_TIMEはリソースを消費するアイドル・セッションに対する制限のみを設定します。MAX_IDLE_TIMEは接続プールにとって問題である場合がありますが、これは、このパラメータによって終了されたセッションの再作成が継続的に試行されることがあるためです。

RACおよびグリッド

一般

Standard Edition高可用性

Oracle Clusterwareを使用し、シングル・インスタンスのStandard EditionのOracle Databases用にクラスタベースのフェイルオーバーを提供します。

Oracle Standard Edition高可用性の利点は、Oracle Clusterware、Oracle Automatic Storage Management (Oracle ASM)およびOracle ASM Cluster File System (Oracle ACFS)など、Oracle Grid Infrastructureにすでに含まれているクラスタ機能およびストレージ・ソリューションです。

データベース・ファイル用および非構造化データ用のOracle ASMやOracle ACFSなどの、統合された、共有の、同時にマウントされた記憶域を使用することにより、Oracle Grid Infrastructureではフェイルオーバーのノード上でOracle Databaseを再起動でき、これは、フェイルオーバーおよび再マウントされたボリュームやファイル・システムに依存するクラスタ・ソリューションよりもはるかに高速です。

パリティ保護されたファイル

Oracle Database Automatic Storage Management (Oracle ASM)では、ライトワンス・ファイルに対してパリティ保護を使用できません。ライトワンス・ファイルとは、アーカイブ・ログやバックアップ・セットなどのファイルです。

データベース・バックアップ操作に関連付けられたファイルに2つまたは3つのOracle ASMミラー化を使用する場合は、大量の領域を消費します。バックアップ・ファイルはライトワンス・ファイルで、この機能により、従来のミラー化ではなく、パリティ保護での保護が可能になります。その結果、かなりの領域を節約できます。

セキュアなクラスタ通信

セキュアなクラスタ通信は、単一ネットワーク・サポートと併用する場合に、一般的なセキュリティに対する脅威からクラスタ相互接続を保護します。セキュアなクラスタ通信は、メッセージ・ダイジェスト・メカニズムや、ファジーに対する保護の機能があり、Transport Layer Security (TLS)を使用してクラスタ・メンバー間のプライバシとデータ整合性を提供します。

クラスタ相互接続のセキュリティ強化は、新しいOracle Grid Infrastructure 19cデプロイメントの一部として、またはOracle Grid Infrastructure 19cへのアップグレードの一部として、自動的に実行されます。データベース管理者やクラスタ管理者が、この機能の構成を変更する必要はありません。

PDBの自動再配置

Oracle Grid Infrastructureでは、フリート・パッチ適用およびプロビジョニングを使用して、あるマルチテナント・コンテナ・データベース(CDB)から別のマルチテナント・コンテナ・データベースへのプラガブル・データベース(PDB)の再配置を自動化できます。

個々のPDBへのパッチ適用を高速化でき、別のPDBがパッチによる変更にさらされることがなくなります。

ゼロ・ダウンタイムのOracle Grid Infrastructureのパッチ適用

ゼロ・ダウンタイムのOracle Grid Infrastructureのパッチ適用では、データベース操作を中断せずにOracle Grid Infrastructureのパッチ適用が可能です。パッチはホーム外およびローリング方式で適用され、一度に1つのノードがパッチ適用され、ノードのデータベース・インスタンスが操作中のままになります。停止時間0のOracle Grid Infrastructureパッチ適用は、2つ以上のノードを持つクラスタでOracle Real Application Clusters (Oracle RAC)データベースをサポートします。

ゼロ・ダウンタイムのグリッド・インフラストラクチャ・パッチ適用では、パッチが適用されるノードでデータベース操作を中断せずに、それらのデータベース・インスタンス上の容量やパフォーマンスに影響を与えることなく、ユーザーにOracle Grid Infrastructureのローリング・パッチを許可することによって、データベースの可用性が大幅に向上します。

Oracle Grid Infrastructureのアップグレードの自動トランザクション排出

Oracle Grid Infrastructureのアップグレードの自動トランザクション排出では、データベース・サービス構成に従って、ローリング方式で一度に1ノードずつ、データベース・インスタンスに対するトランザクションの自動排出を行います。トランザクション排出機能は、データベース・サービス設計の不可欠な部分であり、ローリングOracle Grid Infrastructureパッチのアプリケーションに自動的に統合されるようになりました。

フリート・パッチ適用およびプロビジョニングを使用して、ローリング・パッチ適用中のデータベース・トランザクションの自動化および調整された排出により、パッチ適用操作の影響が軽減されます。ユーザー・トランザクションが排出されると、クラスタ上の特定のノードのパッチ適用操作が完了します。その後で、インスタンスとサービスがローカルで再起動され、新しい接続が確立されてからクラスタ内の次のノードにパッチ適用操作が進展します。

Oracle Restartのパッチ適用およびアップグレード

フリート・パッチ適用およびプロビジョニングを使用して、Oracle Restartにパッチを適用およびアップグレードします。以前のリリースのOracle Restart環境では、ユーザーがパッチ適用操作とアップグレード操作を実行する必要がありました(多くの場合、手動操作が求められます)。フリート・パッチ適用およびプロビジョニングでは、これらの手順が自動化されます。

フリート・パッチ適用およびプロビジョニングを使用してOracle Restartにパッチを適用してアップグレードすると、Oracle Real Application Clusters (Oracle RAC)データベース・インストールで実装されるプロセスが自動化および標準化されます。特にOracle Restartデプロイメントの数が多い場合、これにより操作の必要性とリスクも削減されます。

クライアント・ルーティングのコロケーション・タグ

COLOCATION_TAGパラメータは、Transparent Network Substrate (TNS)接続文字列のCONNECT_DATAパラメータで使用できる英数字の文字列です。COLOCATION_TAGパラメータを設定すると、同じCOLOCATION_TAGを持つクライアントを同じデータベース・インスタンスにルーティングしようとします。

同じインスタンス上のセッションのコロケーションにより、インスタンス間の通信が減少するため、同じインスタンスで実行されることでメリットを得られるワークロードのパフォーマンスが向上します。

グリッド・インフラストラクチャ管理リポジトリのオプションのインストール

Oracle Grid Infrastructure 19c以上では、グリッド・インフラストラクチャ管理リポジトリ(GIMR)は、Oracleスタンドアロン・クラスタの新規インストールでオプションです。Oracleドメイン・サービス・クラスタでは、GIMRをサービス・コンポーネントとしてインストールする必要があります。

GIMRに含まれるデータは、適用された機械学習に基づく予防診断の基礎となり、Oracle Real Application Clusters (Oracle RAC)データベースの可用性の向上に役立ちます。GIMRにオプションのインストールを使用すると、特にテスト・システムや開発システムのインストール時に、ストレージ領域管理の柔軟性が高くなり、デプロイメントも高速になります。

OCRおよび投票ディスクの直接ファイル配置の再サポート

Oracle Grid Infrastructure 19c以上では、共有ファイル・システム上のOracle Cluster Registry (OCR)および投票ディスク・ファイルの直接配置のサポート終了は、Oracleスタンドアロン・クラスタに対して破棄されます。Oracleドメイン・サービス・クラスタでは、共有ファイル・システム上にホストされOracle ASMディスクとして使用されるファイルの上にOracle Automatic Storage Management (Oracle ASM)のOCRおよび投票ファイルを配置しなければならないという要件が残っています。

Oracle Grid Infrastructure 12cリリース2 (12.2)では、共有ファイル・システム上でOracle Grid InfrastructureのOCRおよび投票ファイルの直接配置がサポートされなくなることが発表されました。このサポート終了は現在破棄されました。Oracle Grid Infrastructure 19c (バージョン19.3)以上では、Oracleスタンドアロン・クラスタとともに、OCRおよび投票ディスク・ファイルを共有ファイル・システムに直接配置できます。

動的サービス・フォールバック・オプション

preferredおよびavailable設定を使用して配置された動的データベース・サービスの場合、サービスが使用可能なインスタンスにフェイルオーバーすると、優先インスタンスが使用可能になったときに、このサービスがそのインスタンスに戻るように指定できるようになりました。

この動的サービス・フォールバックのオプションを使用すると、動的データベース・サービスの配置が自由になり、特定のサービスをできるだけ優先インスタンスで使用できるようになります。

セキュリティ

一般

新しいALTER SYSTEM句のFLUSH PASSWORDFILE_METADATA_CACHE

ALTER SYSTEM句のFLUSH PASSWORDFILE_METADATA_CACHEは、データベース・パスワード・ファイルの最新詳細でメタデータ・キャッシュをリフレッシュします。V$PASSWORDFILE_INFOビューを問い合せると、データベース・パスワード・ファイルの最新の詳細が取得されます。

この機能は、データベース・パスワード・ファイル名または場所が変更され、更新されたデータベース・パスワード・ファイルの詳細でメタデータ・キャッシュをリフレッシュする必要がある場合に便利です。

Oracle Managed Files以外のモードでの自動名前変更のための透過的オンライン変換のサポート

このリリース以降、Oracle Managed Files以外のモードでの透過的データ暗号化オンライン変換では、ADMINISTER KEY MANAGEMENT SQL文にFILE_NAME_CONVERT句を含めることは強制されなくなりました。ファイル名は元の名前が維持されます。

この拡張機能によりは、ファイルの名前を元の名前(ファイルが見つからないこともある)に変更する必要がなくなります。

オフライン表領域暗号化のための追加アルゴリズムのサポート

以前のリリースでは、オフライン表領域の暗号化でAES128暗号化アルゴリズムのみがサポートされていました。今回のリリースでは、AES192およびAES256暗号化アルゴリズムと、オフライン表領域暗号化のためのARIAGOSTおよび3DES暗号化アルゴリズムのサポートが追加されています。

この拡張は、オンライン表領域暗号化に必要な補助領域の使用について懸念がある場合に役立ちます。

透過的データ暗号化における暗号化されたOracle管理の表領域のキー管理

今回のリリースでは、閉じた透過的データ暗号化(TDE)暗号化キーストアはOracle管理表領域に対する内部操作には影響しません。

内部プロセスは、キーストアが閉じられているときにキーストアにアクセスできます。これにより、TDEキーストアが閉じられているなどで使用不可のときにも、TDEマスター暗号化キーから導出された中間キーを使用して、内部プロセスを続行して正常に完了できます。

TDEキーストアを閉じても、暗号化されたSYSTEMSYSAUXTEMPおよびUNDO表領域の問合せに影響はありません。ユーザー作成の表領域の問合せでは、TDEキーストアを閉じると、「ORA-28365 ウォレットがオープンしていません」というエラーが引き続き返されます。

暗号化されたOracle管理の表領域に対してユーザーが開始した復号化などの操作では、TDEキーストアがOPEN状態である必要があります。

ホスト証明書のホスト名ベースの部分DN一致のサポート

部分識別名(DN)一致に対して新しいサポートが追加され、クライアントがサーバー証明書をさらに検証する機能が追加されました。

Secure Sockets Layer (SSL)ハンドシェイク中に、サーバー証明書との完全DN一致を実行する以前の機能もサポートされています。クライアントは完全DN一致と部分DN一致の両方をサポートします。サーバーDN一致を有効にすると、部分DN一致がデフォルトになります。

証明書の検証に部分および完全DN一致を許可すると、証明書の作成方法に基づいて柔軟性が向上します。

SYSLOGおよびWindowsイベントビューアの新しいPDB_GUID監査レコード・フィールド

SYSLOGおよびWindowsイベントビューアの監査レコード・フィールドに、新しいフィールドPDB_GUIDが含まれるようになりました。このフィールドでは、統合監査証跡レコードに関連付けられたプラガブル・データベース(PDB)を識別します。

マルチテナント・コンテナ・データベース(CDB)デプロイメントでは、統合監査証跡レコードを生成したプラガブル・データベースが監査証跡で識別される必要があります。今回のリリース以降では、この情報を新しいフィールドで取得します。データ型はVARCHAR2です。

UNIFIED_AUDIT_TRAILビューの新しいEVENT_TIMESTAMP_UTC列

UNIFIED_AUDIT_TRAILビューに、新しいEVENT_TIMESTAMP_UTC列が加わっています。WHERE句のEVENT_TIMESTAMP_UTC列に基づいて、UNIFIED_AUDIT_TRAILビューを問い合せます。この新しい列は、UNIFIED_AUDIT_TRAILビューの読取りパフォーマンスが向上するパーティション・プルーニングに役立ちます。

Oracle Databaseアカウントから削除されたパスワード

Oracle Database提供のほとんどのスキーマのみのアカウントは、ユーザーが認証できないようにするためにパスワードが削除されています。

この拡張機能はサンプル・スキーマには影響しません。サンプル・スキーマは、引き続きデフォルトのパスワードとともにインストールされています。

管理者は、引き続きデフォルトのスキーマのみのアカウントにパスワードを割り当てることができます。そうしたスキーマは、スキーマのみのアカウントに戻すように後から変更することをお薦めします。

この機能の利点は、管理者がこれらのOracle Database提供のスキーマのパスワードを定期的にローテーションする必要がなくなったことです。この機能により、攻撃者がデフォルトのパスワードを使用してこれらのアカウントにハッキングするセキュリティ・リスクも削減されます。

LOBロケータの署名ベース・セキュリティ

今回のリリース以降、ラージ・オブジェクト(LOB)・ロケータの署名ベースのセキュリティを構成できるようになりました。

この機能は、特にLOBデータ型のインスタンス(CLOBおよびBLOB)を分散環境で使用する場合に、Oracle Database LOBのセキュリティを強化します。

LOB署名キーは、マルチテナントのプラガブル・データベース(PDB)またはスタンドアロンの非マルチテナント・データベースのどちらかです。ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS SQL文を実行することで、LOB署名キー資格証明の暗号化を有効にできます。それ以外の場合、資格証明は不明瞭化された形式で格納されます。LOB署名キーを暗号化された形式で格納する場合、データベースまたはPDBには開いている透過的データ暗号化(TDE)キーストアが必要です。

トップレベルの文の統合監査

トップレベルの文の統合監査機能を使用すると、データベース内のトップ・レベル・ユーザー(直接ユーザー)のアクティビティを監査できます。このとき、間接ユーザーのアクティビティ監査データは収集しません。

この機能を使用すると、トップ・レベル・ユーザーによって生成されたイベントのみを監査できます。間接SQL文の監査レコードを作成するオーバーヘッドはありません。トップレベルの文は、ユーザーが直接発行するSQL文です。これらの文は、セキュリティとコンプライアンスの両方にとって重要です。多くの場合、PL/SQLプロシージャまたはファンクション内から実行されるSQL文はトップ・レベルとみなされないため、監査目的にあまり適切でない場合があります。

Oracle Database Enterprise Editionで使用可能な権限分析

権限分析が、Oracle Database Enterprise Editionの一部として使用できるようになりました。

権限分析はユーザーおよびアプリケーションの動的分析を実行し、使用中および未使用の権限およびロールを検出します。権限分析により、各アカウントで使用中および未使用の権限を正確に表示して、最低限の権限のベスト・プラクティスを実装する作業が削減されます。権限分析は高性能であり、テスト、開発および本番開発データベースで機能するように設計されています。

この変更の一環として、権限分析のドキュメントは『Oracle Database Vault管理者ガイド』から『Oracle Databaseセキュリティ・ガイド』に移動しました。

異なるユーザーに対するOracleネイティブ暗号化およびSSL認証の同時サポート

以前のリリースのOracle Databaseでは、Oracleネイティブ暗号化(Advanced Networking Option (ANO)暗号化)とSecure Sockets Layer (SSL)認証の両方を同時に使用することはできませんでした。

たとえば、クライアントのSQLNET.ENCRYPTION_CLIENTパラメータとサーバーのSQLNET.ENCRYPTION_SERVERパラメータの両方をREQUIREDに設定した場合に、TCP/IP with SSL (TCPS)リスナーを使用していると、「ORA-12696 暗号化オプションの両方がオンになっています。ログインできません」というエラーが発生します。今回のリリース以降では、新しいSQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPSパラメータをTRUEに設定できます。この設定では、TCPSクライアントの使用時に、SQLNET.ENCRYPTION_CLIENTまたはSQLNET.ENCRYPTION_SERVERのどちらかがREQUIREDに設定されていると、そのパラメータは無視されます。

スキーマのみのアカウントに対して管理権限を付与または取り消す機能

SYSOPERSYSBACKUPなどの管理権限をスキーマ限定(パスワードなし)アカウントに付与できます。

未使用およびほとんどアクセスされていない管理権限のあるデータベース・ユーザー・アカウントは、スキーマのみのアカウントにすることができるようになりました。この拡張により、管理者はこれらのアカウントのパスワードを管理する必要がなくなります。

SASLおよびSASL以外のActive Directory接続の自動サポート

今回のリリース以降、Microsoft Active Directory接続では、Simple Authentication and Security Layer (SASL)およびトランスポート・レイヤー・セキュリティ(TLS)バインドの両方がサポートされています。

集中管理されたユーザーの場合、Oracle Databaseは最初にSASLバインドを使用してActive Directoryへの接続を試行します。Active DirectoryサーバーがSASLバインド接続を拒否した場合、Oracle DatabaseはTLSによる保護を維持したままSASLバインドなしの接続を自動的に再試行します。

Active Directoryサーバーの接続パラメータを構成するActive Directory管理者は、この新しいActive Directory接続拡張にあわせるようにデータベースを構成する必要はありません。データベースは、SASLを使用する方法からSASLバインドを使用しない方法への調整を自動的に実行します。

インフラストラクチャ・データベース管理者のDatabase Vault操作の制御

マルチテナント・データベースでは、Oracle Database Vaultを使用して、共通ユーザー(インフラストラクチャ・データベース管理者など)がプラガブル・データベース(PDB)内のローカル・データにアクセスするのをブロックできるようになりました。

この拡張により、共通ユーザーはPDBに存在するローカル・データにアクセスできなくなります。これにより、ビジネス・アプリケーションの機密データを格納できるようになり、重要な顧客データにアクセスすることなく、データベース・インフラストラクチャを管理する操作が可能になります。

Database Vaultコマンド・ルールによる統合監査ポリシーのサポート

統合監査ポリシー用のOracle Database Vaultコマンド・ルールを作成できるようになりました。

コマンド・ルールを使用して、個々の統合監査ポリシーを有効および無効にできるようになりました。この拡張によって、1つのコマンド・ルールを介してすべての統合監査ポリシーを同じように管理するのではなく、各ポリシーの管理方法をきめ細かく制御できます。たとえば、HR監査者は、CRM統合監査ポリシーではなく、自分自身のHR統合監査ポリシーを制御できます。この新機能は、コマンド・ルールに対してAUDITおよびNOAUDITの使用を拡張しますが、コマンド・ルールに統合監査ポリシーを指定する場合、AUDIT POLICYまたはNOAUDIT POLICYを指定する必要があります。

共通統合監査ポリシーのためのSYSLOG宛先

共通統合監査ポリシーからの統合監査レコードの特定の事前に定義された列は、UNIX SYSLOG宛先に書き込むことができます。

この機能を有効にするには、新しいCDBレベルの初期化パラメータUNIFIED_AUDIT_COMMON_SYSTEMLOGを設定します。この拡張により、共通統合監査ポリシーからのすべての監査レコードを1つの宛先に統合できるようになります。

この機能はUNIXプラットフォームでのみ使用でき、Windowsでは使用できません。