Oracle Exadata Database Machineの新機能 19.1.0

Oracle Linux 7.5へのOracle Linuxのアップグレード

Oracle Exadata System Softwareリリース19.1.0では、データベース・サーバーおよびストレージ・サーバーで使用されるオペレーティング・システムがOracle Linux 7.5に更新されました。以前のリリースで使用されていたOracle LinuxカーネルUEK4は、引き続き同じままです。

Oracle Linux 7の詳細は、Oracle Linux 7のドキュメントを参照してください。

Oracle Databaseソフトウェアの最小必須バージョン

次のOracle DatabaseおよびOracle Grid Infrastructureソフトウェア・リリースは、Oracle Exadata System Softwareリリース19.1.0およびOracle Linux 7.5でサポートされています。

Oracle Exadata System Software 19.1.0以降では、次のOracle Databaseソフトウェア・リリースがサポートされています。

Oracle DatabaseおよびOracle Grid Infrastructure 19c
Oracle DatabaseおよびOracle Grid Infrastructure 18c
- 最低バージョン18.3.0.0.180717
Oracle DatabaseおよびOracle Grid Infrastructure 12cリリース2 (12.2.0.1.0)
- 最低バージョン12.2.0.1.180717
Oracle DatabaseおよびOracle Grid Infrastructure 12cリリース1 (12.1.0.2.0)
- 最低バージョン12.1.0.2.180831
Oracle Database 11gリリース2(11.2.0.4.0)
- 最低バージョン11.2.0.4.180717
- Oracle Grid Infrastructure release 12.1.0.2.180831以上が必要です
Oracle Database 11gリリース2(11.2.0.3.0)
- 最低バージョン11.2.0.3.28
- Oracle Grid Infrastructure release 12.1.0.2.180831以上が必要です
- Oracle Databaseソフトウェアのインストールは、このリリースでは手動タスクであり、OEDAでは処理されません。
  
  注意:
  Oracle Database 11gリリース2 (11.2.0.3.0)に、これ以上バンドル・パッチはありません。このリリースのパッチ適用終了日は、2015年8月27日でした。

Oracle Linux 7リリースの詳細は、Oracle Linux 7リリース・ノートの新機能および変更点を参照してください。

クラウド・スケール・パフォーマンスの自動監視

Oracle Exadata System Softwareリリース19.1.0以降、Exadata Database Machineは、CPU、メモリー、ファイル・システム、IO、ネットワークなど、幅広いサブシステムを対象に、自動化されたクラウド・スケール・パフォーマンス監視を提供します。この機能では、人工知能、長年にわたる現実世界でのパフォーマンス・トリアージの経験、およびベスト・プラクティスを組み合わせています。

Oracle Exadata System Softwareは、パフォーマンスの問題を自動検出し、人間の介入なしに根本原因を特定できます。この機能の動作例を次に示します。

回転プロセスがシステム上のすべてのリソースを占有し、データベースのパフォーマンスに影響を与える場合、Oracle Exadata System SoftwareはCPUスピンを自動的に検出し、スピンの原因であるプロセスを正確に特定してアラートを生成します。
Oracle Databaseが、ベスト・プラクティス推奨に従って大規模なページに正しく構成されていない場合、Oracle Exadata System Softwareは正しく構成されていないことを自動的に検出し、影響を受けるデータベース・インスタンスについてアラートを生成します。

この機能に構成は必要ありません。アラートを受信するには、通知メカニズムを構成する必要があります。Oracle Exadata Storage Serverのリクエストとアラートの監視、およびALTER DBSERVERを参照してください。

この機能の一部として、ストレージ・サーバー、データベース・サーバー(ベア・メタル構成)および管理ドメイン(dom0)に加えて、ユーザー・ドメイン(domU)で管理サーバー(MS)が有効になります。

最小要件:

Oracle Exadata System Software 19.1.0

列レベルのチェックサムを使用したスマート・スキャンの高速化

