Oracle 移行のセキュリティ、アクセス、操作

この記事は、Oracle から Azure Synapse Analytics に移行する方法に関するガイダンスを提供する 7 つのパートから成るシリーズのパート 3 です。 この記事では、セキュリティ アクセス操作のベスト プラクティスに焦点をあてます。

セキュリティに関する考慮事項

Oracle 環境には、リスクとユーザーへの影響を最小限に抑えて Azure Synapse に移行するために必要なアクセスと認証のためのいくつかの方法が用意されています。 この記事では、既存の接続方法と、ユーザー、ロール、およびアクセス許可の構造をそのまま移行することを前提としています。 そうでない場合は、Azure portal を使用して、新しいセキュリティ体制を作成し、管理します。

Azure Synapse のセキュリティ オプションの詳細については、Azure Synapse Analytics のセキュリティに関するページを参照してください。

接続と認証

認証は、通常、システム内のリソースへのアクセスを許可するための前提条件として、コンピューター システム内のユーザー、デバイス、またはその他のエンティティの ID を確認するプロセスです。

ヒント

Oracle と Azure Synapse の両方の認証は、"データベース内"、または外部の方法経由で行うことができます。

Oracle の承認オプション

Oracle システムには、データベース ユーザーに対して次の認証方法が用意されています。

• データベース認証: データベース認証では、Oracle データベースがユーザー アカウントを管理し、ユーザーを認証します。 Oracle データベースは、認証を実行するために、新しいユーザーのパスワードを生成し、暗号化された形式でパスワードを格納します。 ユーザーは、いつでもパスワードを変更できます。 Oracle では、アカウントのロック、パスワードの経過期間と有効期限、パスワード履歴、パスワードの複雑さの検証を使用したパスワード管理を推奨しています。 データベース認証は、古い Oracle インストールで一般的です。

• 外部認証: 外部認証を使用すると、Oracle データベースはユーザー アカウントを保守し、外部サービスがパスワード管理とユーザー認証を実行します。 外部サービスには、オペレーティング システムや Oracle Net などのネットワーク サービスを使用できます。 データベースは、データベース アカウントへのアクセスの制限を基盤のオペレーティング システムまたはネットワーク認証サービスに依存します。 この種類のサインでは、データベース パスワードは使用されません。 外部認証には次の 2 つのオプションがあります。

  • オペレーティング システム認証: 既定では、リモート ユーザーがネットワーク接続経由でオペレーティング システム ユーザーを偽装できないようにするために、オペレーティング システムが認証するログインにセキュリティで保護された接続を Oracle が要求します。 この要件により、Oracle Net と共有サーバー構成の使用は除外されます。

  • ネットワーク認証: スマート カード、フィンガープリント、Kerberos、オペレーティング システムなどの、いくつかのネットワーク認証メカニズムを使用できます。 Kerberos などの多くのネットワーク認証サービスでは、シングル サインオンがサポートされているため、ユーザーが覚えておく必要があるパスワードが少なくなります。

• グローバル認証と承認: グローバル認証と承認を使用すると、LDAP ベースのディレクトリ サービスで、承認を含むユーザー関連情報の管理を一元化できます。 ユーザーはデータベース内でグローバル ユーザーとして識別されます。つまり、ユーザーは TLS/SSL によって認証され、ユーザー管理はデータベースの外部で行われます。 一元化されたディレクトリ サービスが、ユーザー管理を実行します。 このアプローチでは、TLS/SSL、Kerberos、または Windows ネイティブ認証を使用した強力な認証が提供され、企業全体でユーザーと権限の一元管理が可能になります。 企業内のすべてのデータベースのすべてのユーザーにスキーマを作成する必要がないため、管理が簡単です。 シングル サインオンもサポートされているため、複数のデータベースとサービスにアクセスするためにユーザーが必要とするサインインは 1 回のみになります。

