Autonomous Recovery Serviceのチェックリスト (2025/12/01)

Autonomous Recovery Serviceのチェックリスト (2025/12/01)

https://blogs.oracle.com/infrastructure/autonomous-recovery-service-checklist

投稿者：Bryan Grenn | Database, Infrastructure & Cloud Solutions Architect

OCI (またはマルチクラウド) 内の Oracle Databaseに Autonomous Recovery Service を利用するのが、Oracle Databaseをバックアップする最適な方法です。

Recovery Service を構成するためのドキュメントは、ここ にあります。

 このブログ投稿では、このサービスを正常に実装するために必要な手順について説明します。

まず、バックアップを構成するお客様でよく見られる問題は、Autonomous Recovery Service のネットワーク ポートを開くことです。

Autonomous Recovery Service 用に構成する必要があるポートが 2 つあります。

  • 2484 – このポートは、Autonomous Recovery Service によって使用される RMAN カタログへの SQL*Net 接続に使用されます。
  • 8005 – このポートはバックアップピース自体に使用されます

これらのセキュリティ ルールは、セキュリティ リストまたは NSG を使用して構成できます。

セキュリティ リストは実装が最も簡単なため、OCI でホストされているデータベースをバックアップするときに推奨される方法です。

NSGは通常、マルチクラウド環境でデータベースをバックアップする際に使用されます。マルチクラウド環境では、多くのNSGが自動的に作成されます。

 以下は、開始するための手順のチェックリストです。

まず、OCI ネイティブ データベース (セクション 1) またはマルチクラウド データベース (セクション 2) のいずれかの手順を完了してから、共通の手順に進みます。

 

セクション1 – OCIネイティブデータベース 

 

1.1 データベースのバックアップ用のセキュリティリストを作成する

セキュリティリストは最も使いやすく、Recovery Serviceサブネットのトラフィックを制御できます。宛先ポート8005と2484を許可するステートフルイングレスルールを含める必要があります。

セキュリティリストのセキュリティルールのチェックリスト

1. ルール1 – イングレス。データベースVCN内からのHTTPSバックアップトラフィックを許可する

  • ステートレス: いいえ (すべてのルールはステートフルである必要があります)
  • ソースタイプ: CIDR
  • ソース CIDR  : データベースが存在する VCN の CIDR
  • IPプロトコル:  TCP
  • 送信元ポート範囲: すべて
  • 宛先ポート範囲: 8005

2. ルール2 – イングレス。データベースVCN内からのSQLNetトラフィックを許可する

  • ステートレス: いいえ (すべてのルールはステートフルである必要があります)
  • ソースタイプ: CIDR
  • ソース CIDR  : データベースが存在する VCN の CIDR
  • IPプロトコル:  TCP
  • 送信元ポート範囲: すべて
  • 宛先ポート範囲: 2484

 

注意: VCNでサブネット間のネットワークトラフィックが制限されており、バックアップ専用のサブネットを使用している場合は、データベースサブネットから作成するRecovery Serviceサブネットへのポート2484および8005に対するエグレスルールを必ず追加してください。トラフィックは、VCN内で登録されているすべてのRecovery Serviceサブネットに流れ込む必要があります。

以下は、私の VCN の構成の例です (この例では、CIDR ブロックは 10.1.0.0/16 です)。  

注: セキュリティリストをVCN CIDRブロック全体に設定しました。これにより、VCN内の任意のサブネットからのバックアップトラフィックが許可されます。VCN内の単一のサブネットへのトラフィックを制限したい場合は、CIDRブロックをAutonomous Recovery Serviceに登録されているサブネット（デフォルトのバックアップサブネットを含む場合があります）のみに限定することができます。ただし、他のサブネットや追加のサブネットを使用するように移行する場合は、セキュリティリストを適切に調整する必要があります。

 

セキュリティリスト

 

