Exadata Databaseへの移行
現在このページのコンテンツはありません。Oracle AI Database@Azureチームは、ここにコンテンツを追加する予定であり、このプレースホルダ・テキストは、そのテキストが追加されるまで提供されます。
Oracle AI Database@Azureチームは、この製品および付属のドキュメントに対する将来の新機能、拡張機能および修正に興奮しています。このページをぜひご覧ください。
現在このページのコンテンツはありません。Oracle AI Database@Azureチームは、ここにコンテンツを追加する予定であり、このプレースホルダ・テキストは、そのテキストが追加されるまで提供されます。
Oracle AI Database@Azureチームは、この製品および付属のドキュメントに対する将来の新機能、拡張機能および修正に興奮しています。このページをぜひご覧ください。
現在このページのコンテンツはありません。Oracle AI Database@Azureチームは、ここにコンテンツを追加する予定であり、このプレースホルダ・テキストは、そのテキストが追加されるまで提供されます。
Oracle AI Database@Azureチームは、この製品および付属のドキュメントに対する将来の新機能、拡張機能および修正に興奮しています。このページをぜひご覧ください。
Oracle Data Guardは、同期されたスタンバイ・データベースをメンテナンスすることで、高可用性および障害時リカバリをサポートします。移行では、新しいハードウェア、クラウド・インフラストラクチャ、アップグレード用の別のデータベース・バージョンなど、ターゲット環境にフィジカル・スタンバイ・データベースを設定できます。スタンバイ・データベースがプライマリ・データベースと同期し、スイッチオーバーを実行してスタンバイ・データベースが新規プライマリ・データベースになりますこのアプローチにより、スイッチオーバー時の停止時間が数秒に短縮されます。
このガイドでは、標準プラクティスに基づいた移行のためのフィジカル・スタンバイ構成について説明します。簡略化のために単一インスタンス構成を想定しています。Oracle Real Application Clusters (RAC)構成の場合は、ステップを適宜調整します。12cから19cなどのアップグレードの場合、スタンバイ・データベースは、11.2.0.1以降から入手可能な混合バージョン・サポートを使用して、より高いデータベース・バージョンを実行します。該当する場合は、Zero Downtime Migration (ZDM)を使用してクラウド移行を自動化します。
前提条件
- ソース(プライマリ)サーバーとターゲット(スタンバイ)サーバーには、互換性のあるオペレーティングシステムと十分なリソースがあります。
- Oracle Database Enterprise Edition (Oracle Data Guardが含まれます)。
- ファイアウォールなどの基本的なネットワークでは、リスナーにポート1521、SSHにポート22を使用できます。
ソリューション・アーキテクチャ