チェックサムの計算および検証は、データの格納または取得中に発生する可能性のあるエラーを検出するのに役立ちます。チェックサムは、データがExadataフラッシュ・キャッシュに書き込まれるときに計算され、後続の読取り時に検証されます。

Oracle Exadata System Softwareリリース19.1.0より前では、読取り後にフラッシュ上のブロックでチェックサムが計算されていました。通常、このブロックには複数の列が含まれますが、典型的なデータ・ウェアハウス問合せは表の一部の列にしかアクセスしません。Oracle Exadata System Softwareリリース19.1.0では、チェックサム計算の単位が1列に減っています。チェックサムは列ごとに計算され、列圧縮単位(CU)ヘッダーに格納されます。この最適化は、Exadataスマート・フラッシュ・キャッシュのインメモリー列形式でのみ有効です。

列レベル・チェックサムのアプローチの主な利点は、次のとおりです。

選択的なチェックサム計算: 対象となる列を含むフラッシュ・ブロックがスマート・スキャンによって読み取られるとき、キャッシュ行に他の列が多数存在する場合でも、チェックサム検証は特定の列CUに対してのみ実行されます。そのため、チェックサムが実行されるデータ量が減り、CPU使用率が低くなります。たとえば、A < 5 and Z < 10という述語について考えてみます。列Aが存在するフラッシュ・ブロックには、列B、CおよびDを含まれる可能性があります。ただし、B、CおよびDは問合せで参照されていないため、B、CおよびDに対してチェックサムは実行されません。
Just in timeのチェックサム計算: チェックサムは列が処理される場合にのみ実行されます。たとえば、A < 5 and Z < 10という述語について考えてみます。チェックサムは列Aの列CUで計算され、述語が評価されます。述語A < 5を満たす行がない場合、Z < 10を評価する理由はありません。列Zの列CUに対してチェックサム計算は実行されません。そのため、チェックサムが実行されるデータ量が大幅に減り、CPU使用率が低くなります。

この機能は、INMEMORY_SIZEデータベース初期化パラメータを構成し、Oracle Exadata System Softwareリリース19.1.0にアップグレードするときに自動的に有効になります。この新機能を使用するために、これ以上の構成は必要ありません。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドのデータ検索および取得処理のオフロードを参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0
Exadataスマート・フラッシュキャッシュ
INMEMORY_SIZEデータベース初期化パラメータ

セルの停止およびフラッシュ障害時のOLTP高可用性の拡張

Oracle Exadata System Softwareリリース19.1.0では、セルの停止およびフラッシュ障害に起因するOLTP高可用性をさらに拡張する新機能が導入されています。この機能で、複数のストレージ・サーバーのフラッシュ・キャッシュのホット・データを部分的に複製することによって、フラッシュ・デバイスまたはストレージ・サーバーの障害後にアプリケーション・パフォーマンスが向上します。

セルがオフラインになるかフラッシュ・デバイスが失敗した場合、停止のためにプライマリ・ミラーが使用できないため、データベースは、読取り操作用のセカンダリ・ミラーを使用するようにIOをリダイレクトします。ただし、セカンダリ・ミラーは各セルのフラッシュ・キャッシュにないため、データベースはハード・ディスクからデータを読み取る必要があります。フラッシュ・キャッシュ・ミスが原因で、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。

この新機能を使用すると、Oracle Exadata System Softwareは、フラッシュ・キャッシュに最も頻繁にアクセスされるOLTPデータのセカンダリ・ミラーをプリフェッチします。このプリフェッチはバックグラウンド・タスクとして実行されます。Oracle Exadata System Softwareは、フラッシュ・キャッシュ内のセカンダリ・ミラーを最適な方法で自動的に管理し、新しいアクティブなセカンダリ・ミラーがキャッシュ内のコールド・データを置換します。また、フラッシュ・デバイスを交換すると、この機能によって、新しいフラッシュ・デバイスにデータベースの読取り操作を行う前に、新しく交換されたフラッシュ・デバイスがより新しい(堅牢な)ものになります。したがって、この機能により、セルまたはフラッシュ・デバイスの障害時とフラッシュ・デバイスの交換時に、セカンダリ・ミラー・フラッシュ・キャッシュミスが著しく減少するるため、アプリケーション・パフォーマンスの高可用性が向上します。