• プロキシ認証と承認: プロキシ クライアントに対する中間層サーバーを安全な方法で指定できます。 Oracle には、次のようなプロキシ認証のさまざまなオプションが用意されています。

  • 中間層サーバーは、データベース サーバーで自身を認証できます。 クライアント (この場合はアプリケーション ユーザーまたは別のアプリケーション) は、中間層サーバーで自身を認証します。 クライアント ID は、データベースに到達するまで維持されます。

  • クライアント (この場合はデータベース ユーザー) は、中間層サーバーによって認証されません。 クライアントの ID とデータベース パスワードは、認証のために中間層サーバーを通過してデータベース サーバーに渡されます。

  • クライアント (この場合はグローバル ユーザー) は、中間層サーバーによって認証され、クライアントのユーザー名を取得するために識別名 (DN) または証明書を中間層経由で渡します。

Azure Synapse の認可オプション

Azure Synapse では、接続と認可について、2 つの基本的オプションがサポートされています。

• SQL 認証: SQL 認証は、データベース識別子、ユーザー ID、パスワード、その他の省略可能なパラメーターが含まれるデータベース接続を使用します。 この認証方法は、Oracle のデータベース認証と機能的に同等です。

• Microsoft Entra 認証: Microsoft Entra 認証を使用すると、データベース ユーザーの ID や Microsoft サービスを一元管理できます。 一元管理では、1 か所で Azure Synapse ユーザーを管理できるようになるため、アクセス許可の管理が簡素化されます。 Microsoft Entra 認証は、LDAP サービスと Kerberos サービスへの接続をサポートしています。 たとえば、データベースの移行後も既存の LDAP ディレクトリが存続する場合には、Microsoft Entra 認証を使ってそれに接続できます。

ユーザー、ロール、アクセス許可

Oracle と Azure Synapse の両方とも、ユーザー、ロール、アクセス許可を組み合わせてデータベースのアクセス制御を実装します。 標準 SQL ステートメント CREATE USER と CREATE ROLE/GROUP を使用して、ユーザーとロールを定義できます。 GRANT と REVOKE のステートメントは、ユーザーやロールに対するアクセス許可の割り当てまたは削除を行います。

ヒント

移行プロジェクトを成功させるには、計画が不可欠です。 まず、おおまかなアプローチの決定から始めます。

Oracle と Azure Synapse のデータベースは概念的に類似していて、既存のユーザー ID、グループ、アクセス許可の移行をある程度自動化できます。 Oracle システム カタログ テーブルからレガシのユーザーとグループの情報を抽出し、一致する同等の CREATE USER と CREATE ROLE ステートメントを生成します。 Azure Synapse でこれらのステートメントを実行して、同じユーザーやロールの階層を再作成します。

ヒント

可能な場合は、移行プロセスを自動化して、経過時間とエラーの範囲を削減します。

データの抽出後、Oracle システム カタログ テーブルを使用して同等の GRANT ステートメントを生成し、アクセス許可を割り当てます (同等のものが存在する場合)。

ユーザーと役割

Oracle システムの現在のユーザーとグループに関する情報は、システム・カタログ・ビュー (ALL_USERS、DBA_USERS など) に保持されています。 これらのビューに対して、Oracle SQL*Plus または Oracle SQL Developer を使用して通常の方法でクエリを実行できます。 次のクエリは基本的な例です。

--List of users
select * from dba_users order by username;

--List of roles
select * from dba_roles order by role;

--List of users and their associated roles
select * from user_role_privs order by username, granted_role;

Oracle SQL Developer には、次のスクリーンショットに示すように、[レポート] ペインにユーザーとロールの情報を表示するための組み込みオプションがあります。

例にある SELECT ステートメントを変更して、一連の CREATE USER と CREATE GROUP ステートメントである結果セットを生成できます。 そのためには、SELECT ステートメント内にリテラルとして適切なテキストを含めます。

既存の Oracle パスワードを取得する方法はないため、Azure Synapse で新しい初期パスワードを割り当てるためのスキームを実装する必要があります。

ヒント

データ ウェアハウスを移行するには、テーブル、ビュー、SQL ステートメントの移行以上の作業が必要です。

アクセス許可