Autonomous Recovery Service は、利用されているデータベース サービスに基づいて、デフォルトのバックアップ サブネットを自動的に使用して登録します。

  • Exadata Databaseサービスでは、バックアップサブネットはAutonomous Recovery Serviceに使用されます。
  • Base Databaseサービスでは、データベースサブネットは自律回復サービスにも使用されます。

注: 多数のデータベースをバックアップする場合、またはデフォルトのバックアップサブネット内で使用されるCIDRブロックで利用可能なIPアドレスが少ない場合は、サービス用に別のサブネットを作成することを検討してください。これは、最後のオプションセクションで説明されています。

1.2 バックアップサブネットにセキュリティリストを割り当てる

以下は、Base Database サービスに使用しているネットワークであるサブネット「dbsubnet」のスクリーンショットです。

セキュリティ セクションのこのサブネットに、「Recovery Service」という名前のセキュリティ リストを追加しました。

 

セキュリティリストを追加

 

1.3 Autonomous Recovery ServiceサブネットがOracle Services Networkにルーティングできることを確認する

デフォルト・リカバリ・サービス・サブネットのルーティング・ルールに、Oracle Servicesネットワークへのルートが含まれていることを確認してください。以下は、私が設定してサブネットにアタッチしたルーティング・ルールのスクリーンショットです。ルーティング・ルールに含めるサービス・ゲートウェイは以前に作成済みです。

 

ルーティングルール

​

セクション2 – マルチクラウドデータベース 

 

注: 現時点では、新しい AWS マルチクラウド環境にはいくつかの自動化が事前に準備されており、AWS をパートナークラウドとして使用する場合はいくつかの手順をスキップできます。

  •  新しいNSGを使用してRecovery Serviceサブネットを作成します
  • 新しいNSGを使用してRecovery Serviceサブネットを作成します
  • NSGのルールを設定する
  • サブスクリプションに必要なIAMポリシーを追加します

2.1 Recovery Service用のネットワーク セキュリティ グループ (NSG) を構成する 

 マルチクラウドでは、VCNを作成するとデフォルトのNSGが既に作成されています。この戦略を継続し、リカバリサービス用のNSGを作成することをお勧めします。

ネットワーク セキュリティ グループは、Recovery Service サブネットのトラフィックを制御し、イングレス ポート 8005 および 2484 を許可するステートフル イングレス ルールを含める必要があります。

NSGのセキュリティルールのチェックリスト

1. ルール1 – イングレス。データベースVCN内からのHTTPSバックアップトラフィックを許可する

  • ステートレス: いいえ (すべてのルールはステートフルである必要があります)
  • ソースタイプ: CIDR
  • ソース CIDR  : データベースが存在する VCN の CIDR
  • IPプロトコル:  TCP
  • 送信元ポート範囲: すべて
  • 宛先ポート範囲: 8005

2. ルール2 – イングレス。データベースVCN内からのSQLNetトラフィックを許可する

  • ステートレス: いいえ (すべてのルールはステートフルである必要があります)
  • ソースタイプ: CIDR
  • ソース CIDR  : データベースが存在する VCN の CIDR
  • IPプロトコル:  TCP
  • 送信元ポート範囲: すべて
  • 宛先ポート範囲: 2484

 

注意: VCN がサブネット間のネットワーク トラフィックを制限していて、デフォルトのサブネットを使用していない場合は、データベース サブネットから、作成する Recovery Service サブネットにポート 2484 および 8005 の出力ルールを必ず追加してください。

以下は、私の VCN の構成の例です (CIDR ブロックは 10.1.0.0/16 であることに注意してください)。  

注: NSG を VCN CIDR ブロック全体に設定しました。これにより、VCN 内の任意のサブネットからのバックアップトラフィックが許可されます。VCN 内の単一のサブネットへのトラフィックを制限したい場合は、CIDR ブロックを Autonomous Recovery Service に登録されているサブネット（デフォルトのバックアップサブネットを含む場合があります）のみに限定することができます。ただし、他のサブネットや追加のサブネットを使用するように移行する場合は、NSG を適切に調整する必要があります。