この機能はOLTPワークロードにのみ有効です。Oracle Exadata System Softwareは、スキャン・データのセカンダリ・ミラーをキャッシュしません。また、この機能はライトバック・フラッシュ・キャッシュに対してのみ有効になります。ライトスルー・フラッシュ・キャッシュでは、セカンダリ・ミラー・キャッシュは実行されません。

最小要件:

Oracle Exadata System Softwareリリース19.1.0
大容量ストレージ・サーバー上のExadataライトバック・フラッシュ・キャッシュ
Exadata Database Machine X6以上(フラッシュ・キャッシュ・サイズの要件のため)

個別ネットワーク上のホストおよびILOMのサポート

以前は、Oracle Exadata System Softwareでのアラート通知など特定の機能を使用するために、ExadataサーバーおよびIntegrated Lights Out Manager (ILOM)が同じ管理ネットワークを使用する必要がありました。Oracle Exadata System Softwareリリース19.1.0以降では、以前サポートされていたすべての機能を維持したまま、このネットワーク依存関係がなくなります。

この機能を利用してILOM用に別のネットワークを構成すれば、ExadataサーバーおよびILOMが相互に完全に分離されるため、セキュリティが向上します。

Oracle Exadata Database Machineインストレーションおよび構成ガイドのILOM用の個別ネットワークの構成に関する項を参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

関連トピック

「ネットワーク要件の概要」

DB_UNIQUE_NAMEでExadataストレージを共有する複数クラスタをサポート

同じストレージを共有するデータベースに対して、同じDB_UNIQUE_NAME値を使用できるようになりました。この機能により、同じストレージ・セルを共有するOracle Multitenantクラスタ・データベースが同じDB_UNIQUE_NAMEを持つことができます。

以前のリリースでは、複数のクラスタがExadataストレージを共有できるのは、各インスタンスのDB_UNIQUE_NAME値がすべてのクラスタでグローバルに一意である場合にだけでした。Oracle Exadata System Softwareリリース19.1.0では、各クラスタに独自のDB_UNIQUE_NAMEネームスペースを設定できます。つまり、異なるクラスタ間で同じDB_UNIQUE_NAME値を使用できるということです。たとえば、以前のリリースでは、cluster1およびcluster2は、DB_UNIQUE_NAMEパラメータをdb1に設定したデータベースを1つ(cluster1またはcluster2)しか持てませんでした。このリリースでは、各クラスタでASMスコープのセキュリティを構成すれば、DB_UNIQUE_NAMEパラメータをdb1に設定したデータベースを両方のクラスタが持つことができます。

この機能により、Exadataストレージを共有する異なるクラスタが、DB_UNIQUE_NAME割当てを調整して名前の競合を回避する必要がなくなります。各クラスタでは、クラスタごとにASMスコープのセキュリティを構成しているかぎり、他のクラスタと調整することなく、任意のDB_UNIQUE_NAME値を選択できます。

ASMスコープのセキュリティが構成されている場合、ASMクラスタ名を使用して、ストレージ・サーバーにアクセスする際のDB_UNIQUE_NAMEを修飾します。各データベースについて収集されるメトリックと統計は、I/Oリソース管理(IORM)、フラッシュ・キャッシュ、セルのオフロードなど様々な領域で、asmcluster.database名修飾も使用します。

警告:

同じDB_UNIQUE_NAMEを持つように複数のデータベースを構成する場合、そのデータベースをOracle Zero Data Loss Recovery Applianceにバックアップできません。各データベース・インスタンスのDB_UNIQUE_NAMEは、Oracle Zero Data Loss Recovery Applianceのスコープ内で一意である必要があります。