Oracle システムでは、システムの DBA_ROLE_PRIVS ビューに、ユーザーとロールのアクセス権が保持されています。 SELECT アクセス権がある場合は、そのビューを照会して、システム内で定義されている現在のアクセス権リストを取得できます。 次の Oracle SQL Developer のスクリーンショットは、アクセス権リストの例を示しています。

既存の Oracle 権限に基づいて、Azure Synapse の一連の CREATE と GRANT ステートメントであるスクリプトを生成するクエリを作成することもできます。 次の Oracle SQL Developer のスクリーンショットは、そのスクリプトの例を示しています。

次の表に、ユーザー、ロール、および権限の情報を表示するために必要なデータ ディクショナリ ビューの一覧と説明を示します。

表示	説明
DBA_COL_PRIVS ALL_COL_PRIVS USER_COL_PRIVS	DBA ビューには、データベース内のすべての列オブジェクト許可が表示されます。 ALL ビューには、現在のユーザーまたは PUBLIC がオブジェクト所有者、権限の許可者、または被付与者であるすべての列オブジェクト許可が表示されます。 USER ビューには、現在のユーザーがオブジェクト所有者、権限の許可者、または被付与者である列オブジェクト許可が表示されます。
ALL_COL_PRIVS_MADE USER_COL_PRIVS_MADE	ALL ビューには、現在のユーザーがオブジェクト所有者または権限の許可者である列オブジェクト許可が一覧表示されます。 USER ビューには、現在のユーザーが権限の許可者である列オブジェクト許可が表示されます。
ALL_COL_PRIVS_RECD USER_COL_PRIVS_RECD	ALL ビューには、現在のユーザーまたは PUBLIC が被付与者である列オブジェクト許可が表示されます。 USER ビューには、現在のユーザーが被付与者である列オブジェクト許可が表示されます。
DBA_TAB_PRIVS ALL_TAB_PRIVS USER_TAB_PRIVS	DBA ビューには、データベース内のすべてのオブジェクトに対するすべての許可が一覧表示されます。 ALL ビューには、ユーザーまたは PUBLIC が被付与者であるオブジェクトに対する許可が一覧表示されます。 USER ビューには、現在のユーザーが被付与者であるすべてのオブジェクトに対する許可が一覧表示されます。
ALL_TAB_PRIVS_MADE USER_TAB_PRIVS_MADE	ALL ビューには、現在のユーザーによって行われたか、現在のユーザーが所有するオブジェクトに対して行われたオブジェクト許可が一覧表示されます。 USER ビューには、現在のユーザーが所有するすべてのオブジェクトに対する許可が一覧表示されます。
ALL_TAB_PRIVS_RECD USER_TAB_PRIVS_RECD	ALL ビューには、ユーザーまたは PUBLIC が被付与者であるオブジェクト許可が一覧表示されます。 USER ビューには、現在のユーザーが被付与者であるオブジェクト許可が一覧表示されます。
DBA_ROLES	このビューには、データベースに存在するすべてのロールが一覧表示されます。
DBA_ROLE_PRIVS USER_ROLE_PRIVS	DBA ビューには、ユーザーとロールに付与されたロールが一覧表示されます。 USER ビューには、現在のユーザーに付与されているロールが一覧表示されます。
DBA_SYS_PRIVS USER_SYS_PRIVS	DBA ビューには、ユーザーとロールに付与されているシステム権限が一覧表示されます。 USER ビューには、現在のユーザーに付与されているシステム権限が一覧表示されます。
ROLE_ROLE_PRIVS	このビューには、他のロールに付与されているロールが表示されます。 ユーザーがアクセスできるロールに関してのみ、情報が提供されます。
ROLE_SYS_PRIVS	このビューには、ロールに付与されているシステム権限に関する情報が含まれます。 ユーザーがアクセスできるロールに関してのみ、情報が提供されます。
ROLE_TAB_PRIVS	このビューには、ロールに付与されているオブジェクト権限に関する情報が含まれます。 ユーザーがアクセスできるロールに関してのみ、情報が提供されます。
SESSION_PRIVS	このビューには、ユーザーに対して現在有効になっている権限が一覧表示されます。
SESSION_ROLES	このビューには、ユーザーに対して現在有効になっているロールが一覧表示されます。