バックアップVCN
キャプション

以下は、Autonomous Recovery Service サブネットに使用するために作成した NSG です。

 

NSGマルチクラウド

 

2.2 Autonomous Recovery Serviceサブネットを登録する  

Autonomous Recovery Service は、利用されているデータベース サービスに基づいて、デフォルトのバックアップ サブネットを自動的に使用します。

  • Exadata Databaseサービスでは、バックアップサブネットはAutonomous Recovery Serviceに使用されます。
  • Base Databaseサービスでは、データベースサブネットはAutonomous Recovery Serviceにも使用されます。

注: 多数のデータベースをバックアップする場合、またはデフォルトのバックアップサブネットとして使用されているCIDRブロックで利用可能なIPアドレスが少ない場合は、サービス用に別のサブネットを作成することを検討してください。これは、最後のオプションセクションで説明されています。

バックアップにデフォルトのネットワークを使用している場合は、このサブネットを登録します。それ以外の場合は、Autonomous Recovery Service サブネットとして識別したサブネットを登録することになります。

以下は、バックアップ サブネットを登録する場所を示す画面です。

 

サービスサブネットの回復

 

2.3 NSGをRecovery Serviceサブネットに登録する

Recovery Service サブネットを登録する際には、サブネットと併せて NSG も登録してください。以下のスクリーンショットは、サブネットに関連付けられた NSG が Recovery Service に登録されている様子を示しています。

 

リカバリサービスサブネットにNSGを登録する

 

2.4 バックアップを保存する場所を決める

マルチクラウド環境で作成されたバックアップは、デフォルトでデータベースがホストされているOCIリージョンに保存されます。データベースのバックアップをOCIに保存する場合は、デフォルトの保護ポリシーを使用できます。

Autonomous Recovery Service のバックアップを、データベースがホストされているのと同じクラウド プロバイダーに保存する場合は、カスタム保護ポリシーを作成する必要があります。

以下はカスタム保護ポリシーの作成例です。画面下部には、データベースと同じクラウドプロバイダーにバックアップを保存するオプションが表示されています。この設定を変更してカスタムポリシーを作成してください。バックアップを設定する際は、データベースがこのカスタムポリシーに基づいて設定されていることを確認してください。

マルチクラウドポリシー

 

セクション3 – OCIとマルチクラウドデータベースの共通手順

 

 3.1 テナンシーのリソース制限が適切であることを確認する（該当する場合はマルチクラウドを含む）

 Recovery Service を実装する前に、まず、データベースがテナンシー内に存在するリージョンのリソース設定を確認する必要があります。「リカバリウィンドウに使用する領域 (GB)」と「保護対象データベース数」が、サービスの利用対象となるデータベースの数とバックアップサイズに対応していることを確認してください。

注意: 有料のテナントの場合、テナントにデフォルトの制限が設定されています。

  • 保護されたデータベース 10 個
  • 10 TBのストレージ

これらにより、いくつかの小さなデータベースに対してサービスを活用できるようになります。

以下は、Autonomous Recovery Service のコンソールに表示される内容です。これは私のテナンシーのスクリーンショットで、US-EAST-1 リージョンの制限が表示されています。お客様のテナンシーでは、各リージョンの現在の制限、現在の使用量、利用可能なリソースを確認できます。ルートコンパートメントを確認すると、そのリージョン内のテナンシー全体の制限と使用量が表示されます。

制限

 

テナンシーの上限を引き上げる必要がある場合は、  引き上げたい上限の右側にある3つの点をクリックしてください。「サポートリクエストを開く」という選択肢が表示されます。「サポートリクエストを開く」を選択すると、テナンシーの上限の引き上げをリクエストできるウィンドウが表示されます。