最小要件:

Oracle Exadata System Softwareリリース19.1.0
DB_UNIQUE_NAMEが等しい各データベースは、異なるOracle ASMクラスタに存在する必要があります。
Oracle ASMクラスタごとに構成されたASMスコープのセキュリティ

関連トピック

Secure Eraserの更新

Oracle Exadata System Softwareリリース19.1.0では、Secure Eraserが様々な点で改善されました。

マルチパス・ディスク消去からSecure Eraserへの自動アップグレード

1パス、3パスまたは7パスのメソッドを使用してディスクを消去するように指定した場合、Oracle Exadata System Softwareは、基礎となるハードウェアでサポートされていれば自動的に最適なSecure Eraserメソッドを使用します。

ディスクが大きくなればなるほど、従来のマルチパス上書きメソッド(1パス、3パス、7パスなど)は、Secure Eraserで使用される消去メソッドよりも完了までに時間がかかるようになります。たとえば10TBのハード・ドライブになると、7パス消去に4日以上かかることもありますが、Secure Eraserを使用すれば、わずか1分です。サポートされているハードウェアと推定消去時間については、データベース・サーバーおよびストレージ・サーバーの安全な消去を参照してください。

ディスクでサポートされていれば、Secure Eraserを使用する方が高速で安全です。DROP CELLおよびDROP CELLDISKで使用されるSecure Eraserメソッドは、Secure Eraser機能のものと同じであり、NIST SP-800-88r1標準に準拠しています。

詳細は、DROP CELLおよびDROP CELLDISKを参照してください。

最小要件:

Oracle Exadata System Software 19.1.0
Oracle Exadata Database Machine X5-2以上

イメージ化の一部として自動実行されるSecure Eraser

Oracle Exadataラックを転用する際は通常、最初にOracle Exadata System Softwareリリース12.2.1.1.0で導入されたSecure Eraser機能を使用してデータを消去し、その後必要なOracle Exadata Database Machineイメージでラックを再イメージ化するという2つの部分からなるプロセスです。

Oracle Exadata System Softwareリリース19.1.0以降、ハードウェアがSecure Eraserをサポートしている場合、Secure Eraserは再イメージ化中に自動的に起動されます。これにより、パフォーマンスを維持しながら再イメージ化する手順が大幅に簡略化されます。ラックを転用する場合は、ラックをイメージ化するだけで、プロセスの一環として安全なデータ消去が透過的に行われます。

詳細は、Oracle Exadata Database Machineセキュリティ・ガイドの安全な消去の概要を参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0
Oracle Exadata Database Machine X5-2以上

Secure Eraserの改善および新機能

このリリースでは、次の新機能およびコマンド・オプションがSecure Eraserに追加されました。

証明書のタイムスタンプにタイムゾーンが含まれるようになりました
データ・ディスクのみを消去し、システム・ディスクを除外するオプション(--erase_data_only)
個々のデバイスの消去をサポート(--devices_to_erase)

詳細は、Oracle Exadata Database Machineセキュリティ・ガイドのSecureEraser構文を参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0
Oracle Exadata Database Machine X5-2以上(暗号消去用)

サーバー時刻同期化でchronyを使用

Oracle Exadata System Softwareリリース19.1.0以降、Oracle Linux 7を実行しているExadataデータベース・サーバーおよびストレージ・サーバーはntpdを使用できなくなりました。かわりに、chronyを使用してサーバーのシステム・クロックをNTPサーバーと同期します。chronyは通常、ntpdより高速かつ高精度でシステム・クロックを同期できます。

Oracle Linux 6からOracle Linux 7にアップグレードすると、NTPサーバー設定がchronyに移行されます。

Oracle Linux 7で動作保証されているOracle Grid InfrastructureおよびOracle Databaseリリースもすべて、chronyをサポートしています。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

関連トピック

https://chrony.tuxfamily.org/comparison.html