Oracle では、さまざまな種類の権限がサポートされています。

• システム権限: システム権限を使用すると、被付与者がデータベースで標準の管理者タスクを実行できます。 通常、これらの権限は信頼できるユーザーに制限されます。 多くのシステム権限は、Oracle 操作に固有です。

• オブジェクト権限: 各種類のオブジェクトには、それに関連付けられている権限があります。

• テーブル権限: テーブル権限を使用すると、データ操作言語 (DML) レベルまたはデータ定義言語 (DDL) レベルでセキュリティが有効になります。 テーブル権限は、Azure Synapse 内の同等のものに直接マップできます。

• ビュー権限: テーブルと同様に、ビューに DML オブジェクト権限を適用できます。 ビュー権限は、Azure Synapse 内の同等のものに直接マップできます。

• プロシージャ権限: プロシージャ権限を使用すると、スタンドアロン プロシージャや関数を含むプロシージャに EXECUTE 権限を付与できます。 プロシージャ権限は、Azure Synapse 内の同等のものに直接マップできます。

• 型権限: オブジェクト型、VARRAYs、入れ子になったテーブルなどの、名前付きの型にシステム権限を付与できます。 通常、これらの権限は Oracle に固有であり、Azure Synapse には相当するものがありません。

ヒント

DML や DDL などの基本的なデータベース操作のためには、同等の Azure Synapse アクセス許可が存在します。

次の表に、Azure Synapse に直接同等のものがある一般的な Oracle 管理者権限を示します。

管理権限	説明	Synapse での同等のもの
[Create] Database	ユーザーはデータベースを作成できます。 既存のデータベースを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE DATABASE
[Create] External Table	ユーザーは外部テーブルを作成できます。 既存のテーブルを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE TABLE
[Create] Function	ユーザーはユーザー定義関数 (UDF) を作成できます。 既存の UDF を操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE FUNCTION
[Create] Role	ユーザーはグループを作成できます。 既存のグループを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE ROLE
[Create] Index	システムでの使用専用です。 ユーザーがインデックスを作成することはできません。	CREATE INDEX
[Create] Materialized View	ユーザーはマテリアライズド ビューを作成できます。	CREATE VIEW
[Create] Procedure	ユーザーはストアド プロシージャを作成できます。 既存のストアド プロシージャを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE PROCEDURE
[Create] Schema	ユーザーはスキーマを作成できます。 既存のスキーマを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE SCHEMA
[Create] Table	ユーザーはテーブルを作成できます。 既存のテーブルを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE TABLE
[Create] Temporary Table	ユーザーは一時テーブルを作成できます。 既存のテーブルを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE TABLE
[Create] User	ユーザーはユーザーを作成できます。 既存のユーザーを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE USER
[Create] View	ユーザーはビューを作成できます。 既存のビューを操作するためのアクセス許可は、オブジェクトの特権によって制御されます。	CREATE VIEW

このセクションで前述したように、Oracle カタログ テーブルから Azure Synapse の同等のスクリプトを生成することで、これらの権限の移行を自動化できます。

次の表に、Azure Synapse に直接同等のものがある一般的な Oracle オブジェクト権限を示します。

オブジェクト権限	説明	Synapse での同等のもの
Alter	ユーザーはオブジェクト属性を変更できます。 すべてのオブジェクトに適用されます。	ALTER
削除	ユーザーはテーブル行を削除できます。 テーブルにのみ適用されます。	DELETE
Drop	ユーザーはオブジェクトをドロップできます。 全種類のオブジェクトに適用されます。	DROP
実行	ユーザーは、ユーザー定義関数、ユーザー定義集計、ストアド プロシージャを実行できます。	EXECUTE
挿入	ユーザーはテーブルに行を挿入できます。 テーブルにのみ適用されます。	INSERT
List	ユーザーはリストまたは別の方法でオブジェクト名を表示できます。 すべてのオブジェクトに適用されます。	リスト
Select	ユーザーはテーブル内の行を選択 (またはクエリ) できます。 テーブルとビューに適用されます。	SELECT
Truncate	ユーザーはテーブルからすべての行を削除できます。 テーブルにのみ適用されます。	TRUNCATE
更新	ユーザーはテーブル行を変更できます。 テーブルにのみ適用されます。	UPDATE