注：3つのドットをクリックして「クォータポリシースタブを作成」をクリックすると、2つ目の選択肢が表示されます。表示されるスタブを使用して、特定のコンパートメントのクォータを制限できます。例えば、「dev」コンパートメントの使用量を制限し、本番環境での容量を制限内に確保したい場合などに使用できます。

 

マルチクラウドの制限 ：マルチクラウド環境でAutonomous Recovery Serviceを構成する際は、マルチクラウドサブスクリプションのリソース制限を確認し、変更をリクエストする必要があります。上記の「制限、クォータ、使用量」には「サブスクリプション」も選択可能で、マルチクラウドサブスクリプションを選択して、サブスクリプションの制限を調整できます。

以下に、マルチクラウド環境での制限のサブスクリプション セクションが表示される場所を示します。

マルチクラウドの制限

 

3.2 テナンシーのポリシーを構成する 

 

リカバリサービスのポリシーを追加する際は、ポリシービルダーを使用することをお勧めします。これにより、適用可能な最新のポリシーを確実に設定できます。

以下はこれを行う方法を示す画面です

ポリシーを追加するときは、ポリシーの下で「Autonomous Recovery Service」を選択する必要があります。

次に、「共通ポリシーテンプレート」で、環境に適したテンプレートを選択します。

注意: マルチクラウドを使用する場合は、パートナーのクラウド ホスティング環境に適切なポリシーを選択してください。

DB@AWSを使用しており、AI World 2025の前にAWSテナンシーをOCIテナンシーとペアリングしていた場合は、以下のポリシーを設定する必要があります。 

Allow service database to use organizations-assigned-subscription in tenancy where target.subscription.serviceName = 'ORACLEDBATAWS'

ポリシービルダー

グループを割り当てた後にポリシーを作成します。

 

3.3 データベースリリースでAutonomous Recovery Serviceがサポートされていることを確認する

次の Oracle Database リリースでプロビジョニングされた Oracle Cloud データベースのバックアップ先として、Oracle Database Autonomous Recovery Service を使用できます。

Oracle Databaseのエディションとバージョン詳細情報

Oracle Database 19c リリース 16 (19.16) 以降

リアルタイム データ保護機能を使用するには、データベースに次のものをプロビジョニングする必要があります。

Oracle Database 19c リリース 18 (19.18) 以降

Oracle Database 21c リリース 7 (21.7) 以降

リアルタイム データ保護機能を使用するには、データベースに次のものをプロビジョニングする必要があります。

Oracle Database 21c リリース 8 (21.8) 以降

Oracle Database 23ai/26ai

リアルタイム データ保護機能を使用するには、データベースに次のものをプロビジョニングする必要があります。

Oracle Database 23aiリリース4（23.4）以降

 

 

 3.4 COMPATIBLE初期化パラメータが最新であることを確認する

Autonomous Recovery Service を使用するには、COMPATIBLE パラメータを 19.0.0 以上に設定する必要があります。このパラメータは通常、アップグレードプロセス中に更新されないため、十分に高い値に設定されていることを確認することが重要です。

正しく設定されていない場合に表示されるメッセージの種類を以下に示します。

データベースジョブ: 失敗。DBAAS-10327: 最低限必要な COMPATIBLE バージョンは 19.0.0 です。現在のデータベース COMPATIBLE バージョンは 12.1.0.2.0 です。

 

3.5 データベースにTDEが完全に構成されていることを確認する

Autonomous Recovery Service を使用する場合、データベースを完全に TDE で暗号化する必要があります。クラウドで作成された新しいデータベースの場合は、既に暗号化されているはずです。ただし、OCI でスタブデータベースを作成し、オンプレミスなどから Oracle Database Service にデータベースを移行する場合は、すべての条件を満たしていない可能性があります。これらのデータベースについては、Recovery Serviceへのバックアップの前提条件を満たしていることを確認する必要があります。実行するクエリで確認すべき事項については、こちらのブログ記事をご覧ください。