Quorumディスク・マネージャ・サービスの変更

Oracle Linux 7を実行しているOracle Exadata Database Machineデータベース・サーバーおよびストレージ・サーバーは、Exadata Quorumディスク・マネージャのtgtdサービスのかわりにtargetサービスを使用します。

Oracle Linux 6からOracle Linux 7へのアップグレード中に、Quorumディスク・マネージャを使用するOracle Exadata Database Machineデータベース・サーバーは、基礎となる新しいtargetサービスを使用するよう移行されます。移行はローリング方式で実行できます。Quorumディスク・マネージャの管理インタフェースは同じままで、Oracle Linux 7へのアップグレード後に変更が必要な場合に使用できます。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

関連トピック

Quorumディスク管理の概要

監査ルール・ファイル

Exadataデータベース・サーバー上のOracle Linux 6からOracle Linux 7へのアップグレード中に、Oracle Linux 6監査設定が移行され、監査ファイル01-exadata_audit.rulesに移動されます。Oracle Exadata Database Machineに固有でないルールは、アップグレード中に移行されません。これらのルールは個別に再構成する必要があります。Oracle Exadata Database Machineに固有でないルールのカスタム監査ルール・ファイルを作成して確保しておくことをお薦めします。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドのOracle Exadata Storage Serverでのオペレーティング・システム・アクティビティの監視に関する項を参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

カスタマイズ可能なSYSLOGフォーマット

新しいセルおよびデータベース・サーバー属性syslogFormatを使用して、標準のsyslogフォーマットを任意のフォーマットに変更できます。

この属性を設定すると、管理サーバー(MS)は、指定されたフォーマット文字列を含むように/etc/rsyslog.confファイルを変更し、syslogデーモンを再起動します。syslogFormatを空の文字列に設定すると、フォーマット変更が削除され、デフォルト・フォーマットがリストアされます。

詳細は、Oracle Exadata System Softwareユーザーズ・ガイドのALTER CELL、またはOracle Exadata Database Machineメンテナンス・ガイドのALTER DBSERVERを参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

セキュリティの改善

Oracle Exadata System Softwareリリース19.1.0では、様々なセキュリティ改善が導入されました。

RESTfulサービスのアクセス制御

Oracle Exadata System Softwareリリース19.1.0以上では、Exadata RESTfulサービスへのHTTPsアクセスでユーザーがアクセス制御リストを構成できる新しい機能が導入されています。ユーザーは、IPアドレスまたはIPサブネット・マスクのリストを指定して、HTTPsを介してRESTfulサービスにアクセスできるユーザーを制御できます。または、RESTfulサービスが使用されていない場合、ノードへのHTTPsアクセスの無効化を選択できます。この機能は、Oracle Exadata Database ServerとOracle Exadata Storage Serverの両方に適用されます。

詳細は次のトピックを参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

リモート・ユーザーのパスワードの有効期限

Exadata RESTfulサービスへのアクセスまたはExaCLIを使用するリモート・ユーザーのパスワード有効期限を構成できるようになりました。Exadataサーバーでは、パスワード有効期限を構成し、失効したユーザーがパスワードをリモートで変更できるかどうかを構成する属性を設定できます。追加属性を設定すると、パスワードが期限切れになる前の警告期間の長さと、ユーザー・アカウントがロックされる期限切れまでの時間を指定できます。

注意:

この機能はリモート・ユーザーにのみ適用され、celladminやoracleなどのオペレーティング・システム・ユーザーには適用されません。

これらの属性がサーバーで設定されている場合、ユーザーが有効期限の切れたパスワードでアカウントに接続しようとすると、次の2つのいずれかが発生します。

サーバーがリモートでのパスワード変更を許可するように構成されている場合、ユーザーはただちにパスワードを変更するよう求められます。
サーバーがリモートでパスワードを変更できない場合、パスワードが期限切れであることを示すエラーが表示され、パスワードを変更するには支援が必要になります。