Azure Synapse アクセス許可の詳細については、データベース エンジンのアクセス許可に関するページを参照してください。

ユーザー、ロール、および権限の移行

ここまで、CREATE USER、CREATE ROLE、および GRANT という SQL コマンドを使用して、ユーザー、ロール、および権限を Azure Synapse に移行するための一般的なアプローチについて説明しました。 ただし、付与可能な権限があるすべての Oracle 操作を新しい環境に移行する必要はありません。 たとえば、システム管理操作は新しい環境に適用できないか、同等の機能が自動的であるか、データベースの外部で管理されます。 Azure Synapse 環境に直接同等のものがあるユーザー、ロール、権限のサブセットについては、次の手順で移行プロセスを説明します。

1. Oracle スキーマ、テーブル、ビューの定義を Azure Synapse 環境に移行します。 この手順では、データではなくテーブル定義のみが移行されます。

2. 移行する既存のユーザー ID を Oracle システム テーブルから抽出し、Azure Synapse 用の CREATE USER ステートメントのスクリプトを生成してから、そのスクリプトを Azure Synapse 環境で実行します。 パスワードは Oracle 環境から抽出できないため、新しい初期パスワードを作成する方法を見つけます。

3. 既存のロールを Oracle システム テーブルから抽出し、Azure Synapse 用の CREATE ROLE ステートメントのスクリプトを生成してから、そのスクリプトを Azure Synapse 環境で実行します。

4. Oracle システム テーブルからユーザーとロールの組み合わせを抽出し、Azure Synapse 内のユーザーにロールを GRANT (付与) するスクリプトを生成し、そのスクリプトを Azure Synapse 環境で実行します。

5. Oracle システム テーブルから関連する権限情報を抽出し、Azure Synapse 内のユーザーとロールに適切な権限 を GRANT (付与) するスクリプトを生成し、そのスクリプトを Azure Synapse 環境で実行します。

操作上の考慮事項

このセクションでは、リスクとユーザーへの影響を最小限に抑えて、一般的な Oracle の運用タスクを Azure Synapse に実装する方法について説明します。

すべての運用環境のデータ ウェアハウス製品と同様に、システムを効率的に実行し続け、監視と監査に向けてデータを提供するために、継続的な管理タスクが必要です。 その他の運用上の考慮事項としては、リソース使用率、将来の拡張のための容量計画、データのバックアップ/復元などがあります。

ヒント

データ ウェアハウスを効率的に運用し続けるには、運用タスクが必要です。

Oracle 管理タスクは、通常、2 つのカテゴリに分類されます。

• システム管理: システム管理とは、ハードウェア、構成設定、システムの状態、アクセス、ディスク領域、使用状況、アップグレード、その他の管理タスクです。

• データベース管理: データベース管理とは、ユーザー データベースとそのコンテンツ、データの読み込み、データ バックアップ、データの復旧、データとアクセス許可の管理です。

Oracle には、システムとデータベースに関する管理タスクを実行するために使用できる方法やインターフェースがいくつか用意されています。

• Oracle Enterprise Manager は、Oracle のオンプレミスの管理プラットフォームです。 データ センターにあるか Oracle クラウドにあるかに関係なく、お客様のすべての Oracle デプロイを管理するための 1 つのウィンドウが用意されています。 Oracle Enterprise Manager は、Oracle の製品スタックとの緊密な統合により、Oracle アプリケーション、データベース、ミドルウェア、ハードウェア、およびエンジニアリングされたシステムの管理と自動化をサポートします。

• Oracle Instance Manager には、Oracle インスタンスの高度な管理のための UI が用意されています。 Oracle Instance Manager は、スタートアップ、シャットダウン、ログの表示などのタスクを有効にします。

• Oracle Database Configuration Assistant は、さまざまなデータベース機能の管理と構成を可能にする UI です。