大まかに言うと、次の 3 つの基準を満たす必要があります。

  • データベースにWALLET_ROOTを設定する必要があります。sqlnet.oraをまだ使用している場合は、ツール（下記参照）を使用して、リカバリサービスを利用するすべてのデータベースのWALLET_ROOTを適切に設定する必要があります。 注：sqlnet.oraでのENCRYPTION_WALLET_LOCATIONの設定はサポートされておらず、廃止される予定です。
  •            dbaascli tde enableWalletRoot – 既存のデータベースのwallet_root spfileパラメータを有効にします。
  • データベース内の CDB およびすべての PDB に暗号化キーを設定する必要があります。
  • 最初のバックアップを実行する前に、すべての表領域を TDE で暗号化する必要があります。

クリップボードにコピーされました
エラー: コピーできませんでした
クリップボードにコピーされました
エラー: コピーできませんでした
<tt>           Usage: dbaascli tde enableWalletRoot --dbname <value> [--dbRestart <value>] [--precheckOnly] 
                     Where:
                          --dbname - Oracle database name.
                          [--dbRestart - database restart option. Valid values : full|rolling ]
                          [ --precheckOnly - run the prerequisite checks and report the results. ]
                          [--resume - to resume the previous operation]

           <big><strong> NOTE: In order for this change to take effect you need to have a restart of the database. The default is a rolling bounce of the database.
</strong></big></tt>

 

 

3.6 手動の運用バックアップをオフにする

OCIユーザーは、手動でオペレーションバックアップを実行している場合があります。これは、ツールの外部で実行され、ポイントインタイムリカバリ（非KEEPバックアップ）をサポートするバックアップです。

これらの種類の運用バックアップを実行している場合は、この時点で必ず停止してください。2つの異なる場所に運用バックアップを実行すると、両方のバックアップで問題が発生する可能性があります。

注意: オブジェクト ストレージ バックアップ用のツールを使用していて、Recovery Service に切り替える場合、切り替えはツールによって自動化され、以前のバックアップはすべて引き続き利用可能になります。

 

3.7 クラウドプロバイダーのDNSエントリが解決されることを確認する 

このAutonomous Recovery Serviceはエンドポイントを使用し、クラウド内のDNSエントリがそれらのエンドポイントに割り当てられます。DNS解決をカスタマイズしていて、クラウドのDNSエントリも解決されていない場合、Recovery Serviceがバックアップジョブを実行する際にエラーが発生する可能性があります。ホスト名の解決時にTNSエラーが発生する場合は、DNS設定を確認し、クラウドのエントリが解決可能であることを確認してください。

Autonomous Recovery ServiceがDNSエントリを解決できない場合、tnsping実行時に以下のエラーが表示されます。このエラーが発生した場合は、DBホストのプライベートDNSリゾルバが使用されていることを確認する必要があります。このエラーは、/etc/resolve.confファイルでデフォルトのDNSリゾルバが169.254.169.254から変更された場合によく発生します。IPアドレス169.254.169.254は、VCN内のプライベートDNSリゾルバを自動的に指します。Cloud Protectを使用している場合、または別のプライマリDNSリゾルバを使用している場合は、プライベートDNSリゾルバ用のプライベートエンドポイントIPアドレスを作成し、そのエンドポイントIPアドレスにDNSを転送する必要があります。Autonomous Recovery Serviceでは、VCNのプライベートDNSリゾルバを使用する必要があります。

tnsping dbrs

TNS-12545: Connect failed because target host or object does not exist

セクション4 – オプション

 

 4.1 Autonomous Recovery Service用のサブネットを作成する（オプション） 

Autonomous Recovery Service は、利用されているデータベース サービスに基づいて、デフォルトのバックアップ サブネットを自動的に使用します。

  • Exadata Databaseサービスでは、バックアップサブネットはAutonomous Recovery Serviceに使用されます。
  • Base Databaseサービスでは、データベースサブネットはAutonomous Recovery Serviceにも使用されます。