詳細は次のトピックを参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

Advanced Intrusion Detection Environment (AIDE)

Oracle Exadata System Softwareリリース19.1.0では、Exadataシステム上のファイルへの不正アクセスを防止するために、Advanced Intrusion Detection Environment (AIDE)のサポートが追加されました。AIDEは、システムに対する悪質な改変または計画外の変更をレポートするセキュリティ機能です。AIDEは、システム上にファイルのデータベースを作成し、そのデータベースを使用してファイルの整合性を確認してシステム侵入を検出します。

詳細は次のトピックを参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0
Oracle Linux 7

セキュリティ向上のための最小権限の原則の実装

セキュリティのベスト・プラクティスでは、タスクの実行に必要な最小限の権限で各プロセスを実行する必要があります。次のプロセスは、権限のないユーザーとして実行されるようになりました。

スマート・スキャン・プロセス

rootユーザー権限を使用して実行するために使用されるOracle Exadata Storage Serverでスマート・スキャンを実行するプロセス。条件評価の実行にroot権限は必要ありません。Oracle Exadata System Softwareリリース19.1.0以降、これらのスマート・スキャン・プロセスはcelloflと呼ばれる新しいオペレーティング・システム・ユーザーによって所有されます。Oracle Exadata System Softwareリリース19.1.0へのソフトウェア更新を実行すると、ユーザーcelloflおよびグループcelltraceが自動的に作成されます。
ExaWatcherプロセスの選択

ExaWatcherインフラストラクチャは、Oracle Exadata Database ServerとOracle Exadata Storage Serverの両方でシステム統計を収集およびアーカイブします。iostat、netstat、ps、topなどの情報を収集するコマンドの一部は、rootユーザー権限なしで実行できるように変更されました。Oracle Exadata Storage ServerおよびOracle Exadata Database Serverと、Oracle Exadata Database Serverで実行されている仮想マシンでソフトウェア・アップデートを実行すると、新しいオペレーティング・システム・ユーザーexawatchおよびグループexawatchが自動的に作成されます。

これらの変更の結果、rootユーザーとして実行されるプロセスの数が著しく減少するため、Oracle Exadataサーバーのセキュリティが向上します。

この機能は、Oracle Exadata System Softwareリリース19.1.0へのソフトウェア更新を実行すると自動的に有効になります。追加の構成は不要です。

詳細は次のトピックを参照してください。

ストレージ・サーバー・プロセスのセキュリティの向上

Oracle Linuxカーネルでのセキュアなコンピューティング(seccomp)機能を使用すると、プロセスから実行できるシステム・コールを制限できます。

Oracle Linuxカーネルには数百のシステム・コールがありますが、ほとんどのプロセスでは必要ありません。seccompフィルタは、システム・コールが許可されるか制限されるかを定義します。seccompフィルタがセル・サーバーにインストールされ、アップグレード時にはセル・オフロード・サーバー・プロセスが自動的にインストールされます。ホワイトリストに設定されたシステム・コールは、セル・サーバーおよびセル・オフロード・サーバーから実行できます。ホワイトリストされた特定のシステム・コールの場合、seccompフィルタは引数の追加検証を実行します。

seccompフィルタを使用すると、セル・プロセスのセキュリティ・レベルが向上します。この機能は、Oracle Exadata System Softwareリリース19.1.0で自動的に有効になります。

関連トピック

Oracle Linuxコンテナのセキュリティ・ブログ

SSHD ClientAliveIntervalを600秒に変更

ClientAliveIntervalパラメータを使用すると、非アクティブな期間(秒単位で指定)の経過後にSSHクライアントが自動的にタイムアウトします。指定された時間制限に達したときに、クライアントからデータが受信されなかった場合、SSHDは暗号化されたチャネルを介してメッセージを送信し、クライアントからのレスポンスをリクエストします。サーバー側からレスポンスが受信されない場合、接続は破棄されます。以前のClientAliveIntervalはストレージ・サーバーで2時間、データベース・サーバーでは24時間に設定されていました。patchmgrから行われたdcliコールがタイムアウトしないように、これらには大きい値が必要でした。