• SQL コマンドは、SQL データベース セッション内の管理タスクとクエリをサポートします。 SQL コマンドは、Oracle SQL*Plus コマンド インタープリターや Oracle SQL Developer UI から、または ODBC、JDBC、OLE DB プロバイダーなどの SQL API 経由で実行できます。 SQL コマンドを実行するには、実行するクエリとタスクにとって適切なアクセス許可を持っているデータベース ユーザー アカウントが必要です。

さまざまなデータ ウェアハウスの管理と運用のタスクは、概念は類似していますが、個々の実装は異なっている可能性があります。 Azure Synapse などの最新のクラウドベース製品には、Oracle などの従来の環境でのより手動的なアプローチと比べて、より自動化された "システム管理" アプローチが組み込まれている傾向があります。

以降のセクションでは、さまざまな運用タスクについて、Oracle と Azure Synapse のオプションを比較します。

ハウスキープ処理タスク

従来のデータ ウェアハウス環境では、ほとんどの場合、通常のハウスキープ処理タスクには多くの時間がかかります。 古いバージョンの更新または削除された行を除去することで、ディスク記憶域領域を再利用できます。 別の方法として、データ、ログ ファイル、インデックス ブロックを再編成 (Oracle で ALTER TABLE... SHRINK SPACE を実行するなど) して効率を向上させることで、ディスクストレージ領域を再利用できます。

ヒント

ハウスキープ処理タスクは、運用ウェアハウスが効率的に動作している状態を保ち、ストレージその他のリソースを最適化します。

データの一括取り込みの後、クエリ実行プランのために最新データをクエリ オプティマイザーに提供するのに必要な統計の収集は、多くの時間を要する潜在的可能性があるタスクです。

Oracle には、統計の品質の分析に役立つ機能である "オプティマイザ統計アドバイザ" が組み込まれています。 これは、オプティマイザー統計のベスト プラクティスを表す Oracle ルールの一覧を使用して動作します。 アドバイザーは各ルールをチェックし、必要に応じて、修正措置を講じるための所見、推奨事項、および DBMS_STATS パッケージへの呼び出しを含むアクションを生成します。 次のスクリーンショットに示すように、ユーザーは V$STATS_ADVISOR_RULES ビューにルールの一覧を表示できます。

Oracle ではデータ辞書内に、自動的に、または特定の機能が有効になった後にデータを蓄積する多くのログ テーブルが格納されています。 ログ データは時間の経過とともに増加するため、古い情報を消去して、永続的領域を使い切らないようにします。 Oracle には、ログのメンテナンスを自動化するためのオプションが用意されています。

Azure Synapse は必要に応じて使用できるように、統計を自動的に作成します。 インデックスとデータ ブロックのデフラグを、手動で、スケジュールに基づいて、または自動的に実行できます。 ネイティブの組み込み Azure 機能を使用することで、移行の労力を削減できます。

ヒント

ハウスキープ処理タスクは、Azure で自動化して監視します。

監視と監査

Oracle Enterprise Manager には、アクティビティ、パフォーマンス、キュー、リソース使用率などの、1 つ以上の Oracle システムのさまざまな側面を監視するためのツールが含まれています。 Oracle Enterprise Manager には、ユーザーが任意のグラフの詳細レベルまでドリルダウンできる対話型 UI があります。

ヒント

Oracle Enterprise Manager は、Oracle システムの監視とログ記録に推奨される方法です。

次の図は、Oracle データ ウェアハウスの監視環境の概要を示しています。

Azure Synapse でも Azure portal 内に、データ ウェアハウスのワークロードに関する分析情報を提供するリッチな監視エクスペリエンスが用意されています。 Azure portal は、データ ウェアハウスの監視に推奨されるツールです。構成可能な保持期間、アラート、推奨事項、およびメトリックとログのカスタマイズ可能なグラフとダッシュボードが用意されているためです。

ヒント

Azure portal には、Azure のデータとプロセスすべてについて監視と監査のタスクを管理する GUI が用意されています。

Azure portal では、次のスクリーンショットに示すように、パフォーマンスの向上に関する推奨事項も提供できます。