注意: 大量のデータベースをバックアップする場合や、デフォルトのバックアップ サブネットとして使用される CIDR ブロックで使用可能なデータベースの数が少ない場合は、サービス用に別のサブネットを作成することを検討する必要があります。

Auonomous Recovery Serviceは、プライベートエンドポイントを使用して、データベースとRecovery Service間のバックアップトラフィックを制御します。アーキテクチャは以下のとおりです。

リカバリサービスアーキテクチャ

 

バックアップ用に別のサブネットを作成する手順。

各 Recovery Serviceのプライベート サブネットは、データベースが存在する VNC 内に作成する必要があります。    

注: パブリック サブネットを使用することもできますが、セキュリティ上の理由から推奨されません。 

サブネットの推奨サイズは/24（IPアドレス256個）です。新しいサブネットを作成することも、データベースのVCNに既に存在するサブネットを使用することもできます。このサブネットはIPv4である必要があります。

以下は、専用の Recovery Service サブネットのスクリーンショットです。 

リカバリサービスサブネット

補足

必要な空き IP アドレスの数や、複数のサブネットが可能かどうかなど、多くの質問が寄せられています。

  • IPアドレスがRecovery Serviceに割り当てられる際、それらはIPアドレスの「チャンク」として割り当てられます。これは、データベースリスナーやスキャンリスナーの場合と同様です。現時点では、1つのチャンクは6つのIPアドレスで構成されますが、これらのIPアドレスは必ずしも同じサブネット内に存在する必要はなく、重複している必要もありません。「チャンク」のサイズ（チャンク内のIPアドレスの数）は、将来のリリースで変更される可能性があることにご注意ください。
  • 必要な「チャンク」の数はRecovery Serviceによって管理され、サービスが時間の経過とともにバックアップの場所を動的に管理するにつれて変化する可能性があります。
  • 必要な「チャンク」の数は、新しいデータベースを追加するときにのみ増加します。次のチャンクを割り当てるのに十分な空きIPアドレスがない場合、新しいデータベースの追加は失敗し、空きIPアドレスを追加するように警告が表示されます。
  • サブネットを追加することで、Recovery Service に IP アドレスを追加できます。複数のサブネットを使用できますが、サブネットはパブリックにルーティング可能である必要があります。
  • サブネットを削除すると、その IP アドレスは他の既存のサブネットに移動されます。
  • 利用可能な IP アドレスが限られている場合は、少なくとも 32 個の IP アドレスを許可する /27 CIDR から始めることをお勧めします。 

 

 

 

 

 

簡単なチェックリスト

セクション1 – OCIネイティブデータベース

   データベースのバックアップのセキュリティリストを作成する

   セキュリティリストをバックアップサブネットに割り当てます

   Auonomous Recovery Service サブネットが Oracle サービスにアクセスできることを確認します。

 

セクション2 – マルチクラウドデータベース

   リカバリサービス用のネットワーク セキュリティ グループ (NSG) を構成する

   バックアップ サブネットをリカバリ サービス サブネットとして登録します。

    NSGをリカバリサービスサブネットに登録する

    バックアップを保存する場所を決める

 

セクション3 – すべてのデータベース

    リカバリ サービスの制限と割り当てを確認します (Multicloud のサブスクリプションを含む)

    リカバリ サービスのポリシーを作成します。  

    リリースバージョンとリカバリサービスの可用性を確認してください  

   COMPATIBLE初期化パラメータを確認してください 

   暗号化ウォレットの場所としてWALLET_ROOTを使用していることを確認してください

   すべての表領域がTDE暗号化されていることを確認する

    ツールを通じて実行されなかった既存の運用バックアップを無効にします

 

    クラウドDNSエントリが解決可能であることを確認する

 

セクション4 – オプション

 リカバリサービスのバックアップ用の新しいサブネットを作成する

 