patchmgrユーティリティも変更されています。patchmgrから行われたdcliコールは、実行時パラメータを使用してタイムアウト制限を延長します。こうすると、サーバーから10分以上通信がない場合でも、コールはタイムアウトしなくなります。

オペレーティング・システムのバックアップを行う場合など、データベース・サーバーに長時間の接続の実行が必要な場合は、/etc/ssh/sshd_configファイルでClientAliveIntervalに対してより大きな値を指定できます。変更を有効にするには、SSHサービスを再起動する必要があります。長時間実行する操作が完了したら、ClientAliveIntervalに対する変更を削除して、SSHサービスを再起動する必要があります。

パスワード要件の強化

データベース・サーバーおよびストレージ・サーバーでオペレーティング・システム・ユーザーを作成する場合、新しいExadataデフォルト・パスワード・ポリシー・ルールは次のとおりです。

文字の最小数: 8
数字の最小数: 1
小文字の最小数: 1
大文字の最小数: 1
特殊文字の最小数: 1
連続繰返し文字の最大数:3
同じクラスの連続繰返し文字の最小数:4
異なる数字の最小数: 8
パスワード変更の最小日数:1
パスワード変更の最大日数:60
辞書の単語が無効または受け入れられません。
直前に使った10個までのパスワードは再使用できません

注意:

Oracle Exadata System Softwareリリース19.1.0に新しい制限が追加される前に作成されたパスワードは、問題なく機能します。SSH等価を使用する場合、違いはありません。

詳細は次のトピックを参照してください。

最小要件:

Oracle Exadata System Softwareリリース19.1.0

HTTPsを使用してDIAGPACKをOracle ASRマネージャにアップロード

セキュリティを強化するために、HTTPsを使用して診断パッケージをアップロードするために、管理サーバー(MS)およびOracle ASRマネージャを構成できます。

詳細は、ASRの自動DiagPackアップロードの有効化を参照してください。

Oracle Exadata System Softwareリリース19.1.0で非推奨となった機能

次の機能は、このリリースでは非推奨であり、将来のリリースではサポートされなくなる可能性があります。

インターリーブ・グリッド・ディスクが非推奨に

グリッド・ディスクのインターリーブ・オプションは非推奨になりました。インターリーブ・グリッド・ディスクを作成しようとすると、自動的に通常のグリッド・ディスク作成に変換されます。

Oracle Exadata System Softwareリリース19.1.0より前に作成したインターリーブ・グリッド・ディスクは、以前のリリースと同様に機能します。

nfsimgイメージが非推奨に

Oracle Exadata System Softwareリリース19.1.0以降、Oracle Exadata Database Machineサーバーをイメージ化または再イメージ化する場合、NFSイメージは非推奨になりました。PXEオプションは、NFSイメージ・ファイルではなく、ISOイメージ・ファイルで使用します。

Secure Eraserパッケージ(secureeraser_label.zip)には、Oracle Exadata System Softwareリリース19.1.0以降、NFSイメージではなくISOイメージも含まれています。

この変更を反映するために、ドキュメントの該当セクションが更新されています。

Oracle Exadata Database Machineインストレーションおよび構成ガイドの新しいシステムのイメージ化には、更新されたイメージ化の手順が記載されています。
Oracle Exadata Database Machineセキュリティ・ガイドのOracle Exadata Database Machineの安全な消去には、更新されたSecure Eraserの手順が記載されています。

Oracle Exadata System Softwareリリース19.1.0でサポートが終了した機能

Oracle Exadata V2は、Oracle Exadata System Softwareリリース19.1.0以降、動作保証されなくなりました。現在の動作保証情報は、Exadata System Softwareの動作保証(My Oracle SupportDoc ID2075007.1)にあります。