このポータルでは、Operations Management Suite (OMS) や Azure Monitor などの他の Azure 監視サービスとの統合がサポートされ、データ ウェアハウスと Azure 分析プラットフォーム全体とが統合された監視エクスペリエンスが提供されます。 詳細については、Azure Synapse の操作と管理のオプションに関するページを参照してください。

高可用性 (HA) とディザスター リカバリー (DR)

1979 年の初回リリース以降、Oracle 環境は、高可用性 (HA) やディザスター リカバリー (DR) のオプションをはじめとする、企業のお客様が必要とする多数の機能を含むように進化してきました。 この分野の最新のお知らせは、Maximum Availability Architecture (MAA) です。これには、4 つのレベルの HA と DR のリファレンス アーキテクチャが含まれています。

• Bronze レベル: 単一インスタンスの HA アーキテクチャ
• Silver レベル: 自動フェールオーバーを使用した HA
• Gold レベル: 包括的な HA と DR
• Platinum レベル: 停止なしにするためのプラチナ対応アプリケーション

Azure Synapse では、データベース スナップショットを使用してデータ ウェアハウスの HA を提供します。 データ ウェアハウス スナップショットでは、データ ウェアハウスの以前の状態を復元するために利用できる復元ポイントが作成されます。 Azure Synapse は分散システムであるため、データ ウェアハウス スナップショットは、Azure Storage に格納された多数のファイルで構成されます。 スナップショットでは、データ ウェアハウスに格納されたデータの増分の変更がキャプチャされます。

ヒント

Azure Synapse では、復旧時間が確実に短縮されるように、スナップショットを自動的に作成します。

Azure Synapse では、スナップショットが終日自動的に取得され、7 日間利用できる復元ポイントが作成されます。 この保持期間は変更できません。 Azure Synapse では、8 時間の回復ポイントの目標 (RPO) がサポートされています。 プライマリ リージョンのデータ ウェアハウスを、過去 7 日間に作成されたいずれかのスナップショットから復元することができます。

ヒント

キーの更新前に、ユーザー定義スナップショットを使用して復旧ポイントを定義できます。

Azure Synapse では、手動でトリガーされたスナップショットから作成されるユーザー定義の復元ポイントがサポートされます。 大規模なデータ ウェアハウスの変更の前後に復元ポイントを作成することで、復元ポイントの論理的な一貫性を確保できます。 ユーザー定義の復元ポイントは、ワークロードの中断やユーザー エラーが発生した場合の、データ保護を強化し、復旧時間を短縮します。

スナップショットに加えて、Azure Synapse によって、1 日に 1 回、ペアになっているデータセンターに対して標準の geo バックアップが実行されます。 geo 復元の RPO は 24 時間です。 geo バックアップは、Azure Synapse がサポートされている任意のリージョンのサーバーに復元できます。 geo バックアップにより、プライマリ リージョン内の復元ポイントを使用できない場合でも、データ ウェアハウスを復元できるようになります。

ヒント

Microsoft Azure では、DR を実現するために、地理的に離れた場所への自動バックアップを提供しています。

ワークロードの管理

Oracle には、ワークロードを管理するための Enterprise Manager や Database Resource Manager (DBRM) などのユーティリティが用意されています。 これらのユーティリティには、大規模なクラスター間での負荷分散、並列クエリ実行、パフォーマンス測定、優先順位付けなどの機能が含まれています。 これらの機能の多くは自動化できるため、システムはある程度自己調整されます。

ヒント

一般的な運用データ ウェアハウスでは、異なるリソース使用特性を持つ混合ワークロードが同時に実行されます。

Azure Synapse は、リソース使用率の統計情報を自動的にログに記録します。 メトリックには、各クエリの CPU、メモリ、キャッシュ、I/O、一時ワークスペースの使用状況の統計情報が含まれます。 Azure Synapse は、接続の失敗などの接続情報もログに記録します。

ヒント

詳細レベルとシステム全体のメトリックが、Azure Synapse で自動的にログに記録されます。