バックアップが引き続き失敗する場合は、セキュリティリストまたはNSGを確認し、リカバリサービス用のポートが適切に開いていることを確認してください。制限の確認など、多くの事前チェックが行われていますが、バックアップが構成されるまでポートの問題は検出できません。

 

注意: このチェックリストに従って、最初のデータベースのオンボード時にAutonomous Recovery Serviceの構成が失敗した場合は、SRを開くときに以下の手順に従ってください。

1. 使用しているデータベースサービスのSRを開きます。

                    –  Oracle Cloud Infrastructure -Exadata クラウドサービス

  •     問題の種類は、パッチ適用の               問題とツール -> クラウド ツールです。

 

                    –  Oracle データベース クラウド サービス

  •    問題の種類は                DBCS ツール –> クラウド ツールセットの使用です。

                    –  Autonomous Database Dedicate

  •    問題の種類は                データベース管理 -> バックアップとリカバリです

2. SR を開くときに、次の情報を含めます。

  •     コンソールに表示されたワークリクエスト エラー OCID
  •     データベース OCID
  •     VM クラスタ OCID
  •     エラーのスクリーンショット
  •     リージョン

 

 

クローン問題

バックアップを別の環境にクローンする場合は、次のいずれかの方法で実行できます。

  • 同じリージョン内の別のVCN
  • 別のリージョンの VCN

データベースをリカバリするには、Autonomous Recovery Service に必要なポートが開いていることを確認する必要があります。

これらの環境では、Autonomous Recovery Service が設定されていない可能性があります。その場合は、リストアに必要なポート 2484 と 5003 の両方が開いていることを確認する必要があります。そのためには、これらのポートをセキュリティリストに追加するか（通常は OCI バックアップの場合）、ネットワーク セキュリティ グループに追加する必要があります（通常はマルチクラウドの場合）。

バックアップと同様に、リストアではリストア操作を実行するために「バックアップサブネット」上にエンドポイントが作成されます。セキュリティリストまたはNSGは、通常バックアップに使用されるサブネットに追加されます。

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

イメージ
ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
続きを読む

Oracle Enterprise Manager 24aiの概要 (2024/12/18)

イメージ
Oracle Enterprise Manager 24aiの概要 (2024/12/18) https://blogs.oracle.com/observability/post/oracle-enterprise-manager-24 投稿者： David Le Roy | Senior Director of Product Management 本日、Oracle Enterprise Manager 24ai(EM 24ai)を発表します。これは、最新のAIを活用した管理テクノロジのパワーを活用して、データ・センターとクラウド全体にOracle Databaseとエンジニアド・システムをさらに充実させる画期的なリリースです。ソフトウェアの ダウンロード が可能になりました。この新しいリリースについてさらに学習するには、2024年12月17日から19日に開催されるOracle Enterprise Manager Technology Forumの年次開催にご 参加 ください。 図1: Oracle Enterprise Manager 24aiの概要 この新しいリリースについてさらに学習するには、2024年12月17日から19日に開催されるOracle Enterprise Manager Technology Forumの年次開催にご参加ください。12月17日午前9時に、エンジニアリング担当エグゼクティブ・バイスプレジデントのWim Coekaerts氏と製品管理担当シニア・バイスプレジデントのMughees Minhas氏が率いるイベント基調講演をご覧ください。基調講演に続き、データベース・パフォーマンス、エンジニアド・システム管理、可用性、セキュリティ、コンプライアンスなどに関するベストプラクティスと新製品機能をカバーする25のテクニカル・セッションが追加されました。オラクルのセッションでは、Oracle製品のエキスパートがお客様の技術的な質問にお答えできるよう、Oracle製品マネージャーや主要なお客様が主導しています。 本日 登録 ! Oracle Enterprise Manager 24aiの新機能 EM 24aiリリースは、お客様がオンプレミスおよびクラウドにデプロイされたOracle DatabaseおよびOracle Exadataフ...
続きを読む