前提条件
開始する前に、次の前提条件を確認してください。
- ソース・データベース:
- データベースを
ARCHIVELOGモードで実行します。SELECT log_mode FROM v$database;問合せはARCHIVELOGを返します。データベースがARCHIVELOGモードで実行されない場合は、ARCHIVELOGモードを有効にします。この変更には停止時間が必要です。SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN; FORCE LOGGINGを有効にします。ALTER DATABASE FORCE LOGGING;- スタンバイREDOログを追加します(オンラインREDOログより1つのグループ、同じサイズ)。
v$logにサイズを問い合せて、各スレッドのスタンバイREDOログを追加します。ALTER DATABASE ADD STANDBY LOGFILE GROUP <n> ('<path>') SIZE <size>; - プライマリ・データベースおよびスタンバイ・データベースの
tnsnames.oraエントリを構成します。 - RMAN制御ファイルの自動バックアップを構成します。
CONFIGURE CONTROLFILE AUTOBACKUP ON; - アップグレードの場合は、Oracle Supportガイダンスに従って、ソース・データベースとターゲット・データベースのバージョンに互換性があることを確認してください。たとえば、
Doc ID 785347.1です。
- データベースを
- ターゲット・サーバー
- Oracleバイナリをインストールします。アップグレードに同じデータベース・バージョンまたはそれ以上のバージョンを使用します。
- ソース環境に一致するディレクトリを作成します。たとえば、Fast Recovery Areaの
/u01/oradata、/u01/fraなどです。 oracleなどのユーザーのソースからターゲット、ターゲットからソースへのSSHキーベースのアクセスを構成します。- リスナーを起動し、プライマリ・データベースおよびスタンバイ・データベースの
tnsnames.oraエントリを構成します。 - Zero Downtime Migration (オプションの自動化)の場合は、別のホストにZDMソフトウェアをインストールし、レスポンス・ファイルを構成します。
- ネットワーキング
- Azure ExpressRoute (推奨)またはサイト間VPNゲートウェイを使用して、AzureスタンバイへのData Guardの一貫性のある同期のためのプライベート専用接続を作成します。
- SQL*Net接続を確認します。ホスト間で
tnspingをテストします。 - 勤務時間同期の設定NTPを使用します。
- バックアップ・ストレージ
ZDMまたは外部バックアップを使用する場合。
- Object Storage、NFSまたはZDLRAへのアクセスを確認します。
- ツール(オプション)
- アップグレードにはOracle AutoUpgradeを使用します。
- クラウド移行にZDMを使用します。ZDMでは、Oracle Data Guardが自動的に使用されます。
次の表を使用して、プライマリ・データベースでキー初期化パラメータを構成し、これらのパラメータ設定をスタンバイ・データベースに伝播します。パラメータ 値の例 目的 DB_NAME'orcl'プライマリとスタンバイで同じです。 DB_UNIQUE_NAME'orcl_primary' (primary), 'orcl_standby' (standby)Data Guardの一意識別子。 LOG_ARCHIVE_CONFIG'DG_CONFIG=(orcl_primary,orcl_standby)'ログの送受信を有効にします。 STANDBY_FILE_MANAGEMENT'AUTO'スタンバイでファイルを自動作成します。 FAL_SERVER'standby_tns'ギャップ解決のためのアーカイブ・ログ・サーバーのフェッチ。 LOG_ARCHIVE_DEST_2'SERVICE=standby_tns ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_standby'リモートアーカイブ先。 - プライマリ・データベースの準備
- SYSとして必要な機能を有効にします。
ALTER DATABASE FORCE LOGGING; ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(<primary_unique_name>,<standby_unique_name>)' SCOPE=BOTH; ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SCOPE=BOTH; - スタンバイREDOログを追加します(たとえば、3つのオンライン・グループ、4つのスタンバイ・グループを追加します)。
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 4 ('/u01/oradata/standby_redo04.log') SIZE 100M; -- Repeat for additional groups. - RMANを使用して、プライマリ・データベースのバックアップを作成します(同期には
archivelogsを含めます)。CONNECT TARGET / BACKUP DATABASE FORMAT '/backup/db_%U' PLUS ARCHIVELOG FORMAT '/backup/arc_%U'; BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '/backup/standby_ctl.ctl'; - バックアップ・ファイル、パスワード・ファイル(
orapw<sid>)およびパラメータ・ファイル(init.oraまたはspfile)をターゲット・サーバーにコピーします。
- SYSとして必要な機能を有効にします。
- スタンバイ・データベース・サーバーの準備
- Oracleソフトウェアをインストールします(アップグレード用のバージョン以上)。
- 必要なディレクトリを作成します。
mkdir -p /u01/oradata/<db_name>mkdir -p /u01/fra/<DB_UNIQUE_NAME_upper>mkdir -p /u01/app/oracle/admin/<db_name>/adump - スタンバイでコピーしたパラメータ・ファイルを編集します。
DB_UNIQUE_NAMEをスタンバイ値に設定します。FAL_SERVERをプライマリTNS名に設定します。- 必要に応じてパスを調整します。たとえば、
CONTROL_FILES, DB_RECOVERY_FILE_DESTです。
NOMOUNTでスタンバイ・インスタンスを起動します。CREATE SPFILE FROM PFILE='/path/to/init.ora';STARTUP NOMOUNT;
- スタンバイ・データベースの構築
- RMANを使用して、アクティブ・データベースからデータベースを複製します。
CONNECT TARGET sys/<password>@primary_tns CONNECT AUXILIARY sys/<password>@standby_tns DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER NOFILENAMECHECK;代替方法: バックアップ・ファイルを使用する場合は、バックアップの場所からスタンバイ用のデータベースを複製します。DUPLICATE DATABASE FOR STANDBY BACKUP LOCATION '/backup' NOFILENAMECHECK; - スタンバイで、管理対象リカバリを開始します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
- RMANを使用して、アクティブ・データベースからデータベースを複製します。
- Data Guardの構成
- プライマリで、リモート・ロギングを設定します。
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=<standby_tns> ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=<standby_unique_name>' SCOPE=BOTH;ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;ALTER SYSTEM SET FAL_SERVER='<standby_tns>' SCOPE=BOTH; - スタンバイ中:
ALTER SYSTEM SET FAL_SERVER='<primary_tns>' SCOPE=BOTH; - (オプション)管理を容易にするためにData Guard Brokerを有効にします。
- 両方に
DG_BROKER_START=TRUEを設定します。 - 構成の作成:
DGMGRL> CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS <primary_unique_name> CONNECT IDENTIFIER IS <primary_tns>; - スタンバイの追加:
DGMGRL> ADD DATABASE <standby_unique_name> AS CONNECT IDENTIFIER IS <standby_tns>; - 次の構成を有効にします。
DGMGRL> ENABLE CONFIGURATION;
- 両方に
- プライマリで、リモート・ロギングを設定します。
- 同期の確認
- プライマリでは、ログ・スイッチを強制的に実行します。
ALTER SYSTEM SWITCH LOGFILE; - スタンバイで、適用ステータスを確認します。
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM v$managed_standby;ログを適用している'MRP0'を探します。
- ギャップを確認する:
SELECT * FROM v$archive_gap;行は戻されません。
- モニター・ラグ:
SELECT NAME, VALUE FROM v$dataguard_stats WHERE NAME = 'apply lag';
移行前の完全同期の時間を許可します。
- プライマリでは、ログ・スイッチを強制的に実行します。
- スイッチオーバーの実行(移行カットオーバー)
- プライマリに接続されているアプリケーションを停止します(最小停止時間はここから始まります)。
- ギャップがないことを確認し、スタンバイでリカバリを停止します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - ブローカの使用(推奨):
DGMGRL> SWITCHOVER TO <standby_unique_name>;- 手動による代替方法:
- プライマリ:
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN; - 古いプライマリ(現在のスタンバイ):
STARTUP MOUNT; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; - 新しいプライマリ(古いスタンバイ):
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL PRIMARY WITH SESSION SHUTDOWN; ALTER DATABASE OPEN;
- プライマリ:
- 手動による代替方法:
- ロールの確認:
SELECT DATABASE_ROLE FROM v$database;新しいプライマリは
PRIMARYである必要があります。 - アプリケーションを新しいプライマリにリダイレクトします。
- (オプション)古いプライマリをデコミッションするか、新しいスタンバイとして保持します。
オプション: 移行中のアップグレード
より新しいデータベース・バージョンに移行する場合:
- ターゲット・サーバーに新しいバージョンのOracle Databaseバイナリをインストールします。
- ステップ3の後、アップグレードのためにスタンバイ・データベースをアクティブ化します。
ALTER DATABASE ACTIVATE STANDBY DATABASE; - データベースをアップグレード・モードで起動します。
STARTUP UPGRADE; - AutoUpgradeを使用します。
- 構成ファイルを作成してください
- 次のコマンドを実行します
java -jar autoupgrade.jar -config <file> -mode upgrade
- 次のアップグレードの後:
- 次のコマンドを実行します
datapatch - データベースのオープン
- 新しいプライマリ・データベースとしてデータベースを続行します。
- 次のコマンドを実行します
自動化のためのZero Downtime Migration(ZDM)の使用
たとえば、Oracle Cloud Infrastructure (OCI)へのクラウド移行の場合:
- 専用ホストにZDMをインストールします。
MIGRATION_METHOD=ONLINE_PHYSICAL、DATA_TRANSFER_MEDIUM=OSS、TGT_DB_UNIQUE_NAMEなどのパラメータを使用してレスポンス・ファイルを作成します。- 実行 最初に評価を実行してから、完全移行を実行します。Data Guard構成ステップの後に一時停止して検証します。
zdmcli migrate database -rsp <file> -sourcesid <sid> ... - ZDMは、バックアップ、スタンバイ・データベースの作成およびスイッチオーバーを自動化します。
トラブルシューティング・ヒント
- 共通エラー:
- ORA-01110 (ファイルの不一致): ファイル・パスを確認してください。
- 適用ラグ:
- ネットワーク接続を確認し、使用可能な帯域幅を増やします。
- 追加の詳細は、次のとおりです。
- 次のようなアラート・ログおよびOracle Data Guard動的パフォーマンス・ビューを確認します。
v$dataguard_status
- 次のようなアラート・ログおよびOracle Data Guard動的パフォーマンス・ビューを確認します。
- 最初に、非本番環境で手順をテストします。
- バージョン固有の相違点については、Oracleのドキュメントを参照してください。
このプロセスでは、停止時間がほぼゼロの移行がサポートされます。