Azure Synapse では、リソース クラスは、クエリ実行のためにコンピューティング リソースとコンカレンシーを制御する、あらかじめ決定されたリソース制限です。 リソース クラスは、ワークロードを管理するのに便利です。それには、同時に実行されるクエリの数と、各クエリに割り当てられるコンピューティング リソースに制限を設定します。 メモリとコンカレンシーの間にはトレードオフがあります。

Azure Synapse では、次の基本的なワークロード管理の概念がサポートされています。

• ワークロードの分類: ワークロード グループに要求を割り当てて、重要度レベルを設定できます。

• ワークロードの重要度: 要求がリソースにアクセスする順序に影響を与えることができます。 既定では、クエリは、リソースが使用可能になると先入れ先出しでキューから解放されます。 ワークロードの重要度を使用すると、キューに関係なく、優先順位の高いクエリがリソースをすぐに受け取るようにできます。

• ワークロードの分離: ワークロード グループのリソースを予約したり、さまざまなリソースの最大と最小の使用量を割り当てたり、要求のグループが使用できるリソースを制限したり、タイムアウト値を設定してランナウェイ クエリを自動的に強制終了したりできます。

混合ワークロードを実行すると、ビジー状態のシステムでリソースの問題が発生する可能性があります。 正常なワークロード管理スキームでは、リソースが効果的に管理され、リソースが確実に効率よく利用され、投資収益率 (ROI) が最大化されます。 ワークロードの分類、ワークロードの重要度、ワークロードの分離により、ワークロードでのシステム リソースの利用方法をより詳細に制御できます。

容量計画のために Azure Synapse が収集するワークロード メトリックを使用して、たとえば、追加のユーザーや大規模なアプリケーション ワークロードに必要なリソースを特定できます。 ワークロード メトリックを使用して、ピーク性の強いワークロードをコスト効率良くサポートするためのコンピューティング リソースのスケールアップ/スケールダウンを計画することもできます。

ワークロード管理ガイドでは、ワークロードの分析、ワークロードの重要度の管理と監視の手法、およびリソース クラスのワークロード グループへの変換手順について説明しています。 Azure portal と DMV に対する T-SQL クエリを使用してワークロードを監視し、該当するリソースが効率的に利用されるようにします。 Azure Synapse には、ワークロード管理のすべての側面を監視するための一連の動的管理ビュー (DMV) が用意されています。 これらのビューは、アクティブにトラブルシューティングを行うときと、ワークロードでパフォーマンスのボトルネックを特定するときに役立ちます。

Azure Synapse でのワークロード管理の詳細については、「リソース クラスを使用したワークロード管理」を参照してください。

コンピューティング リソースをスケーリングする

Azure Synapse アーキテクチャでは、ストレージとコンピューティングが分離されていて、それぞれを別個にスケーリングできます。 結果として、データ ストレージから独立して、パフォーマンスの需要を満たすためにコンピューティング リソースをスケーリングできます。 コンピューティング リソースは、一時停止して再開することもできます。 このアーキテクチャのもう 1 つの利点は、コンピューティングとストレージに対する課金が別々であることです。 データ ウェアハウスが使用されていない場合は、コンピューティングを一時停止してコンピューティング コストを節約できます。

ヒント

Azure の主な利点は、コンピューティング リソースをオンデマンドで個別にスケールアップおよびスケールダウンし、ピーク時間のあるワークロードをコスト効率よく処理できることです。

データ ウェアハウスの Data Warehouse ユニット (DWU) 設定を調整することで、コンピューティング リソースをスケールアップまたはスケールダウンできます。 より多くの DWU を割り当てると、読み込みとクエリのパフォーマンスが直線的に向上します。

DWU を増やすと、コンピューティング ノードの数が増えるため、より多くのコンピューティング能力が追加され、より多くの並列処理がサポートされます。 コンピューティング ノードの数が増えるにつれて、コンピューティング ノードあたりのディストリビューション数が減少し、クエリのために提供されるコンピューティング能力と並列処理が増加します。 同様に、DWU を減らすと、コンピューティング ノードの数が減り、クエリのためのコンピューティング リソースが減少します。

次のステップ

視覚化とレポートの詳細を確認するには、このシリーズの次の記事「Oracle 移行の視覚化とレポート」を参照してください。