oracle® database oracle shardingの使用, 19c · 2019-08-26 · oracle database...

前次このコンテンツを正しく表示するには、JavaScriptが有効になっている必要があります

1. 目次

目次タイトルおよび著作権情報はじめに

対象読者ドキュメントのアクセシビリティについて関連ドキュメント表記規則

このリリースでのOracle Shardingの変更点Oracle Database 19cでの変更点

新機能システム管理のシャーディングのための複数の表ファミリのサポート同一のCDBでの複数のPDBシャードのサポートシャード間の一意の順序番号の生成シャード・カタログ・スタンバイでのマルチシャード問合せコーディネータのサポートシャード間のパラメータ設定の伝播

非推奨およびサポート終了GDSCTLコマンドラインでのパスワードの設定のサポート終了

Oracle Database 18cでの変更点新機能

ユーザー定義のシャーディング方法シャードとしてのPDBのサポートOracle GoldenGateレプリケーションのサポート集中診断マルチシャード問合せの一貫性レベルJSON、LOBおよび空間オブジェクトのシャーディングのサポートマルチシャード問合せに関するオプティマイザの機能強化シャードの置換Oracle RAC Sharding

その他の変更点1 Oracle Shardingの概要

1.1 シャーディングについて1.2 シャーディングの利点1.3 Oracle Shardingアーキテクチャのコンポーネント1.4 シャーディングに対するアプリケーションの適合性

2 シャード・データベース・スキーマの設計2.1 シャード表2.2 シャード表ファミリ2.3 重複した表2.4 すべてのシャードに作成される表以外のオブジェクト2.5 シャード・データベースでのDDLの実行

2.5.1 シャード・データベースのためのDDL構文の拡張2.6 シャード・データベースでのPL/SQLプロシージャの実行2.7 シャード間の一意の順序番号の生成

3 シャード・データベースの物理編成3.1 分散パーティション化としてのシャーディング

1

3.2 パーティション、表領域およびチャンク4 シャーディング方法

4.1 システム管理のシャーディング4.2 ユーザー定義のシャーディング4.3 コンポジット・シャーディング4.4 サブパーティション化とシャーディングの使用

5 シャード・データベース・アプリケーションの設計に関する考慮事項5.1 シャード・データベース・スキーマ設計の考慮点5.2 Oracle Sharding用アプリケーションの開発

6 シャード・データベース環境でのリクエストのルーティング6.1 シャードへの直接ルーティング

6.1.1 シャードへの直接ルーティングについて6.1.2 シャーディングAPI

6.2 シャード・データベースでのプロキシ・ルーティングを使用した問合せおよびDML6.2.1 シャード・データベースでのプロキシ・ルーティングについて6.2.2 Oracle Shardingマルチシャード問合せコーディネータ

6.2.2.1 プロキシ・ルーティングの回復力6.2.3 プロキシ・ルーティングを使用した問合せおよびDML6.2.4 単一シャード問合せのためのプロキシ・ルーティング6.2.5 マルチシャード問合せのためのプロキシ・ルーティング

6.2.5.1 マルチシャード問合せでの一貫性レベルの指定6.2.6 プロキシ・ルーティングでサポートされる問合せの形態6.2.7 プロキシ・ルーティング用の実行計画

6.3 中間層接続プールとシャード間のアフィニティの作成7 シャード・レベルの高可用性

7.1 シャーディングとレプリケーションについて7.1.1 シャードの高可用性としてOracle GoldenGateを選択するケース

7.2 シャード・データベースでのOracle Data Guardの使用7.3 シャード・データベースでのOracle GoldenGateの使用

8 シャード・データベースのデプロイ8.1 シャード・データベースのデプロイの概要

8.1.1 デプロイメント方法の選択8.1.2 Oracle ShardingでのOracle Multitenantの使用

8.2 Oracle Shardingの前提条件8.3 Oracle Databaseソフトウェアのインストール8.4 シャード・ディレクタ・ソフトウェアのインストール8.5 シャード・カタログ・データベースの作成8.6 Oracle Shardingの管理およびルーティング層のセットアップ8.7 システム管理のシャード・データベースの作成およびデプロイ

8.7.1 システム管理のシャード・データベースのデプロイ8.7.2 システム管理のシャード・データベースのスキーマの作成8.7.3 システム管理のSDBのデモ・アプリケーション

8.8 ユーザー定義のSDBの作成およびデプロイ8.8.1 ユーザー定義のSDBのデプロイ8.8.2 ユーザー定義のSDBのスキーマ作成

8.9 コンポジットSDBの作成およびデプロイ8.9.1 コンポジットSDBのデプロイ8.9.2 コンポジットSDBのスキーマ作成

8.10 Oracle Shardingでの透過的データ暗号化の使用8.10.1 すべてのシャードに対する単一の暗号化鍵の作成

9 シャード・データベースへのデータの移行9.1 シャード・データベースへのデータの移行について

2

9.2 シャード・データベースへのデータのロードに関する一般的なガイドライン9.3 スキーマの移行9.4 ソース・データベースの準備9.5 ターゲット・シャード・データベースの準備9.6 データの移行9.7 アプリケーションの移行

10 シャード・データベースの管理10.1 シャーディング対応スタックの管理

10.1.1 シャーディング対応タックの起動10.1.2 シャーディング対応スタックの停止

10.2 Oracle Shardingデータベース・ユーザーの管理10.2.1 GSMUSERアカウントについて10.2.2 GSMROOTUSERアカウントについて

10.3 シャード・データベースの監視10.3.1 GDSCTLによるシャード・データベースの監視10.3.2 Enterprise Manager Cloud Controlによるシャード・データベースの監視

10.3.2.1 シャード・データベースのコンポーネントの検出10.3.3 シャード間のシステム・オブジェクトの問合せ

10.4 シャード・データベースのバックアップおよびリカバリ10.5 シャード・データベース・スキーマの変更10.6 シャード間のパラメータ設定の伝播10.7 シャード・データベースのソフトウェア・バージョンの管理

10.7.1 シャード・データベースへのパッチ適用およびアップグレード10.7.2 シャード・データベースのコンポーネントのアップグレード10.7.3 シャード・データベースのダウングレード

10.8 シャード管理10.8.1 シャードの追加について10.8.2 再シャーディングおよびホット・スポット回避10.8.3 プールからのシャードの削除10.8.4 スタンバイ・シャードの追加10.8.5 Oracle Enterprise Manager Cloud Controlを使用したシャードの管理

10.8.5.1 シャードの検証10.8.5.2 プライマリ・シャードの追加10.8.5.3 スタンバイ・シャードの追加10.8.5.4 シャードのデプロイ

10.8.6 GDSCTLを使用したシャードの管理10.8.6.1 シャードの検証10.8.6.2 システム管理のSDBへのシャードの追加10.8.6.3 シャードの置換

10.9 チャンク管理10.9.1 チャンクの移動について10.9.2 チャンクの移動10.9.3 チャンクの分割について10.9.4 チャンクの分割

10.10 シャード・ディレクタ管理10.10.1 シャード・ディレクタの作成10.10.2 シャード・ディレクタ構成の編集10.10.3 シャード・ディレクタの削除

10.11 リージョン管理10.11.1 リージョンの作成10.11.2 リージョン構成の編集10.11.3 リージョンの削除

3

10.12 シャード領域管理10.12.1 シャード領域の作成10.12.2 コンポジット・シャード・データベースへのシャード領域の追加

10.13 シャードグループ管理10.13.1 シャードグループの作成

10.14 サービス管理10.14.1 サービスの作成

11 Oracle Shardingのトラブルシューティング11.1 Oracle Shardingのトレースおよびデバッグ情報

11.1.1 Oracle Shardingに対するトレースの有効化11.1.2 Oracle Shardingのアラート・ログおよびトレース・ファイルの検索場所

11.2 シャード・データベースの一般的なエラー・パターンおよび解決11.2.1 リモート・スケジューラ・エージェントの起動時の問題11.2.2 シャード・ディレクタの起動時の障害11.2.3 CREATE SHARDで作成されたシャードのエラー11.2.4 CREATE SHARDの使用時の問題11.2.5 deployコマンドの使用時の問題

索引

4

前次このコンテンツを正しく表示するにはJavaScriptを有効にする必要があります

1. Oracle Shardingの使用2. Oracle® Database

Oracle® Database

Oracle Shardingの使用

19c

F16095-03(原本部品番号:E87088-04)

2019年2月

タイトルおよび著作権情報

Oracle Database Oracle Shardingの使用 19c

F16095-03

Copyright © 2018, 2019, Oracle and/or its affiliates. All rights reserved.

原本著者: Virginia Beecher

原本協力者: Raihan Al-Ekram、Lance Ashdown、Nagesh Battula、David Colello、Mark Dilman、VidhyaGovindaraju、Belinda Leung、Darshan Maniyani、Joseph Meeks、Janet Stern、Nirav Vyas、NickWagner、Jean Zeng

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, anyprograms installed on the hardware, and/or documentation, delivered to U.S. Government end users are"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specificsupplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs,including any operating system, integrated software, any programs installed on the hardware, and/ordocumentation, shall be subject to license terms and license restrictions applicable to the programs. No otherrights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のため

5

に開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、TheOpen Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。お客様との間に適切な契約が定められている場合を除いて、オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。お客様との間に適切な契約が定められている場合を除いて、オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

6


1. Oracle Shardingの使用2. はじめに

はじめにこのマニュアルでは、Oracle Shardingを使用してシャード・データベースを作成および管理する方法について説明します。また、シャード・データベース用のアプリケーションの設計についても説明します。

対象読者ドキュメントのアクセシビリティについて関連ドキュメント表記規則

対象読者

このマニュアルは、シャード・データベースを使用するデータベース管理者およびアプリケーション開発者を対象としています。

親トピック: はじめに

ドキュメントのアクセシビリティについてOracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。


関連ドキュメント

詳細は、Oracle Databaseのドキュメント・セットを参照してください。特に関連性の高いドキュメントを次に示します。

Oracle Database Global Data Services概念および管理ガイド

Oracle Database管理者ガイド

『Oracle Data Guard概要および管理』

『Oracle Data Guard Broker』

『Oracle Fusion Middleware Oracle GoldenGate Microservices Architectureの使用』

7

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-415B8BB5-5C8D-4C78-8E76-43DB1648E467


https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ADMIN-GUID-EA8CC987-EF18-4434-B962-01312CD3A8AC

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ADMIN-GUID-EA8CC987-EF18-4434-B962-01312CD3A8AC

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SBYDB-GUID-5E73667D-4A56-445E-911F-1E99092DD8D7



https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=DGBKR-GUID-723E5B73-A350-4B2E-AF3C-5EA4EFC83966



https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GGSAU-GUID-2C059382-7753-4EFA-B313-A6E0DAF7EA1C



『Oracle Database JDBC開発者ガイド』

Oracle Universal Connection Pool開発者ガイド

Oracle Data Provider for .NETの開発者ガイド

Oracle Call Interfaceプログラマーズ・ガイド


表記規則

このドキュメントでは次の表記規則を使用します。

規則意味

太字太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。


8

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=JJDBC-GUID-1D7795CA-79DC-452B-9FCC-0EF430F87461



https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=JJUCP-GUID-12685D3A-F083-433A-90DF-C5533009B841


https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ODPNT8599


https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=LNOCI-GUID-C64136C2-CF65-4507-8811-9A03946CC817



1. Oracle Shardingの使用2. Oracle Shardingのこのリリースの変更点

Oracle Shardingのこのリリースの変更点「はじめに」の内容は次のとおりです。

Oracle Database 19cでの変更点Oracle Database 18cでの変更点

Oracle Database 19cでの変更点

次に、Oracle Database 19cのOracle Shardingの変更点を示します。

新機能非推奨およびサポート終了

親トピック: このリリースでのOracle Shardingの変更

新機能

このリリースの新機能は次のとおりです。

システム管理のシャーディングのための複数の表ファミリのサポート同一のCDBでの複数のPDBシャードのサポートシャード間の一意の順序番号の生成シャード・カタログ・スタンバイでのマルチシャード問合せコーディネータのサポートシャード間のパラメータ設定の伝播

親トピック: Oracle Database 19cでの変更点

システム管理のシャーディングのための複数の表ファミリのサポート

Oracle Database 18cのOracle Sharding機能では、シャード・データベースごとに1つの表ファミリ(同じシャーディング・キーを共有する関連表のセット)のみがサポートされていました。Oracle Database19cのOracle Shardingでは、異なる表ファミリのすべてのデータが同じチャンクに存在する、複数の表ファミリをサポートしています。この機能は、システム管理のシャード・データベースにのみ適用されます。異なる表ファミリにアクセスする異なるアプリケーションが、1つのシャード・データベースでホストできるようになりました。

1つの新しいGDSCTLコマンドCONFIG TABLE FAMILYがあり、この機能をサポートするために、ADDSERVICE、MODIFY SERVICE、CONFIG SERVICE、CONFIG CHUNKS、STATUS ROUTING、VALIDATE CATALOGといったその他のコマンドが拡張されています。

この機能で導入された新しいSQLキーワードまたは文はありませんが、CREATE SHARDED TABLEおよびTABLESPACE SETの使用について、一部の制限事項が変更されています。

関連項目

9

シャード表ファミリ


Oracle Database SQL言語リファレンス

親トピック: 新機能

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

Oracle Database 18cのOracle Shardingでは、CDBで1つのPDBをシャードまたはシャード・カタログ・データベースとして使用する機能が導入されました。Oracle Database 19cのOracle Shardingでは、CDBで複数のPDBをシャードまたはシャード・カタログ・データベースとして使用できますが、特定の制限事項があります。たとえば、この機能によって、CDBには異なるシャード・データベース(SDB)からのシャードPDBを含めることができ、それぞれに個別のカタログ・データベースがあります。

関連項目

Oracle ShardingでのOracle Multitenantの使用(PDBをシャードとして使用する方法の詳細)


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

Oracle Database 19cより前では、シャード間で一意の番号が必要な場合、それを自分で管理する必要がありました。Oracle Database 19cでは、Oracle Shardingを使用して、シャードごとに順序番号を個別に生成できます。順序番号はすべてのシャード間で一意です。

この機能をサポートするために、新しいSEQUENCEオブジェクト句、SHARDおよびNOSHARDがSEQUENCEオブジェクトのDDL構文に含まれます。

関連項目

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



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

Oracle Database 19cより前は、マルチシャード問合せコーディネータとして使用できるのはプライマリ・シャード・カタログ・データベースのみでした。Oracle Database 19cでは、シャード・カタログ・データベースのOracle Active Data Guardスタンバイでマルチシャード問合せコーディネータを有効にすることもできます。これにより、マルチシャード問合せワークロードのスケーラビリティおよび可用性が向上します。

関連項目

Oracle Shardingマルチシャード問合せコーディネータ

10

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-E6E76443-AD85-455C-99AA-BF0A7856F880


https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SQLRF-GUID-3C11D3A9-8B14-4DCC-B212-B7FE57EE81E8





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

Oracle Database 19cより前は、データベース管理者はシャード・データベースの各シャードでALTERSYSTEMパラメータ設定を構成する必要がありました。この機能により、管理者はパラメータ設定を集中的に管理し、シャード・カタログからすべてのデータベース・シャードに伝播できるため、管理性が向上します。シャード・カタログで設定を構成すると、シャード・データベースのすべてのシャードに自動的に伝播されます。

シャード間のパラメータ設定の伝播を参照してください。


非推奨およびサポート終了

このリリースで非推奨となった機能またはサポートされなくなった機能は次のとおりです。

GDSCTLコマンドラインでのパスワードの設定のサポート終了


GDSCTLコマンドラインでのパスワードの設定のサポート終了

セキュリティを強化するために、Oracle Database 19c以降、オペレーティング・システム・プロンプトからコールされたときにGlobal Data Services制御ユーティリティ(GDSCTL)のコマンドラインからパスワードを指定する機能はサポートされなくなりました。

このサポート終了は、ユーザー・コマンドライン・プロンプトからGDSCTLがコールされた場合のパスワード変更にのみ適用されます。たとえば、次のコマンドはサポートされなくなりました。$ gdsctl add database -connect inst1 -pwd gsm_password

GDSCTLユーティリティ自体からのパスワードの指定は、引き続き有効です。たとえば、次のコマンドは有効です。GDSCTL> add database -connect inst1 -pwd gsm_password

この非推奨では、オペレーティング・システム・プロンプトからコールされるGDSCTLコマンドでパスワードを指定する際のセキュリティの脆弱性に対処します。

親トピック: 非推奨およびサポート終了

Oracle Database 18cでの変更点

次に、Oracle Database 18cのOracle Shardingの変更点を示します。

新機能その他の変更

親トピック: このリリースでのOracle Shardingの変更

11

新機能

このリリースの新機能は次のとおりです。

ユーザー定義のシャーディング方法シャードとしてPDBのサポートOracle GoldenGateレプリケーションのサポート集中診断マルチシャード問合せの一貫性レベルJSON、LOBおよび空間オブジェクトのシャーディングのサポートマルチシャード問合せに関するオプティマイザの機能強化シャードの置換Oracle RAC Sharding


ユーザー定義のシャーディング方法

ユーザー定義のシャーディングでは、個々のシャードへのデータのマッピングをユーザーが明示的に指定できます。これは、パフォーマンスや規制などの理由で、特定のデータを特定のシャードに格納する必要があり、シャード間のデータの移動を完全に制御する必要がある場合に使用します。この方法を使用して、LISTまたはRANGEベースのシャーディングを定義できます。

関連項目

ユーザー定義のシャーディング(ユーザー定義のシャーディングの概念的な概要)

シャード・データベースでのOracle Data Guardの使用(Oracle Data Guardによるユーザー定義のシャード・データベースのレプリケートの詳細)

ユーザー定義のSDBの作成とデプロイ(ユーザー定義のシャード・データベースの構成、作成およびデプロイに関連するタスク)


シャードとしてのPDBのサポート

CDB内のPDBをシャードまたはシャード・カタログ・データベースのために使用します。OracleShardingのこのリリースでは、シャードまたはシャード・カタログがCDB内の1つのPDBとしてサポートされています。Oracle Shardingでマルチテナント・アーキテクチャをサポートできるように、GDSCTLコマンドADD SHARDが拡張され、新しいコマンドADD CDB、MODIFY CDB、CONFIGCDBおよびREMOVE CDBが実装されています。

関連項目

Oracle ShardingでのOracle Multitenantの使用(PDBをシャードとして使用する方法の詳細)

Oracle Database Global Data Services概要および管理ガイド(新しいコマンドの詳細)


Oracle GoldenGateレプリケーションのサポート

12

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-08E1234F-1083-4CCE-8002-385FC3FE0616

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-08E1234F-1083-4CCE-8002-385FC3FE0616

Oracle GoldenGateは、すべてのシャードが書込み可能で、各シャードをシャードグループ内の別のシャードに部分的にレプリケートできるファイングレイン・アクティブ-アクティブ・レプリケーションのために使用されます。アクティブ-アクティブ・レプリケーションによる競合の処理には、Oracle 12.2に追加された自動競合検出および解決機能が使用されます。

シャード・レベルの高可用性を参照してください。


集中診断

SQLのSHARDS()句は、すべてのシャード間でV$、DBA/USER/ALLビュー、ディクショナリ表などのOracle提供オブジェクトを問い合せることができます。

シャード間のシステム・オブジェクトの問合せを参照してください。


マルチシャード問合せの一貫性レベル

マルチシャード問合せを実行するときに、初期化パラメータMULTISHARD_QUERY_DATA_CONSISTENCYを使用して様々な一貫性レベルを設定できます。

マルチシャード問合せでの一貫性レベルの指定を参照してください。


JSON、LOBおよび空間オブジェクトのシャーディングのサポート

このリリースでは、一時LOB、大規模なJSONドキュメント(LOB記憶域を必要とするもの)、空間オブジェクト、索引と演算子および永続LOBを生成するJSON演算子をシャード環境で使用できます。

この機能の一部として、次のインタフェースが新規作成または変更されました。

問合せおよびDML文

LOBに関連するシャード間の問合せがサポートされています。

複数のシャードを使用するDMLはサポートされていません。この動作は、スカラー列に似ています。

1つのシャードを使用するDMLは、コーディネータでサポートされています。

シャードから選択したロケータは、同じシャードにバインド値として渡すことができます。

OCILob

シャーディング環境では、BFILE関連を除くすべてのOCILob APIがサポートされていますが、いくつかの制限事項があります。

コーディネータでは、LOBがシャード表から取得された場合にLOBディスクリプタのOCI_ATTR_LOB_REMOTE属性がTRUEを返します。

13

制限事項: 入力として2つのロケータを取るAPI (OCILobAppendやOCILobCompareなど)では、両方のロケータを同じシャードから取得する必要があります。ロケータを異なるシャードから取得すると、エラーが発生します。

DBMS_LOB

シャーディング環境では、BFILE関連を除くすべてのDBMS_LOB APIがサポートされていますが、いくつかの制限事項があります。コーディネータでは、LOBがシャード表から取得された場合にDBMS_LOB.isremoteがTRUEを返します。

制限事項: 入力として2つのロケータを取るAPI (DBMS_LOB.appendやDBMS_LOB.compareなど)では、両方のロケータを同じシャードから取得する必要があります。ロケータを異なるシャードから取得すると、エラーが発生します。

シャード・データベース・デプロイメントでのLOBの使用例は、システム管理のシャード・データベースのスキーマの作成、ユーザー定義のSDB用のスキーマの作成およびコンポジットSDB用のスキーマの作成を参照してください。


マルチシャード問合せに関するオプティマイザの機能強化

シャード問合せの堅牢性とフォルト・トレランスを向上させるため、様々な機能強化が行われました。問合せの実行計画が拡張され、問合せに含まれるすべてのシャードの情報が表示されるようになりました。

これらのトピックの最新情報は、プロキシ・ルーティングでサポートされる問合せの形態およびプロキシ・ルーティング用の実行計画を参照してください。


シャードの置換

シャードで障害が発生してリカバリ不能になった場合は、GDSCTLでADD SHARD -REPLACEコマンドを使用してシャードを置き換えることができます。また、なんらかの理由で、-replaceコマンド・オプションを使用して新しい装置にシャードを移動することもできます。

シャードの置換を参照してください。


Oracle RAC Sharding

Oracle RAC Shardingは、特定のOracle RACインスタンスに対する表パーティションのアフィニティを作成し、対応するパーティションを論理的に保持するインスタンスにパーティション化キーを指定するデータベース・リクエストをルーティングします。これにより、キャッシュをより適切に利用できるようになり、インスタンス間のブロックpingを大幅に削減できます。パーティション化キーは、最もパフォーマンスを重視するリクエストにのみ追加できます。キーを指定しないリクエストは透過的に機能し、任意のインスタンスにルーティングできます。この機能を有効にするためにデータベース・スキーマを変更する必要はありません。

14

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=RACAD-GUID-1100990E-18BD-4C92-A0C7-3C08C40AAD14

詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください


その他の変更

このリリースでの追加変更は次のとおりです。

シャーディングのコンテンツを新しいマニュアルに移動

Oracle Database 12cリリース2 (12.2.0.2)では、Oracle Shardingのコンテンツは『Oracle Database管理者ガイド』に含まれていました。Oracle Database 18c以降では、Oracle Shardingのコンテンツは独自のマニュアルであるOracle Shardingの使用に含まれています。


15

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=RACAD-GUID-1100990E-18BD-4C92-A0C7-3C08C40AAD14


1. Oracle Shardingの使用2. Oracle Shardingの概要

1 Oracle Shardingの概要Oracle Shardingによるシャード・データベースの管理に関連する概念を詳しく学びます。

次の項目では、Oracle Shardingの用語、概念および利点について説明します。

シャーディングについてシャーディングはデータ階層アーキテクチャで、独立したデータベース間にデータが水平にパーティション化されます。シャーディングの利点シャーディングにより、要求の厳しいOLTPアプリケーションの線形スケーラビリティおよび完全な障害分離が実現します。Oracle ShardingアーキテクチャのコンポーネントOracle Shardingは、使用に適したOLTPアプリケーションのためのスケーラビリティ機能および可用性機能です。ハードウェアまたはソフトウェアを共有しないOracleデータベースのプールで、データの分散およびレプリケーションを可能にします。シャーディングに対するアプリケーションの適合性Oracle Shardingは、シャード・データベースに適したOLTPアプリケーション用です。

1.1 シャーディングについてシャーディングは、独立したデータベース間でデータが水平にパーティション化されるデータ階層アーキテクチャです。

各データベースは、独自のローカル・リソース(CPU、メモリー、フラッシュまたはディスク)を持つ専用サーバーでホストされます。このような構成の各データベースはシャードと呼ばれます。すべてのシャードが一体的に単一の論理データベースを形成し、これはシャード・データベース(SDB)と呼ばれます。

水平パーティション化にはシャード間のデータベース表の分割が伴い、これによって各シャードには、列は同じですが行は異なるサブセットを持つ表が含まれます。この方法で分割された表はシャード表とも呼ばれています。

次の図は、3つのシャード間で水平パーティション化された表を示しています。

図1-1 シャード間の表の水平パーティション化

16

「図1-1 シャード間の表の水平パーティション化」の説明

シャーディングはシェアードナッシング・ハードウェア・インフラストラクチャに基づいており、シャードがCPU、メモリーまたはストレージ・デバイスなどの物理リソースを共有しないため、単一障害点が排除されます。シャードはソフトウェアの観点でも疎結合されています。クラスタウェアが実行されないためです。

通常、シャードは専用サーバーでホストされます。これらのサーバーには、市販のハードウェアまたはエンジニアド・システムを使用できます。シャードは、単一インスタンスまたはOracle RACデータベースで実行できます。それらは、オンプレミス、クラウド、またはオンプレミスとクラウドのハイブリッド構成に配置できます。

データベース管理者の視点からすると、SDBは、まとめて管理することも個別に管理することも可能な複数のデータベースで構成されています。ただし、アプリケーションの視点からはSDBは単一のデータベースのように見えます。シャードの数とそのシャード間におけるデータ分散は、データベース・アプリケーションに対して完全に透過的です。

シャーディングは、シャード・データベース・アーキテクチャに適したカスタムOLTPアプリケーションを対象としています。シャーディングを使用するアプリケーションには、シャーディング・キーを使用して主にデータにアクセスする適切に定義されたデータ・モデルおよびデータ分散方法(コンシステント・ハッシュ、範囲、リストまたはコンポジット)が必要です。シャーディング・キーの例としてcustomer_id、account_noまたはcountry_idがあります。

親トピック: Oracle Shardingの概要

1.2 シャーディングの利点

シャーディングは、最も負荷の高いOLTPアプリケーションに対する線形の拡張性と完全な障害分離を提供します。

シャーディングには、次のような主な利点があります。

線形のスケーラビリティ。シャーディングによりパフォーマンス上のボトルネックを排除し、シャードを追加することでパフォーマンスと容量を線形に拡張できます。

障害の封じ込め。シャーディングは、共有ディスク、SAN、クラスタウェアなど、単一障害点を排除するシェアード・ナッシング・ハードウェア・インフラストラクチャであり、強力な障害分離が可能なため、1つのシャードの障害または処理速度の低下は他のシャードのパフォーマンスまたは可用性に影響しません。

データの地理的分散.シャーディングは、データを特定の管轄に配置することが必要なときに、特定のデータをそのコンシューマの近くに格納して定期的な要求を満たすことを可能にしま

17

す。

ローリング・アップグレード。1回につき1つのシャードへの構成変更の適用は他のシャードに影響を及ぼさないため、管理者は最初にデータの小さなサブセットで変更をテストできます。

クラウド・デプロイメントの簡潔性。シャーディングはクラウドへのデプロイメントに適しています。シャードのサイズは必要に応じて設定し、使用可能なクラウド・インフラストラクチャを収容して、必要なサービス・レベルを実現できます。Oracle Shardingは、オンプレミス、クラウドおよびハイブリッドのデプロイメント・モデルをサポートしています。

シャーディングを実装するNoSQLデータ・ストアとは異なり、Oracle ShardingはエンタープライズRDBMSの機能を犠牲にすることなく、シャーディングの利点を提供します。たとえば、OracleShardingは次の要素をサポートしています。

リレーショナル・スキーマ

データベース・パーティション化

ACIDプロパティおよび読取りの一貫性

SQLおよびその他のプログラム的インタフェース

複合データ型

オンラインのスキーマ変更

マルチコアの拡張性

高度なセキュリティ

圧縮

高可用性機能

エンタープライズ級のバックアップおよびリカバリ


1.3 Oracle ShardingアーキテクチャのコンポーネントOracle Shardingは、使用に適したOLTPアプリケーションのためのスケーラビリティ機能および可用性機能です。ハードウェアまたはソフトウェアを共有しないOracleデータベースのプールで、データの分散およびレプリケーションを可能にします。

アプリケーションは、データベースのプールを単一の論理データベースとして認識します。アプリケーションは、データベース(シャード)をプールに追加することによって、どのプラットフォーム上でも、いずれのレベルにも弾力的に(データ、トランザクションおよびユーザーを)スケーリングできます。Oracle Databaseでは、1,000シャードまでのスケーリングがサポートされています。

次の図は、Oracle Shardingの主要なアーキテクチャ・コンポーネントを示しています。

シャード・データベース(SDB) – ハードウェアまたはソフトウェアを共有しない物理OracleDatabase (シャード)のプールで水平にパーティション化された単一の論理Oracle Database

18

シャード - シャード・データベースのサブセットをホストする独立した物理Oracleデータベース

グローバル・サービス - SDBのデータへのアクセスを提供するデータベース・サービス

シャード・カタログ – 自動的なシャードのデプロイメント、シャード・データベースの集中管理、およびマルチシャード問合せをサポートするOracle Database

シャード・ディレクタ – シャーディング・キーに基づいて高パフォーマンスな接続ルーティングを可能にするネットワーク・リスナー

接続プール - 実行時に、プールされている接続にデータベース・リクエストをルーティングすることによって、シャード・ディレクタとして機能します

管理インタフェース - GDSCTL (コマンドライン・ユーティリティ)およびOracle EnterpriseManager (GUI)

図1-2 Oracle Shardingのアーキテクチャ

「図1-2 Oracle Shardingのアーキテクチャ」の説明

シャード・データベースとシャード

シャードは、独自のローカル・リソース(CPU、メモリーまたはディスク)を持つデータベース・サーバーでホストされる独立したOracleデータベースです。シャードには共有記憶域は必要ありません。

シャード・データベースはシャードの集まりです。各シャードは、1つのリージョンに配置するか、別々のリージョンに配置できます。Oracle Shardingのコンテキストでのリージョンは、1つのデータ・センターまたはネットワーク上で近接している複数のデータ・センターを表します。

19

シャードは、高可用性(HA)および障害時リカバリ(DR)のためにOracleレプリケーション・テクノロジ(Data Guardなど)を使用してレプリケートされます。HAのためには、プライマリ・シャードが配置されているリージョンと同じリージョンにスタンバイ・シャードを配置できます。DRのためには、スタンバイ・シャードを別のリージョンに配置します。

グローバル・サービス

グローバル・サービスは、従来のデータベース・サービスの概念を拡張したものです。グローバル・サービスでは、従来のデータベース・サービスのすべてのプロパティがサポートされます。シャード・データベースでは、グローバル・サービス用の追加のプロパティが設定されます。たとえば、データベース・ロール、レプリケーション・ラグの許容値、クライアントとシャード間のリージョン・アフィニティなどがあります。読取り/書込みトランザクション・ワークロードの場合は、SDB内のプライマリ・シャードからデータにアクセスするために、単一のグローバル・サービスが作成されます。Active Data Guardを使用する高可用性シャードの場合は、別個の読取り専用グローバル・サービスを作成できます。

シャード・カタログ

シャード・カタログは特殊な目的のOracle Databaseであり、SDB構成データの永続的なストアとなり、シャード・データベースの集中管理で主要な役割を果たします。すべての構成の変更(シャードやグローバル・サービスの追加、削除など)は、シャード・カタログで開始されます。SDBのすべてのDDLは、シャード・カタログに接続することによって実行されます。

シャード・カタログには、SDBのすべての重複表のマスター・コピーも含まれています。シャード・カタログは、マテリアライズド・ビューを使用して、すべてのシャードの重複表に変更を自動的にレプリケートします。シャード・カタログは、マルチシャード問合せ、およびシャーディング・キーを指定しない問合せを処理するための問合せコーディネータとしても機能します。

シャード・カタログの高可用性のためにOracle Data Guardを使用することをベスト・プラクティスとしてお薦めします。シャード・カタログの可用性はSDBの可用性に影響しません。シャード・カタログの停止は、スタンバイ・シャード・カタログへの自動フェイルオーバーを完了するために必要な短い時間に、保守操作またはマルチシャード問合せを実行する機能にのみ影響します。OLTPトランザクションは引き続きSDBにルーティングされて実行され、カタログの停止の影響を受けません。

シャード・ディレクタ

Oracle Database 12cでは、グローバル・サービス・マネージャが導入され、データベース・ロール、負荷、レプリケーション・ラグおよびローカル性に基づいて接続がルーティングされます。OracleShardingをサポートするために、グローバル・サービス・マネージャはデータの場所に基づいた接続のルーティングをサポートします。グローバル・サービス・マネージャは、Oracle Shardingのコンテキストではシャード・ディレクタと呼ばれます。

シャード・ディレクタは、グローバル・サービス・マネージャの特殊な実装であり、SDBに接続するクライアントのリージョナル・リスナーとして機能します。シャード・ディレクタはSDBの現在のトポロジ・マップを維持します。接続リクエスト中に渡されたシャーディング・キーに基づいて、シャード・ディレクタは適切なシャードに接続をルーティングします。

一般的なシャード・データベースの場合、一連のシャード・ディレクタが各リージョンの市販のローエンドの専用サーバーにインストールされます。高可用性を実現するには、複数のシャード・ディレクタをデプロイします。特定の領域に最大5つのシャード・ディレクタをデプロイできます。

シャード・ディレクタの主な機能を次に示します。

20

SDB構成に関する実行時データおよびシャードの可用性の保守

配下のリージョンと他のリージョンの間のネットワーク待機時間の測定

クライアントがSDBへの接続に使用するためのリージョナル・リスナーとして機能します

グローバル・サービスの管理

接続ロード・バランシングの実行

接続プール

Oracle Databaseは、データ・アクセス・ドライバ(OCI、JDBC、ODP.NETなど)の接続プーリングをサポートしています。これらのドライバは、接続リクエストの一部として指定されたシャーディング・キーを認識できます。同様に、JDBCクライアントのOracle Universal Connection Pool (UCP)は、接続URLで指定されたシャーディング・キーを認識できます。また、Oracle UCPを使用すると、非Oracleアプリケーション・クライアント(Apache Tomcat、WebSphereなど)は、Oracle Shardingと連携できます。

OracleクライアントはUCPキャッシュのルーティング情報を使用し、アプリケーションから渡されたシャーディング・キーに基づいて、データベース・リクエストを適切なシャードに直接ルーティングします。データベース・リクエストをそのようにデータ依存でルーティングすることにより、余分なネットワークのホップが排除され、ボリュームの大きいOLTPアプリケーションのトランザクション待機時間が減少します。

ルーティング情報は、シャード・ディレクタを使用して確立されるシャードへの最初の接続時にキャッシュされます。キャッシュされた範囲内のシャーディング・キーに対する後続のデータベース・リクエストは、シャード・ディレクタをバイパスしてシャードに直接ルーティングされます。

UCPと同様に、シャード・ディレクタは接続文字列に指定されたシャーディング・キーを処理して、ルーティング情報をキャッシュできます。ただし、UCPはすでに確立されている接続を使用してデータベース・リクエストをルーティングしますが、シャード・ディレクタは接続リクエストをシャードにルーティングします。シャードが使用できなくなった場合、またはシャーディング・トポロジに変更が発生した場合、ルーティング・キャッシュは自動的にリフレッシュされます。高パフォーマンスのデータ依存のルーティングにするには、SDBのデータへのアクセス時に接続プールを使用することをお薦めします。

SDBの管理インタフェース

2つのインタフェース(Oracle Enterprise Manager Cloud ControlおよびGDSCTL)を使用して、Oracleシャード・データベースをデプロイ、管理および監視できます。

Cloud Controlでは、グラフィカル・ユーザー・インタフェースを使用してシャード・データベースのライフサイクル管理を有効化します。可用性およびパフォーマンスのためにSDBを管理および監視できます。シャード、サービス、シャード・ディレクタおよび他のシャーディング・コンポーネントの追加およびデプロイなどのタスクを実行できます。

GDSCTLは、SDBの構成の指定およびデプロイメントの自動化を行うための簡単な宣言的手段を提供するコマンドライン・インタフェースです。たとえば、次のようないくつかのGDSCTLコマンドを使用するだけで、SDBを作成できます。

CREATE SHARDCATALOG

21

ADD GSMおよびSTART GSM (シャード・ディレクタの作成および開始)

CREATE SHARD (各シャードが対象)

DEPLOY

GDSCTLのDEPLOYコマンドは、シャードおよびそれに対応するリスナーを自動的に作成します。また、このコマンドは管理者によって指定されたシャードレベルの高可用性のために使用されるレプリケーション構成を自動的にデプロイします。

関連項目:

Oracle Shardingで使用されるグローバル・サービス・マネージャ、グローバル・サービスおよびGDSCTLコマンドの詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください

Oracle MAAのWebページのOracle DatabaseセクションのOracle Shardingのベスト・プラクティス・ホワイト・ペーパー


1.4 シャーディングに対するアプリケーションの適合性Oracle Shardingは、シャード・データベースに適したOLTPアプリケーションのためのものです。

シャード・アーキテクチャの利点を享受するには、シャーディングを使用する予定がない既存のアプリケーションで、一定のレベルの再設計が必要となります。シャーディング・キーを渡すのみで済む簡単な場合や、シャード・データベースで必要となるデータおよびワークロードの水平パーティション化を行うことができない場合があります。

電子商取引、モバイル、ソーシャル・メディアなど、多くの顧客対応Webアプリケーションはシャーディングに適切です。そのようなアプリケーションには、適切に定義されたデータ・モデルおよびデータ分散方法(ハッシュ、範囲、リストまたはコンポジット)があり、主にシャーディング・キーを使用してデータにアクセスします。シャーディング・キーの例として顧客ID、アカウント番号、country_idなどがあります。通常、アプリケーションでは、シャーディングが十分に機能するためにデータの部分的な非正規化も必要となります。

シャーディング・キーの単一値に関連付けられたデータにアクセスするOLTPトランザクションは、シャード・データベースの主なユースケースです。たとえば、顧客のレコード、サブスクライバのドキュメント、財務トランザクション、電子商取引トランザクションなどの検索および更新などです。同じ値のシャーディング・キーを持つ、シャード・スキーマ内のすべての行は同じシャード上にあることが保証されるため、そのようなトランザクションは常に単一のシャードで最高のパフォーマンスで実行され、最高レベルの一貫性となります。マルチシャード操作はサポートされますが、パフォーマンスおよび一貫性のレベルは低くなります。そのようなトランザクションには単純な集計、レポートなどが含まれ、単一シャードのOLTPトランザクションが優位を占めるワークロードに比べて、シャード・アプリケーションで重要度の低い役割を果たします。

関連項目:

シャード・データベース・アプリケーションの設計に関する考慮事項


22



http://www.oracle.com/goto/maa





1. Oracle Shardingの使用2. シャード・データベース・スキーマの設計

2 シャード・データベース・スキーマの設計シャーディングの利点を活用するには、1つのシャードで実行されるデータベース・リクエストの数が最大になるように、シャード・データベースのスキーマを設計する必要があります。

次のトピックでは、この目的で使用されるオブジェクトについて説明します。

シャード表シャード表は、複数のデータベース間でより小さい管理しやすい断片にパーティション化された表であり、シャードと呼ばれます。シャード表ファミリシャード表ファミリは、同様にシャーディングされた一連の表です。重複表シャード表に加えて、すべてのシャードで複製される表もSDBに格納できます。すべてのシャードに作成される表以外のオブジェクト重複表に加えて、他のスキーマ・オブジェクト(ユーザー、ロール、ビュー、索引、シノニム、ファンクション、プロシージャ、パッケージなど)および非スキーマ・データベース・オブジェクト(表領域、表領域セット、ディレクトリ、コンテキストなど)をすべてのシャードに作成できます。シャード・データベースでのDDLの実行SDBにスキーマを作成するには、シャード・カタログ・データベースでDDLコマンドを発行する必要があります。シャード・カタログ・データベースは、DDLを検証し、シャードで実行する前にそれらをローカルで実行します。シャード・データベースでのPL/SQLプロシージャの実行構成内のすべてのシャードでDDL文を実行するのと同じ方法で、特定のOracle提供のPL/SQLプロシージャも実行できます。これらの特定のプロシージャ・コールは、シャードDDL文であるかのように動作します。この場合、それらはすべてのシャードに伝播され、カタログによって追跡され、新しいシャードが構成に追加されるたびに実行されます。シャード間の一意の順序番号の生成Oracle Shardingを使用すると、主キー以外の列に対してシャード間でグローバルに一意の順序番号を生成できます。これはシャード・データベースで処理されます。

2.1 シャード表

シャード表は、複数のデータベース間でより小さい管理しやすい断片にパーティション化された表であり、シャードと呼ばれます。

シャーディングには、次のような主な利点があります。

線形のスケーラビリティ。シャーディングによりパフォーマンス上のボトルネックを排除し、シャードを追加することでパフォーマンスと容量を線形に拡張できます。

障害の封じ込め。シャーディングは、共有ディスク、SAN、クラスタウェアなど、単一障害点を排除するシェアード・ナッシング・ハードウェア・インフラストラクチャであり、強力な障害分離が可能なため、1つのシャードの障害または処理速度の低下は他のシャードのパフォーマンスまたは可用性に影響しません。

23

データの地理的分散.シャーディングは、データを特定の管轄に配置することが必要なときに、特定のデータをそのコンシューマの近くに格納して定期的な要求を満たすことを可能にします。

ローリング・アップグレード。1回につき1つのシャードへの構成変更の適用は他のシャードに影響を及ぼさないため、管理者は最初にデータの小さなサブセットで変更をテストできます。

クラウド・デプロイメントの簡潔性。シャーディングはクラウドへのデプロイメントに適しています。シャードのサイズは必要に応じて設定し、使用可能なクラウド・インフラストラクチャを収容して、必要なサービス・レベルを実現できます。Oracle Shardingは、オンプレミス、クラウドおよびハイブリッドのデプロイメント・モデルをサポートしています。

シャード・アーキテクチャ

アプリケーションは、データベースのプールを単一の論理データベースとして認識します。アプリケーションは、データベース(シャード)をプールに追加することによって、どのプラットフォーム上でも、いずれのレベルにも弾力的に(データ、トランザクションおよびユーザーを)スケーリングできます。Oracle Databaseでは、1,000シャードまでのスケーリングがサポートされています。

次の図は、Oracle Shardingの主要なアーキテクチャ・コンポーネントを示しています。

シャード・データベース(SDB) – ハードウェアまたはソフトウェアを共有しない物理OracleDatabase (シャード)のプールで水平にパーティション化された単一の論理Oracle Database

シャード - シャード・データベースのサブセットをホストする独立した物理Oracleデータベース

グローバル・サービス - SDBのデータへのアクセスを提供するデータベース・サービス

シャード・カタログ – 自動的なシャードのデプロイメント、シャード・データベースの集中管理、およびマルチシャード問合せをサポートするOracle Database

シャード・ディレクタ – シャーディング・キーに基づいて高パフォーマンスな接続ルーティングを可能にするネットワーク・リスナー

接続プール - 実行時に、プールされている接続にデータベース・リクエストをルーティングすることによって、シャード・ディレクタとして機能します

管理インタフェース - GDSCTL (コマンドライン・ユーティリティ)およびOracle EnterpriseManager (GUI)

図2-1 Oracle Shardingのアーキテクチャ

24

「図2-1 Oracle Shardingのアーキテクチャ」の説明

シャーディングとパーティション化

Oracle Shardingは、シャード間の表パーティションの分散をサポートすることでパーティション化を拡張するため、事実上の分散パーティション化です。

パーティションはシャーディング・キーに基づいて表領域レベルでシャード間に分散されます。キーの例として顧客ID、アカウント番号、国IDなどがあります。シャーディング・キーには次のデータ型がサポートされています。

NUMBER

INTEGER

SMALLINT

RAW

(N)VARCHAR

(N)VARCHAR2

(N)CHAR

DATE

TIMESTAMP

25

シャード表の各パーティションが個別の表領域に存在し、各表領域が特定のシャードと関連付けられます。シャーディング方法に応じて、関連付けは自動的に確立されるか、管理者によって定義されることができます。

シャード表のパーティションが複数のシャード内に存在する場合でも、アプリケーションにとってその表は、単一データベース内のパーティション表とまったく同じように表示され、動作します。アプリケーションによって発行されたSQL文はシャードを参照する必要はなく、シャードの数およびその構成に依存することもありません。

例2-1 シャード表

シャード間で行をパーティション化する方法は、表のパーティション化でよく目にするSQL構文によって指定します。たとえば、次のSQL文はシャーディング・キーcust_idに基づいて、シャード間で表を水平にパーティション化したシャード表を作成します。CREATE SHARDED TABLE customers ( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250), region VARCHAR2(20), class VARCHAR2(3), signup DATECONSTRAINT cust_pk PRIMARY KEY(cust_id))PARTITION BY CONSISTENT HASH (cust_id)PARTITIONS AUTOTABLESPACE SET ts1;

前述の表はコンシステント・ハッシュ(スケーラブルな分散システムで一般的に使用される特殊なタイプのハッシュ・パーティション化)によりパーティション化されます。この手法は、シャード間で表領域を自動的に分散するため、データおよびワークロードが均等に分散されます。シャード表に対するグローバル索引はサポートされていませんが、ローカル索引はサポートされています。

表領域セット

Oracle Shardingは、表領域セットと呼ばれる単位として表領域を作成および管理します。PARTITIONSAUTO句は、パーティション数を自動的に判別することを指定します。このハッシュ・タイプによってシャード間のデータ移行でさらに柔軟性および効率性がもたらされ、これは弾力的な拡張性にとって重要です。

表領域はSDB内にデータを分散するための物理ユニットです。異なるシャードに存在する表領域にパーティションを自動的に作成することで、シャード間にパーティションを分散します。マルチシャード結合の数を最小にするために、関連する表の対応するパーティションは常に同じシャードに格納されます。シャード表の各パーティションが個別の表領域に格納されます。

注意:

表領域セットでは、Oracle Managed Filesのみがサポートされます。

個々の表領域を表領域セット全体とは別個に削除または変更することはできません。

TABLESPACE SETをユーザー定義のシャーディング方法とともに使用することはできません。

親トピック: シャード・データベース・スキーマの設計

2.2 シャード表ファミリ

26

シャード表ファミリは、同様にシャーディングされた一連の表です。

しばしば、データベースの表には親子関係があり、親表の主キーを参照する子表(外部キー)には参照制約があります。このような関係でリンクされている複数の表は、通常はツリーのような構造になり、各子が1つの親を持ちます。そのような一連の表は、表ファミリと呼ばれます。表ファミリ内の親を持たない表をルート表と呼びます。1つの表ファミリに存在できるルート表は1つのみです。

表ファミリのシャーディング方法

表ファミリのシャーディングを説明するために、Customers–Orders–LineItemsスキーマの例を取り上げます。このスキーマの表は次の例のようになります。3つの表に親子関係があり、Customersがルート表になります。

Customers表:

CustNo Name Address Location Class--------- ---------- -------------- --------- ------123 Brown 100 Main St us3 Gold456 Jones 300 Pine Ave us1 Silver999 Smith 453 Cherry St us2 Bronze

Orders表:

OrderNo CustNo OrderDate--------- -------- -----------4001 123 14-FEB-20134002 456 09-MAR-20134003 456 05-APR-20134004 123 27-MAY-20134005 999 01-SEP-2013

LineItems表:

LineNo OrderNo CustNo StockNo Quantity------ ------- ------ ------- --------40011 4001 123 05683022 140012 4001 123 45423609 440013 4001 123 68584904 140021 4002 456 05683022 140022 4002 456 45423509 340022 4003 456 80345330 1640041 4004 123 45423509 140042 4004 123 68584904 240051 4005 999 80345330 12

ルートであるCustomers表の顧客番号CustNoに基づいて表をシャーディングできます。次の表の例には、顧客123に関連するデータが格納されたシャードが示されています。

Customers表:

CustNo Name Address Location Class--------- ---------- -------------- ---------- ------123 Brown 100 Main St us3 Gold

Orders表:

OrderNo CustNo OrderDate--------- -------- -----------4001 123 14-FEB-20134004 123 27-MAY-2013

LineItems表:

LineNo OrderNo CustNo StockNo Quantity

27

------ ------- ------ ------- --------40011 4001 123 05683022 140012 4001 123 45423609 440013 4001 123 68584904 140041 4004 123 45423509 140042 4004 123 68584904 2

CREATE TABLEを使用したシャード表ファミリの作成

シャード表ファミリは、参照パーティション化を使用し、表間の親子関係を指定して作成することをお薦めします。

次に、Customers–Orders–LineItemsスキーマに適切なCREATE TABLE文を示します。最初の文でCustomersという表ファミリのルート表を作成します。CREATE SHARDED TABLE Customers ( CustNo NUMBER NOT NULL, Name VARCHAR2(50), Address VARCHAR2(250) , CONSTRAINT RootPK PRIMARY KEY(CustNo))PARTITION BY CONSISTENT HASH (CustNo)PARTITIONS AUTOTABLESPACE SET ts1;

次の2つの文で、Customers表の子と孫であるOrders表とLineItems表を作成します。CREATE SHARDED TABLE Orders ( OrderNo NUMBER NOT NULL, CustNo NUMBER NOT NULL, OrderDate DATE, CONSTRAINT OrderPK PRIMARY KEY (CustNo, OrderNo), CONSTRAINT CustFK FOREIGN KEY (CustNo) REFERENCES Customers(CustNo) )PARTITION BY REFERENCE (CustFK);

CREATE SHARDED TABLE LineItems ( CustNo NUMBER NOT NULL, LineNo NUMBER(2) NOT NULL, OrderNo NUMBER(5) NOT NULL, StockNo NUMBER(4), Quantity NUMBER(2), CONSTRAINT LinePK PRIMARY KEY (CustNo, OrderNo, LineNo), CONSTRAINT LineFK FOREIGN KEY (CustNo, OrderNo) REFERENCES Orders(CustNo, OrderNo))PARTITION BY REFERENCE (LineFK);

前述の例の文では、ファミリ内のすべての表の対応するパーティションが同じ表領域セットTS1に格納されます。ただし、各表に個別の表領域セットを指定できます。

参照パーティション化の場合、ルート表のみにパーティション化スキームを指定するため構文が簡単です。また、ルート表に対して実行されるパーティション管理操作が自動的に子孫に伝播されます。たとえば、ルート表にパーティションを追加すると、すべての子孫に新しいパーティションが作成されます。

前述の例の文では、シャーディング・キーとして使用されているパーティション化列CustNoは、3つの表のすべてに存在します。これは、参照パーティション化では一般に子表にキー列を複製することなく親表を使用して子表を等価パーティション化できるという事実と異なります。この理由は、子表をその親表にリンクするために使用される子表の外部キー制約には主キーを指定する必要があるので、参照パーティション化では親表に主キーが必要となるためです。ただし、シャード表の主キーは、シャーディング・キーと同じであるか、最初の列にシャーディング・キーが含まれている必要があります。これにより、線形スケーラビリティの重要な要件である主キーのグローバルな一意性が、

28

他のシャードと調整することなく維持されます。

要約すると、シャード・データベースで参照パーティション表を使用するには、次のルールに従う必要があります。

シャード表の主キーは、シャーディング・キーと同じであるか、最初の列がシャーディング・キーである複数の列である必要があります。他のシャードと調整することなく、主キーのグローバルな一意性を維持するためにこれが必要となります。

子表をその親表にリンクするための子表の外部キー制約には主キーを指定する必要があるため、参照パーティション化では親表に主キーが必要となります。たとえば、LineItems (子)表をOrders (親)表にリンクするには、Orders表に主キーが必要となります。この2番目のルールは、Orders表の主キーがCustNo値で始まることを意味します(これはOracle Shardingに固有ではない既存のパーティション化のルールです。)

場合によっては、参照パーティション化に必要な主キー制約と外部キー制約を作成することが不可能か望ましくないことがあります。そのような場合に表ファミリの親子関係を指定するには、すべての表が明示的に等価パーティション化され、各子表が親の名前を含むCREATE SHARDED TABLEのPARENT句を使用して作成される必要があります。次に、構文の例を示します。 CREATE SHARDED TABLE Customers ( CustNo NUMBER NOT NULL, Name VARCHAR2(50), Address VARCHAR2(250) , region VARCHAR2(20), class VARCHAR2(3), signup DATE)PARTITION BY CONSISTENT HASH (CustNo)PARTITIONS AUTOTABLESPACE SET ts1;

CREATE SHARDED TABLE Orders ( OrderNo NUMBER , CustNo NUMBER NOT NULL, OrderDate DATE)PARENT CustomersPARTITION BY CONSISTENT HASH (CustNo)PARTITIONS AUTOTABLESPACE SET ts1;

CREATE SHARDED TABLE LineItems ( LineNo NUMBER, OrderNo NUMBER, CustNo NUMBER NOT NULL, StockNo NUMBER, Quantity NUMBER)PARENT CustomersPARTITION BY CONSISTENT HASH (CustNo)PARTITIONS AUTOTABLESPACE SET ts1;

すべてのCREATE SHARDED TABLE文でパーティション化スキームが完全に指定されているため、任意の表を個別にサブパーティション化できます。ルート表のみにサブパーティションを指定でき、表ファミリのすべての表のサブパーティション化スキームが同じである参照パーティション化の場合、これは許可されません。

この方法は2レベルの表ファミリのみをサポートすることに注意してください。つまり、すべての子が同じ親を持つ必要があり、孫は存在できません。親表のパーティション化列がすべての子表に存在

29

するかぎり、これは制限にはなりません。

チャンク

シャード間のデータ移行の単位はチャンクです。チャンクは、表ファミリのすべての表の対応するパーティションが格納される一連の表領域です。チャンクには、一連の関連表の各表の1つのパーティションが含まれます。これより、様々なシャード表の関連するデータが一緒に移動されることが保証されます。各シャード内のチャンクの数は、SDBを作成するときに指定します。

シャード・データベース内の複数の表ファミリ

注意:

Oracle Database 19cでは、Oracle Shardingには複数の表ファミリのサポートが含まれています。この機能は、システム管理のシャード・データベースにのみ適用されます。コンポジットおよびユーザー定義のシャード・データベースでは、1つの表ファミリのみがサポートされます。

シャード・データベースには複数の表ファミリを含めることができます。この場合、異なる表ファミリのデータはすべて同じチャンクに存在し、チャンクには同じハッシュ・キー範囲を共有する異なる表ファミリからのパーティションが含まれます。表ファミリ間の問合せは最小にする必要があり、シャーディング・コーディネータでのみ実行されるようにします。各表ファミリは、異なるグローバル・サービスに関連付けられています。異なる表ファミリからのアプリケーションにはそれぞれ独自の接続プールおよびサービスがあり、適切なシャードにルーティングするために独自のシャーディング・キーを使用します。

各表ファミリは、ルート表によって識別されます。異なる表ファミリの表は、互いに関連付けないでください。各表ファミリには独自のシャーディング・キー定義が必要ですが、子表に同じシャーディング・キー列があるという同じ制限が各表ファミリ内で当てはまります。つまり、異なる表ファミリからのすべての表は、コンシステント・ハッシュと同じ方法で同じ数のチャンクにシャーディングされ、各チャンクにはすべての表ファミリからのデータが含まれます。

次の例は、PARENT句を使用して複数の表ファミリを作成する方法を示しています。CREATE SHARDED TABLE Customers <=== Table Family #1( CustId NUMBER NOT NULL, Name VARCHAR2(50), Address VARCHAR2(250), region VARCHAR2(20), class VARCHAR2(3), signup DATE)PARTITION BY CONSISTENT HASH (CustId)PARTITIONS AUTOTABLESPACE SET ts1;

CREATE SHARDED TABLE Orders( OrderNo NUMBER, CustId NUMBER, OrderDate DATE)PARENT CustomersPARTITION BY CONSISTENT HASH (CustId)PARTITIONS AUTOTABLESPACE SET ts1;

CREATE SHARDED TABLE LineItems( LineNo NUMBER, OrderNo NUMBER, CustId NUMBER, StockNo NUMBER, Quantity NUMBER

30

))PARENT CustomersPARTITION BY CONSISTENT HASH (CustId)PARTITIONS AUTOTABLESPACE SET ts1;

CREATE SHARDED TABLE Products <=== Table Family #2( ProdId NUMBER NOT NULL, CONSTRAINT pk_products PRIMARY KEY (ProdId))PARTITION BY CONSISTENT HASH (ProdId)PARTITIONS AUTOTABLESPACE SET ts_2;

表領域セットが既存の表ファミリで使用されている場合、別の表ファミリにその表領域セットを使用しようとすると、ORA-3850がスローされます。

最初のルート表(つまり、最初の表ファミリ)を作成すると、すべての既存のグローバル・サービスがその表に自動的に関連付けられます。GDSCTLコマンドMODIFY SERVICEを使用すると、表ファミリが追加で作成された後に表ファミリ・サービスの関連付けを変更できます。例:

GDSCTL> MODIFY SERVICE –GDSPOOL shdpool –TABLE_FAMILY sales.customer -SERVICE sales

注意:

表ファミリ間の結合は効率がよくないこともあるため、そのような結合が多数ある場合、またはパフォーマンスが重視されている場合は、複数の表ファミリではなく重複表を使用する必要があります。

関連項目:

『Oracle Database VLDBおよびパーティショニング・ガイド』

GDSCTLコマンド・リファレンスについては、Oracle Database Global Data Services概念および管理ガイドを参照してください


2.3 重複表

シャード表に加えて、すべてのシャードで複製される表もSDBに格納できます。

多くのアプリケーションの場合、単一のシャードで処理されるデータベース・リクエストの数は、すべてのシャードに読取り専用またはほぼ読取り専用の表を複製することによって最大化できます。この方法は、シャード表とともにアクセスされることがよくある比較的小さい表の場合は適切です。各シャードに同じ内容を含む表を重複表と呼びます。

SDBには、シャード間で水平にパーティション化されたシャード表、およびすべてのシャードにレプリケートされる重複表が含まれています。重複表には参照情報が含まれています(たとえば、各シャードで共通のStock Items表)。シャード表と重複表の組合せによって、シャーディング・キーに関連付けられているすべてのトランザクションを単一のシャードで処理できます。この技法によって、線形のスケーラビリティおよび障害の分離が可能になります。

重複表が必要な例として、シャード表ファミリで説明される表ファミリを取り上げます。データベース・スキーマにはProducts表も含まれる可能性があり、この表には、この表ファミリに対して作成さ

31

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=VLDBG-GUID-54D18B18-6838-4115-9389-E1FB0D20A8CA






れたシャード内のすべての顧客が共有するデータが含まれますが、顧客番号でシャーディングすることはできません。注文処理中のマルチシャード問合せを回避するため、表全体をすべてのシャードに複製する必要があります。

シャード表(Customers、OrdersおよびLineItems)と重複表(Products)の違いを次の図に示します。

図2-2 SDBのシャード表と重複表

「図2-2 SDBのシャード表と重複表」の説明

CREATE TABLEを使用した重複表の作成

重複表Productsは次の文を使用して作成できます。CREATE DUPLICATED TABLE Products ( StockNo NUMBER PRIMARY KEY, Description VARCHAR2(20), Price NUMBER(6,2));

重複表の更新とその内容の同期

Oracle Shardingは、マテリアライズド・ビュー・レプリケーションを使用して重複表の内容を同期します。各シャードの重複表がマテリアライズド・ビューとして表示されます。マテリアライズド・ビューのマスター表はシャード・カタログにあります。CREATE DUPLICATED TABLE文によって、マスター表、マテリアライズド・ビュー、およびマテリアライズド・ビューのレプリケーションに必要なその他のオブジェクトが自動的に作成されます。

32

Oracle Database 12cリリース2では、重複表を更新するためにクライアントをシャード・カタログ・データベースに接続する必要があります。Oracle Database 18c以降では、シャードで重複した表を更新できます。更新は、まずdblinkを介してシャードからシャード・カタログのマスター表に伝播されます。その後、マテリアライズド・ビューのリフレッシュの結果として、更新が他のすべてのシャードに非同期的に伝播されます。

すべてのシャードのマテリアライズド・ビューが、構成可能な頻度で自動的にリフレッシュされます。すべての重複表のリフレッシュの頻度は、データベース初期化パラメータSHRD_DUPL_TABLE_REFRESH_RATEによって制御されます。このパラメータのデフォルト値は、60秒です。

注意:

シャードで実行されるトランザクションがシャード・カタログで削除された行を更新しようとすると、競合状態になる可能性があります。この場合、エラーが戻され、シャードのトランザクションがロールバックされます。

シャード上の重複表を更新する場合、次のユース・ケースはサポートされません。

LOBの更新またはdblinkでサポートされていないデータ型の更新

同じトランザクションによって挿入された行の更新または削除

関連項目:

Oracle Database管理者ガイド


2.4 すべてのシャードに作成される表以外のオブジェクト

重複表に加えて、他のスキーマ・オブジェクト(ユーザー、ロール、ビュー、索引、シノニム、ファンクション、プロシージャ、パッケージなど)および非スキーマ・データベース・オブジェクト(表領域、表領域セット、ディレクトリ、コンテキストなど)をすべてのシャードに作成できます。

CREATE文に追加のキーワード(SHARDEDまたはDUPLICATED)が必要となる表と異なり、他のオブジェクトは既存の構文を使用してすべてのシャードに作成します。唯一の要件は、SHARD DDLセッション・プロパティを有効にする必要があることです。

すべてのシャードでの次のオブジェクトの自動作成は、このリリースではサポートされません。これらのオブジェクトは、個別のシャードに接続することによって作成できます。

クラスタ

制御ファイル

データベース・リンク

ディスク・グループ

エディション

フラッシュバック・アーカイブ

33

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ADMIN-GUID-A422B474-4BED-4A60-AEDB-E93630746083

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ADMIN-GUID-A422B474-4BED-4A60-AEDB-E93630746083

マテリアライズド・ゾーン・マップ

アウトライン

Pfile

プロファイル

リストア・ポイント

ロールバック・セグメント

サマリー

Oracle Database 18c以降では、マテリアライズド・ビューとビュー・ログがサポートされますが、次の制限事項があります。

シャード表に対して作成されたマテリアライズド・ビューは、カタログ・データベースでは空のままですが、シャード上の対応するマテリアライズド・ビューには個々のシャードのデータが含まれています。

シャード表のマテリアライズド・ビューでは、REFRESH COMPLETE ON DEMAND USING TRUSTEDCONSTRAINTSオプションのみがサポートされます。


2.5 シャード・データベースでのDDLの実行SDBにスキーマを作成するには、シャード・カタログ・データベースでDDLコマンドを発行する必要があります。シャード・カタログ・データベースは、DDLを検証し、シャードで実行する前にそれらをローカルで実行します。このため、シャード・カタログ・データベースには、シャード・データベースに存在するすべてのオブジェクトのローカル・コピーが含まれており、SDBのスキーマのマスター・コピーとして機能します。カタログの検証およびDDLの実行が成功した場合、そのDDLはすべてのシャードに自動的に伝播され、シャード・カタログで発行された順序で適用されます。

DDLの伝播中にシャードが停止しているか、アクセスできない場合、カタログはそのシャードに適用できなかったDDLを追跡し、そのシャードがアクセス可能になったときにそれらを適用します。新しいシャードがSDBに追加された場合、クライアントがアクセスできるようになる前に、SDBで実行されたすべてのDDLがそのシャードに同じ順序で適用されます。

SDBでDDLを発行する方法は2つあります。

GDSCTLのsqlコマンドを使用します。

この方法でDDLを発行した場合、すべてのシャードでそのDDLの実行が完了して実行のステータスが返されるまで、GDSCTLは待機します。次に例を示します。GDSCTL> sql “create tablespace set tbsset”

GDS$CATALOG.sdbnameサービスを使用し、SQL*Plusを使用してシャード・カタログ・データベースに接続します。次に例を示します。SQL> create tablespace set tbsset;

34

シャード・カタログ・データベースに対してDDLを発行すると、ローカルでの実行が完了したときにステータスが返されますが、すべてのシャードへのDDLの伝播はバックグラウンドで非同期に行われます。

DDLの伝播の確認

シャードへのDDLの伝播のステータスを確認するには、GDSCTLのshow ddlコマンドおよびconfigshardコマンドを使用できます。シャード・カタログでSQL*Plusを使用してDDLを実行した場合、SQL*Plusではすべてのシャードの実行ステータスが返されないため、この確認は必須です。シャードでDDLが失敗した場合、その失敗が解決されて、GDSCTLのrecover shardコマンドが実行されるまで、そのシャードに対するその後のすべてのDDLはブロックされます。これらのGDSCTLコマンドを実行するには、ユーザーにGSM_ADMIN権限がある必要があります。

ローカルまたはグローバルでのオブジェクトの作成

オブジェクトを作成するDDLがGDSCTLのsqlコマンドを使用して発行された場合、オブジェクトがすべてのシャードで作成されます。オブジェクトのマスター・コピーが、シャード・カタログ・データベースにも作成されます。すべてのシャードおよびカタログ・データベースに存在するオブジェクトは、SDBオブジェクトと呼ばれます。

SQL*Plusを使用してシャード・カタログに接続する場合、2つのタイプのオブジェクト(SDBオブジェクトよびローカル・オブジェクト)を作成できます。ローカル・オブジェクトは、シャード・カタログにのみ存在する従来のオブジェクトです。ローカル・オブジェクトは、管理のために使用したり、カタログ・データベースから発行されるマルチシャード問合せで(たとえば、レポートを生成および格納するために)使用したりできます。

SQL*Plusセッションで作成されるオブジェクトのタイプ(SDBまたはローカル)は、セッションでSHARDDDLモードが有効にされているかどうかによって異なります。SDBユーザー(すべてのシャードおよびシャード・カタログ・データベースに存在するユーザー)の場合、このモードは、シャード・カタログ・データベースではデフォルトで有効になっています。セッションでSHARD DDLが有効であるときに作成されたすべてのオブジェクトは、SDBオブジェクトです。ローカル・オブジェクトを作成するには、SDBユーザーは最初にalter session disable shard ddlを実行する必要があります。SHARDDDLが無効であるときに作成されたすべてのオブジェクトは、ローカル・オブジェクトです。セッションでSHARD DDLを有効にするには、SDBユーザーはalter session enable shard ddlを実行する必要があります。

SHARD DDLセッション・パラメータの詳細は、ALTER SESSIONを参照してください。

スキーマ・オブジェクトを作成するためにSDBユーザーを作成する

シャード・カタログ・データベースにのみ存在するローカル・ユーザーには、SDBにスキーマ・オブジェクトを作成するための権限がありません。このため、SDBスキーマを作成するための最初のステップは、SYSDBAとしてシャード・カタログ・データベースに接続し、SHARD DDLを有効にして、CREATE USERコマンドを実行することによって、SDBユーザーを作成することです。SDBユーザーがカタログ・データベースに接続すると、SHARD DDLモードがデフォルトで有効になります。

注意:

ローカル・ユーザーは、SHARD DDLモードを有効にしている場合、非スキーマSDBオブジェクト(表領域、ディレクトリ、コンテキストなど)を作成できます。ただし、スキーマSDBオブジェクト(表、ビュー、索引、ファンクション、プロシージャなど)は作成できません。

シャード・オブジェクトは、ローカル・オブジェクトに対する依存性を持つことができません。たと

35

えば、ローカル表にすべてのシャードを表示するビューを作成することはできません。

DDLの実行例

次の例は、DDLを発行して実行ステータスを確認する手順、およびエラーが発生した場合の対処方法を示しています。この例はSQL*Plusを使用してDDLを発行する場合の例を示していますが、GDSCTLのsqlコマンドを使用する場合も同じステータスの確認および修正のための対処を行います。

例2-2 シャード・カタログでのDDL実行エラー

この例では、ユーザーがCREATE USERコマンドで入力ミスをしています。SQL> alter session enable shard ddl;Session altered.

SQL> CREATE USER example_user IDENTRIFIED BY out_standing1;CREATE USER example_user IDENTRIFIED BY out_Standing1 *ERROR at line 1:ORA-00922: missing or invalid option

シャード・カタログでDDLの実行が失敗し、すべてのシャードでDDLが実行されなかったことがGDSCTLのshow ddlコマンドに予想どおり表示されます。GDSCTL> show ddlid DDL Text Failed shards -- -------- -------------

その後、ユーザーが正しいスペリングでコマンドを実行し直します。同じセッションを使用しているため、alter session enable shard ddlを再度実行する必要はありません。SQL> CREATE USER example_user IDENTIFIED BY out_Standing1;User created.

今度は、DDLがシャード・カタログ・データベースで正常に実行され、オンラインのシャードで失敗していないことがshow ddlに示されます。GDSCTL> show ddlid DDL Text Failed shards -- -------- ------------- 1 create user example_user identified by *****

注意:

DDLの実行時に停止していたシャードの場合、DDLはそのシャードがアクセス可能になったときに自動的に適用されます。

例2-3 シャードで修正のための対処を実行することによって、シャードでのエラーをリカバリする

この例では、ユーザーはシステム管理のシャード表のための表領域セットを作成しようとします。ただし、1つのシャードのデータファイル・ディレクトリが書込み可能ではないため、DDLはカタログでは正常に実行されますが、そのシャードでは失敗します。SQL> connect example_user/out_Standing1Connected

SQL> create tablespace set tbsset;Tablespace created.

ユーザーexample_userはSDBユーザーとして作成され、SHARD DDLがデフォルトで有効にされるた

36

め、alter session enable shard ddlを実行する必要はありません。

GDSCTLのshow ddlを使用してステータスを確認します。GDSCTL> show ddlid DDL Text Failed shards -- -------- ------------- 1 create user example_user identified by *****2 create tablespace set tbsset shard01

このコマンド出力は、シャードshard01でDDLが失敗したことを示しています。GDSCTLのconfigshardコマンドを実行して、詳細情報を取得します。GDSCTL> config shard -shard shard01

Conversion = ':'Name: shard01Shard Group: dbs1Status: OkState: DeployedRegion: eastConnection string: (DESCRIPTION=(ADDRESS=(HOST=shard01-host)(PORT=1521)(PROTOCOL=tcp))(CONNECT_DATA=(SID=shard01)))SCAN address: ONS remote port: 0Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Failed DDL: create tablespace set tbssetDDL Error: ORA-02585: create tablepsace set failure, one of its tablespaces not createdORA-01119: error in creating database file \'/ade/b/3667445372/oracle/rdbms/dbs/SHARD01/datafile/o1_mf_tbsset_%u_.dbf\'ORA-27040: file create error, unable to create fileLinux-x86_64 Error: 13: Permission deniedAdditional information: 1 $ngsmoci_execute$ Failed DDL id: 2Availability: ONLINE

「Failed DDL:」で始まるテキストは問題を示しています。それを解決するには、ユーザーはシャード・データベースのホストにログインして、そのディレクトリを書込み可能にする必要があります。

ディレクトリの権限を表示します。cd $ORACLE_HOME/rdbms/dbs ls –l ../ | grep dbsdr-xr-xr-x 4 oracle dba 102400 Jul 20 15:41 dbs/

ディレクトリを書込み可能に変更します。chmod +w .ls –l ../ | grep dbsdrwxrwxr-x 4 oracle dba 102400 Jul 20 15:41 dbs/

GDSCTL コンソールに戻って、recover shardコマンドを発行します。GDSCTL> recover shard -shard shard01

ステータスを再度確認します。GDSCTL> show ddlid DDL Text Failed shards -- -------- ------------- 1 create user example_user identified by *****2 create tablespace set tbsset

GDSCTL> config shard -shard shard01

Conversion = ':'Name: shard01Shard Group: dbs1

37

Status: OkState: DeployedRegion: eastConnection string: (DESCRIPTION=(ADDRESS=(HOST=shard01-host)(PORT=1521)(PROTOCOL=tcp))(CONNECT_DATA=(SID=shard01)))SCAN address: ONS remote port: 0Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Last Failed DDL: DDL Error: ---DDL id: Availability: ONLINE

この出力に示されているように、失敗したDDLエラーが表示されなくなりました。

例2-4 他のすべてのシャードで修正のための対処を実行することによって、シャードでのエラーをリカバリする

この例では、ユーザーは別の表領域セットtbs_setを作成しようとしますが、同じ名前の既存のローカル表領域がすでに存在するため、シャードでDDLが失敗します。

シャード・カタログで次のコマンドを実行します。SQL> create tablespace set tbs_set;Tablespace created.

GDSCTLのshow ddlコマンドを使用してステータスを確認します。GDSCTL> show ddlid DDL Text Failed shards -- -------- ------------- 1 create user example_user identified by *****2 create tablespace set tbsset 3 create tablespace set tbs_set shard01

GDSCTL> config shard -shard shard01Conversion = ':'Name: shard01……Failed DDL: create tablespace set tbs_setDDL Error: ORA-02585: create tablespace set failure, one of its tablespaces not createdORA-01543: tablespace \'TBS_SET\' already exists $ngsmoci_execute$

この問題を解決するには、ローカル・データベース管理者としてshard01にログインし、表領域TBS_SETを削除して、GDSCTLのrecover shard -shard shard01を実行します。ただし、この表領域を維持して、かわりに名前が競合している新しく作成した表領域セットを削除し、別の名前(tbsset2など)を持つ別の表領域セットを作成するとします。次の例では、シャード・カタログで実行する方法を示します。SQL> drop tablespace set tbs_set;SQL> create tablespace set tbs_set2;

GDSCTLを使用してステータスを確認します。GDSCTL> show ddlid DDL Text Failed shards -- -------- ------------- 1 create user example_user identified by *****2 create tablespace set tbsset 3 create tablespace set tbs_set shard01 4 drop tablespace set tbs_set5 create tablespace set tbsset2

DDL 3がshard01で失敗したため、DDL 4および5はshard01で実行されなかったことがわかります。このシャードがシャード・カタログと整合性を持つようにするには、GDSCTLのrecover shardコマンド

38

を実行する必要があります。ただし、DDL 3は再び失敗し、実際には表領域セットtbs_setをもう作成するつもりがないため、このシャードでDDL 3を実行することは意味がありません。DDL 3をスキップするために、–ignore_firstオプションを指定してrecover shardを実行します。GDSCTL> recover shard -shard shard01 –ignore_firstGSM Errors: dbs1 shard01:ORA-00959: tablespace \'TBS_SET\' does not exist (ngsmoci_execute)

GDSCTL> show ddlid DDL Text Failed shards -- -------- ------------- 1 create user sidney identified by *****2 create tablespace set tbsset 3 create tablespace set tbs_set 4 drop tablespace set tbs_set shard01 5 create tablespace set tbsset2

DDL 3がスキップされたため、今度はDDL 3で失敗しません。ただし、次のDDL (4 - drop tablespace settbs_set)が適用され、削除する表領域セットがシャードに存在しないため、エラーとなります。

–ignore_firstオプションは最初のDDLのみをスキップするため、recover shardを再び実行してdrop文もスキップする必要があります。GDSCTL> recover shard -shard shard01 –ignore_first

GDSCTL> show ddlid DDL Text Failed shards -- -------- -------------1 create user sidney identified by *****2 create tablespace set tbsset 3 create tablespace set tbs_set 4 drop tablespace set tbs_set5 create tablespace set tbsset2

失敗は表示されなくなり、すべてのDDLがシャードに正常に適用されました。

–ignore_firstオプションを指定してrecover shardを実行した場合、失敗したDDLは増分デプロイメントで無視とマークされます。このため、新しいシャードがSDBに追加されたとき、DDL番号3および4はスキップされ、DDL番号1および5のみが適用されます。

シャード・データベースのためのDDL構文の拡張Oracle ShardingのためにSQL DDL文に変更が加えられました。この構文を持つDDL文は、シャード・データベースに対してのみ実行できます。


2.5.1 シャード・データベースのためのDDL構文の拡張

Oracle ShardingのためにSQL DDL文に変更が加えられました。この構文を持つDDL文は、シャード・データベースに対してのみ実行できます。

Oracle Shardingをサポートするために問合せおよびDML文を変更する必要はなく、DDL文の変更も非常に限られています。ほとんどの既存のDDL文は、通常のOracle Databaseと同じ構文およびセマンティクスを使用して、シャード・データベースで同様に機能します。

CREATE TABLESPACE SET

これはOracle Shardingのために導入された新しい文です。構文はCREATE TABLESPACEと似ています。CREATE TABLESPACE SET tablespace_set [IN SHARDSPACE shardspace]

39

[USING TEMPLATE ( { MINIMUM EXTENT size_clause | BLOCKSIZE integer [ K ] | logging_clause | FORCE LOGGING | ENCRYPTION tablespace_encryption_spec | DEFAULT [ table_compression ] storage_clause | { ONLINE | OFFLINE } | extent_management_clause | segment_management_clause | flashback_mode_clause }... )];

この文は、1つ以上のシャード表および索引の論理ストレージ・ユニットとして使用できる表領域セットを作成します。表領域セットは、シャード領域のシャード間に分散された複数のOracle表領域で構成されます。

システム管理のシャーディングでは、シャード・データベースにデフォルトの1つのシャード領域のみがあります。表領域セット内の表領域の数は自動的に決定され、対応するシャード領域内のチャンクの数と同じです。

表領域セット内のすべての表領域はビッグファイルであり、プロパティが同じです。プロパティはUSING TEMPLATE句に指定します。この句は、通常の表領域のpermanent_tablespace_clauseと同じですが、datafile_tempfile_spec句にデータファイル名を指定できないことが異なります。表領域セット内の各表領域のデータファイル名は自動的に生成されます。

表領域セットは永続表領域のみで構成され、システム、UNDOまたは一時表領域セットはありません。

例CREATE TABLESPACE SET TSP_SET_1 IN SHARDSPACE sgr1 USING TEMPLATE( DATAFILE SIZE 100m EXTEND MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO);

ALTER TABLESPACE SET

表領域セットのシャード領域のプロパティは変更できません。表領域セットの他のすべての属性は、通常の永続表領域と同様に変更できます。表領域セット内の表領域はビッグファイルであるため、ADD DATAFILE句およびDROP DATAFILE句はサポートされません。

DROP TABLESPACE SETおよびPURGE TABLESPACE SET

これらの文の構文およびセマンティクスは、DROP文およびPURGE TABLESPACE文と似ています。

CREATE TABLE

この文は、シャード表と重複表の作成および表ファミリの指定ができるように拡張されました。

構文CREATE [ { GLOBAL TEMPORARY | SHARDED | DUPLICATED} ] TABLE [ schema. ] table { relational_table | object_table | XMLType_table } [ PARENT [ schema. ] table ] ;

CREATE TABLE文の次の部分は、Oracle Shardingをサポートするためのものです。

40

SHARDEDキーワードおよびDUPLICATEDキーワードは、表のコンテンツがシャード間でパーティション化されるか、すべてのシャードで複製されることをそれぞれ示します。DUPLICATEDキーワードは、重複表を作成するための唯一の構文の変更です。以降で説明する他のすべての変更はシャード表にのみ適用されます。

PARENT句は、シャード表を表ファミリのルート表にリンクします。

シャード表を作成するには、TABLESPACEのかわりにTABLESPACE SETを使用します。TABLESPACEが含まれるすべての句は、TABLESPACE SETが含まれるように拡張されました。

3つの句: table_partitioning_clauses内のconsistent_hash_partitions、consistent_hash_with_subpartitionsおよびpartition_set_clause。table_partitioning_clauses ::={range_partitions| hash_partitions| list_partitions| composite_range_partitions| composite_hash_partitions| composite_list_partitions| reference_partitioning| system_partitioning| consistent_hash_partitions| consistent_hash_with_subpartitions| partition_set_clause}

現在のリリースでのシャード表に関する制限:

シャード表のデフォルトの表領域セットはありません。

一時表はシャーディングまたは複製できません。

索引構成シャード表はサポートされません。

シャード表には、ネストした表の列またはアイデンティティ列を含めることはできません。

シャード表に定義される主キー制約には、シャーディング列を含める必要があります。重複表の列を参照するシャード表の列の外部キー制約はサポートされていません。

システム・パーティション化および間隔レンジ・パーティション化は、シャード表ではサポートされません。個別のハッシュ・パーティションの指定は、コンシステント・ハッシュによるパーティション化ではサポートされません。

PARTITION BY句またはPARTITIONSET BY句に使用されるシャード表の列には、仮想列を指定できません。

現在のリリースの重複表では、次のことはサポートされません。

システム・パーティション表および参照パーティション表

LONG、抽象(MDSYSデータ型はサポートされています)、REFデータ型

主キーを除く列の最大数は999個です

nologging、parallel、inmemoryオプション

41

重複表のXMLType列は非ASSM表領域で使用できません

例CREATE SHARDED TABLE customers ( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250) , location_id VARCHAR2(20), class VARCHAR2(3), signup_date DATE,CONSTRAINT cust_pk PRIMARY KEY(cust_id, class))PARTITIONSET BY LIST (class)PARTITION BY CONSISTENT HASH (cust_id)PARTITIONS AUTO(PARTITIONSET gold VALUES (‘gld’) TABLESPACE SET ts2, PARTITIONSET silver VALUES (‘slv’) TABLESPACE SET ts1);

ALTER TABLE

次のオプションは、システム管理またはコンポジット・シャード・データベースのシャード表ではサポートされません。

名前変更

外部キー制約の追加

個々のパーティションおよびサブパーティションに対するすべての操作

シャードに対するすべてのパーティション関連の操作(TRUNCATE PARTITION、UNUSABLELOCAL INDEXESおよびREBUILD UNUSABLE LOCAL INDEXESを除く)

次の操作は、重複表ではサポートされていません。

データ型: LONG、抽象(MDSYSデータ型はサポートされています)、REF

列のオプション: ベクトル・エンコード、不可視の列、ネストした表

オブジェクト型

クラスタ化表

外部表

ILMポリシー

PARENT句

表のフラッシュバック操作

システムおよび参照パーティション化

nologgingオプションの有効化

表の切捨て

42

重複表のマテリアライズド・ビュー・ログの削除

シャード上の重複表のマテリアライズド・ビューの削除

シャード上の(重複表の)マテリアライズド・ビューの変更

ALTER SESSION

セッションレベルのSHARD DDLパラメータは、シャード・カタログ・データベースに対して発行されたDDLのスコープを設定します。ALTER SESSION { ENABLE | DISABLE } SHARD DDL;

SHARD DDLを有効にした場合、セッションで発行されたすべてのDDLはシャード・カタログおよびすべてのシャードで実行されます。SHARD DDLを無効にした場合、DDLはシャード・カタログ・データベースに対してのみ実行されます。SDBユーザー(すべてのシャードおよびカタログに存在するユーザー)の場合、SHARD DDLはデフォルトで有効にされます。SDBユーザーを作成するには、CREATEUSERを実行する前に、SHARD DDLパラメータを有効にする必要があります。

親トピック: シャード・データベースでのDDLの実行

2.6 シャード・データベースでのPL/SQLプロシージャの実行

構成内のすべてのシャードでDDL文を実行するのと同じ方法で、特定のOracle提供のPL/SQLプロシージャも実行できます。これらの特定のプロシージャ・コールは、シャードDDL文であるかのように動作します。この場合、それらはすべてのシャードに伝播され、カタログによって追跡され、新しいシャードが構成に追加されるたびに実行されます。

次のプロシージャはすべて、シャードDDL文であるかのように動作します。

DBMS_FGAパッケージのプロシージャDBMS_RLSパッケージのプロシージャDBMS_STATSパッケージの次のプロシージャ:

GATHER_INDEX_STATSGATHER_TABLE_STATSGATHER_SCHEMA_STATSGATHER_DATABASE_STATSGATHER_SYSTEM_STATS

DBMS_GOLDENGATE_ADMパッケージの次のプロシージャ:ADD_AUTO_CDRADD_AUTO_CDR_COLUMN_GROUPADD_AUTO_CDR_DELTA_RESALTER_AUTO_CDRALTER_AUTO_CDR_COLUMN_GROUPPURGE_TOMBSTONESREMOVE_AUTO_CDRREMOVE_AUTO_CDR_COLUMN_GROUPREMOVE_AUTO_CDR_DELTA_RES

シャードDDL文と同じ方法でいずれかのプロシージャを実行するには、次の手順を実行します。

1. gsm_pooladmin_roleを持つデータベース・ユーザーとしてSQL*Plusを使用して、シャード・カタログ・データベースに接続します。

43

2. alter session enable shard ddlを使用してシャードDDLを有効にします。3. SYS.EXEC_SHARD_PLSQLという名前のシャーディング固有のPL/SQLプロシージャを使用して、ターゲット・プロシージャを実行します。

このプロシージャは、単一のCLOB引数を取ります。これは、完全修飾プロシージャ名とその引数を指定する文字列です。EXEC_SHARD_PLSQLを使用せずにターゲット・プロシージャを実行すると、そのプロシージャはカタログでのみ実行され、すべてのシャードに伝播されません。完全修飾名(たとえば、 SYS.DBMS_RLS.ADD_POLICY)を指定せずにプロシージャを実行すると、エラーが発生します。

たとえば、すべてのシャードでDBMS_RLS.ADD_POLICYを実行するには、シャードDLLを有効にした後にSQL*Plusから次を実行します。exec sys.exec_shard_plsql('sys.dbms_rls.add_policy(object_schema => ''testuser1'', object_name => ''DEPARTMENTS'', policy_name => ''dept_vpd_pol'', function_schema => ''testuser1'', policy_function => ''authorized_emps'', statement_types => ''INSERT, UPDATE, DELETE, SELECT, INDEX'', update_check => TRUE)' ) ;

コール仕様自体はexec_shard_plsqlへの文字列パラメータであるため、ターゲット・プロシージャ・コール仕様内に2つの一重引用符が必要なことに注意してください。

ターゲット・プロシージャがシャード・カタログ・データベースで正しく実行されると、現在デプロイされているすべてのシャードでの処理用にキューに入れられます。カタログでのターゲット・プロシージャ実行のエラーは、SQL*Plusセッションに戻されます。シャードでの実行時のエラーは、DDLの場合と同じ方法で追跡できます。


2.7 シャード間の一意の順序番号の生成Oracle Shardingを使用すると、主キー以外の列に対してシャード間でグローバルに一意の順序番号を生成できます。これはシャード・データベースで処理されます。

customer_idがシャーディング・キーの場合、顧客は大抵、主キー以外の列(order_idなど)に対して一意のIDを生成する必要があります。この場合、この機能を使用してシャード間で一意の順序番号を生成できますが、アプリケーション内の主キー以外の特定の列のグローバルな一意性を管理する必要はありません。

この機能は、新しいオブジェクトSHARDED SEQUENCEでサポートされています。シャード順序はシャード・カタログに作成されますが、各シャード上にインスタンスがあります。各インスタンスは、他のシャードで使用される範囲とオーバーラップしない範囲に属する、単調に増加する番号を生成します。したがって、生成されたすべての番号はグローバルに一意になります。

たとえば、シャード順序を使用すると、顧客IDでシャーディングされた表に対して一意の順序番号を生成できます。顧客IDをキーとして使用してシャードへの接続を確立するアプリケーションでは、シャード順序のローカル・インスタンスを使用して、グローバルに一意の順序番号を生成できます。

44

シャード順序で生成された番号は、このシャードに挿入される新しい行のシャーディング・キーとしてすぐに使用できません。これは、キー値が別のシャードに属している場合に、挿入によってエラーが発生するためです。新しい行を挿入するには、まずアプリケーションでシャーディング・キーの値を生成し、それを使用して適切なシャードに接続する必要があります。シャーディング・キーの新しい値を生成する一般的な方法は、シャード・カタログで通常の(シャーディングされていない)順序を使用することです。

単一のシャーディング・キー・ジェネレータがボトルネックになっている場合、シャード順序をこの目的で使用できます。この場合、アプリケーションは(シャーディング・キーを指定せずにグローバル・サービスを使用して)ランダムなシャードに接続し、シャード順序から一意のキー値を取得してから、キー値を使用して適切なシャードに接続する必要があります。

この機能をサポートするために、次のCREATE文の構文に示すように、新しいSEQUENCEオブジェクト句、SHARDおよびNOSHARDがSEQUENCEオブジェクトのDDL構文に含まれます。CREATE | ALTER SEQUENCE [ schema. ]sequence [ { INCREMENT BY | START WITH } integer | { MAXVALUE integer | NOMAXVALUE } | { MINVALUE integer | NOMINVALUE } | { CYCLE | NOCYCLE } | { CACHE integer | NOCACHE } | { ORDER | NOORDER } | { SCALE {EXTEND | NOEXTEND} | NOSCALE} | { SHARD {EXTEND | NOEXTEND} | NOSHARD} ]

NOSHARDは、順序のデフォルトです。SHARD句を指定すると、このプロパティは順序オブジェクトのディクショナリ表に登録され、DBA_SEQUENCES、USER_SEQUENCESおよびALL_SEQUENCESビューを使用して表示されます。

SHARDを指定すると、EXTENDおよびNOEXTEND句によってシャード順序の動作が定義されます。EXTENDを指定すると、生成された順序値はすべての長さ(x+y)になります。xは順序値の先頭に付加されるサイズ4のSHARDオフセット(最大シャード数の幅に対応、つまり1000)の長さ、yは順序MAXVALUE/MINVALUEの最大桁数です。

SHARD句のデフォルト設定はNOEXTENDです。NOEXTENDが設定されていると、生成される順序値の幅は最大でも順序内の数字の最大数(MAXVALUE/MINVALUE)です。この設定は、固定幅の列を移入するために順序が使用される、既存のアプリケーションとの統合に役立ちます。SHARD NOEXTENDを指定した順序でNEXTVALを呼び出すと、生成された値に順序のMAXVALUE/MINVALUEよりも多くの桁数の表現が必要な場合は、ユーザー・エラーがスローされます。

SCALE句もSHARD句で指定されている場合、順序によって、グローバルに一意である複数のインスタンスおよびセッションに対してシャード内でスケーラブルな値が生成されます。EXTENDをSHARDキーワードとSCALEキーワードの両方で指定する場合、生成された順序値はすべての長さ(x+y+z)になります。xは先頭に付加されるサイズ4のSHARDオフセットの長さ、yはスケーラブルなオフセットの長さ(デフォルトは6)、zは順序MAXVALUE/MINVALUEの最大桁数です。

注意:

SHARD句を使用する場合は、順序にORDERを指定しないでください。SHARDを使用すると、グローバルに順序付けされていない値が生成されます。ORDERが必要な場合は、各ノードでローカルに順序を作成します。

SHARDキーワードは、CACHEおよびNOCACHEモードの操作と組み合せて使用できます。

関連項目:

45



46




1. Oracle Shardingの使用2. シャード・データベースの物理編成

3 シャード・データベースの物理編成シャード・データベースの物理編成について学びます。

以下の項目では、シャード・データベースの物理編成について説明します。

分散パーティション化としてのシャーディングシャーディングは、データを複数の独立した物理データベース間に水平にパーティション化するデータベースのスケール・テクニックです。このような構成内の各物理データベースをシャードと呼びます。パーティション、表領域およびチャンク異なるシャードに存在する表領域にパーティションを作成することで、シャード間にパーティションを分散します。

3.1 分散パーティション化としてのシャーディング

シャーディングは、データを複数の独立した物理データベース間に水平にパーティション化するデータベースのスケール・テクニックです。このような構成内の各物理データベースをシャードと呼びます。

シャード・データベース(SDB)はアプリケーションおよびアプリケーション開発者には単一のデータベースのように見えますが、データベース管理者の視点では別個のOracleデータベースのセットで、それぞれがシャードと呼ばれます。シャード表はSDBのすべてのシャード間にパーティション化されます。各シャードの表のパーティションは、シャーディングされていないOracleデータベースで使用できるパーティションと同様です。

次の図は、単一の論理データベースのパーティション化と複数シャード間に分散されたパーティションの違いを示しています。

図3-1 分散パーティション化としてのシャーディング

47

「図3-1 分散パーティション化としてのシャーディング」の説明

CREATE SHARDED TABLE文を実行すると、Oracle Shardingは自動的にシャード間にパーティションを分散します。パーティションの分散はアプリケーションに対して透過的です。前述の図は、シャード表の論理ビューとその物理的な実装を示しています。

親トピック: シャード・データベースの物理編成

3.2 パーティション、表領域およびチャンク

異なるシャードに存在する表領域にパーティションを作成することで、シャード間にパーティションを分散します。

シャード表の各パーティションが個別の表領域に格納され、表領域がSDBのデータ分散の単位になります。

シャード表ファミリで説明するように、マルチシャード結合の数を最小にするために、表ファミリのすべての表の対応するパーティションが常に同じシャードに格納されます。構文の例で表領域セットts1がすべての表に使用されているように、1つの表ファミリの表が分散された表領域の同じセットに作成されるときに、これが保証されます。

ただし、1つの表ファミリの異なる表を異なる表領域のセットに作成することも可能です。たとえば、表領域セットts1にCustomers表を作成し、表領域セットts2にOrdersを作成できます。この場合、Customersのパーティション1が格納される表領域が常に、Ordersのパーティション1が格納される表領域と同じシャードに存在することが保証される必要があります。この機能をサポートするために、表ファミリのすべての表の対応するパーティションのセット(チャンクと呼ばれる)が作成されます。チャンクには表ファミリの各表の1つのパーティションが含まれます。

次の図に、Cutomers-Orders-LineItemsスキーマの表の対応するパーティションを含むチャンクを示します。

図3-2 パーティションのセットとしてのチャンク

48

「図3-2 パーティションのセットとしてのチャンク」の説明

次の図のように、各シャードに複数のチャンクが含まれます。

図3-3 シャードの内容

「図3-3 シャードの内容」の説明

シャード表に加えて、シャードには1つ以上の重複表も含めることができます。重複表は、シャード表に使用される表領域には格納できません。

親トピック: シャード・データベースの物理編成

49


1. Oracle Shardingの使用2. シャーディング方法

4 シャーディング方法この章では、Oracle Shardingでサポートされるシャーディング方法、方法の選択およびサブパーティションの使用方法について説明します。

次の項目では、Oracle Shardingでサポートされるシャーディング方法について説明します。

システム管理のシャーディングシステム管理のシャーディングでは、シャードへのデータのマッピングをユーザーが指定する必要はありません。コンシステント・ハッシュによるパーティション化を使用して、データが自動的にシャード間に分散されます。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。ユーザー定義のシャーディングユーザー定義のシャーディングでは、個々のシャードへのデータのマッピングをユーザーが明示的に指定できます。これは、パフォーマンスや規制などの理由で、特定のデータを特定のシャードに格納する必要があり、管理者がシャード間のデータの移動を完全に制御する必要がある場合に使用します。コンポジット・シャーディングコンポジット・シャーディング方法では、コンシステント・ハッシュによりパーティション化された表のデータの異なるサブセットについて、複数のシャード領域を作成できます。シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。シャーディングへのサブパーティションの使用Oracle Shardingは表のパーティション化に基づくため、Oracle Databaseで提供されるすべてのサブパーティション方法がシャーディングでもサポートされます。

4.1 システム管理のシャーディング

システム管理のシャーディングでは、シャードへのデータのマッピングをユーザーが指定する必要はありません。コンシステント・ハッシュによるパーティション化を使用して、データが自動的にシャード間に分散されます。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。

システム管理のシャーディングで使用される分散はホット・スポットを回避し、シャード間で均一なパフォーマンスを実現するためのものです。Oracle Shardingは、SDBへのシャードの追加または削除の際に、バランスの取れたチャンク分散を自動的に維持します。

コンシステント・ハッシュはスケーラブルな分散システムでよく使用されるパーティション化の方法です。従来のハッシュ・パーティション化とは異なります。従来のハッシュの場合はバケット数がHF(key) % Nとして計算されます。ここで、HFはハッシュ関数、Nはバケット数です。この方法はNが一定の場合はうまく機能しますが、Nが変化するとすべてのデータの再シャッフルが必要になります。

線形ハッシュ法などのより高度なアルゴリズムの場合、ハッシュ・バケットを追加するために表全体を再ハッシュする必要はありませんが、バケット数が2のべき乗のみ、およびバケットを分割できるオーダーのみなど、バケット数に制限があります。

50

Oracle Shardingで使用するコンシステント・ハッシュの実装では、このような制限を回避するために、次の図のように、ハッシュ関数の値の取りうる範囲(たとえば、0から232)をN個の隣接する間隔のセットに分割し、それぞれの間隔をチャンクに割り当てます。この例では、SDBに1024個のチャンクが含まれ、各チャンクに222のハッシュ値の範囲が割り当てられます。したがって、コンシステント・ハッシュによるパーティション化は、本質的にはハッシュ値の範囲によるパーティション化です。

図4-1 チャンクに割り当てられるハッシュ値の範囲

「図4-1 チャンクに割り当てられるハッシュ値の範囲」の説明

すべてのシャードの計算能力が同じだとすると、SDBの各シャードに等しい数のチャンクが割り当てられます。たとえば、16個のシャードを含むSDB内に1024個のチャンクが作成されると、各シャードに64個のチャンクが含まれます。

SDBへのシャードの追加や削除の際の再シャーディングの場合、いくつかのチャンクがシャード間を移動して、シャード間のチャンクの均一な分散が維持されます。このプロセスでチャンクの内容は変化せず、再ハッシュは行われません。

1つのチャンクが分割されるときに、ハッシュ値の範囲が2つの範囲に分割されますが、他のチャンクに対して何かを行う必要はありません。任意のチャンクをいつでも個別に分割できます。

接続リクエストのシャードへの送信にかかわるSDBのすべてのコンポーネントに、各シャードでホストされるチャンクのリスト、および各チャンクに関連付けられたハッシュ値の範囲を含むルーティング表が保持されます。特定のデータベース・リクエストのルーティング先を決定するために、ルーティング・アルゴリズムによって、シャーディング・キーで指定された値にハッシュ関数が適用され、計算されたハッシュ値が適切なチャンクにマップされ、次にチャンクを含むシャードにマップされます。

システム管理のシャーディングのSDB内のチャンク数は、GDSCTLコマンド、CREATE SHARDCATALOGで指定できます。指定しない場合は、デフォルト値としてシャード当たり120個のチャンクが使用されます。SDBのデプロイ後にチャンク数を変更する方法はチャンクの分割のみです。

コンシステント・ハッシュによってパーティション化されたシャード表を作成する前に、表のパーティションを格納するために表領域のセット(チャンク当たり1つの表領域)を作成する必要があります。表領域はCREATE TABLESPACE SETのSQL文を実行すると自動的に作成します。

表領域セットのすべての表領域が同じ物理属性を持ち、Oracle Managed Files (OMF)のみを格納できます。最も簡単な形式の場合、CREATE TABLESPACE SET文は、たとえば次のように表領域セットの名前という1つのパラメータのみを持ちます。CREATE TABLESPACE SET ts1;

この場合、セットの各表領域にデフォルトの属性を持つ1つのOMFファイルが含まれます。表領域の属性をカスタマイズするには、文にUSING TEMPLATE句(次の例を参照)を追加します。USINGTEMPLATE句は、セットの各表領域に適用される属性を指定します。CREATE TABLESPACE SET ts1

51

USING TEMPLATE( DATAFILE SIZE 10M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K SEGMENT SPACE MANAGEMENT AUTO ONLINE);

表領域セットが作成されたら、コンシステント・ハッシュでパーティション化される表を作成して、セットに属する表領域にパーティションを格納できます。CREATE TABLE文は、たとえば次のようになります。CREATE SHARDED TABLE customers ( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250) , location_id VARCHAR2(20), class VARCHAR2(3), signup DATE, CONSTRAINT cust_pk PRIMARY KEY(cust_id))PARTITION BY CONSISTENT HASH (cust_id)PARTITIONS AUTOTABLESPACE SET ts1;

この文のPARTITIONS AUTOは、パーティション数が自動的に表領域セットts1の表領域の数(チャンク数と等しい)に設定され、各パーティションが個別の表領域に格納されることを意味します。

表領域セットの各表領域が別個のチャンクに属します。つまり、1つのチャンクは所定の表領域セットの1つの表領域のみを含むことができます。ただし、同じ表ファミリに属する複数の表に同じ表領域セットを使用できます。この場合、セットの各表領域に複数のパーティション(各表から1つ)が格納されます。

または、表ファミリの各表を個別の表領域セットに格納できます。この場合、1つのチャンクに複数の表領域(各表領域セットから1つ)が含まれ、各表領域に1つのパーティションが格納されます。

次の図は、単一シャード表のユースケースの場合のパーティション、表領域およびシャード間の関係を示しています。この場合、各チャンクに1つの表領域が含まれ、各表領域に1つのパーティションが格納されます。

図4-2 システム管理のシャーディング

「図4-2 システム管理のシャーディング」の説明

注意:

52

シャーディング方法はGDSCTL CREATE SHARDCATALOGコマンドで指定し、後から変更することはできません。

親トピック: シャーディング方法

4.2 ユーザー定義のシャーディング

ユーザー定義のシャーディングでは、個々のシャードへのデータのマッピングをユーザーが明示的に指定できます。これは、パフォーマンスや規制などの理由で、特定のデータを特定のシャードに格納する必要があり、管理者がシャード間のデータの移動を完全に制御する必要がある場合に使用します。

ユーザー定義のシャード・データベースでは、Oracle Data GuardとOracle Active Data Guardの2つのレプリケーション・スキーマがサポートされます。レプリケーション方法としてOracle GoldenGateが使用されている場合、ユーザー定義のシャーディングはサポートされません。

ユーザー定義のシャーディングのもう1つのメリットとして、シャードの計画停止または計画外停止の場合に、どのデータが使用できないかをユーザーが正確に知ることができます。ユーザー定義のシャーディングのデメリットは、データベース管理者が、シャード間のデータおよびワークロードの分散のバランスを監視して維持する必要があることです。

ユーザー定義のシャーディングの場合、範囲またはリストによってシャード表をパーティション化できます。シャード表のCREATE TABLE構文は、各パーティションを個別の表領域に格納する必要があることを除き、通常の表のための構文とそれほど違いはありません。 CREATE SHARDED TABLE accounts( id NUMBER, account_number NUMBER, customer_id NUMBER, branch_id NUMBER, state VARCHAR(2) NOT NULL, status VARCHAR2(1))PARTITION BY LIST (state)( PARTITION p_northwest VALUES ('OR', 'WA') TABLESPACE ts1, PARTITION p_southwest VALUES ('AZ', 'UT', 'NM') TABLESPACE ts2, PARTITION p_northcentral VALUES ('SD', 'WI') TABLESPACE ts3, PARTITION p_southcentral VALUES ('OK', 'TX') TABLESPACE ts4, PARTITION p_northeast VALUES ('NY', 'VM', 'NJ') TABLESPACE ts5, PARTITION p_southeast VALUES ('FL', 'GA') TABLESPACE ts6);

ユーザー定義のシャーディングには表領域セットはありません。各表領域を個別に作成し、シャード領域と明示的に関連付ける必要があります。シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。

ユーザー定義のシャーディングでは、シャード領域が1つのシャード、または完全にレプリケートされたシャードのセットから構成されます。ユーザー定義のシャーディングでのレプリケーションの詳細は、シャード・レベルの高可用性を参照してください。わかりやすいように、各シャード領域が1つのシャードから構成されると仮定します。

次の構文を使用して、前述の例に示したaccounts表の表領域を作成します。CREATE TABLESPACE tbs1 IN SHARDSPACE west;CREATE TABLESPACE tbs2 IN SHARDSPACE west;

CREATE TABLESPACE tbs3 IN SHARDSPACE central;CREATE TABLESPACE tbs4 IN SHARDSPACE central;

53

CREATE TABLESPACE tbs5 IN SHARDSPACE east;CREATE TABLESPACE tbs6 IN SHARDSPACE east;

CREATE TABLESPACE文を実行する前に、シャード領域を作成し、シャードを移入する必要があります。たとえば、次のGDSCTLコマンドを使用できます。ADD SHARDSPACE -SHARDSPACE eastADD SHARDSPACE -SHARDSPACE centralADD SHARDSPACE -SHARDSPACE westADD SHARD –CONNECT shard-1 –SHARDSPACE west;ADD SHARD –CONNECT shard-2 –SHARDSPACE central;ADD SHARD –CONNECT shard-3 –SHARDSPACE east;

次の図は、前述の例に示したaccounts表について、表領域へのパーティションのマッピング、およびシャードへの表領域のマッピングを示しています。

図4-3 ユーザー定義のシャーディング

「図4-3 ユーザー定義のシャーディング」の説明

システム管理のシャーディングと同様に、ユーザー定義のシャーディングで作成される表領域もチャンクに割り当てられます。ただし、SDBにシャードを追加したときに、チャンクの移行は自動的には開始しません。移行する必要がある各チャンクに対して、ユーザーがGDSCTLコマンドMOVE CHUNKを実行する必要があります。

GDSCTLコマンドSPLIT CHUNKはシステム管理のシャーディングでは、ハッシュ範囲の中央でチャンクを分割するために使用されますが、ユーザー定義のシャーディングではサポートされません。ALTERTABLE SPLIT PARTITION文を使用してチャンクを分割する必要があります。

注意:



4.3 コンポジット・シャーディング

コンポジット・シャーディング方法では、コンシステント・ハッシュによりパーティション化された表のデータの異なるサブセットについて、複数のシャード領域を作成できます。シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。

システム管理のシャーディングでは、コンシステント・ハッシュによるパーティション化を使用して、シャード間にデータをランダムに分散します。これは、範囲またはリストによるパーティション

54

化を使用するユーザー定義のシャーディングと比べて、よりよいロード・バランスを実現します。ただし、システム管理のシャーディングでは、データのシャードへの割当てをユーザーが制御できません。

主キーのコンシステント・ハッシュによるシャーディングの際には、データのサブセットを異なる地理的場所に格納する、データのサブセットに異なるハードウェア・リソースを割り当てる、または高可用性と障害回復を異なる構成にするために、SDB内のデータのサブセットを区別する必要が生じることがよくあります。通常は、この区別は顧客の場所やサービスのクラスなど、別の(主キーでない)列の値に基づいて行われます。

コンポジット・シャーディングは、ユーザー定義のシャーディングとシステム管理のシャーディングの組合せで、必要に応じて両方の利点を活用できます。コンポジット・シャーディングでは、最初にデータがリストまたは範囲により複数のシャード領域にパーティション化され、次にコンシステント・ハッシュにより各シャード領域の複数のシャード間にさらにパーティション化されます。2つのレベルのシャーディングにより、各シャード領域のシャード間のバランスのとれたデータ分散を自動的に維持し、同時にシャード領域間にデータをパーティション化できます。

たとえば、高速なサーバーでホストされる3つのシャードをゴールド顧客に割り当て、低速のマシンでホストされる4つのシャードをシルバー顧客に割り当てるとします。顧客IDのコンシステント・ハッシュによるパーティション化を使用して、シャードの各セット内に顧客を分散する必要があります。

図4-4 コンポジット・シャーディング

「図4-4 コンポジット・シャーディング」の説明

そのような構成には2つのシャード領域を作成する必要があります。たとえば、次のGDSCTLコマンドを使用できます。

55

ADD SHARDSPACE –SHARDSPACE shspace1;ADD SHARDSPACE –SHARDSPACE shspace2;

ADD SHARD –CONNECT shard1 –SHARDSPACE shspace1;ADD SHARD –CONNECT shard2 –SHARDSPACE shspace1;ADD SHARD –CONNECT shard3 –SHARDSPACE shspace1;

ADD SHARD –CONNECT shard4 –SHARDSPACE shspace2;ADD SHARD –CONNECT shard5 –SHARDSPACE shspace2;ADD SHARD –CONNECT shard6 –SHARDSPACE shspace2;ADD SHARD –CONNECT shard7 –SHARDSPACE shspace2;

コンポジット・シャーディングでは、他のシャーディング方法と同様に、表領域を使用してシャードへのパーティションのマッピングを指定します。シャード表のデータのサブセットを異なるシャード領域に割り当てるために、次の例に示すように、各シャード領域に個別の表領域のセットを作成する必要があります。CREATE TABLESPACE SET tbs1 IN SHARDSPACE shspace1;CREATE TABLESPACE SET tbs2 IN SHARDSPACE shspace2;

ユーザー定義のデータのサブセットを異なる表領域に格納するために、Oracle Shardingには、パーティションをセットにグループ化し、パーティションの各セットを表領域のセットと関連付ける構文が用意されています。パーティション・セットのサポートは、論理的には、コンシステント・ハッシュによるパーティション化の上位に実装される高レベルのパーティション化に相当すると考えることができます。

次の例に示す文では、サービスのクラスに基づいて、シャード表をgoldとsilverという2つのパーティション・セットにパーティション化しています。各パーティション・セットが個別の表領域に格納されます。次に、各パーティション・セットのデータが、顧客IDのコンシステント・ハッシュによってさらにパーティション化されます。CREATE SHARDED TABLE customers( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250) , location_id VARCHAR2(20) , class VARCHAR2(3) , signup_date DATE , CONSTRAINT cust_pk PRIMARY KEY(cust_id, class) )PARTITIONSET BY LIST (class) PARTITION BY CONSISTENT HASH (cust_id) PARTITIONS AUTO(PARTITIONSET gold VALUES (‘gld’) TABLESPACE SET tbs1, PARTITIONSET silver VALUES (‘slv’) TABLESPACE SET tbs2);

注意:

Oracle Database 12cリリース2では、表の単一のパーティション・セットのみをシャード領域に格納できます。



4.4 サブパーティション化とシャーディングの使用Oracle Shardingは表のパーティション化に基づくため、Oracle Databaseで提供されるすべてのサブパーティション方法がシャーディングでもサポートされます。

56

サブパーティション化は各パーティションをさらに小さい部分に分割します。これはシャード内の効率的なパラレル実行、特に、シャード当たりのパーティション数が少ないときの範囲またはリストによるシャーディングの場合に役立つ可能性があります。

管理性の面では、サブパーティションを個別の表領域に割り当てて記憶域階層間で移動することで、サブパーティション化によって記憶域の階層化をサポートできます。シャーディングのスケーラビリティと可用性という利点を損なわず、パーティション・プルーニングと主キーによるパーティション単位の結合の実行を犠牲にすることなく、記憶域階層間でサブパーティションを移行できます。

次の例は、コンシステント・ハッシュと範囲によるサブパーティション化を組み合せたシステム管理のシャーディングを示しています。CREATE SHARDED TABLE customers ( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250), location_id VARCHAR2(20), class VARCHAR2(3), signup_date DATE, CONSTRAINT cust_pk PRIMARY KEY(cust_id, signup_date))TABLESPACE SET ts1PARTITION BY CONSISTENT HASH (cust_id)SUBPARTITION BY RANGE (signup_date)SUBPARTITION TEMPLATE ( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY')), SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY')), SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY')), SUBPARTITION future VALUES LESS THAN (MAXVALUE))PARTITIONS AUTO;

次の図は、この文によって作成される表を示しています。

図4-5 親パーティションの表領域に格納されるサブパーティション

「図4-5 親パーティションの表領域に格納されるサブパーティション」の説明

この例では、各サブパーティションが親パーティションの表領域に格納されます。日付によってサブパーティション化されているため、サブパーティションを個別の表領域に格納して、古いデータをアーカイブしたり、読取り専用の記憶域に移動できるようにするほうが合理的です。適切な構文を次に示します。CREATE SHARDED TABLE customers ( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250) , location_id VARCHAR2(20), class VARCHAR2(3), signup_date DATE NOT NULL

57

, CONSTRAINT cust_pk PRIMARY KEY(cust_id, signup_date))PARTITION BY CONSISTENT HASH (cust_id)SUBPARTITION BY RANGE(signup_date)SUBPARTITION TEMPLATE ( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY')) TABLESPACE SET ts1, SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY')) TABLESPACE SET ts2, SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY')) TABLESPACE SET ts3, SUBPARTITION future VALUES LESS THAN (MAXVALUE) TABLESPACE SET ts4)PARTITIONS AUTO;

シャーディングされていないデータベースの場合は、サブパーティション・テンプレートで表領域を指定すると、すべてのパーティションのサブパーティションNが同じ表領域に格納されることに注意してください。これは、シャーディングされている場合に、異なるパーティションに属するサブパーティションを個別の表領域に格納して、再シャーディングの際に移動できるようにする場合とは異なります。

サブパーティション化はコンポジット・シャーディングでも使用できます。この場合、表のデータがパーティション・セット、パーティションおよびサブパーティションの3つのレベルに編成されます。次に、3つのレベルにデータを編成する例を示します。

パーティションセット間でサブパーティションの数と境界を均一にするため、パーティションセット単位でのサブパーティション・テンプレートの指定はサポートされていません。パーティションセット単位でサブパーティションの表領域を指定する必要がある場合は、SUBPARTITIONS STORE IN句を使用できます。CREATE SHARDED TABLE customers ( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250) , location_id VARCHAR2(20), class VARCHAR2(3) NOT NULL, signup_date DATE NOT NULL, CONSTRAINT cust_pk PRIMARY KEY(cust_id, class, signup_date))PARTITIONSET BY LIST (class)PARTITION BY CONSISTENT HASH (cust_id)SUBPARTITION BY RANGE (signup_date) SUBPARTITION TEMPLATE /* applies to both SHARDSPACEs */ ( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY')) , SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY')) , SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY')) , SUBPARTITION future VALUES LESS THAN (MAXVALUE))PARTITIONS AUTO( PARTITIONSET gold VALUES (‘gld’) TABLESPACE SET tbs1 subpartitions store in(tbs1), PARTITIONSET silver VALUES (‘slv’) TABLESPACE SET tbs2 subpartitions store in(tbs2));

この例では、サブパーティションが親パーティションの表領域に格納され、サブパーティション・テンプレートは各PARTITIONSETで同じです。サブパーティションを個別の表領域に格納するために、次の構文を使用できます。CREATE SHARDED TABLE customers ( cust_id NUMBER NOT NULL, name VARCHAR2(50), address VARCHAR2(250) , location_id VARCHAR2(20)

58

, class VARCHAR2(3) NOT NULL, signup_date DATE NOT NULL, CONSTRAINT cust_pk PRIMARY KEY(class, cust_id, signup_date))PARTITIONSET BY LIST (class)PARTITION BY CONSISTENT HASH (cust_id)SUBPARTITION BY RANGE (signup_date)PARTITIONS AUTO ( PARTITIONSET gold VALUES (‘gld’) SUBPARTITION TEMPLATE ( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY')) TABLESPACE SET tbs1 , SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY')) TABLESPACE SET tbs2 , SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY')) TABLESPACE SET tbs3 , SUBPARTITION future VALUES LESS THAN (MAXVALUE) TABLESPACE SET tbs4 ), PARTITIONSET silver VALUES (‘slv’) SUBPARTITION TEMPLATE ( SUBPARTITION per1 VALUES LESS THAN (TO_DATE('01/01/2000','DD/MM/YYYY')) TABLESPACE SET tbs5 , SUBPARTITION per2 VALUES LESS THAN (TO_DATE('01/01/2010','DD/MM/YYYY')) TABLESPACE SET tbs6 , SUBPARTITION per3 VALUES LESS THAN (TO_DATE('01/01/2020','DD/MM/YYYY')) TABLESPACE SET tbs7 , SUBPARTITION future VALUES LESS THAN (MAXVALUE) TABLESPACE SET tbs8 ));


59


1. Oracle Shardingの使用2. シャード・データベース・アプリケーションの設計に関する考慮事項

5 シャード・データベース・アプリケーションの設計に関する考慮事項シャーディングの利点を活用するには、1つのシャードで実行されるデータベース・リクエストの数が最大になるように、SDBのスキーマを設計する必要があります。

次の各項で、シャード・データベース・スキーマの管理に必要な用語と概念について説明します。

シャード・データベース・スキーマ設計の考慮点データベース・スキーマの設計はシャード・データベース(SDB)のパフォーマンスとスケーラビリティに大きく影響します。スキーマの設計が不適切な場合、データおよびワークロードがシャード間にバランスよく分散されず、マルチシャード操作の割合が大きくなります。Oracle Sharding用アプリケーションの開発シャーディングは、Oracle Databaseのエンタープライズ品質を損なうことなく、要求の厳しいほとんどのOLTPアプリケーションに線形のスケーラビリティと完全な障害分離を提供します。厳密な一貫性、SQLの完全活用、JSONによる軽快な開発、セキュリティ、高可用性、バックアップおよびリカバリ、ライフサイクル管理など多くの利点があります。

5.1 シャード・データベース・スキーマ設計の考慮点

データベース・スキーマの設計はシャード・データベース(SDB)のパフォーマンスとスケーラビリティに大きく影響します。スキーマの設計が不適切な場合、データおよびワークロードがシャード間にバランスよく分散されず、マルチシャード操作の割合が大きくなります。

SDBにデータを移入した後で、表をシャーディングまたは複製するかや、シャーディング・キーなど、スキーマの多くの属性を変更することはできません。したがって、SDBをデプロイする前に次の点を慎重に考慮してください。

どの表をシャーディングするか?

どの表を複製するか?

どのシャード表をルート表にするか?

他の表をルート表にリンクするためにどの方法を使用するか?

どのシャーディング方法を使用するか?

どのシャーディング・キーを使用するか?

使用するスーパー・シャーディング・キー(シャーディング方法がコンポジットである場合)

親トピック: シャード・データベース・アプリケーションの設計に関する考慮事項

5.2 Oracle Sharding用アプリケーションの開発

60

シャーディングは、Oracle Databaseのエンタープライズ品質を損なうことなく、ほとんどの要求の厳しいOLTPアプリケーションの線形スケーラビリティと完全な障害分離を提供します。厳密な一貫性、SQLの完全活用、JSONによる軽快な開発、セキュリティ、高可用性、バックアップおよびリカバリ、ライフサイクル管理など多くの利点があります。

シャーディングは、独立したデータベース間でデータが水平にパーティション化されるデータ階層アーキテクチャです。このような構成内の各データベースをシャードと呼びます。すべてのシャードが一体的に単一の論理データベースを形成し、これはシャード・データベース(SDB)と呼ばれます。

シャーディングは、シャード・データベース・アーキテクチャに適したOLTPアプリケーションを対象としています。具体的には、次のことに注意してください。

アプリケーションは、適切に定義されたデータ・モデルおよびデータ分散戦略を必要とするほか、シャーディング・キーを使用して主にデータにアクセスする必要があります。シャーディング・キーの例には、顧客ID、アカウント番号、country_idなどがあります。

データ・モデルは、単一のルート表を持つ階層ツリー構造である必要があります。OracleShardingは任意のレベル数の階層をサポートします。

システム管理のシャーディング方法の場合、シャーディング・キーはカーディナリティが高い列に基づいている必要があります。この列の一意の値の数は、シャードの数より大幅に多い必要があります。たとえば、顧客IDはシャーディング・キーのよい候補ですが、米国の州名は適していません。

シャーディング・キーが非常に安定していて、その値がほとんど変更されることがない必要があります。

シャーディング・キーはすべてのシャード表に存在する必要があります。これにより、シャーディング・キーに基づく等価パーティション表のファミリを作成できます。シャーディング・キーは、ルート表の主キーの最初の列である必要があります。

表ファミリ内の表の結合は、シャーディング・キーを使用して実行する必要があります。

コンポジット・シャーディングを使用すると、2つのレベルのシャーディング(リストまたは範囲によるシャーディングとコンシステント・ハッシュによるシャーディング)を行うことができます。これは、2つのキー(スーパー・シャーディング・キーおよびシャーディング・キー)を提供するアプリケーションによって実現されます。

高いパフォーマンスおよび障害分離を必要とするすべてのデータベース・リクエストは、単一の値のシャーディング・キーに関連付けられているデータにのみアクセスする必要があります。データベース接続を確立するときに、アプリケーションはシャーディング・キーを渡す必要があります。これに該当する場合、リクエストは適切なシャードに直接ルーティングされます。

複数のリクエストは、それらがすべて同じシャーディング・キーに関連しているかぎり、同じセッションで実行できます。通常、そのようなトランザクションは数十行または数百行にアクセスします。単一シャードのトランザクションの例としては、オーダー入力、顧客の請求書レコードの検索と更新、およびサブスクライバのドキュメントの検索と更新があります。

複数の値のシャーディング・キーに関連付けられているデータ、またはシャーディング・キーの値が不明なデータにアクセスする必要があるデータベース・リクエストは、複数のシャードでの問合せのパラレル実行を調整する問合せコーディネータから実行する必要があります。

61

アプリケーションはOracleの統合接続プール(UCP、OCI、ODP.NET、JDBC)を使用して、シャード・データベースに接続します。

直接ルーティングおよびプロキシ・ルーティングには、個別の接続プールを使用する必要があります。直接ルーティングの場合は、読取り書込みワークロードおよび読取り専用ワークロードのために、個別のグローバル・サービスを作成する必要があります。これは、Data Guardレプリケーションが使用されている場合にのみ当てはまります。プロキシ・ルーティングの場合は、シャード・カタログ・データベースでGDS$CATALOGサービスを使用します。

関連項目:

シャードへの直接ルーティング

シャード・データベースでのプロキシ・ルーティングを使用した問合せおよびDML

親トピック: シャード・データベース・アプリケーションの設計に関する考慮事項

62


1. Oracle Shardingの使用2. シャード・データベース環境でのリクエストのルーティング

6 シャード・データベース環境でのリクエストのルーティングOracle Shardingでは、シャードへの直接(キー・ベース)ルーティング、プロキシによるルーティングおよび中間層へのルーティングをサポートされています。

次の項では、シャード・データベース環境でのルーティングについて説明します。

シャードへの直接ルーティングOracleクライアントおよび接続プールは、高パフォーマンスのデータ依存ルーティングのために接続文字列に指定されたシャーディング・キーを認識できます。接続レイヤーのシャード・ルーティング・キャッシュは、データが常駐するシャードにデータベース・リクエストを直接ルーティングするために使用されます。シャード・データベースでのプロキシ・ルーティングを使用した問合せおよびDMLシャーディングでは、シャーディング・キーを指定しない問合せのルーティングがサポートされます。これにより、データベース・アプリケーションが柔軟になり、問合せが実行されるシャードを指定することなく、表がシャーディングまたは複製されているシステムでSQL文(SELECTおよびDMLを含む)を実行できるようになります。中間層接続プールとシャード間のアフィニティの作成中間層ルーティングと呼ばれるOracle Universal Connection Pool (UCP)機能により、スマート・ルーター(F5 BigIPなど)がシャーディング・キーに関連付けられた中間層にルーティングできます。シャード・データベース・トポロジをルーター層に公開して、特定のシャーディング・キーに基づくリクエストが適切なアプリケーション中間層にルーティングされ、そこから特定のシャード・サブセットに対して接続が確立されるようにします。

6.1 シャードへの直接ルーティングOracleクライアントおよび接続プールは、高パフォーマンスのデータ依存ルーティングのために接続文字列に指定されたシャーディング・キーを認識できます。接続レイヤーのシャード・ルーティング・キャッシュは、データが常駐するシャードにデータベース・リクエストを直接ルーティングするために使用されます。

次の項では、シャードへの直接(キーベース)ルーティングについて説明します。

シャードへの直接ルーティングについてシャードへの直接(キーベース)ルーティングでは、必要なトランザクションに関連するデータが含まれている単一の関連するシャードに対して、シャーディング・キーを使用して接続が確立されます。シャーディングAPIOracle接続プールおよびドライバはOracle Shardingをサポートしています。

親トピック: シャード・データベース環境でのリクエストのルーティング

6.1.1 シャードへの直接ルーティングについて

シャードへの直接(キーベース)ルーティングでは、必要なトランザクションに関連するデータが含まれている単一の関連するシャードに対して、シャーディング・キーを使用して接続が確立されます。

63

接続のチェック時にユーザー・セッション・レベルでデータベース接続リクエストをルーティングするために、シャーディング・キーが使用されます。コンポジット・シャーディング方法では、シャーディング・キーおよびスーパー・シャーディング・キーの両方が必要となります。直接(キーベース)ルーティングでは、シャーディング・キー(またはスーパー・シャーディング・キー)を接続の一部として渡す必要があります。この情報に基づいて、指定されたシャーディング・キーまたはスーパー・シャーディング・キーに関係するデータが含まれている関連するシャードに対して、接続が確立されます。

シャードとのセッションが確立されると、すべてのSQL問合せおよびDMLが該当するシャードのスコープ内でサポートされ、実行されます。このルーティングは高速であり、シャード内トランザクションを実行するすべてのOLTPワークロードで使用されます。最高のパフォーマンスおよび可用性を必要とするすべてのOLTPワークロードに直接ルーティングを使用することをお薦めします。

Oracle Shardingをサポートするために、Oracle接続プールおよびドライバに対して重要な機能強化が行われました。JDBC、UCP (Universal Connection Pool)、OCI (OCI Session Pool)およびODP.NET (OracleData Provider for .NET)は、接続作成中にシャーディング・キーを渡すためのAPIを提供しています。Apache Tomcat、IBM Websphere、Oracle WebLogic ServerおよびJBOSSでは、JDBC/UCPのサポートを活用してシャーディングを使用できます。PHP、Python、PerlおよびNode.jsではOCIのサポートを活用できます。

シャード・トポロジ・キャッシュは、シャードとシャーディング・キーの範囲のマッピングです。Oracle統合接続プールは、このシャード・トポロジ・キャッシュをそのメモリー内に保持します。特定のシャードへの最初の接続時(プールの初期化時またはプールが新しいシャードに接続するとき)に、シャーディング・キーの範囲のマッピングがシャードから収集されて、シャード・トポロジ・キャッシュが動的に作成されます。

シャード・トポロジをキャッシュすると、シャードへの高速なパスが作成され、シャードへの接続を作成するプロセスが迅速になります。シャーディング・キーを使用して接続リクエストが実行されると、接続プールはこの特定のシャーディング・キーが存在する対応するシャードを検索します(トポロジ・キャッシュから)。一致する接続がプールで利用できる場合、プールは内部接続選択アルゴリズムを適用することによって、シャードへの接続を返します。

キャッシュされたトポロジ・マップに存在する特定のシャーディング・キーへのデータベース接続リクエストは、そのシャードに直接送られます(つまり、シャード・ディレクタがバイパスされます)。また、接続プールは、SDBからRLB通知をサブスクライブし、実行時ロード・バランシング・アドバイザに基づいて最適な接続を分配します。接続が確立されると、クライアントはシャードに対するトランザクションを直接実行します。指定したシャーディング・キーのすべてのトランザクションが実行されたら、アプリケーションはその接続をプールに返し、別のキーの接続を取得する必要があります。

一致する接続がプールにない場合は、シャーディング・キーとともに接続リクエストをシャード・ディレクタに転送することによって、新しい接続が作成されます。

プールが初期化され、シャード・トポロジ・キャッシュがすべてのシャードに基づいて作成されると、シャード・ディレクタが停止しても直接ルーティングに影響しなくなります。

関連項目:

シャードへの直接ルーティング

親トピック: シャードへの直接ルーティング

64

6.1.2 シャーディングAPI

Oracle接続プールおよびドライバはOracle Shardingをサポートしています。

JDBC、UCP、OCIおよびOracle Data Provider for .NET (ODP.NET)は、接続チェックの一部としてシャーディング・キーを認識します。Apache Tomcat、WebsphereおよびWebLogicはシャーディングのためのUCPサポートを活用し、PHP、Python、PerlおよびNode.jsはOCIサポートを活用します。

Oracle UCPのシャーディングAPI

シャード対応のアプリケーションは、createShardingKeyBuilderおよびcreateConnectionBuilderという拡張シャーディングAPIを使用してシャーディング・キーを指定することによって、特定のシャードへの接続を取得します。

大まかに言うと、アプリケーションがシャード・データベースと連携するようにするには、次の手順に従う必要があります。

1. シャード・ディレクタおよびグローバル・サービスが反映されるようにURLを更新します。

2. プール・パラメータをプール・レベルおよびシャード・レベルで設定します。

setInitialPoolSize: UCPが起動されたときに作成される初期の接続数

setMinPoolSize: 実行時にプールによって維持される接続の最小数

setMaxPoolSize: 接続プールで許可される接続の最大数を設定するためのUCPプロパティ

setMaxConnectionsPerShard: シャードごとの最大接続数の設定

3. createShardingKeyBuilderを使用してシャーディング・キー・オブジェクトを作成します。

4. createConnectionBuilderを使用して接続を確立します。

5. 特定のシャードのスコープ内でトランザクションを実行します。

例6-1 UCPシャーディングAPIを使用した接続の確立

シャーディング・キーを作成し、UCPシャーディングAPIコールを使用して接続を確立する方法を示すコード片を次に示します。...

PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource(); // Set Connection Pool propertiespds.setURL(DB_URL);pds.setUser("hr"); pds.setPassword("****");pds.setInitialPoolSize(10);pds.setMinPoolSize(20);pds.setMaxPoolSize(30); // build the sharding key object

OracleShardingKey shardingKey = pds.createShardingKeyBuilder() .subkey("[email protected]", OracleType.VARCHAR2) .build();

65

// Get an UCP connection for a shardConnection conn = pds.createConnectionBuilder() .shardingKey(shardingKey) .build();...

例6-2 UCP接続プールを使用したシャード対応アプリケーション・コードの例

この例では、プール設定をプール・レベルおよびシャード・レベルで定義しています。import java.sql.Connection;import java.sql.ResultSet;import java.sql.SQLException;import java.sql.Statement;

import oracle.jdbc.OracleShardingKey;import oracle.jdbc.OracleType;import oracle.jdbc.pool.OracleDataSource;import oracle.ucp.jdbc.PoolDataSource;import oracle.ucp.jdbc.PoolDataSourceFactory;

public class MaxConnPerShard{ public static void main(String[] args) throws SQLException { String url = "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(HOST=shard-dir1)(PORT=3216) (PROTOCOL=tcp))(CONNECT_DATA=(SERVICE_NAME=shsvc.shpool.oradbcloud)(REGION=east)))"; String user="testuser1", pwd = "testuser1"; int maxPerShard = 100, initPoolSize = 20;

PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource(); pds.setConnectionFactoryClassName(OracleDataSource.class.getName()); pds.setURL(url); pds.setUser(user); pds.setPassword(pwd); pds.setConnectionPoolName("testpool"); pds.setInitialPoolSize(initPoolSize);

// set max connection per shard pds.setMaxConnectionsPerShard(maxPerShard); System.out.println("Max-connections per shard is: "+pds.getMaxConnectionsPerShard()); // build the sharding key object int shardingKeyVal = 123; OracleShardingKey sdkey = pds.createShardingKeyBuilder() .subkey(shardingKeyVal, OracleType.NUMBER) .build();

// try to build maxPerShard connections with the sharding key Connection[] conns = new Connection[maxPerShard]; for (int i=0; i<maxPerShard; i++) { conns[i] = pds.createConnectionBuilder() .shardingKey(sdkey) .build(); Statement stmt = conns[i].createStatement(); ResultSet rs = stmt.executeQuery("select sys_context('userenv', 'instance_name'), sys_context('userenv', 'chunk_id') from dual"); while (rs.next()) { System.out.println((i+1)+" - inst:"+rs.getString(1)+", chunk:"+rs.getString(2)); } rs.close(); stmt.close(); }

System.out.println("Try to build "+(maxPerShard+1)+" connection ..."); try { Connection conn = pds.createConnectionBuilder() .shardingKey(sdkey) .build();

Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select sys_context('userenv', 'instance_name'),

66

sys_context('userenv', 'chunk_id') from dual"); while (rs.next()) { System.out.println((maxPerShard+1)+" - inst:"+rs.getString(1)+", chunk:"+rs.getString(2)); } rs.close(); stmt.close();

System.out.println("Problem!!! could not build connection as max-connections per shard exceeded"); conn.close(); } catch (SQLException e) { System.out.println("Max-connections per shard met, could not build connection any more, expected exception: "+e.getMessage()); } for (int i=0; i<conns.length; i++) { conns[i].close(); } }}

ODP.NETシャーディングAPI

シャード対応のアプリケーションは、ODP.NET API (OracleConnectionクラスのSetShardingKey(OracleShardingKey shardingKey, OracleShardingKey superShardingKey)インスタンス・メソッドなど)を使用してシャーディング・キーおよびスーパー・シャーディング・キーを指定することによって、特定のシャードへの接続を取得します。

大まかに言うと、.NETアプリケーションがシャード・データベースと連携するようにするには、次の手順を実行する必要があります。

1. ODP.NET管理対象外ドライバを使用します。

シャーディングは、ODP.NET接続プールを使用する場合もODP.NET接続プールを使用しない場合もサポートされます。各プールは、シャード・データベースの異なるシャードへの接続を保持できます。

2. OracleShardingKeyクラスを使用して、シャーディング・キー、およびスーパー・シャーディング・キーの別のインスタンスを設定します。

3. ODP.NETが指定したシャーディング・キーおよびスーパー・シャーディング・キーを使用する接続を返すことができるように、OracleConnection.Open()を呼び出す前に、OracleConnection.SetShardingKey()メソッドを呼び出します。

これらのキーは、OracleConnectionがクローズ状態のときに設定する必要があります。そうしないと、例外がスローされます。

例6-3 ODP.NETを使用したシャード対応アプリケーション・コードの例using System;using Oracle.DataAccess.Client; class Sharding{ static void Main() { OracleConnection con = new OracleConnection ("user id=hr;password=hr;Data Source=orcl;"); //Setting a shard key OracleShardingKey shardingKey = new OracleShardingKey(OracleDbType.Int32, 123); //Setting a second shard key value for a composite key shardingKey.SetShardingKey(OracleDbType.Varchar2, "gold"); //Creating and setting the super shard key OracleShardingKey superShardingKey = new OracleShardingKey();

67

superShardingKey.SetShardingKey(OracleDbType.Int32, 1000); //Setting super sharding key and sharding key on the connection con.SetShardingKey(shardingKey, superShardingKey); con.Open();

//perform SQL query }}

関連項目:

Oracle Shardingに対するJDBCのサポートの詳細は、Oracle Database JDBC開発者ガイドを参照してください

Oracle Shardingに対するUCPのサポートの詳細は、Oracle Universal Connection Pool開発者ガイドを参照してください

Oracle Shardingに対するODP.NETのサポートの詳細は、Microsoft Windows用Oracle Data Provider for.NET開発者ガイドを参照してください

シャードを使用するためのOCIインタフェースの詳細は、Oracle Call Interfaceプログラマーズ・ガイドを参照してください

親トピック: シャードへの直接ルーティング

6.2 シャード・データベースでのプロキシ・ルーティングを使用した問合せおよびDML

シャーディングでは、シャーディング・キーを指定しない問合せのルーティングがサポートされます。これにより、データベース・アプリケーションが柔軟になり、問合せが実行されるシャードを指定することなく、表がシャーディングまたは複製されているシステムでSQL文(SELECTおよびDMLを含む)を実行できるようになります。

次のトピックでは、プロキシ・ルーティングについてさらに詳しく説明します。

シャード・データベースでのプロキシ・ルーティングについてプロキシ・ルーティングは、開発者の利便性のための補助的な使用パターンです。これを使用するには、コーディネータに対して接続を確立する必要があります。マルチシャード問合せコーディネータマルチシャード問合せコーディネータ・データベースには、シャード・トポロジのメタデータが含まれており、シャード・データベースの問合せ処理をサポートします。プロキシ・ルーティングを使用した問合せおよびDMLプロキシ・ルーティングを使用すると、データを集計したり、複数のシャードに関するレポートを作成したりできます。また、データベース・アプリケーションが柔軟になり、文が実行されるシャーディング・キーを(接続中に)指定することなく、表がシャーディングまたは複製されているシステムでSQL文(SELECT、DMLを含む)を実行できるようになります。単一シャード問合せのためのプロキシ・ルーティング単一シャード問合せは、1つのシャードでのみデータをスキャンする必要があり、他のシャードでデータを検索する必要がない問合せです。マルチシャード問合せのためのプロキシ・ルーティングマルチシャード問合せでは、複数のシャードでデータをスキャンする必要があり、各シャードでの処理は他のシャードから独立しています。プロキシ・ルーティングでサポートされる問合せの形態Oracle Shardingでは、単一シャード問合せとマルチシャード問合せの形態がサポートされていま

68













すが、いくつかの制限事項があります。プロキシ・ルーティング用の実行計画マルチシャード問合せでは、各シャードが問合せ内の他のシャードの計画とは異なる可能性がある別個の実行計画を生成します。


6.2.1 シャード・データベースでのプロキシ・ルーティングについて

プロキシ・ルーティングは、開発者の利便性のための補助的な使用パターンです。これを使用するには、コーディネータに対して接続を確立する必要があります。

シャード・カタログ・データベースには、コーディネータ・データベースの役割があります。コーディネータは、シャード・トポロジのメタデータを使用し、シャード・データベースの問合せ処理をサポートします。SQLコンパイラは、関連するシャードを自動的に識別し、関与するすべてのシャード間での問合せの実行を調整します。コーディネータとのセッションが確立されると、変更を必要とせずにSQL問合せおよびDMLが実行されます。

プロキシ・ルーティングは次のシナリオに適しています。

接続中にアプリケーションがシャーディング・キーを渡すことができない場合

アプリケーションが複数のシャードに存在するシャード表のデータにアクセスする必要がある場合

レポート(販売データの集計など)に一般的に使用されるSQL問合せ

コーディネータを使用したルーティングでは、接続中にシャーディング・キー値を渡すことなく、アプリケーションがSQL文を発行できます。コーディネータのSQLコンパイラは問合せを分析して問合せの断片にリライトし、それらが関与するシャードに送信されて実行されます。問合せは、関与するシャードでほとんどの問合せ処理が行われて、コーディネータによって集計されるようにリライトされます。要するに、シャードはコーディネータによって実行された問合せの計算ノードとして動作します。計算がデータのあるシャードにプッシュされるため、シャードとコーディネータの間のデータの移動が減少します。この仕組みによって、コーディネータの処理負荷ができるだけ多くのシャードに移動するため、リソースを効率的に使用できるようになります。

アプリケーションでワークロードを直接ルーティングとプロキシ・ルーティングに分離することをお薦めします。これらのワークロードのために、個別の接続プールを作成する必要があります。

親トピック: シャード・データベースでのプロキシ・ルーティングを使用した問合せおよびDML

6.2.2 Oracle Shardingマルチシャード問合せコーディネータ

マルチシャード問合せコーディネータ・データベースには、シャード・トポロジのメタデータが含まれており、シャード・データベースの問合せ処理をサポートします。

マルチシャード・コーディネータへの接続

マルチシャード問合せを実行するには、シャード・カタログ・データベースでGDS$CATALOGサービスを使用してマルチシャード・コーディネータに接続します。sqlplus app_schema/app_schema@shardcatvm:1521/GDS\$CATALOG.oradbcloud

69

マルチシャード・コーディネータの高可用性

マルチシャード・コーディネータの可用性はプロキシ・ルーティング・ベースのワークロードに影響するため、ファスト・スタート・フェイルオーバーを有効にして最大可用性保護モード(データ損失のないフェイルオーバー)でData Guardを使用してコーディネータを保護することをお薦めします。コーディネータはさらなる可用性およびスケーラビリティのためにオプションでOracle RAC対応にすることができます。

マルチシャード問合せワークロードのスケーラビリティおよび可用性を向上させるために、読取り専用モードのOracle Active Data Guardスタンバイ・シャード・カタログ・データベースをマルチシャード問合せコーディネータとして機能させることができます。カタログ・データベースのアクティブなレプリカごとに、特別なコーディネータ・サービスGDS$COORDINATOR.cloud_nameが実行されます(cloud_nameは、GDSCTLコマンドcreate shardcatalogのconfignameパラメータに指定した値であり、デフォルト値はoradbcloudです)。このサービスは、すべてのシャード・ディレクトリに登録されます。クライアントは、任意のレプリカでこのサービスに接続し、マルチシャード問合せを実行することで、ランタイム・ロード・バランシングについてはシャード・ディレクタでマルチシャード問合せワークロードを分散し、Oracle Shardingフレームワークの中心的なコンポーネントであるプライマリ・シャード・カタログの負荷を軽減できます。また、データベースのリージョンが設定され、クライアントが接続文字列でリージョンを指定すると、シャード・ディレクタは地域アフィニティに関する接続をルーティングします。

マルチシャード問合せコーディネータの可用性は、直接ルーティングを使用したワークロードに影響を与えません。

マルチシャード問合せコーディネータ・データベースのサイズ設定

シャード・カタログおよびマルチシャード問合せコーディネータは次の重要な情報をホストします。

シャード・データベース・トポロジのメタデータ

シャード・アプリケーションのスキーマ

重複表のマスター・コピー

メタデータおよびスキーマのサイズは通常どおりです。ただし、マルチシャード問合せコーディネータのサイズを決定するときに、重複表の数およびそれらが占有する領域を計画する必要があります。

それに加えて、CPU、I/Oおよびメモリーが集中的に使用されることがあるプロキシ・ルーティングを処理するために、SQL問合せおよび処理されるデータ量に基づいて、マルチシャード問合せコーディネータのサイズを設定する必要もあります。

プロキシ・ルーティングの回復力可用性およびスケーラビリティのために、ファスト・スタート・フェイルオーバーを持つDataGuardを使用したり、オプションでOracle RAC対応にすることによって、コーディネータを保護することをお薦めします。


6.2.2.1 プロキシ・ルーティングの回復力

可用性およびスケーラビリティのために、ファスト・スタート・フェイルオーバーを持つDataGuardを使用したり、オプションでOracle RAC対応にすることによって、コーディネータを保護することをお薦めします。

70

コーディネータの障害は、コーディネータを介してルーティングされるマルチシャード問合せおよび単一シャード問合せに影響します。問合せの実行中の障害のシナリオ、およびプロキシ・ルーティングの予期される動作を次に示します。

関与するシャードが停止している場合、コーディネータは同じデータを使用してその問合せを別のシャードに送信します。

関与するシャードに対して問合せを実行しているときに障害が発生した場合、ユーザーはエラーを受け取ります。

親トピック: Oracle Shardingマルチシャード問合せコーディネータ

6.2.3 プロキシ・ルーティングを使用した問合せおよびDML

プロキシ・ルーティングを使用すると、データを集計したり、複数のシャードに関するレポートを作成したりできます。また、データベース・アプリケーションが柔軟になり、文が実行されるシャーディング・キーを(接続中に)指定することなく、表がシャーディングまたは複製されているシステムでSQL文(SELECT、DMLを含む)を実行できるようになります。

集計とシャーディング・キーを使用しないSQL実行のどちらのユースケースでも、ユーザーは直接(キーベース)ルーティングと比べて低いレベルのパフォーマンスを受け入れます。

シャード・データベース(SDB)には、2つのタイプの表(シャード表および重複表)があります。

シャード表はシャーディング・キーによって等価パーティション化されます。S=S1 U S2 U … U Sn

重複表はすべてのシャードで同一です。R = R1 = … = Rn

SDBのプロキシ・ルーティングは、アプリケーションが関連するシャードを指定することなく、シャード表および重複表のデータにアクセスする通常のSQL問合せを実行するための透過的なメカニズムを提供します。SQLコンパイラは、関連するシャードを自動的に識別し、関与するすべてのシャード間での問合せの実行を調整します。コーディネータとシャードの間の通信のために、データベース・リンクが使用されます。

大まかに言うと、コーディネータは各受信問合せQを2つの問合せ(CQおよびSQ)で構成される分配形式にリライトします。ここで、SQ (シャード問合せ)は関与する各シャードで実行されるQの部分であり、CQ (コーディネータ問合せ)はコーディネータ・シャードで実行される部分です。Q => CQ ( Shard_Iterator( SQ ) )

次の例は、集計問合せQ1をシャード間実行のためにQ1'にリライトしています。Q1 : SELECT COUNT(*) FROM customers

Q1’: SELECT SUM(sc) FROM (Shard_Iterator(SELECT COUNT(*) sc FROM s1 (i) ))

このプロセスには2つの重要な要素があります。(1)関連するシャードを識別し、(2)分配形式でシャードごとに繰り返すように問合せをリライトすることです。

コーディネータ・データベースでの問合せのコンパイル中に、問合せコンパイラはシャーディング・キーに対する述語を分析し、関与するシャード(つまり、問合せで参照されるシャード表の行がある

71

シャード)を識別するために使用できる述語を抽出します。残りのシャードは除外されたシャードと呼ばれます。

関与するシャードが1つのみ識別された場合は、問合せ全体がそのシャードにルーティングされて、すべてが実行されます。これは単一シャード問合せと呼ばれます。関与する複数のシャードがある場合、その問合せはマルチシャード問合せと呼ばれ、リライトされます。リライト処理では、問合せによって計算される式および問合せの形態が考慮されます。


6.2.4 単一シャード問合せのためのプロキシ・ルーティング

単一シャード問合せは、1つのシャードでのみデータをスキャンする必要があり、他のシャードでデータを検索する必要がない問合せです。

単一シャード問合せは、特定のシャードに接続してそのシャードに問合せを発行するクライアントに似ています。このシナリオでは、問合せ全体が関与する単一のシャードで実行され、コーディネータは処理された行をクライアントに返すだけです。コーディネータの計画は、リモート・マップ・カーソルに似ています。

たとえば、次の問合せは、顧客123のデータが1つのシャードのみにあるため、そのシャードにすべてマップされます。SELECT count(*) FROM customers c, orders o WHERE c.custno = o.custno and c.custno = 123;

この問合せには、問合せのコンパイル時(リテラル)または問合せ開始時(バインド)に判明する1つのシャードにのみマップするシャード・キーの条件が含まれています。問合せは該当するシャードですべて実行されます。

単一シャード問合せでは次のものがサポートされます。

等価およびINリスト(Area = 'West'など)

リテラル、バインド、またはリテラルとバインドの式を含む次のような条件Area = :bind

Area = CASE :bind <10 THEN ‘West’ ELSE ‘East’ END

SELECT、UPDATE、DELETE、INSERT、FOR UPDATEおよびMERGE。UPSERTはサポートされていません。


6.2.5 マルチシャード問合せのためのプロキシ・ルーティング

マルチシャード問合せでは、複数のシャードでデータをスキャンする必要があり、各シャードでの処理は他のシャードから独立しています。

マルチシャード問合せは、複数のシャードにマップされ、結果をクライアントに送信する前に、コーディネータが処理する必要がある場合があります。たとえば、次の問合せは各顧客によって発注されたオーダー数をフェッチします。SELECT count(*), c.custno FROM customers c, orders o WHERE c.custno = o.custno GROUP BY c.custno;

72

この問合せは、コーディネータによって次のように変換されます。SELECT sum(count_col), custno FROM (SELECT count(*) count_col, c.custno FROM customers c, orders o WHERE c.custno = o.custno GROUP BY c.custno) GROUP BY custno;

インライン問合せブロックは、リモート・マップ問合せブロックのように各シャードにマップされます。コーディネータは、すべてのシャードからの結果セットに対して、さらなる集計およびGROUPBYを実行します。各シャードでの実行の単位はインライン問合せブロックです。

マルチシャード問合せではSELECT文のみがサポートされます。問合せは、単一のシャード(等価フィルタの場合)またはすべてのシャード(シャーディング・キーにフィルタ述語がない場合)にアクセスできます。

マルチシャード問合せでの一貫性レベルの指定シャード間でマルチシャード問合せを実行するときに、初期化パラメータMULTISHARD_QUERY_DATA_CONSISTENCYを使用して様々な一貫性レベルを設定できます。


6.2.5.1 マルチシャード問合せでの一貫性レベルの指定

シャード間でマルチシャード問合せを実行するときに、初期化パラメータMULTISHARD_QUERY_DATA_CONSISTENCYを使用して様々な一貫性レベルを設定できます。

マルチシャード問合せでは、様々な一貫性レベルを指定できます。たとえば、一部の問合せでシャード間のSCN同期のコストを回避する必要がある場合は、それらのシャードをグローバルに分散できます。別のユース・ケースとして、レプリケーション用のスタンバイを使用している場合は、プライマリとそのスタンバイから結果がフェッチされる可能性があるため、マルチシャード問合せで少し古いデータが許容されます。

デフォルトのモードは厳密な一貫性であり、すべてのシャード間でSCN同期が実行されます。他のモードでは、SCN同期はスキップされます。delayed_standby_allowedレベルでは、ロード・バランシングなどの要因に応じてスタンバイからもデータをフェッチでき、古いデータを含めることができます。

このパラメータは、システム・レベルまたはセッション・レベルで設定できます。

関連項目:

MULTISHARD_QUERY_DATA_CONSISTENCYの使用方法の詳細は、Oracle Databaseリファレンスを参照してください。

親トピック: マルチシャード問合せのためのプロキシ・ルーティング

6.2.6 プロキシ・ルーティングでサポートされる問合せの形態

Oracle Shardingでは、単一シャード問合せとマルチシャード問合せの形態がサポートされていますが、いくつかの制限事項があります。

制限事項

73

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=REFRN-GUID-313D79DE-1A42-482C-BF41-6F821C8F3307

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=REFRN-GUID-313D79DE-1A42-482C-BF41-6F821C8F3307

Oracle Shardingでの問合せコンストラクトの使用に関する制限事項は、次のとおりです。

DMLの制限事項は、下の「トランザクション」の項の例を参照してください。

CONNECT BY問合せはサポートされていません。

ユーザー定義PL/SQLは、SELECT句にかぎり、マルチシャード問合せで使用できます。WHERE句で指定された場合は、エラーがスローされます。

XLATE、XML問合せおよびオブジェクト型の列はサポートされていません。

コーディネータのシャード表のIASはサポートされていません。

MODEL句はサポートされていません。

重複表のみが関係する問合せ

重複表のみが関係する問合せの場合、問合せの形態に制限はありません。問合せはコーディネータで実行されます。

シャード表のみが関係する問合せ

単一表の問合せの場合、問合せにはシャードを限定するシャーディング・キーに対する等価フィルタを指定できます。結合問合せの場合は、すべての表がシャーディング・キーに対する等価フィルタを使用して結合される必要があります。次の例では、シャード表が関係する問合せの例をいくつか示します。

シャーディング・キーのみを使用する等価結合の内部結合SELECT … FROM s1 INNER JOIN s2 ON s1.sk=s2.sk WHERE any_filter(s1) AND any_filter(s2)

シャーディング・キーのみを使用する左外部結合SELECT … FROM s1 LEFT OUTER JOIN s2 ON s1.sk=s2.sk

右外部結合(左外部結合と同じ)

SELECT … FROM s1 RIGHT OUTER JOIN s2 ON s1.sk=s2.sk

シャーディング・キーのみを使用する完全外部結合(等価結合を必要とするネイティブが有効な場合のみ)

SELECT … FROM s1 FULL OUTER JOIN s2 ON s1.sk=s2.skWHERE any_filter(s1) AND any_filter(s2)

シャード表および重複表が関係する問合せ

シャード表と重複表が関係する問合せは、シャーディング・キーに対する述語に応じて、単一シャード問合せまたはマルチシャード問合せになります。唯一の違いは、各シャードで重複している非シャード表が問合せに含まれていることです。

シャード表と重複表の結合では、任意の列で、任意の比較演算子(= < > <= >=)または任意の結合式を使用できます。結合パターンの例を次に示します。

内部結合

74

SELECT … FROM s1 INNER JOIN r1 ON any_join_condition(s1,r1) WHERE any_filter(s1) AND any_filter(r1)

左/右外部結合

シャード表がLEFT OUTER JOINの最初の表であるSELECT … FROM s1 LEFT OUTER JOIN r1 ON any_join_condition(s1,r1) WHERE any_filter(s1) AND any_filter(r1)

SELECT … FROM r1 LEFT OUTER JOIN s1 ON any_join_condition(s1,s2) AND any_filter(r1) AND filter_one_shard(s1)

シャード表がRIGHT OUTER JOINの2番目の表であるSELECT … FROM r1 RIGHT OUTER JOIN s1 ON any_join_condition(s1,r1) WHERE any_filter(s1) AND any_filter(r1)

SELECT … FROM s1 RIGHT OUTER JOIN r1 ON any_join_condition(s1,s2) AND filter_one_shard(s1) AND any_filter(r1)

完全外部結合SELECT … FROM s1 FULL OUTER JOIN r1 ON s1.sk=s2.skWHERE any_filter(s1) AND any_filter(s2)

セミ結合(EXISTS)

SELECT … FROM s1 EXISTS (SELECT 1 FROM r1 WHERE r1.anykey=s1.anykey)

SELECT … FROM r1 EXISTS (SELECT 1 FROM s1 WHERE r1.anykey=s1.anykey and filter_one_shard(s1))

アンチ結合(NOT EXISTS)

SELECT … FROM s1 NOT EXISTS (SELECT 1 FROM r1 WHERE r1.anykey=s1.anykey)

左/右外部結合

重複表がLEFT OUTER JOINの最初の表であるか、シャード表が最初の表でシャーディング・キーに対するフィルタ述語に基づいて単一のシャードにマップされます。SELECT … FROM r1 LEFT OUTER JOIN s1 ON any_join_condition(s1,s2) AND any_filter(r1) AND any_filter(s1)

重複表がRIGHT OUTER JOINの2番目の表であるか、シャード表が2番目の表でシャーディング・キーに対するフィルタ述語に基づいて単一のシャードにマップされます。SELECT … FROM s1 RIGHT OUTER JOIN r1 ON any_join_condition(s1,s2) AND any_filter (s1) AND any_filter(r1)

完全外部結合

複数のシャードへのアクセスが必要となるシャード表:

SELECT … FROM s1 FULL OUTER JOIN r1 ON s1.non_sk=s2.non_skWHERE any_filter(s1) AND any_filter(s2)

セミ結合(EXISTS)

複数のシャードへのアクセスが必要となる副問合せのシャード表。

75

SELECT … FROM r1 EXISTS (SELECT 1 FROM s1 WHERE r1.anykey=s1.anykey)

アンチ結合(NOT EXISTS)

シャード表が副問合せにあります:

SELECT … FROM r1 NOT EXISTS (SELECT 1 FROM s1 WHERE r1.anykey=s1.anykey

集計関数

次の集計はプロキシ・ルーティングによってサポートされます。

COUNT

SUM

MIN

MAX

AVG

マルチシャード問合せとグローバルCR

マルチシャード問合せでは、すべてのシャードで最も大きい共通SCNで問合せを発行することによって、グローバルな読込み一貫性(CR)を維持する必要があります。一貫性レベルを設定する方法の詳細は、マルチシャード問合せでの一貫性レベルの指定を参照してください。

トランザクション

1つのシャードのみに影響するDML文はサポートされます。例:

update S1 set col = … where sk = <constant>;

複数のシャードに影響するDML文はサポートされません。例:

update S1 set col = …;

1つのトランザクション内では、複数の単一シャードDMLを異なるシャードに対して実行できます。例:

insert into S1 values (…);Update S1 set col = … where sk = constant;Delete S1 where sk = constant;Commit;

マルチシャードDMLの場合、コーディネータはデータベース・リンクを使用して分散トランザクションを開始し、2フェーズ・コミットを実行して分散トランザクションの一貫性を保証します。インダウト・トランザクションの場合、データベース管理者はそれを手動でリカバリする必要があります。

マルチシャード問合せでのヒントの受け渡し

コーディネータに対する元の問合せで指定したヒントは、シャードに伝播されます。

マルチシャード問合せでの実行速度低下のトレースとトラブルシューティング

76

クエリー・リライトおよびシャード・プルーニングをトレースするには、コーディネータに対してトレース・イベントshard_sqlを設定します。観測される一般的なパフォーマンス問題の1つは、シャーディングの一定の制限により、GROUP BYがシャードにプッシュされない場合です。考えられるすべての操作がシャードにプッシュされ、シャードからの結果を統合するためのコーディネータでの処理が最低限であるかどうかを確認します。


6.2.7 プロキシ・ルーティング用の実行計画

マルチシャード問合せでは、各シャードが問合せ内の他のシャードの計画とは異なる可能性がある別個の実行計画を生成します。

SQLフラグメントの実行計画を参照するために、個々のシャードに接続する必要はありません。dbms_xplan.display_cursor()で提供されるインタフェースは、シャードで実行されたSQLセグメントの計画をコーディネータに表示します。また、[V/X]$SHARD_SQLは、マルチシャード問合せのシャードSQLフラグメントをターゲットのシャード・データベースに一意にマップします。

dbms_xplan.display_cursor()のSQLセグメント・インタフェース

2つのインタフェースを使用して、シャードで実行されたSQLセグメントの計画を表示します。これらのインタフェースは、引数としてシャードIDを取り、指定されたシャードの計画を表示します。ALL_SHARDS形式では、すべてのシャードの計画が表示されます。

シャードのすべての計画を出力するには、次に示すようにALL_SHARDS形式を使用します。select * from table(dbms_xplan.display_cursor(sql_id=>:sqlid, cursor_child_no=>:childno, format=>'BASIC +ALL_SHARDS‘, shard_ids=>shard_ids))

シャードの計画を選択して出力するには、display_cursor()関数内でシャードIDを渡します。複数のシャードの計画を出力する場合は、次に示すようにshard_idsパラメータで目的のシャードIDを含む数値の配列を渡します。select * from table(dbms_xplan.display_cursor(sql_id=>:sqlid, cursor_child_no=>:childno, format=>'BASIC', shard_ids=>ids))

1つのシャードの計画を返すには、次に示すようにshard_idパラメータにシャードIDを直接渡します。select * from table(dbms_xplan.display_cursor(sql_id=>:sqlid, cursor_child_no=>:childno, format=>'BASIC', shard_id=>1))

[V/X]$SHARD_SQL

[V/X]$SHARD_SQLは、マルチシャード問合せのシャードSQLフラグメントをターゲットのシャード・データベースに一意にマップします。このビューは、特定のマルチシャード問合せのシャードSQLフラグメントごとにアクセスされたシャードのリストがシャード・コーディネータ・データベースに格納されている場合にのみ関連します。マルチシャード問合せを実行するたびに、異なるシャードのセットに対してシャードSQLフラグメントを実行できるため、実行のたびにシャードIDが更新されます。このビューには、各リモート・ノードのシャードSQLフラグメントのSQL IDと、シャードSQLフラグメントが実行されたシャードIDが保持されています。

77

Name Null? Type----------------------------------------- -------- ---------------------------- SQL_ID VARCHAR2(13) CHILD_NUMBER NUMBER NODE_ID NUMBER SHARD_SQL_ID VARCHAR2(13) SHARD_ID NUMBER SHARD_CHILD_NUMBER NUMBER

SQL ID - コーディネータ上のマルチシャード問合せのSQL ID

CHILD_NUMBER - コーディネータ上のマルチシャード問合せのカーソル子番号

NODE - マルチシャード問合せのシャードSQLフラグメントのリモート・ノードのID

SHARD_SQL_ID - 指定されたリモート・ノードIDに対するシャードSQLフラグメントのSQL ID

SHARD_ID - シャードSQLフラグメントが実行されたシャードのID

SHARD_CHILD_NUMBER - シャードに対するシャードSQLフラグメントのカーソル子番号(デフォルトは0)

シャード・データベースに対するマルチシャード問合せと実行計画の例を次に示します。SQL> select count(*) from departments a where exists (select distinct department_id from departments b where b.department_id=60);------------------------------------------------| Id | Operation | Name |------------------------------------------------| 0 | SELECT STATEMENT | || 1 | SORT AGGREGATE | || 2 | FILTER | || 3 | VIEW | VW_SHARD_377C5901 || 4 | SHARD ITERATOR | || 5 | REMOTE | || 6 | VIEW | VW_SHARD_EEC581E4 || 7 | SHARD ITERATOR | || 8 | REMOTE | |------------------------------------------------

V$SHARD_SQLビューに対するSQL_IDの問合せ。SQL> Select * from v$shard_sql where SQL_ID = ‘1m024z033271u’;SQL_ID NODE_ID SHARD_SQL_ID SHARD_ID------------- ------- -------------- --------1m024z033271u 5 5z386yz9suujt 11m024z033271u 5 5z386yz9suujt 11 1m024z033271u 5 5z386yz9suujt 21 1m024z033271u 8 8f50ctj1a2tbs 11

関連項目:

Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

Oracle Databaseリファレンス


6.3 中間層接続プールとシャード間のアフィニティの作成

中間層ルーティングと呼ばれるOracle Universal Connection Pool (UCP)機能により、スマート・ルーター(F5 BigIPなど)がシャーディング・キーに関連付けられた中間層にルーティングできます。シャー

78

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ARPLS-GUID-BEE6D488-0381-4864-9B19-6299DE2B6210

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ARPLS-GUID-BEE6D488-0381-4864-9B19-6299DE2B6210

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=REFRN-GUID-35400A54-B329-4C50-96AB-830152437737

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=REFRN-GUID-35400A54-B329-4C50-96AB-830152437737

ド・データベース・トポロジをルーター層に公開して、特定のシャーディング・キーに基づくリクエストが適切なアプリケーション中間層にルーティングされ、そこから特定のシャード・サブセットに対して接続が確立されるようにします。

一般的なOracle Sharding環境では、中間層接続プールはデータベース・リクエストを特定のシャードにルーティングします。このため、各中間層接続プールが各シャードへの接続を確立する状況をまねくことがあります。この場合、データベースへの接続が多くなりすぎる可能性があります。この問題は、中間層とシャード間にアフィニティを作成することで解決できます。このシナリオでは、各データ・センターまたはクラウドに中間層(Webサーバー、アプリケーション・サーバー)を確保し、クライアント・データ(クライアント・シャーディング・キーに対応する)を含むシャードが存在する中間層にクライアント・リクエストを直接ルーティングすることが理想的です。この種の設定によく使用される用語はスイム・レーンです。各スイムレーンは、Webサーバーからアプリケーション・サーバー、データベースへと至る専用のスタックです。

Oracle Universal Connection Pool (UCP)は、関連する中間層にクライアント・リクエストをルーティングするために使用できる中間層ルーティングAPIを提供することで、この問題を解決します。UCP中間層APIは、OracleShardRoutingCacheクラスによって公開されます。このクラスのインスタンスはUCP内部シャード・ルーティング・キャッシュを表し、ユーザー、パスワード、URLなどの接続プロパティを指定して作成できます。ルーティング・キャッシュは、シャーディング・カタログに接続して、シャード・マッピング・トポロジへのキーを取得し、キャッシュに格納します。

ルーティング・キャッシュはUCP中間層API getShardInfoForKey(shardKey,superShardKey)によって使用されます。これは、シャーディング・キーを入力として受け入れ、入力シャーディング・キーにマップされたShardInfoインスタンスのセットを返します。ShardInfoインスタンスは、シャードの一意のシャード名と優先度をカプセル化します。中間層APIを使用するアプリケーションは、戻された一意のシャード名の値を、特定のシャードへの接続がある中間層にマップできます。ルーティング・キャッシュは、各ONSイベントをサブスクライブすることによってチャンクの分割または他のシャードへの移動時に自動的に更新されます。

次のコード例は、Oracle UCP中間層ルーティングAPIの使用方法を示しています。

例6-4 UCP APIを使用した中間層ルーティングimport java.sql.SQLException;import java.util.Properties;import java.util.Random;import java.util.Set;

import oracle.jdbc.OracleShardingKey;import oracle.jdbc.OracleType;import oracle.ucp.UniversalConnectionPoolException;import oracle.ucp.routing.ShardInfo;import oracle.ucp.routing.oracle.OracleShardRoutingCache;

/** * The code example illustrates the usage of UCP's mid-tier routing feature. * The API accepts sharding key as input and returns the set of ShardInfo * instances mapped to the sharding key. The ShardInfo instance encapsulates * unique shard name and priority. The unique shard name then can be mapped * to a mid-tier server which connects to a specific shard. * */public class MidtierShardingExample {

private static String user = "testuser1"; private static String password = "testuser1";

// catalog DB URL private static String url = "jdbc:oracle:thin:@//hostName:1521/catalogServiceName"; private static String region = "regionName";

public static void main(String args[]) throws Exception { testMidTierRouting();

79

}

static void testMidTierRouting() throws UniversalConnectionPoolException, SQLException {

Properties dbConnectProperties = new Properties(); dbConnectProperties.setProperty(OracleShardRoutingCache.USER, user); dbConnectProperties.setProperty(OracleShardRoutingCache.PASSWORD, password); // Mid-tier routing API accepts catalog DB URL dbConnectProperties.setProperty(OracleShardRoutingCache.URL, url);

// Region name is required to get the ONS config string dbConnectProperties.setProperty(OracleShardRoutingCache.REGION, region);

OracleShardRoutingCache routingCache = new OracleShardRoutingCache( dbConnectProperties);

final int COUNT = 10; Random random = new Random();

for (int i = 0; i < COUNT; i++) { int key = random.nextInt(); OracleShardingKey shardKey = routingCache.getShardingKeyBuilder() .subkey(key, OracleType.NUMBER).build(); OracleShardingKey superShardKey = null;

Set<ShardInfo> shardInfoSet = routingCache.getShardInfoForKey(shardKey, superShardKey);

for (ShardInfo shardInfo : shardInfoSet) { System.out.println("Sharding Key=" + key + " Shard Name=" + shardInfo.getName() + " Priority=" + shardInfo.getPriority()); } }

}}

関連項目

UCPを使用した中間層ルーティング


80

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=JJUCP-GUID-6B3483EE-6E38-4B76-AAAC-0192E5827C3A

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=JJUCP-GUID-6B3483EE-6E38-4B76-AAAC-0192E5827C3A


1. Oracle Shardingの使用2. シャード・レベルの高可用性

7 シャード・レベルの高可用性Oracle Shardingは、シャード・レベルの高可用性と障害回復のためにOracle Databaseレプリケーション・テクノロジに統合されています。

次の各項で、Oracleのレプリケーション・テクノロジを使用してシャード・データベースの高可用性を実現する方法を説明します。

シャーディングとレプリケーションについてOracle Shardingは、Oracleのレプリケーションおよび障害時リカバリ・テクノロジであるOracleData GuardおよびOracle GoldenGateと緊密に統合されています。シャード・データベースでのOracle Data Guardの使用Oracle Data Guardのレプリケーションは、高可用性およびデータ保護のために、シャード(プライマリ)の1つ以上の同期されたコピー(スタンバイ)を維持します。スタンバイはローカルまたはリモートにデプロイでき、Oracle Active Data Guardを使用する場合は、読取り専用アクセスでオープンすることもできます。シャード・データベースでのOracle GoldenGateの使用Oracle GoldenGateは、すべてのシャードが書込み可能で、各シャードをシャードグループ内の別のシャードに部分的にレプリケートできるファイングレイン・アクティブ-アクティブ・レプリケーションのために使用されます。

7.1 シャーディングとレプリケーションについてOracle Shardingは、Oracleのレプリケーションおよび障害時リカバリ・テクノロジであるOracle DataGuardおよびOracle GoldenGateと緊密に統合されています。

レプリケーションによって高可用性、障害回復、および読取りのスケーラビリティ向上が実現します。レプリケーションの単位にはシャード、シャードの一部またはシャードのグループがあります。

シャード・データベースのレプリケーション・トポロジは、GDSCTLコマンド構文を使用して宣言的に指定します。2つのテクノロジ(Oracle Data GuardとOracle GoldenGate)のいずれかを選択して、データをレプリケートできます。Oracle Shardingは指定されたレプリケーション・トポロジを自動的にデプロイし、データ・レプリケーションを有効にします。

シャード・データベースの可用性は、1つ以上のシャードが停止したり、処理速度が低下しても影響されません。個別のシャードレベルの高可用性(Oracle Active Data GuardまたはOracle GoldenGate)を提供するために、レプリケーションが使用されます。レプリケーションはシャード・データベースが作成されると自動的に構成およびデプロイされます。オプションで、シャードレベルの高可用性のために、レプリケーションによって補完されるOracle RACを使用すると、クラスタが停止した場合にシャードレベルのデータの可用性を維持できます。Oracle Shardingは、計画外の停止が発生したときに、データベース接続をシャードからレプリカに自動的にフェイルオーバーします。

シャードの高可用性としてOracle GoldenGateを選択するケースOracle Shardingの高可用性ソリューションとしてOracle GoldenGateを採用するのはどのような場合でしょうか。

81

親トピック: シャードレベルの高可用性

7.1.1 シャードの高可用性としてOracle GoldenGateを選択するケース

Oracle Shardingの高可用性ソリューションとしてOracle GoldenGateを採用するのはどのような場合でしょうか。

次の場合は、高可用性ソリューションとしてOracle GoldenGateが適しています。

すべてのシャードが読取り/書込みである場合。Active Data Guardでは、DR/バックアップ・シャードが読取り専用になります。

シャードをより柔軟にデプロイする必要がある場合。個々のシャードを異なるオペレーティング・システムまたは異なるデータベース・バージョンに配置できます。

1つのシャードグループ内であっても、データの更新可能なコピーが1つ以上存在します。たとえば、Oracle GoldenGateでレプリケーション・ファクタを4に設定すると、データの読取り/書込みコピーを4個作成して更新できます。

関連項目:

Fusion MiddlewareのOracle GoldenGateマイクロサービス・アーキテクチャの使用ガイドのOracleGoldenGateシャーディングの使用(Oracle ShardingでのOracle GoldenGateの使用の詳細)

親トピック: シャーディングとレプリケーションについて

7.2 シャード・データベースでのOracle Data Guardの使用Oracle Data Guardのレプリケーションは、高可用性およびデータ保護のために、シャード(プライマリ)の1つ以上の同期されたコピー(スタンバイ)を維持します。スタンバイはローカルまたはリモートにデプロイでき、Oracle Active Data Guardを使用する場合は、読取り専用アクセスでオープンすることもできます。

Oracle Data Guardは、シャーディング方法としてシステム管理、ユーザー定義またはコンポジットを使用するシャード・データベースのレプリケーション・テクノロジとして使用できます。

システム管理のシャード・データベースでのOracle Data Guardの使用

システム管理またはコンポジットのシャーディングの場合、レプリケーションの論理単位はシャードグループと呼ばれるシャードのグループです。システム管理のシャーディングの場合、シャード・データベースに格納されるすべてのデータがシャードグループに含まれます。データはシャードグループを構成するシャード間で、均一なハッシュによってシャードされます。シャードグループに属するシャードは通常、同じデータ・センターにあります。シャードグループ全体を、同じまたは異なるデータ・センターの1つ以上のシャードグループに完全にレプリケートできます。

次の図は、システム管理シャーディングとともにData Guardレプリケーションが使用される方法を示しています。図に示す例には、プライマリ・シャードグループのShardgroup 1、および2つのスタンバイ・シャードグループのShardgroup 2とShardgroup 3があります。Shardgroup 1はData Guardプライマリ・データベース(シャード1-3)から構成されます。Shardgroup 2は、同じデータ・センターに存在し、同期レプリケーション用に構成されたローカル・スタンバイ・データベース(シャード4-6)から構成されます。Shardgroup 3は、異なるデータ・センターに存在し、非同期レプリケーション用に構成されたリモート・スタンバイ(シャード7-9)から構成されます。この構成ではOracle Active Data

82




Guardが有効なため、各スタンバイが読取り専用でオープンされています。

図7-1 Data Guardレプリケーションを使用するシステム管理のシャーディング

「図7-1 Data Guardレプリケーションを使用するシステム管理シャーディング」の説明

レプリケーションの論理単位としてのシャードグループという概念によって、レプリケーションの実装の詳細がユーザーには隠されています。Data Guardの場合、レプリケーションはシャード(データベース)のレベルで実行されます。前の図のシャード・データベースは、レプリケートされた3つのシャードのセット({1, 4, 7}、{2, 5, 8}および{3, 6, 9})で構成されています。レプリケートされたシャードの各セットは、ファスト・スタート・フェイルオーバー(FSFO)が有効なData Guard Broker構成として管理されます。

レプリケーションをデプロイするには、シャードグループのプロパティ(リージョン、ロールなど)を指定し、そこにシャードを追加します。Oracle ShardingによってData Guardが自動的に構成され、レプリケートされたシャードの各セットに対してFSFOオブザーバが起動されます。さらに、読取り専用ワークロード、ロール・ベースのグローバル・サービス、レプリケーション・ラグのロード・バランシング、および地域ベースのルーティングが提供されます。

次のGDSCTLコマンドを実行して、前の図に示されている構成例をデプロイします。CREATE SHARDCATALOG –database host00:1521:shardcat –region dc1,dc2

ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:shardcat –region dc1ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:shardcat –region dc2START GSM -gsm gsm1START GSM -gsm gsm2

ADD SHARDGROUP -shardgroup shardgroup1 -region dc1 -deploy_as primary ADD SHARDGROUP -shardgroup shardgroup2 -region dc1 -deploy_as active_standby ADD SHARDGROUP -shardgroup shardgroup3 -region dc2 -deploy_as active_standby

CREATE SHARD -shardgroup shardgroup1 -destination host01 -credential oracle_cred CREATE SHARD -shardgroup shardgroup1 -destination host02 -credential oracle_cred CREATE SHARD -shardgroup shardgroup1 -destination host03 -credential oracle_cred ...CREATE SHARD -shardgroup shardgroup3 -destination host09 -credential oracle_cred

83

DEPLOY

ユーザー定義のシャード・データベースでのOracle Data Guardの使用

ユーザー定義のシャーディングの場合、レプリケーションの論理(および物理)単位はシャードです。シャードはシャードグループに統合されません。各シャードとそのレプリカがシャード領域を構成し、これが1つのData Guard Broker構成に対応します。シャードスペースごとに個別にレプリケーションを構成できます。異なるデータ・センターに存在する異なる数のスタンバイをシャード領域に含めることができます。Data Guardレプリケーションを使用するユーザー定義シャーディングの例を次の図に示します。

図7-2 Data Guardレプリケーションを使用するユーザー定義のシャーディング

「図7-2 Data Guardレプリケーションを使用するユーザー定義シャーディング」の説明

前の図に示されているData Guardレプリケーションを使用するユーザー定義シャード・データベースの例をデプロイするには、次のGDSCTLコマンドを実行します。CREATE SHARDCATALOG -sharding user –database host00:1521:cat –region dc1,dc2,dc3

ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:cat –region dc1ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:cat –region dc2ADD GSM -gsm gsm3 -listener 1571 –catalog host00:1521:cat –region dc3START GSM -gsm gsm1START GSM -gsm gsm2

84

START GSM -gsm gsm3

ADD SHARDSPACE -shardspace shardspace_a ADD SHARDSPACE -shardspace shardspace_bADD SHARDSPACE -shardspace shardspace_c

CREATE SHARD -shardspace shardspace_a –region dc1 -deploy_as primary -destination host01 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp

CREATE SHARD -shardspace shardspace_a –region dc1 -deploy_as standby -destination host04 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp



CREATE SHARD -shardspace shardspace_b –region dc1 -deploy_as primary -destination host08 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rs...

CREATE SHARD -shardspace shardspace_c –region dc3 -deploy_as standby -destination host10 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp

DEPLOY

コンポジット・シャード・データベースでのOracle Data Guardの使用

コンポジット・シャーディングの場合、ユーザー定義のシャーディングと同様にシャード・データベースが複数のシャード領域から構成されます。ただし、各シャード領域には、レプリケートされたシャードではなくレプリケートされたシャードグループが含まれます。

図7-3 複合シャーディングとData Guardレプリケーション

85

「図7-3 複合シャーディングとData Guardレプリケーション」の説明

次のGDSCTLコマンドを実行して、前の図に示されている構成例をデプロイします。CREATE SHARDCATALOG -sharding composite –database host00:1521:cat –region dc1,dc2,dc3

ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:cat –region dc1ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:cat –region dc2ADD GSM -gsm gsm3 -listener 1571 –catalog host00:1521:cat –region dc3START GSM -gsm gsm1START GSM -gsm gsm2START GSM -gsm gsm3

ADD SHARDSPACE -shardspace shardspace_a ADD SHARDSPACE -shardspace shardspace_b

ADD SHARDGROUP -shardgroup shardgroup_a1 –shardspace shardspace_a -region dc1 -deploy_as primary ADD SHARDGROUP -shardgroup shardgroup_a2 –shardspace shardspace_a -region dc1 -deploy_as active_standbyADD SHARDGROUP -shardgroup shardgroup_a3 –shardspace shardspace_a -region dc3 -deploy_as active_standby ADD SHARDGROUP -shardgroup shardgroup_b1 –shardspace shardspace_b -region dc1 -deploy_as primary ADD SHARDGROUP -shardgroup shardgroup_b2 –shardspace shardspace_b -region dc1 -deploy_as active_standby ADD SHARDGROUP -shardgroup shardgroup_b3 –shardspace shardspace_b -region dc2 -deploy_as active_standby

CREATE SHARD -shardgroup shardgroup_a1 -destination host01 –credential orcl_cred ...

86

CREATE SHARD -shardgroup shardgroup_b3 -destination host09 -credential orcl_cred

DEPLOY


7.3 シャード・データベースでのOracle GoldenGateの使用Oracle GoldenGateは、すべてのシャードが書込み可能で、各シャードをシャードグループ内の別のシャードに部分的にレプリケートできるファイングレイン・アクティブ-アクティブ・レプリケーションのために使用されます。

Oracle GoldenGateでは、レプリケーションがチャンク・レベルで処理されます。たとえば、次の図のShardgroup 1では、各シャードに格納されているデータの半分が1つのシャードにレプリケートされ、残りの半分が別のシャードにレプリケートされます。いずれかのシャードが使用できなくなった場合、そのワークロードはシャードグループ内の他の2つのシャードに分割されます。フェイルオーバー先が複数存在し、障害が発生したシャードのすべてのワークロードを1つのシャードで処理する必要がないため、シャード障害の影響が軽減されます。

図7-4 GoldenGateレプリケーションを使用するシステム管理シャーディング

「図7-4 GoldenGateレプリケーションを使用するシステム管理シャーディング」の説明

Oracle GoldenGateレプリケーションでは、シャードグループにシャード表内の各行の複数のレプリカを含めることができるため、シャードグループ内に高可用性が提供され、Data Guardレプリケーションの場合のようにシャードグループのローカル・レプリカを作成する必要はありません。シャードグループ内で各行がレプリケートされる回数は、シャードグループのレプリケーション・ファクタと呼ばれ、構成可能なパラメータです。

87

障害時リカバリ機能を提供するため、シャードグループを1つ以上のデータ・センターにレプリケートできます。シャードグループの各レプリカは、異なる数のシャード、レプリケーション・ファクタ、データベース・バージョンおよびハードウェア・プラットフォームを持つことができます。ただし、レプリケーションはチャンク・レベルで実行されるため、すべてのシャードグループ・レプリカが同じ数のチャンクを持つ必要があります。

前の図のShardgroup 2は、Shardgroup 1と同じデータを含んでいますが、異なるデータ・センターにあります。どちらのデータ・センターのシャードも書込み可能です。どちらのシャードグループでもデフォルトのレプリケーション・ファクタ(2)が使用されます。

Shardgroup 2には2つのシャードのみが含まれており、レプリケーション・ファクタが2であるため、シャードは完全にレプリケートされており、シャード・データベースに格納されているすべてのデータが各シャードに含まれています。これは、シャード間を移動せずにこれらのシャードにルーティングされた問合せを実行できることを意味します。このシャードグループにはフェイルオーバー先が1つしかないため、シャードが停止した場合、他のシャードへの負荷が2倍になります。

Oracle Shardingは、異なるシャードの同じ行に対して実行される競合更新の数が最小限になるように設計されています。これは、ハッシュ値の範囲ごとにマスター・チャンクを指定し、対応するデータのほとんどのリクエストをこのチャンクにルーティングすることで実現されます。

状態遷移(チャンクの移動や分割、シャードの起動と停止など)のために、更新の競合を避けられない場合があります。トランザクションの待機時間を最小限にするため、ユーザーが意図的に競合を発生させる場合もあります。このような場合、Oracle GoldenGateは挿入と削除の競合を含むすべての種類の競合を処理する自動的な競合検出および解決機能を提供します。

シャードを作成する前に、いくつかの前提条件があります。

スケジューラに登録します(GDSCTLのcreate shardを使用する場合)。

サイトセキュリティ・ウォレットまたはクライアント証明書とサーバー証明書を準備します。

Oracle GoldenGateをインストールし、シャーディング・オプションを使用して1つ以上のセキュアなデプロイメントを追加し、GoldenGateサービスおよびサーバーを起動します。

各Oracleホームで、GoldenGateデプロイメントの追加時に使用するクライアント・ウォレットのコピーを作成し、それを$ORACLE_BASE/admin/ggshd_wallet/に配置します。

GoldenGateのインストール・ホームからPL/SQLパッケージをロードします。GDSCTLのCREATESHARDを使用してシャードを作成している場合、この手順はシャード・カタログにのみ適用されます。GDSCTLのADD SHARDを使用している場合、シャード・カタログおよびすべてのシャードに適用されます。

前の図に示されている構成例をデプロイするには、次のGDSCTLコマンドを実行します。CREATE SHARDCATALOG -database host00:1521:shardcat -chunks 60 -user 'gsmcatuser/gsmcatuser_password' -repl OGG -sharding system -sdb orasdbADD GSM -gsm gsm1 -listener 1571 –catalog shard-dir1:1521:shardcat -localons 3841ADD GSM -gsm gsm2 -listener 1571 –catalog shard-dir1:1521:shardcat -localons 3841START GSM -gsm gsm1START GSM -gsm gsm2CONFIGURE -timeout 900ADD REGION -region dc1ADD REGION -region dc2MODIFY GSM -gsm gsm1 -region dc1MODIFY GSM -gsm gsm2 -region dc2ADD SHARDGROUP -shardgroup shardgroup1 -region dc1 -repfactor 2 ADD SHARDGROUP -shardgroup shardgroup2 -region dc2 -repfactor 2

88

CREATE SHARD -shardgroup shardgroup1 -destination host01 -credential oracle_cred -netparam /home/oracle/netca_dbhome.rsp -gg_service host01:9900/deployment_name -gg_password ggadmin_password -dbparamfile /home/oracle/dbparams01.tmp -dbtemplatefile /home/oracle/sharddb01.dbt CREATE SHARD -shardgroup shardgroup1 -destination host02 -credential oracle_cred -netparam /home/oracle/netca_dbhome.rsp -gg_service host02:9900/remote_scheduler_agent -gg_password ggadmin_password -dbparamfile /home/oracle/dbparams02.tmp -dbtemplatefile /home/oracle/sharddb02.dbt

CREATE SHARD -shardgroup shardgroup1 -destination host03 -credential oracle_cred -netparam /home/oracle/netca_dbhome.rsp -gg_service host03:9900/remote_scheduler_agent -gg_password ggadmin_password -dbparamfile /home/oracle/dbparams03.tmp -dbtemplatefile /home/oracle/sharddb03.dbt CREATE SHARD -shardgroup shardgroup2 -destination host04 -credential oracle_cred -netparam /home/oracle/netca_dbhome.rsp -gg_service host04:9900/remote_scheduler_agent -gg_password ggadmin_password -dbparamfile /home/oracle/dbparams04.tmp -dbtemplatefile /home/oracle/sharddb04.dbt CREATE SHARD -shardgroup shardgroup2 -destination host05 -credential oracle_cred -netparam /home/oracle/netca_dbhome.rsp -gg_service host05:9900/remote_scheduler_agent -gg_password ggadmin_password -dbparamfile /home/oracle/dbparams05.tmp -dbtemplatefile /home/oracle/sharddb05.dbt

DEPLOY

前の例では、デプロイメント中にCREATE SHARDを使用して新しいシャードを作成していることに注意してください。CREATE SHARDのかわりにADD SHARDを使用することもできますが、ADD SHARDによる方法は、データベース・シャードに変換できる白紙の状態のデータベース・インスタンスがすでに存在することが前提となります。

注意:

Data GuardまたはActive Data Guardを使用するシャーディング・レプリケーションとは異なり、OracleGoldenGateは手動でデプロイできません。DEPLOYコマンドを使用して行う必要があります。

Oracle GoldenGateは、PDBをシャードとしてサポートしません。

関連項目:

Fusion MiddlewareのOracle GoldenGateマイクロサービス・アーキテクチャの使用ガイドのOracleGoldenGateシャーディングの使用(Oracle ShardingでのOracle GoldenGateの使用の詳細)


89





1. Oracle Shardingの使用2. シャード・データベースのデプロイ

8 シャード・データベースのデプロイシャード・データベースのデプロイでは、必要なソフトウェア・コンポーネントのインストール、カタログ、ロール、シャード・データベースの作成、高可用性のためのレプリケーションの構成、およびシャード・データベースのスキーマの作成のための前提条件と手順について説明します。

次の各項で、シャード・データベースのデプロイに必要な概念とタスクについて説明します。

シャード・データベースのデプロイの概要Oracle Shardingには、シャード・データベースを自動的にデプロイする機能があり、これにはシャードとレプリカの両方が含まれます。Oracle Shardingの前提条件ソフトウェアをインストールする前に、Oracle Shardingのハードウェア、ネットワークおよびオペレーティング・システムの要件を確認してください。Oracle Databaseソフトウェアのインストールシャード・カタログまたはデータベース・シャードをホストする各システムにOracle Databaseをインストールします。シャード・ディレクタ・ソフトウェアのインストールシャード・ディレクタをホストする各システムにグローバル・サービス・マネージャ・ソフトウェアをインストールします。シャード・カタログ・データベースの作成DBCAを使用して、シャード・カタログをホストするOracle Databaseを作成します。Oracle Shardingの管理およびルーティング層のセットアップシャード・カタログ、シャード・ディレクタおよびシャードを相互に通信するように構成する必要があります。システム管理のシャード・データベースの作成およびデプロイユーザー定義のSDBの作成およびデプロイコンポジットSDBの作成およびデプロイコンポジットSDBをデプロイするには、必要なOracle Shardingソフトウェア・コンポーネントをインストールし、コンポジットSDBにオブジェクトを構成して、スキーマを作成する必要があります。Oracle Shardingでの透過的データ暗号化の使用Oracle Shardingでは透過的データ暗号化(TDE)がサポートされますが、TDEを有効にした状態でシャード・データベース内のチャンクを正常に移行できるように、すべてのシャードが暗号化された表領域に対する同じ暗号化鍵を共有して使用する必要があります。

8.1 シャード・データベースのデプロイの概要Oracle Shardingには、シャード・データベースを自動的にデプロイする機能があり、これにはシャードとレプリカの両方が含まれます。

シャード・データベース管理者は、トポロジ(リージョン、シャード・ホスト、レプリケーション・テクノロジ)を定義し、GDSCTLコマンドライン・インタフェースを使用して宣言的に指定することでDEPLOYコマンドを起動します。

大まかなデプロイメント手順は次のとおりです。

90

1. コンポーネントを設定します。

シャード・カタログをホストするデータベースを作成します。

シャード・ノードにOracle Databaseソフトウェアをインストールします。

シャード・ディレクタ・ノードにシャード・ディレクタ(GSM)ソフトウェアをインストールします。

注意:

本番のデプロイメントでは、シャード・カタログ・データベース用にData Guardを構成することをお薦めします。

2. 次のコマンドを使用してトポロジ・レイアウトを指定します。

CREATE SHARDCATALOG

ADD GSM

START GSM

ADD CREDENTIAL (CREATE SHARDを使用する場合)

ADD SHARDGROUP

ADD INVITEDNODE

シャードごとにCREATE SHARD (またはADD SHARD)

3. DEPLOYを実行し、シャード・データベース内のシャードにアクセスするためのグローバル・サービスを追加します。

DEPLOY

ADD SERVICE

デプロイメント方法の選択シャード・データベースをデプロイするには、新しいデータベースに対して同時にシャードを作成するか、既存のデータベースからシャードを追加します。Oracle ShardingでのOracle Multitenantの使用プラガブル・データベース(PDB)を含むマルチテナント・コンテナ・データベース(CDB)をOracle Sharding構成内のシャードおよびシャード・カタログとして使用できます。

親トピック: シャード・データベースのデプロイ

8.1.1 デプロイメント方法の選択

シャード・データベースをデプロイするには、新しいデータベースに対して同時にシャードを作成するか、既存のデータベースからシャードを追加します。

Oracle Shardingでは、2つのデプロイメント方法がサポートされています。1つ目はCREATE SHARDコマンドを使用する方法で、Oracle Shardingの管理層によってシャードとレプリケーション構成の作成が

91

自動的に実行されます。この方法は、PDBをシャードとして使用するマルチテナント・アーキテクチャでは使用できません。

2つ目はADD SHARDコマンドを使用するデプロイメント方法です。データベース作成の標準で、事前に作成した独自のデータベースを使用してSDBをデプロイする必要がある場合、ADD SHARDデプロイメント方法は、事前に作成したデータベース・シャードを追加するだけでこの要件に対応します。

デプロイメント方法: CREATE SHARD

DEPLOYコマンドは、シャードを作成します。これは、DBMS_SCHEDULERパッケージ(シャード・カタログで実行)を使用して実行され、このパッケージはリモート・シャード・ホストのスケジューラ・エージェントと通信します。

すると、エージェントがDBCAとNETCAおよび(Oracle GoldenGateレプリケーションが指定されている場合は) GoldenGate Creation Assistance (GGCA)を起動し、シャードおよびローカル・リスナーを作成します。プライマリ・シャードが作成されると、対応するスタンバイ・シャードがRMANDUPLICATEコマンドを使用して作成されます。

高可用性ソリューションとしてData Guardを使用している場合は、プライマリ・シャードおよびスタンバイ・シャードが作成されると、DEPLOYコマンドがファスト・スタート・フェイルオーバー(FSFO)を有効にしてData Guard Brokerを構成します。FSFOオブザーバがリージョナル・シャード・ディレクタで自動的に起動されます。

注意:

CREATE SHARDによる方法は、シャードとして使用されるPDBではサポートされません。マルチテナント・アーキテクチャでは、ADD SHARDによる方法のみが使用できます。

すべてのシャードについて、アーカイブ・ログおよびフラッシュバックは有効になります。これは、フェイルオーバー時にFSFOオブザーバがスタンバイの自動再インスタンス化を実行するために必要です。

デプロイメント方法: ADD SHARD

独自のデータベース作成標準があり、事前に作成した独自のデータベースを使用してシャード・データベースをデプロイする場合は、ADD SHARDコマンドを使用してシャード・データベース構成にシャードを追加します。この方法は、Oracle RAC対応のシャード、Oracle Restart対応のシャードまたはPDBシャードの場合にお薦めします。この方法は、ASMを使用している場合にお薦めします。ADDSHARDによるデプロイメント方法は、新しいインスタンスを作成せずに、データベースがすでにデプロイされているシャードを追加することによって、この要件をサポートします。

デプロイメントにADD SHARDコマンドを使用し、高可用性のためにData Guardを使用している場合、DEPLOYコマンドはOracle GoldenGate、またはData Guard、ブローカおよびファスト・スタート・フェイルオーバーの構成を処理します。また、追加されるシャード用にData Guardを事前に構成したシナリオにも対処します。

Data GuardまたはActive Data Guardを使用したシャーディングとは異なり、Oracle GoldenGateを手動でデプロイすることはできません。その場合は、DEPLOYコマンドを使用して行う必要があります。

親トピック: シャード・データベースのデプロイの概要

8.1.2 Oracle ShardingでのOracle Multitenantの使用

92

プラガブル・データベース(PDB)を含むマルチテナント・コンテナ・データベース(CDB)をOracleSharding構成内のシャードおよびシャード・カタログとして使用できます。

稼働率が低いハードウェアでのデータベースの統合、管理のしやすさ、または地理的なビジネス要件をサポートするため、CDB内のPDBをデータベース・シャードとして使用できます。たとえば、データベース統合の場合は、シャードPDBを含むCDBに他の非シャードPDBまたはシャードPDBを追加できます。CDBには異なるシャード・データベースからのシャードPDBを含めることができ、それぞれに個別のカタログ・データベースがあります。CDBでは、異なるシャード・データベースからの複数のPDBシャードをサポートできますが、このサポートはCDBごとに指定された1つのシャード・データベースから1つのPDBシャードのみに制限されます。

シャード・データベース構成にシャードPDBを追加するには、まずシャード・カタログにそのシャードPDBが含まれているCDBを追加する必要があります。事前に作成されたCDBをシャード・カタログに追加するには、GDSCTLコマンドのADD CDBを使用します。次に、デプロイメント時に-cdbオプションを指定したGDSCTLのADD SHARDコマンドを使用して、CDBに含まれるPDBであるシャードをシャード・データベースに追加します。

次の例では、一意の名前がdb11であるCDBをシャード・カタログに追加し、それをシャード・データベース構成内のシャードグループshgrp1に追加しています。GDSCTL> add cdb -connect CDB$ROOT_connect_string -pwd GSMROOTUSER_passwordGDSCTL> add shard -cdb db11 -connect PDB_connect_string –shardgroup shgrp1 -deploy_as active_standby -pwd GSMUSER_password

シャード・カタログ内のCDBに関する情報を表示するには、CONFIG CDBを使用します。GDSCTL> config cdb

Name: tstsdbyb Connection string: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=cdb1host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=cdb1.example.com))) SCAN address: ONS remote port: 0 Disk Threshold, ms: 20 CPU Threshold, %: 75 Version: 18.0.0.0 Rack:

注意:

Oracle GoldenGateレプリケーションでは、PDBをシャードとしてサポートしません。

PDBシャードの移動

シャードPDBは、手動でCDBから切断し、異なるCDBに接続できます。これは、シャーディング・インタフェースの外部で行うことができます。その後、シャード・カタログのメタデータを更新して、PDBシャードが別のCDBに移動したことを示すことができます。シャード・カタログ内のシャードPDBの場所を更新するには、-REPLACEオプションを指定したGDSCTLコマンドADD SHARDを使用します。

SQLコマンドALTER PLUGGABLE DATABASE UNPLUGおよびALTER PLUGGABLE DATABASE OPENを使用した一部のPDB操作(既存のPDBを切断して同じCDBに接続するなど)は、登録更新イベントを発生させません。これは、シャードPDBが接続された後、GDSCTL config shard出力に登録されたものとして表示されない可能性があります。これが発生した場合、SQL*PlusでPDBに接続し、SHUTDOWNおよびSTARTUP SQLコマンドを使用してPDBの完全な停止と起動のサイクルを実行することで、登録イベントを強制できます。

PDBシャードの高可用性

93

Oracle Data Guardでは、CDBレベルのレプリケーションのみがサポートされます。既存のシャーディング・アーキテクチャでは、高可用性を実現するためにシャード・データのレプリケート・コピーが許可されており、必要に応じてこれらのコピーを作成および管理できるようにData Guardを構成して使用できます。Data Guardでは、現在PDBレベルのレプリケーションがサポートされておらず、コンテナ全体のみをレプリケートできます。

異なるシャード・データベースから同じCDBにPDBシャードを追加する場合、CDB内のすべての常駐シャード・データベースのレプリケーション・トポロジが一致している必要があります。各DataGuard構成で異なる数のスタンバイPDBを使用してシャード・データベースが構成されている無効な構成が作成される場合があります。そのため、各シャード・データベースのPDBおよびCDBの数および場所を検証することで、この不一致が発生しないようにする必要があります。

シャーディング構成でのCDBの変更

シャード・カタログ内のCDBのメタデータを変更するには、MODIFY CDBを使用します。CDBにシャードが格納されるか、デプロイされたシャードが格納された後は、一部のパラメータを使用できません。GDSCTL> modify cdb -shard cdb1 -pwd new_GSMROOTUSER_password

シャード・カタログからCDBを削除するには、REMOVE CDBを使用します。CDBを削除しても、そのCDBは破棄されません。GDSCTL> remove cdb -cdb cdb1

非PDBシャードからPDBシャードへのアップグレード

非PDBシャード環境からPDBを利用する環境にアップグレードするときは、既存の非PDBシャードをそれぞれバックアップしてから、新しいCDBを作成し、その内部に新しいPDBを作成する必要があります。その後、CDB移行ガイドの推奨事項に従ってシャードをCDB内のPDBにリストアします。この時点で、シャードはCDB内のPDBになっているので、GDSCTLのADD CDBコマンドを使用して新しいCDBを追加した後、PDBの接続文字列を指定してADD SHARD -REPLACEを実行し、古いシャードの場所を新しいPDBの場所に置き換えるようにシャーディング・インフラストラクチャを設定します。

データベースの互換性および移行

特定のCDBに単一のPDBシャードを含むOracle Database 18cインストールからアップグレードする場合、PDBのシャード・カタログ・メタデータを更新する必要があります。具体的には、18cのPDBシャードの名前はCDBのdb_unique_nameですが、Oracle Database 19cのシャード名はdb_unique_name_of_CDB_pdb_nameです。

カタログ・メタデータを更新してこの新しいネーミング方法を反映し、GSMROOTUSERアカウントについての説明に従って新しいGSMROOTUSERアカウントもサポートするには、シャード・データベース・コンポーネントのアップグレードの説明に従って、アップグレード・プロセス中に次の手順を実行します。

PDBシャードを含むCDBをアップグレードした後、GSMROOTUSERアカウントが存在し、ロック解除され、パスワードが割り当てられ、SYSDG、SYSBACKUPおよびgsmrootuser_role権限が付与されていることを確認します。SQL*Plusの次のSQL文は、CDBのルート・コンテナ(CDB$ROOT)への接続中にGSMROOTUSERを正常に設定します。SQL> alter session set "_oracle_script"=true;Session altered. SQL> create user gsmrootuser;

94

User created.

SQL> alter user gsmrootuser identified by new_GSMROOTUSER_password account unlock;User altered.

SQL> grant sysdg, sysbackup, gsmrootuser_role to gsmrootuser container=current;Grant succeeded.

SQL> alter session set "_oracle_script"=false;Session altered.

カタログ・データベースを目的のOracle Databaseバージョンにアップグレードした後、次のPL/SQLプロシージャを実行して、構成に存在するPDBシャードの新しい名前を反映するようにカタログ・メタデータを更新します。このプロシージャは、Oracle Database 18cのPDBシャードごとに実行する必要があります。

pdb_fixupの最初のパラメータは、PDBシャードを含むCDBのdb_unique_nameの値です。OracleDatabase 18cでは、gdsctl config shardで示されるシャード名と同じです。

2番目のパラメータはシャードPDBのPDB名で、シャードPDBへの接続時にSQL*Plusのshowcon_nameによって示されます。

pdb_fixupプロシージャは、カタログ・メタデータを更新して、PDBシャードの新しいネーミング・メソッドに対応させます。SQL> connect sys/password as sysdbaConnected.SQL> set serveroutput onSQL> execute gsmadmin_internal.dbms_gsm_pooladmin.pdb_fixup('cdb1', 'pdb1');

すべてのシャード・ディレクタを目的のバージョンにアップグレードした後、構成内の各CDBに対して次のGDSCTLコマンドを実行し、各CDBのGSMROOTUSERのパスワードをシャード・ディレクタに通知します。GDSCTL> modify cdb -cdb CDB_name -pwd new_GSMROOTUSER_password

関連項目:

Oracle Database Global Data Services概念および管理ガイド(PDBシャードで使用されるGDSCTLコマンドの詳細)

Oracle Database管理者ガイド(Oracle Multitenantの詳細)

親トピック: シャード・データベースのデプロイの概要

8.2 Oracle Shardingの前提条件

ソフトウェアをインストールする前に、Oracle Shardingのハードウェア、ネットワークおよびオペレーティング・システムの要件を確認してください。

シャードのハードウェアおよびオペレーティング・システムの要件は、Oracle Databaseがサポートされる要件と同じです。これらの要件の詳細は、Oracle Databaseのインストール・ドキュメントを参照してください。

シャード・カタログおよびシャード・ディレクタのハードウェア、ソフトウェアおよびオペレーティング・システムの要件は、Global Data Servicesカタログおよびグローバル・サービス・マネージャのサポート要件と同じです。これらの要件の詳細は、Oracle Database Global Data

95

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-98E3FE17-E87D-4ED8-9C64-30D1D527DDC3

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-98E3FE17-E87D-4ED8-9C64-30D1D527DDC3

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=MULTI-GUID-A1F3A63E-3BE5-4B80-A053-46D9EF71D45E

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=MULTI-GUID-A1F3A63E-3BE5-4B80-A053-46D9EF71D45E

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-B7010949-4EAE-4AB1-A136-D5A4CD2AE688

Services概要および管理ガイドを参照してください。

ネットワーク要件は低遅延GigEです。

ポート通信の要件は次のとおりです。CREATE SHARDを使用するには、次のすべての要件を満たす必要があります。ADD SHARDを使用する場合、項目4と5は関係ありません。

1. すべてのシャードがすべてのシャード・ディレクタのリスナーとONSポートに到達できる必要があります。シャード・ディレクタのデフォルトのリスナー・ポートは、1522です。デフォルトのONSポートは、ほとんどのプラットフォームで6123 (ローカルONS)および6234 (リモートONS)です。シャード・ディレクタのこれらのリスナー・ポートおよびONSポートが、アプリケーション/クライアント層、すべてのシャード、シャード・カタログおよび他のすべてのシャード・ディレクタに対して開かれている必要があります。

2. すべてのシャードがシャード・カタログ(プライマリとスタンバイの両方)のTNSリスナー・ポートに到達できる必要があります。

3. 各シャードのTNSリスナー・ポート(デフォルトは1521)がシャード・ディレクタおよびシャード・カタログに対して開かれている必要があります。

4. プライマリおよびスタンバイ・シャード・カタログ・データベースで、CREATESHARDCATALOGコマンドの-agent_port (デフォルトは8080)に使用されているポートがすべてのシャードから可視である必要があります。

5. すべてのシャードのスケジューラ・エージェント・ポートがシャード・カタログ・ノードから可視である必要があります。このポートを特定するには、各シャードに対してschagent -statusを実行します。


8.3 Oracle Databaseソフトウェアのインストール

シャード・カタログまたはデータベース・シャードをホストする各システムにOracle Databaseをインストールします。

Oracle Databaseをインストールする前に、シャード・データベース、シャード・カタログおよびシャード・ディレクタをホストするすべてのシステムでオペレーティング・システムのユーザーを作成し、それらをDBAグループに割り当てます。ユーザーがsuを実行することを許可し、後の手順で使用できるように資格証明をメモします。

オペレーティング・システム・ユーザーの構成の詳細は、Oracle Databaseインストレーション・ガイドfor Linuxまたは使用しているプラットフォームのインストール・ガイドを参照してください。

1. シャード・カタログまたはデータベース・シャードをホストするすべてのシステムにOracleDatabaseインストーラをダウンロードします。

2. シャード・カタログまたはシャード・データベースをホストするすべてのシステムにOracleDatabaseをインストールします。

a. 最初のシステムでインストーラを実行します。$ cd /u01/stage/database$ ./runInstaller

Oracle Databaseのインストールをステップ・スルーするときに、該当する画面で次のオプションを選択してください。

96



https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=LADBI-GUID-B65E6113-D056-4DD9-940F-DFF493E413D5




インストール・オプション・ページで、データベース・ソフトウェアのみをインストールを選択します。

グリッド・インストール・オプション・ページで、単一インスタンス・データベースのインストールを選択します。Oracle RACおよびOracle RAC One Nodeは、このリリースではサポートされていません。

「データベース・エディション」ページで、「Enterprise Edition」を選択します。

インストールの場所ページで、前述のステップで環境スクリプトを作成するときに使用した値と同じ「Oracleベース」値および「ソフトウェアの場所」値を使用します。

インベントリの作成ページで、デフォルトを受け入れます。

「オペレーティング・システム・グループ」ページで、デフォルトを受け入れるか、環境に適した設定に変更します。

「サマリー」ページで、レスポンス・ファイルの保存をクリックすると、残りのホストでOracle Databaseソフトウェアのサイレント・インストールを行うためのファイルを作成できます。

インストール中に要求された場合は、別個のターミナルでorainstRoot.shスクリプトおよびroot.shスクリプトをrootとして実行します。

b. 必要に応じて、最初のインストールで作成したレスポンス・ファイルを使用し、残りの各ホストでサイレント・インストールを実行します。

レスポンス・ファイルを使用してサイレント・インストールを実行した後に、データベースのroot.shスクリプトを実行すると、その実行で対話形式で値を入力するように求められず、デフォルト値(たとえば、ローカル・ユーザーのbinディレクトリ)のみが使用されることがあります。デフォルト以外の値を使用する場合は、インストーラを起動するときに-silentオプションを省略して-responseFileの場所のみを指定します。インストーラ画面をクリックして進み、レスポンス・ファイルの値を受け入れ、要求に応じてルート・スクリプトを実行します。ルート・スクリプトの実行中に、ユーザー・プロンプトが表示され、デフォルト以外の値を入力できます。

関連項目:

Oracle Databaseのサイレント・インストールのレスポンス・ファイルの使用方法の詳細は、OracleDatabaseインストレーション・ガイドfor Linuxを参照してください


8.4 シャード・ディレクタ・ソフトウェアのインストール

シャード・ディレクタをホストする各システムにグローバル・サービス・マネージャ・ソフトウェアをインストールします。

1. シャード・ディレクタをホストするすべてのシステムにOracle Global Service Managerインストーラをダウンロードします。

2. グローバル・サービス・マネージャのインストールの詳細は、Oracle Database Global Data

97

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=LADBI-GUID-D53355E9-E901-4224-9A2A-B882070EDDF7




https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-04D33448-2CB4-40C7-9DA0-1CFC6EC5E101

Services概要および管理ガイドを参照してください。3. 必要に応じて、最初のインストールで作成したレスポンス・ファイルを使用し、残りのシャード・ディレクタの各ホストでサイレント・インストールを実行します。

サイレント・インストール・プロセスの詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。

レスポンス・ファイルを使用してサイレント・インストールを実行した後に、データベースのroot.shスクリプトを実行すると、その実行で対話形式で値を入力するように求められず、デフォルト値(たとえば、ローカル・ユーザーのbinディレクトリ)のみが使用されることがあります。デフォルト以外の値を使用する場合は、インストーラを起動するときに-silentオプションを省略して-responseFileの場所のみを指定します。インストーラ画面をクリックして進み、レスポンス・ファイルの値を受け入れ、要求に応じてルート・スクリプトを実行します。ルート・スクリプトの実行中に、ユーザー・プロンプトが表示され、デフォルト以外の値を入力できます。


8.5 シャード・カタログ・データベースの作成DBCAを使用して、シャード・カタログをホストするOracle Databaseを作成します。

1. シャード・カタログをホストするホストに接続し、必要な環境変数に正しい値が設定されていることを確認します。$ env |grep ORAORACLE_BASE=/u01/app/oracleORACLE_HOME=/u01/app/oracle/product/18.0.0/dbhome_1

2. oradataディレクトリおよびfast_recovery_areaディレクトリを作成します。$ mkdir /u01/app/oracle/oradata$ mkdir /u01/app/oracle/fast_recovery_area

3. DBCAを実行して、シャード・カタログ・データベースを作成します。$ dbca

Database Configuration Assistantが開きます。4. 「データベース操作」ページで、「データベースの作成」を選択して、「次へ」をクリックします。

5. 「作成モード」ページで、「拡張構成」を選択して、「次へ」をクリックします。6. 「デプロイメント・タイプ」ページで、「Oracle単一インスタンス・データベース」データベース・タイプを選択して「汎用またはトランザクション処理」テンプレートを選択し、「次へ」をクリックします。

7. 「データベースID」ページで、シャード・カタログのホスト環境スクリプトで構成した「グローバル・データベース名」とシャード・カタログの「SID」を入力し、「次」をクリックします。

8. 「記憶域オプション」ページで、データベース・ストレージ属性に以下を使用するオプションを選択し、「ファイル・システム」を選択して「Oracle Managed Filesの使用(OMF)」オプションを選択し、「次へ」をクリックします。

9. 高速リカバリ・オプションの選択ページで、「高速リカバリ領域の指定」、「アーカイブ有効化」の順に選択し、「次へ」をクリックします。

10. ネットワーク構成の詳細の指定ページで、「新規リスナーの作成」を選択してリスナー名とポート番号を設定し、「次へ」をクリックします。

98



https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-C03F39F9-576F-48B7-892B-2636F423BF21



後でデータベースに接続できるように、リスナー名をメモします。11. Data Vaultオプション・ページをスキップします。12. 「構成オプション」ページの「メモリー」タブで、自動共有メモリー管理を使用するを選択します。

13. 「構成オプション」ページの「文字セット」タブで、「Unicode(AL32UTF8)を使用」を選択して、「次へ」をクリックします。

14. 「管理オプション」ページで、「Enterprise Manager (EM) Database Expressの構成」オプションの選択を解除して、「次へ」をクリックします。

15. 「ユーザー資格証明」ページで、ビジネスのニーズに適したオプションを選択して、パスワードを入力し、「次へ」をクリックします。

後で必要となるので、入力したパスワードをメモしてください。

16. 「作成オプション」ページで、「データベースの作成」を選択して、「次へ」をクリックします。

17. 「サマリー」ページで「終了」をクリックします。18. データベースが作成されたら、グローバル・データベース名、SIDおよびspfile値をメモします。

19. Oracle Data Guardを使用してシャード・カタログ・データベースを保護する計画の場合は、「パスワード管理」をクリックして、SYSDGアカウントをアンロックし、このアカウントに入力したパスワードをメモします。

20. 「閉じる」をクリックしてDBCAを終了します。


8.6 Oracle Shardingの管理およびルーティング層のセットアップ

シャード・カタログ、シャード・ディレクタおよびシャードが相互に通信するように構成する必要があります。

始める前に、Oracle Shardingの前提条件にリストされているポート要件の前提条件を注意深く読み、必要な変更を行ってから、この項のタスクを続行してください。

1. シャード・カタログのホストで、必要な環境値に正しい値が設定されていることを確認します。$ env |grep ORAORACLE_SID=shardcatORACLE_BASE=/u01/app/oracleORACLE_HOME=/u01/app/oracle/product/18.0.0/dbhome_1

2. シャード・カタログのリスナーがまだ開始されていない場合は、シャード・カタログのリスナーを起動します。$ lsnrctl start

3. DB_CREATE_FILE_DESTパラメータがシャード・カタログ・データベースに設定されていることを確認します。

パラメータが設定されていない場合は、次の例に示すように設定します。Oracle Shardingデモ・アプリケーションのために、open_linksおよびopen_links_per_instanceに16が設定されます。$ sqlplus / as sysdba

SQL> alter system set db_create_file_dest='/u01/app/oracle/oradata' scope=both;SQL> alter system set open_links=16 scope=spfile;SQL> alter system set open_links_per_instance=16 scope=spfile;

99

4. シャード・カタログ・データベースを停止して再起動します。SQL> shutdown immediateDatablase closed.Database dismounted.

SQL> startupORACLE instance started.

Total System Global Area 4798283776 bytesFixed Size 4430760 bytesVariable Size 1006634072 bytesDatabase Buffers 3774873600 bytesRedo Buffers 12345344 bytesDatabase mounted.Database opened.

5. シャード・カタログ・データベースにロールおよび権限を付与します。SQL> set echo onSQL> set termout onSQL> spool setup_grants_privs.lst

a. GSMCATUSERスキーマのパスワードをアンロックして設定します。

このスキーマは、シャード・ディレクタがシャード・カタログ・データベースに接続するときに使用されます。SQL> alter user gsmcatuser account unlock;SQL> alter user gsmcatuser identified by gsmcatuser_password;

b. 管理者スキーマを作成し、それに権限を付与します。

mysdbadminアカウントは、シャーディング環境に関する情報を格納するシャード・カタログ・データベースのアカウントです。mysdbadminアカウントは、シャード・データベース環境に対して管理上の変更を行うためのデータベース管理者スキーマです。GDSCTLはGDSCTLコマンドを実行するときにこのユーザーを介してデータベースに接続し、mysdbadminユーザーがデータベースで必要な変更を行います。SQL> create user mysdbadmin identified by mysdbadmin_password;SQL> grant connect, create session, gsmadmin_role to mysdbadmin;SQL> grant inherit privileges on user SYS to GSMADMIN_INTERNAL;SQL> spool off

6. シャード・ディレクタのホストに接続し、GDSCTLを開始します。

以降のステップのコマンドは、シャード・ディレクタのホストから実行されます(GDSCTLコマンドライン・インタフェースがそこにインストールされているため)。

次の例には、環境変数が適切に設定されていることの健全性チェックが含まれています。$ env |grep ORAORACLE_BASE=/u01/app/oracleORACLE_HOME=/u01/app/oracle/product/18.0.0/gsmhome_1

$ gdsctl

7. シャード・カタログを作成し、シャード・カタログにリモート・スケジューラ・エージェントを構成します。

この例では、シャード・データベースにcust_sdbという名前が指定され、2つのリージョン(region1およびregion2)が作成されます。リージョンは、プライマリから物理スタンバイへのシャードのフェイルオーバーのために、ローカルの可用性ドメインとして使用されます。以下

100

の例では、リージョンは地理的な地域を表していません。

Oracle GoldenGateレプリケーションを使用してシステム管理のシャーディング用のシャード・カタログを作成するには:

GDSCTL> create shardcatalog -database shard_catalog_host:port_number:shard_catalog_name -user gsm_admin/mysdbadmin_password -repl OGG -repfactor 2 -sdb cust_sdb-region region1, region2 -agent_port port_num -agent_password rsa_password

注意:

本番システムの場合は、シャード・カタログの作成時に-chunksパラメータを指定せずに、デフォルト(1シャード当たり120個のチャンク)を使用することをお薦めします。

システム管理はデフォルトのシャーディング方法であるため、-shardingパラメータで指定する必要はありません。

Data Guardレプリケーションを使用してコンポジット・シャード・データベース用のシャード・カタログを作成するには:

GDSCTL> create shardcatalog -database shard_catalog_host:port_number:shard_catalog_name-chunks 60 -shardspace shardspace1 -sharding composite -sdb comp_shpool-protectmode maxavailability -user gsm_admin/mysdbadmin_password

Data Guardレプリケーションを使用してユーザー定義のシャード・データベース用のシャード・カタログを作成するには:

GDSCTL> create shardcatalog -sdb udef_shpool -sharding user-protectmode maxavailability-database shard_catalog_host:port_number:shard_catalog_name-user gsm_admin/mysdbadmin_password -region region1, region2

注意:

ADD SHARDによるデプロイメント方法を使用する場合は、-agent_portおよび-agent_passwordパラメータは必要ありません。

8. シャード・ディレクタのホストに接続されているときに、シャード・ディレクタを作成して起動します。GDSCTL> add gsm -gsm sharddirector1 -listener listener_port -pwd gsmcatuser_password -catalog shard_catalog_host:1521:shardcat -region region1

GDSCTL> start gsm -gsm sharddirector1

シャード・ディレクタの各ホストで、ステップ6および8を繰り返します。シャード・ディレクタ名およびリージョン名を各ホストの適切な値に置き換えます。

9. GDSCTLを使用して、オペレーティング・システムの資格証明を設定します。GDSCTL> add credential -credential credential_name -osaccount os_account_name -ospassword os_passwordGDSCTL> exit

注意:

ADD SHARDによるデプロイメント方法を使用する場合は、この手順は必要ありません。

101

これらの資格証明は、シャードのホストカタログのホストではなくのオペレーティング・システムのユーザー名とパスワードであり、資格証明はリモート・スケジューラ・エージェントがホストでジョブを実行したり、DBCA、NETCAなどを使用してシャードをセットアップしたりするために使用されます。

各ホストに別のオペレーティング・システムの資格証明を使用する場合は、このステップを繰り返します。

10. 各シャードのホストに接続して、リモート・スケジューラ・エージェントをそれらに登録し、oradataおよびfast_recovery_areaのディレクトリを作成します。

注意:

このステップは、シャード・データベースのデプロイの概要で説明されているCREATE SHARD方法を使用している場合にのみ必要です。ADD SHARD方法を使用している場合は、このステップをスキップできます。

シャードをホストする各マシンで次の文を実行します。

os_account_nameはOracleソフトウェアのインストールに使用したアカウント、shard_hostはシャードをホストするマシンのホスト名またはIPアドレス、shard_catalog_hostはシャード・カタログのホストのホスト名またはIPアドレス、およびport_numは前述のステップ7でcreateshardcatalogの-agent_portパラメータに指定したリモート・スケジューラ・エージェントのポート番号です。リモート・スケジューラ・エージェントから、前述のステップ7のcreateshardcatalogの-agent_passwordパラメータに指定したエージェント登録パスワードの入力を求められます。$ ssh os_account_name@shard_hostpasswd: os_password

$ schagent -start$ schagent -status$ schagent -registerdatabase shard_catalog_host port_num

$ mkdir /u01/app/oracle/oradata$ mkdir /u01/app/oracle/fast_recovery_area

関連項目:

GDSCTLコマンドの使用方法とオプションの詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください。


8.7 システム管理のシャード・データベースの作成およびデプロイ

次の各項では、システム管理のシャード・データベースを作成してデプロイするタスクについて説明します。

システム管理のシャード・データベースのデプロイシステム管理のシャード・データベースをデプロイするには、シャードグループおよびシャードを作成し、シャードとして使用するデータベースを作成および構成し、DEPLOYコマンドを実行してロールベースのグローバル・サービスを作成します。システム管理のシャード・データベースのスキーマの作成シャード・データベースのスキーマ・ユーザー、表領域セット、シャード表および重複表を作成します。DDLがすべてのシャードに伝播されたことを確認し、シャードに接続されている状

( )

102

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-16E4FFF2-29C9-4954-9474-6D269BF3F6AF



態で、ファスト・スタート・フェイルオーバーを使用した自動Data Guard Broker構成を検証します。システム管理のSDBのデモ・アプリケーションシステム管理のシャード・データベース(SDB)のデモ・アプリケーションは、オンライン小売業者のワークロードをシミュレートしています。システム管理(自動シャーディング)のSDB構成のセットアップを検証するために使用してください。また、デモ・アプリケーションは、データベース・シャーディングを初めて使用する管理者および開発者にシャーディングの概念の実例を示します。


8.7.1 システム管理のシャード・データベースのデプロイ

システム管理のシャード・データベースをデプロイするには、シャードグループおよびシャードを作成し、シャードとして使用するデータベースを作成および構成し、DEPLOYコマンドを実行してロールベースのグローバル・サービスを作成します。

システム管理のシャーディングでは、ユーザーがデータをシャードにマップする必要はありません。コンシステント・ハッシュによるパーティション化を使用して、データが自動的にシャード間に分散されます。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。システム管理のシャード・データベースの概念に関する詳細は、システム管理のシャーディングを参照してください。

1. シャード・データベースのデプロイの概要で説明されているADD SHARD方法を使用している場合、まずそれぞれのホストでシャードとして使用するデータベースを作成する必要があります。

シャード・データベースには次の特性が必要です。

各ホストに関連付けられたTNSリスナーがあること

GSMUSERアカウントのロックが既知のパスワードで解除されていること

SYSDGおよびSYSBACKUP権限がGSMUSERに付与されていること

プライマリ・データベースとスタンバイ・データベースがそのように構成されていること

REDO適用が対応するプライマリ・データベースとスタンバイ・データベース間で設定されていること

フラッシュバック・ロギングと強制ロギングが有効になっていること

compatibleパラメータが12.2.0以上に設定されていること

サーバー・パラメータ・ファイル(SPFILE)が使用されていること

DATA_PUMP_DIRディレクトリ・オブジェクトが各データベースで作成され、有効なディレクトリを指していること

次に、データベースがシャード用に正しく設定されていることを検証する必要があります。データベースを構成に追加する前に、SYSとしてログインしている間に各データベースに対して次の文を実行します。SQL> set serveroutput on

103

SQL> execute DBMS_GSM_FIX.validateShard

画面出力には、問題の分析に必要なINFO、WARNINGおよびERRORの情報が含まれます。WARNINGメッセージとERRORメッセージはすべて解決する必要があります。変更後にvalidateShard()を再度実行して構成を確認します。

2. シャード・ディレクタのホストに接続します。$ ssh os_user@shard_director1_host

3. 現在のセッションのグローバル・サービス・マネージャを設定し、それを管理するための資格証明を指定します。$ gdsctlGDSCTL> set gsm -gsm sharddirector1GDSCTL> connect mysdbadmin/mysdbadmin_password

4. プライマリ・シャードのシャードグループを追加します。

この例では、シャードグループはprimary_shardgroupという名前であり、Data Guardレプリケーション・ソリューションの一部です。GDSCTL> add shardgroup -shardgroup primary_shardgroup -deploy_as primary -region region1

次の例は、Oracle GoldenGateレプリケーション・ソリューション用のシャードグループを作成する方法を示しています。GDSCTL> add shardgroup -shardgroup shardgroup1 -region region1 -repfactor 2

5. スタンバイ・シャードのシャードグループを追加します。

この例では、シャードグループはstandby_shardgroupという名前であり、-deploy_asパラメータを使用してActive Data Guardのアクティブ・スタンバイ用に作成されます。GDSCTL> add shardgroup -shardgroup standby_shardgroup -deploy_as active_standby -region region2

Oracle GoldenGate構成に2番目のシャードグループを追加する方法は、次の例のようになります。GDSCTL> add shardgroup -shardgroup shardgroup2 -region region2 -repfactor 2

6. 各シャードのホスト・アドレスをカタログ内の登録に関する有効ノード・チェック(VNCR)リストに追加し、次の例に示すように、プライマリまたはスタンバイ・シャードグループにシャードを作成または追加します。

注意:

登録に関する有効ノード・チェック(VNCR)機能では、シャード・ディレクタによって許可された登録リクエストのIPアドレス、ホスト名またはサブネットのセットの構成や動的な更新が可能になります。シャード・ディレクタへのデータベース・インスタンスの登録は、リクエスト元が有効なノードである場合にのみ成功します。デフォルトでは、create shardまたはaddshardが実行されるたびに、シャード管理層(Oracle Global Data Servicesフレームワークに基づく)は、リモート・データベースが実行されているホストのVNCRエントリを自動的に追加します。自動化(自動VNCRと呼ばれます)によってターゲット・ホストのパブリックIPアドレスが検索され、そのIPアドレスのVNCRエントリが自動的に追加されます。ホストに複数のパブリックIPアドレスがある場合は、データベースに登録されたアドレスが自動VNCRを使用して追加さ

104

れたアドレスと同じではないことがあり、登録が拒否されることがあります。ターゲット・データベースのホストに複数のパブリックIPアドレスがある場合は、GDSCTLでaddinvitednodeコマンドまたはadd invitedsubnetコマンドを使用して、このホストのVNCRを手動で構成することをお薦めします。

複数のネットカードがターゲット・ホストにある(/sbin/ifconfigで複数のパブリック・インタフェースが返されます)場合は、安全のためにadd invitednodeを使用します(パケットをルーティングするために使用されるインタフェースを確認してから)。

登録になんらかの疑念がある場合は、必要に応じてconfig vncrおよびadd invitednodeを使用します。これを行っても問題はありません。ノードがすでに追加されている場合、自動VNCRはそれを無視し、自動VNCRによってすでに追加された後にノードを追加しようとすると、すでに存在しているという警告を受け取るからです。

次の例は、CREATE SHARDコマンドとData Guard高可用性ソリューションを使用して4つのシャード(プライマリ・シャードグループに2つとスタンバイ・シャードグループに2つ)を作成する方法を示しています。credential_nameは、シャード・カタログで宛先ホストのために作成されたオペレーティング・システムの資格証明です。

シャードを作成するときに、次の例に示すようにcreate shardで-sys_passwordを使用してSYSのパスワードを設定することもできます。これにより、シャードが作成されてDEPLOYを実行したときに、SYSのパスワードが設定されます。

CREATE SHARDには、他にもデータベース・パラメータ、記憶域とファイルの場所、リスナー・ポート番号などをカスタマイズできるオプションのパラメータがあります。詳細は、OracleDatabase Global Data Services概要および管理ガイドの付録を参照してください。GDSCTL> add invitednode shard_host_1 GDSCTL> create shard -shardgroup primary_shardgroup -destination shard_host_1 -credential credential_name -sys_password sys_password

GDSCTL> add invitednode shard_host_2GDSCTL> create shard -shardgroup standby_shardgroup -destination shard_host_2 -credential credential_name -sys_password sys_passwordGDSCTL> add invitednode shard_host_3 GDSCTL> create shard -shardgroup primary_shardgroup -destination shard_host_3 -credential credential_name -sys_password sys_passwordGDSCTL> add invitednode shard_host_4GDSCTL> create shard -shardgroup standby_shardgroup -destination shard_host_4 -credential credential_name -sys_password sys_password

Oracle GoldenGateレプリケーション・ソリューションでは、レプリケーションがチャンク・レベルで処理され、シャードグループ内のシャード間に分散されるため、シャードグループがプライマリおよびスタンバイとして指定されません。ただし、障害時リカバリのために、シャードグループを1つ以上のデータ・センターにレプリケートすることをお薦めします。OracleGoldenGateレプリケーションを使用してシャードを作成する例を次に示します。GDSCTL> create shard -shardgroup shardgroup -destination shard_host -credential oracle_cred -netparam /home/oracle/netca_dbhome.rsp -gg_service shard_host_1:$ADMINSRVR_PORT/$GGHOME -gg_password ggadmin_password -dbparamfile /home/oracle/dbparams01.tmp -dbtemplatefile /home/oracle/sharddb01.dbt

シャード・データベースのデプロイの概要で説明されているADD SHARD方法を使用している場合は、前述の例のCREATE SHARDコマンドのかわりに次のコマンドを使用します。追加されるシャード・データベースがプラガブル・データベース(PDB)である場合は、ADD SHARDで-cdbオプションを使用して、PDBシャードが含まれているコンテナ・データベース(CDB)を指定する必要があります。また、ADD SHARDコマンドの前にADD CDBを使用してカタログにCDBを追加する

105

必要があります。ADD CDBおよびADD SHARDの構文は、Oracle Database Global Data Services概要および管理ガイドを参照してください。Oracle Database 18cでは、各CDB内の1つのPDBのみをシャードにすることができます。GDSCTL> add shard –shardgroup shgrp1 –connect shard_host:TNS_listener_port/shard_database_name –pwd GSMUSER_password

7. シャード・ディレクタから構成を確認します。

CREATE SHARD方法を使用している場合、シャード名sh1、sh2、sh3およびsh4はシステム生成のシャード名となります。GDSCTL> configRegions-----------------------region1region2

GSMs-----------------------sharddirector1sharddirector2

Sharded Database-----------------------cust_sdb

Databases-----------------------sh1sh2sh3sh4

Shard Groups-----------------------primary_shardgroupstandby_shardgroup

Shard spaces-----------------------shardspaceora

Services-----------------------

GDSCTL pending requests-----------------------Command Object Status------- ------ ------

Global properties-----------------------Name: oradbcloudMaster GSM: sharddirector1DDL sequence #: 0

GDSCTL> config shardspaceSHARDSPACE Chunks---------- ------shardspaceora 12

GDSCTL> config shardgroupShard Group Chunks Region SHARDSPACE----------- ------ ------ ----------primary_shardgroup 12 region1 shardspaceorastandby_shardgroup 12 region2 shardspaceora

GDSCTL> config vncrName Group ID ---- --------shard_host_1 shard_host_2

106

shard_host_3shard_host_4shard_catalog_host_IP

GDSCTL> config shardName Shard Group Status State Region Availability---- ----------- ------ ----- ------ ------------sh1 primary_shardgroup U none region1 -sh2 standby_shardgroup U none region2 -sh3 primary_shardgroup U none region1 -sh4 standby_shardgroup U none region2 -

8. DEPLOYコマンドを実行して、シャードとレプリカを作成します。

DEPLOYコマンドは実行に約15-30分かかります。GDSCTL> deploy

CREATE SHARD方法を使用してシャードを作成する場合、DEPLOYコマンドはDBCAを使用してプライマリ・シャードとスタンバイ・シャードを作成します。スタンバイの再インスタンス化を実行するためにファスト・スタート・フェイルオーバー・オブザーバが必要なアーカイブログとフラッシュバックが、すべてのシャードで有効になります。

プライマリ・シャードおよびスタンバイ・シャードが作成されると、DEPLOYコマンドはファスト・スタート・フェイルオーバーを有効にしてData Guard Brokerを構成します。ファスト・スタート・フェイルオーバー・オブザーバは、スタンバイ・グループのシャード・ディレクタ(この例ではsharddirector2)で自動的に起動されます。

9. すべてのシャードがデプロイされたことを確認します。GDSCTL> config shardName Shard Group Status State Region Availability---- ----------- ------ ----- ------ ------------sh1 primary_shardgroup Ok Deployed region1 ONLINEsh2 standby_shardgroup Ok Deployed region2 READ_ONLYsh3 primary_shardgroup Ok Deployed region1 ONLINEsh4 standby_shardgroup Ok Deployed region2 READ_ONLY

10. すべてのシャードが登録されたことを確認します。GDSCTL> databasesDatabase: "sh1" Registered: Y State: Ok ONS: N. Role: PRIMARYInstances: 1 Region: region1 Registered instances: cust_sdb%1Database: "sh2" Registered: Y State: Ok ONS: N. Role: PH_STNDBYInstances: 1 Region: region2 Registered instances: cust_sdb%11Database: "sh3" Registered: Y State: Ok ONS: N. Role: PRIMARYInstances: 1 Region: region1 Registered instances: cust_sdb%21Database: "sh4" Registered: Y State: Ok ONS: N. Role: PH_STNDBYInstances: 1 Region: region2 Registered instances: cust_sdb%31

11. シャードの構成を確認します。GDSCTL> config shard -shard sh1Name: sh1Shard Group: primary_shardgroupStatus: OkState: DeployedRegion: region1Connection string: shard_host_1:TNS_listener_port/sh1:dedicatedSCAN address:ONS remote port: 0

107

Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Last Failed DDL: DDL Error: ---Failed DDL id:Availability: ONLINE

Supported services-----------------------Name Preferred Status---- --------- ------

12. すべてのプライマリ・シャードで実行されるグローバル・サービスを追加します。

oltp_rw_srvcグローバル・サービスは、クライアントがシャード・データベースに接続するために使用できるグローバル・データ・サービスです。oltp_rw_srvcサービスはプライマリ・シャードでOLTPトランザクションを実行します。同様に、スタンバイ・シャードで読取り専用のワークロードを実行するために、oltp_ro_srvcグローバル・サービスが作成されます。GDSCTL> add service -service oltp_rw_srvc -role primary

GDSCTL> config service

Name Network name Pool Started Preferred all---- ------------ ---- ------- -------------oltp_rw_srvc oltp_rw_srvc.cust_sdb.oracdbcloud cust_sdb No Yes

13. oltp_rw_srvcグローバル・サービスを開始します。GDSCTL> start service -service oltp_rw_srvc

GDSCTL> status serviceService "oltp_rw_srvc.cust_sdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE Instance "cust_sdb%1", name: "sh1", db: "sh1", region: "region1", status: ready. Instance "cust_sdb%21", name: "sh3", db: "sh3", region: "region1", status: ready.

14. スタンバイ・シャードで実行する読取り専用のワークロードのためのグローバル・サービスを追加します。GDSCTL> add service -service oltp_ro_srvc -role physical_standby


Name Network name Pool Started Preferred all---- ------------ ---- ------- -------------oltp_rw_srvc oltp_rw_srvc.cust_sdb.oracdbcloud cust_sdb Yes Yesoltp_ro_srvc oltp_ro_srvc.cust_sdb.oracdbcloud cust_sdb No Yes

15. 読取り専用サービスを開始し、そのグローバル・サービスのステータスを確認します。GDSCTL> start service -service oltp_ro_srvc

GDSCTL> status serviceService "oltp_ro_srvc.cust_sdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE Instance "cust_sdb%11", name: "sh2", db: "sh2", region: "region2", status: ready. Instance "cust_sdb%31", name: "sh4", db: "sh4", region: "region2", status: ready.Service "oltp_rw_srvc.cust_sdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE Instance "cust_sdb%1", name: "sh1", db: "sh1", region: "region1", status: ready. Instance "cust_sdb%21", name: "sh3", db: "sh3", region: "region1", status: ready.

関連項目:

システム管理のシャード・データベースのスキーマの作成

GDSCTLコマンドの使用方法については、Oracle Database Global Data Services概念および管理ガイドを参照してください

108

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-3285C437-78F8-4339-AAAB-33DBB7A9D400



親トピック: システム管理のシャード・データベースの作成およびデプロイ

8.7.2 システム管理のシャード・データベースのスキーマの作成

シャード・データベースのスキーマ・ユーザー、表領域セット、シャード表および重複表を作成します。DDLがすべてのシャードに伝播されたことを確認し、シャードに接続されている状態で、ファスト・スタート・フェイルオーバーを使用した自動Data Guard Broker構成を検証します。

1. シャード・カタログ・データベースに接続し、アプリケーション・スキーマのユーザーを作成して、そのユーザーに権限とロールを付与します。

この例では、アプリケーション・スキーマのユーザーはapp_schemaという名前です。$ sqlplus / as sysdba

SQL> alter session enable shard ddl;SQL> create user app_schema identified by app_schema_password;SQL> grant all privileges to app_schema;SQL> grant gsmadmin_role to app_schema;SQL> grant select_catalog_role to app_schema;SQL> grant connect, resource to app_schema;SQL> grant dba to app_schema;SQL> grant execute on dbms_crypto to app_schema;

2. シャード表の表領域セットを作成します。SQL> CREATE TABLESPACE SET TSP_SET_1 using template (datafile size 100m autoextend on next 10M maxsize unlimited extent management local segment space management auto);

表領域セットを作成する場合、シャード領域の指定はオプションです。コマンドにシャード領域を指定しない場合は、デフォルトのシャード領域(shardspaceora)が使用されます。

3. 列にLOBを使用する場合は、LOBの表領域セットを指定できます。SQL> CREATE TABLESPACE SET LOBTS1;

注意:

システム管理のシャーディングでは、LOBの表領域セットをサブパーティション・レベルで指定できません。

4. 重複表の表領域を作成します。

この例では、重複表はサンプルのCustomers-Orders-ProductsスキーマのProducts表です。SQL> CREATE TABLESPACE products_tsp datafile size 100m autoextend on next 10M maxsize unlimited extent management local uniform size 1m;

5. ルート表のシャード表を作成します。

この例では、ルート表はサンプルのCustomers-Orders-ProductsスキーマのCustomers表です。SQL> CONNECT app_schema/app_schema_password

SQL> ALTER SESSION ENABLE SHARD DDL;

SQL> CREATE SHARDED TABLE Customers ( CustId VARCHAR2(60) NOT NULL, FirstName VARCHAR2(60),

109

LastName VARCHAR2(60), Class VARCHAR2(10), Geo VARCHAR2(8), CustProfile VARCHAR2(4000), Passwd RAW(60), CONSTRAINT pk_customers PRIMARY KEY (CustId), CONSTRAINT json_customers CHECK (CustProfile IS JSON) ) TABLESPACE SET TSP_SET_1 PARTITION BY CONSISTENT HASH (CustId) PARTITIONS AUTO;

注意:

列にLOBが含まれる場合は、次に示すように親表の作成文に表領域セットを含めることができます。SQL> CREATE SHARDED TABLE Customers ( CustId VARCHAR2(60) NOT NULL, FirstName VARCHAR2(60), LastName VARCHAR2(60), Class VARCHAR2(10), Geo VARCHAR2(8), CustProfile VARCHAR2(4000), Passwd RAW(60), image BLOB, CONSTRAINT pk_customers PRIMARY KEY (CustId), CONSTRAINT json_customers CHECK (CustProfile IS JSON) ) TABLESPACE SET TSP_SET_1 LOB(image) store as (TABLESPACE SET LOBTS1) PARTITION BY CONSISTENT HASH (CustId) PARTITIONS AUTO;

6. 表ファミリの他の表のシャード表を作成します。

この例では、シャード表はサンプルのCustomers-Orders-ProductsスキーマのOrders表およびLineItems表として作成されます。

Ordersシャード表を最初に作成します。SQL> CREATE SHARDED TABLE Orders ( OrderId INTEGER NOT NULL, CustId VARCHAR2(60) NOT NULL, OrderDate TIMESTAMP NOT NULL, SumTotal NUMBER(19,4), Status CHAR(4), CONSTRAINT pk_orders PRIMARY KEY (CustId, OrderId), CONSTRAINT fk_orders_parent FOREIGN KEY (CustId) REFERENCES Customers ON DELETE CASCADE ) PARTITION BY REFERENCE (fk_orders_parent);

OrderId列に使用される順序を作成します。SQL> CREATE SEQUENCE Orders_Seq;

LineItemsのシャード表を作成します。SQL> CREATE SHARDED TABLE LineItems ( OrderId INTEGER NOT NULL, CustId VARCHAR2(60) NOT NULL, ProductId INTEGER NOT NULL, Price NUMBER(19,4), Qty NUMBER, CONSTRAINT pk_items PRIMARY KEY (CustId, OrderId, ProductId), CONSTRAINT fk_items_parent FOREIGN KEY (CustId, OrderId) REFERENCES Orders ON DELETE CASCADE ) PARTITION BY REFERENCE (fk_items_parent);

7. 必要な重複表を作成します。

110

この例では、Products表は重複しているオブジェクトです。SQL> CREATE DUPLICATED TABLE Products ( ProductId INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, Name VARCHAR2(128), DescrUri VARCHAR2(128), LastPrice NUMBER(19,4) ) TABLESPACE products_tsp;

8. シャード・ディレクタのホストから、表領域の作成中に障害が発生しなかったことを確認します。GDSCTL> show ddlid DDL Text Failed shards-- -------- -------------5 grant connect, resource to app_schema6 grant dba to app_schema7 grant execute on dbms_crypto to app_s... 8 CREATE TABLESPACE SET TSP_SET_1 usin...9 CREATE TABLESPACE products_tsp datafi...10 CREATE SHARDED TABLE Customers ( Cu...11 CREATE SHARDED TABLE Orders ( Order...12 CREATE SEQUENCE Orders_Seq;13 CREATE SHARDED TABLE LineItems ( Or...14 CREATE MATERIALIZED VIEW "APP_SCHEMA"...

注意:

show ddlコマンドの出力は切り捨てられることがあります。出力内容の完全なテキストを表示するには、カタログでSELECT ddl_text FROM gsmadmin_internal.ddl_requestsを実行します。

9. 各シャードにDDLエラーがないことを確認します。

構成の各シャードでconfig shardコマンドおよびconfig chunksコマンドを実行します。GDSCTL> config shard -shard sh1Name: sh1Shard Group: primary_shardgroupStatus: OkState: DeployedRegion: region1Connection string: shard_host_1:1521/sh1_host:dedicatedSCAN address: ONS remote port: 0Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Last Failed DDL: DDL Error: ---Failed DDL id: Availability: ONLINE

Supported services------------------------Name Preferred Status ---- --------- ------ oltp_ro_srvc Yes Enabled oltp_rw_srvc Yes Enabled

GDSCTL> config chunksChunks------------------------Database From To -------- ---- -- sh1 1 6 sh2 1 6 sh3 7 12 sh4 7 12

10. シャード表ファミリのために作成した表領域セットの表領域、および重複表のために作成した表領域が、すべてのシャードに作成されたことを確認します。

111

表領域セットの表領域の数は、create shardcatalogコマンドで指定したチャンク数に基づいています。

シャード・カタログの作成例で指定した12個のチャンクのうちの最初の6個のチャンクを持つ表領域セット、および複製されたProductsの表領域を次の例に示します。$ sqlplus / as sysdba

SQL> select TABLESPACE_NAME, BYTES/1024/1024 MB from sys.dba_data_files order by tablespace_name;

TABLESPACE_NAME MB----------------------- ----------C001TSP_SET_1 100C002TSP_SET_1 100C003TSP_SET_1 100C004TSP_SET_1 100C005TSP_SET_1 100C006TSP_SET_1 100PRODUCTS_TSP 100SYSAUX 650SYSTEM 890SYS_SHARD_TS 100TSP_SET_1 100

TABLESPACE_NAME MB------------------------ ----------UNDOTBS1 105USERS 5

13 rows selected.

構成のすべてのシャードでこのステップを繰り返します。

11. チャンクおよびチャンク表領域がすべてのシャードに作成されたことを確認します。SQL> set linesize 140SQL> column table_name format a20SQL> column tablespace_name format a20SQL> column partition_name format a20SQL> show parameter db_unique_name

NAME TYPE VALUE---------------- ----------- ------------------------------db_unique_name string sh1

SQL> select table_name, partition_name, tablespace_name from dba_tab_partitions where tablespace_name like 'C%TSP_SET_1' order by tablespace_name;

TABLE_NAME PARTITION_NAME TABLESPACE_NAME---------------- ---------------- --------------------ORDERS CUSTOMERS_P1 C001TSP_SET_1CUSTOMERS CUSTOMERS_P1 C001TSP_SET_1LINEITEM CUSTOMERS_P1 C001TSP_SET_1CUSTOMERS CUSTOMERS_P2 C002TSP_SET_1LINEITEMS CUSTOMERS_P2 C002TSP_SET_1ORDERS CUSTOMERS_P2 C002TSP_SET_1CUSTOMERS CUSTOMERS_P3 C003TSP_SET_1ORDERS CUSTOMERS_P3 C003TSP_SET_1LINEITEMS CUSTOMERS_P3 C003TSP_SET_1ORDERS CUSTOMERS_P4 C004TSP_SET_1CUSTOMERS CUSTOMERS_P4 C004TSP_SET_1

TABLE_NAME PARTITION_NAME TABLESPACE_NAME---------------- ---------------- --------------------LINEITEMS CUSTOMERS_P4 C004TSP_SET_1CUSTOMERS CUSTOMERS_P5 C005TSP_SET_1LINEITEMS CUSTOMERS_P5 C005TSP_SET_1ORDERS CUSTOMERS_P5 C005TSP_SET_1

112

CUSTOMERS CUSTOMERS_P6 C006TSP_SET_1LINEITEMS CUSTOMERS_P6 C006TSP_SET_1ORDERS CUSTOMERS_P6 C006TSP_SET_118 rows selected.


12. シャード・カタログ・データベースに接続して、チャンクが均等に配分されていることを確認します。$ sqlplus / as sysdba

SQL> set echo offSQL> SELECT a.name Shard, COUNT(b.chunk_number) Number_of_Chunks FROM gsmadmin_internal.database a, gsmadmin_internal.chunk_loc b WHERE a.database_num=b.database_num GROUP BY a.name ORDER BY a.name;

SHARD NUMBER_OF_CHUNKS------------------------------ ----------------sh1 6sh2 6sh3 6sh4 6

13. シャード表および重複表が作成されたことを確認します。

シャード・カタログ・データベースおよび各シャードで、アプリケーション・スキーマのユーザーとしてログインします。

次の例は、app_schemaユーザーとしてデータベース・シャード上の表に問い合せています。$ sqlplus app_schema/app_schema_passwordConnected.

SQL> select table_name from user_tables;

TABLE_NAME-----------------------------------------------------------------------CUSTOMERSORDERSLINEITEMSPRODUCTS

4 rows selected.

14. Data Guard Brokerの自動ファスト・スタート・フェイルオーバー構成が設定されたことを確認します。$ ssh os_username@shard_host_1$ dgmgrl

DGMGRL> connect sys/passwordConnected to "sh1"Connected as SYSDG.DGMGRL> show configuration

Configuration - sh1

Protection Mode: MaxPerformance Members: sh1 - Primary database sh2 - (*) Physical standby database

Fast-Start Failover: ENABLED

Configuration Status:SUCCESS (status updated 15 seconds ago)

DGMGRL> show database sh1

113

Database - sh1

Role: PRIMARY Intended State: TRANSPORT-ON Instance(s): sh1

Database Status:SUCCESS


Database - sh2

Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 0 seconds ago) Apply Lag: 0 seconds (computed 0 seconds ago) Average Apply Rate: 2.00 KByte/s Real Time Query: ON Instance(s): sh2


DGMGRL> show fast_start failover


Threshold: 30 seconds Target: sh2 Observer: shard_director_host Lag Limit: 30 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: (none) Observer Override: FALSE

Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile NO Stuck Archiver NO Datafile Write Errors YES

Oracle Error Conditions: (none)

15. ファスト・スタート・フェイルオーバーのオブザーバを見つけます。

シャード・カタログ・データベースに接続して、次のコマンドを実行します。$ sqlplus / as sysdba

SQL> SELECT observer_state FROM gsmadmin_internal.broker_configs;

OBSERVER_STATE--------------------------------------------------------------------------------GSM server SHARDDIRECTOR2. Observer started. Log files at '/u01/app/oracle/product/18.0.0/gsmhome_1/network/admin/gsm_observer_1.log'.

GSM server SHARDDIRECTOR2. Observer started. Log files at '/u01/app/oracle/product/18.0.0/gsmhome_1/network.admin/gsm_observer_2.log'.

関連項目:


114





8.7.3 システム管理のSDBのデモ・アプリケーション

システム管理のシャード・データベース(SDB)のデモ・アプリケーションは、オンライン小売業者のワークロードをシミュレートしています。システム管理(自動シャーディング)のSDB構成のセットアップを検証するために使用してください。また、デモ・アプリケーションは、データベース・シャーディングを初めて使用する管理者および開発者にシャーディングの概念の実例を示します。

デモ・アプリケーションでは、システム管理のSDB環境およびCUSTOMER表ファミリがすでに作成されていることを想定しています。この環境では、任意の数のチャンクおよびシャード(データベース・ノード)を持つことができます。実行すると、アプリケーションは最初にProductsにデータを移入してから、管理者がいつでも一時休止できる1時間のワークロードを開始します。このワークロードには、4つのタイプのトランザクション(顧客オーダーの作成、オーダーのリストの検索、新しい製品の作成、およびレポートの生成でのマルチシャード問合せ)が含まれています。シャード・データベース構成のすべての特徴が示されます。

デモ・アプリケーション、および実行方法および監視方法について説明しているREADMEファイルは、My Oracle Supportドキュメント2184500.1からダウンロードできます。


8.8 ユーザー定義のSDBの作成およびデプロイ

次の各項では、ユーザー定義のSDBを作成してデプロイするタスクについて説明します。

ユーザー定義のSDBのデプロイ次の手順では、ADD SHARDコマンドとOracle Active Data Guard高可用性ソリューションを使用してユーザー定義のシャード・データベースをデプロイする方法について説明します。ユーザー定義のSDBのスキーマの作成SDBのスキーマ・ユーザー、表領域セット、シャード表および重複表を作成します。DDLがすべてのシャードに伝播されたことを確認し、シャードに接続されている状態で、ファスト・スタート・フェイルオーバーを使用した自動Data Guard Broker構成を検証します。


8.8.1 ユーザー定義のSDBのデプロイ

次の手順では、ADD SHARDコマンドとOracle Active Data Guard高可用性ソリューションを使用してユーザー定義のシャード・データベースをデプロイする方法について説明します。

ユーザー定義のシャーディングでは、ユーザーがデータをシャードにマップできます。ユーザー定義のシャーディング方法の概念に関する詳細は、ユーザー定義のシャーディングを参照してください。

1. この手順では、シャード・データベースのデプロイの概要で説明されているADD SHARDによる方法を使用して説明しているため、最初にそれぞれのホストでシャードとして使用するデータベースを作成する必要があります。

シャード・データベースには次の特性が必要です。

各ホストに関連付けられたTNSリスナーがあること

115

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=2184500.1



GSMUSERアカウントのロックが既知のパスワードで解除されていること

SYSDGおよびSYSBACKUP権限がGSMUSERに付与されていること

プライマリ・データベースとスタンバイ・データベースがそのように構成されていること

REDO適用が対応するプライマリ・データベースとスタンバイ・データベース間で設定されていること

フラッシュバック・ロギングと強制ロギングが有効になっていること

compatibleパラメータが12.2.0以上に設定されていること

サーバー・パラメータ・ファイル(SPFILE)が使用されていること

DATA_PUMP_DIRディレクトリ・オブジェクトが各データベースで作成され、有効なディレクトリを指していること

次に、データベースがシャード用に正しく設定されていることを検証する必要があります。構成に追加する前に、各データベースに対して次のコマンドを実行します。SQL> set serveroutput onSQL> execute DBMS_GSM_FIX.validateShard

画面出力には、問題の分析に必要なINFO、WARNINGおよびERRORの情報が含まれます。WARNINGメッセージとERRORメッセージはすべて解決する必要があります。変更後にvalidateShard()を再度実行して構成を確認します。

2. シャード・ディレクタのホストに接続します。$ ssh os_user@shard_director1_host


4. ビジネスに必要なカスタマイズされた各シャード・グループ用のシャード領域をシャード・データベース構成に追加します。

シャード領域には、プライマリ・シャード・データベースと1つ以上のアクティブ・スタンバイが含まれています。

この例では、シャード領域にshspace1とshspace2という名前が付けられています。名前は自分で選択できます。GDSCTL> add shardspace -shardspace shspace1 -protectmode maxavailabilityGDSCTL> add shardspace -shardspace shspace2 -protectmode maxavailability

5. 各シャードのホスト・アドレスをカタログ内の登録に関する有効ノード・チェック(VNCR)リストに追加してから、次の例に示すように、プライマリまたはスタンバイ・シャードグループにシャードを追加します。

注意:

116

登録に関する有効ノード・チェック機能では、シャード・ディレクタによって許可された登録リクエストのIPアドレス、ホスト名またはサブネットのセットの構成や動的な更新が可能になります。シャード・ディレクタへのデータベース・インスタンスの登録は、リクエスト元が有効なノードである場合にのみ成功します。デフォルトでは、create shardまたはaddshardが実行されるたびに、シャード管理層(Oracle Global Data Servicesフレームワークに基づく)は、リモート・データベースが実行されているホストのVNCRエントリを自動的に追加します。自動化(自動VNCRと呼ばれます)によってターゲット・ホストのパブリックIPアドレスが検索され、そのIPアドレスのVNCRエントリが自動的に追加されます。ホストに複数のパブリックIPアドレスがある場合は、データベースに登録されたアドレスが自動VNCRを使用して追加されたアドレスと同じではないことがあり、登録が拒否されることがあります。ターゲット・データベースのホストに複数のパブリックIPアドレスがある場合は、GDSCTLでaddinvitednodeコマンドまたはadd invitedsubnetコマンドを使用して、このホストのVNCRを手動で構成することをお薦めします。



次の例は、ADD SHARDコマンドを使用して4つのシャードを作成する方法を示しています。最初の2つはシャード領域shspace1のプライマリおよびアクティブ・スタンバイ・シャードであり、後の2つはシャード領域shspace2のプライマリおよびアクティブ・スタンバイです。リージョンとしてプライマリにはregion1が指定され、スタンバイにはregion2が指定されていることに注意してください。GDSCTL> add invitednode shard_host_1 GDSCTL> add shard -connect shard_host_1:1521/shard_database_name-shardspace shspace1 -deploy_as primary -pwd GSMUSER_password -region region1

GDSCTL> add invitednode shard_host_2GDSCTL> add shard -connect shard_host_2:1521/shard_database_name-shardspace shspace1 -deploy_as active_standby -pwd GSMUSER_password-region region2

GDSCTL> add invitednode shard_host_3 GDSCTL> add shard -connect shard_host_3:1521/shard_database_name-shardspace shspace2 -deploy_as primary -pwd GSMUSER_password -region region1

GDSCTL> add invitednode shard_host_4GDSCTL> add shard -connect shard_host_4:1521/shard_database_name-shardspace shspace2 -deploy_as active_standby -pwd GSMUSER_password-region region2

追加されるシャード・データベースがプラガブル・データベース(PDB)である場合は、ADDSHARDで-cdbオプションを使用して、PDBシャードが含まれているコンテナ・データベース(CDB)を指定する必要があります。また、ADD SHARDコマンドの前にADD CDBを使用してカタログにCDBを追加する必要があります。ADD CDBおよびADD SHARDの構文は、Oracle Database GlobalData Services概要および管理ガイドを参照してください。Oracle Database 18cでは、各CDB内の1つのPDBのみをシャードにすることができます。

6. シャード・ディレクタから構成を確認します。GDSCTL> configRegions-----------------------region1

(VNCR)

117

region2

GSMs-----------------------sharddirector1sharddirector2

Sharded Database-----------------------udef_shpool

Databases-----------------------sh1sh2sh3sh4

Shard spaces-----------------------shspace1shspace2

Services-----------------------

GDSCTL pending requests-----------------------Command Object Status------- ------ ------

Global properties-----------------------Name: oradbcloudMaster GSM: sharddirector1DDL sequence #: 0

GDSCTL> config vncrName Group ID ---- --------shard_host_1 shard_host_2shard_host_3shard_host_4shard_catalog_host_IP

GDSCTL> config shardName Shard space Status State Region Availability---- ----------- ------ ----- ------ ------------sh1 shspace1 U none region1 -sh2 shspace1 U none region2 -sh3 shspace2 U none region1 -sh4 shspace2 U none region2 -

7. DEPLOYコマンドを実行して、シャードとレプリカを作成します。

DEPLOYコマンドは実行に約15-30分かかります。GDSCTL> deploy

プライマリ・シャードおよびスタンバイ・シャードが作成されると、DEPLOYコマンドはファスト・スタート・フェイルオーバーを有効にしてData Guard Brokerを構成します。ファスト・スタート・フェイルオーバー・オブザーバは、スタンバイ・グループのシャード・ディレクタ(この例ではsharddirector2)で自動的に起動されます。

8. すべてのシャードがデプロイされたことを確認します。GDSCTL> config shardName Shard space Status State Region Availability---- ----------- ------ ----- ------ ------------sh1 shspace1 Ok Deployed region1 ONLINE

118

sh2 shspace1 Ok Deployed region2 READ_ONLYsh3 shspace2 Ok Deployed region1 ONLINEsh4 shspace2 Ok Deployed region2 READ_ONLY

9. すべてのシャードが登録されたことを確認します。GDSCTL> databasesDatabase: "sh1" Registered: Y State: Ok ONS: N. Role: PRIMARYInstances: 1 Region: region1 Registered instances: udef_shpool%1Database: "sh2" Registered: Y State: Ok ONS: N. Role: PH_STNDBYInstances: 1 Region: region2 Registered instances: udef_shpool%11Database: "sh3" Registered: Y State: Ok ONS: N. Role: PRIMARYInstances: 1 Region: region1 Registered instances: udef_shpool%21Database: "sh4" Registered: Y State: Ok ONS: N. Role: PH_STNDBYInstances: 1 Region: region2 Registered instances: udef_shpool%31

10. シャードの構成を確認します。GDSCTL> config shard -shard sh1Name: sh1Shard space: shspace1Status: OkState: DeployedRegion: region1Connection string: shard_host_1:1521/sh1:dedicatedSCAN address:ONS remote port: 0Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Last Failed DDL: DDL Error: ---Failed DDL id:Availability: ONLINE

Supported services-----------------------Name Preferred Status---- --------- ------


oltp_rw_srvcグローバル・サービスは、クライアントがシャード・データベースに接続するために使用できるグローバル・データ・サービスです。oltp_rw_srvcサービスはプライマリ・シャードでOLTPトランザクションを実行します。同様に、スタンバイ・シャードで読取り専用のワークロードを実行するために、oltp_ro_srvcグローバル・サービスが作成されます。GDSCTL> add service -service oltp_rw_srvc -role primary


Name Network name Pool Started Preferred all---- ------------ ---- ------- -------------oltp_rw_srvc oltp_rw_srvc.cust_sdb.oracdbcloud udef_shpool No Yes


GDSCTL> status serviceService "oltp_rw_srvc.cust_sdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE Instance "udef_shpool%1", name: "sh1", db: "sh1", region: "region1", status: ready. Instance "udef_shpool%21", name: "sh3", db: "sh3", region: "region1", status: ready.

119

13. スタンバイ・シャードで実行する読取り専用のワークロードのためのグローバル・サービスを追加します。GDSCTL> add service -service oltp_ro_srvc -role physical_standby


Name Network name Pool Started Preferred all---- ------------ ---- ------- -------------oltp_rw_srvc oltp_rw_srvc.cust_sdb.oracdbcloud cust_sdb Yes Yesoltp_ro_srvc oltp_ro_srvc.cust_sdb.oracdbcloud cust_sdb No Yes

14. 読取り専用サービスを開始し、そのグローバル・サービスのステータスを確認します。GDSCTL> start service -service oltp_ro_srvc

GDSCTL> status serviceService "oltp_ro_srvc.cust_sdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE Instance "udef_shpool%11", name: "sh2", db: "sh2", region: "region2", status: ready. Instance "udef_shpool%31", name: "sh4", db: "sh4", region: "region2", status: ready.Service "oltp_rw_srvc.cust_sdb.oradbcloud" has 2 instance(s). Affinity: ANYWHERE Instance "udef_shpool%1", name: "sh1", db: "sh1", region: "region1", status: ready. Instance "udef_shpool%21", name: "sh3", db: "sh3", region: "region1", status: ready.

関連項目:


親トピック: ユーザー定義のSDBの作成およびデプロイ

8.8.2 ユーザー定義のSDBのスキーマ作成

SDBのスキーマ・ユーザー、表領域セット、シャード表および重複表を作成します。DDLがすべてのシャードに伝播されたことを確認し、シャードに接続されている状態で、ファスト・スタート・フェイルオーバーを使用した自動Data Guard Broker構成を検証します。

1. シャード・カタログ・データベースに接続し、アプリケーション・スキーマのユーザーを作成して、そのユーザーに権限とロールを付与します。


SQL> alter session enable shard ddl;SQL> create user app_schema identified by app_schema_password;SQL> grant all privileges to app_schema;SQL> grant gsmadmin_role to app_schema;SQL> grant select_catalog_role to app_schema;SQL> grant connect, resource to app_schema;SQL> grant dba to app_schema;SQL> grant execute on dbms_crypto to app_schema;

2. シャード表の表領域を作成します。SQL> CREATE TABLESPACE c1_tsp DATAFILE SIZE 100M autoextend on next 10M maxsize unlimited extent management local segment space management auto in shardspace shspace1;

SQL> CREATE TABLESPACE c2_tsp DATAFILE SIZE 100M autoextend on next 10M maxsize unlimited extent management local segment space management auto in shardspace shspace2;

120




3. 列にLOBを使用する場合は、LOBの表領域を指定できます。SQL> CREATE TABLESPACE lobts1 ... in shardspace shspace1;

SQL> CREATE TABLESPACE lobts2 ... in shardspace shspace2;


この例では、重複表はサンプルのCustomers-Orders-ProductsスキーマのProducts表です。SQL> CREATE TABLESPACE products_tsp datafile size 100m autoextend on next 10M maxsize unlimited extent management local uniform size 1m;


この例では、ルート表はサンプルのCustomers-Orders-ProductsスキーマのCustomers表です。SQL> CONNECT app_schema/app_schema_password

SQL> ALTER SESSION ENABLE SHARD DDL;

SQL> CREATE SHARDED TABLE Customers ( CustId VARCHAR2(60) NOT NULL, CustProfile VARCHAR2(4000), Passwd RAW(60), CONSTRAINT pk_customers PRIMARY KEY (CustId), CONSTRAINT json_customers CHECK (CustProfile IS JSON) ) PARTITION BY RANGE (CustId) ( PARTITION ck1 values less than ('m') tablespace ck1_tsp, PARTITION ck2 values less than (MAXVALUE) tablespace ck2_tsp );

注意:

シャード表の列にLOBが含まれる場合は、次に示すようにCREATE SHARDED TABLE文にLOB表領域を含めることができます。SQL> CREATE SHARDED TABLE Customers ( CustId VARCHAR2(60) NOT NULL, CustProfile VARCHAR2(4000), Passwd RAW(60), image BLOB, CONSTRAINT pk_customers PRIMARY KEY (CustId), CONSTRAINT json_customers CHECK (CustProfile IS JSON) ) PARTITION BY RANGE (CustId) ( PARTITION ck1 values less than ('m') tablespace ck1_tsp lob(image) store as (tablespace lobts1), PARTITION ck2 values less than (MAXVALUE) tablespace ck2_tsp lob(image) store as (tablespace lobts2) );



Ordersシャード表を最初に作成します。SQL> CREATE SHARDED TABLE Orders ( OrderId INTEGER NOT NULL, CustId VARCHAR2(60) NOT NULL, OrderDate TIMESTAMP NOT NULL, SumTotal NUMBER(19,4), Status CHAR(4),

121

CONSTRAINT pk_orders PRIMARY KEY (CustId, OrderId), CONSTRAINT fk_orders_parent FOREIGN KEY (CustId) REFERENCES Customers ON DELETE CASCADE ) PARTITION BY REFERENCE (fk_orders_parent);

OrderId列に使用される順序を作成します。SQL> CREATE SEQUENCE Orders_Seq;

LineItemsのシャード表を作成します。SQL> CREATE SHARDED TABLE LineItems ( OrderId INTEGER NOT NULL, CustId VARCHAR2(60) NOT NULL, ProductId INTEGER NOT NULL, Price NUMBER(19,4), Qty NUMBER, CONSTRAINT pk_items PRIMARY KEY (CustId, OrderId, ProductId), CONSTRAINT fk_items_parent FOREIGN KEY (CustId, OrderId) REFERENCES Orders ON DELETE CASCADE ) PARTITION BY REFERENCE (fk_items_parent);


この例では、Products表は重複しているオブジェクトです。SQL> CREATE DUPLICATED TABLE Products ( ProductId INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, Name VARCHAR2(128), DescrUri VARCHAR2(128), LastPrice NUMBER(19,4) ) TABLESPACE products_tsp;

8. シャード・ディレクタのホストから、表領域の作成中に障害が発生しなかったことを確認します。GDSCTL> show ddlid DDL Text Failed shards-- -------- -------------

3 grant create table, create procedure,... 4 grant unlimited tablespace to app_schema 5 grant select_catalog_role to app_schema 6 create tablespace c1_tsp DATAFILE SIZ... 7 Create tablespace c2_tsp DATAFILE SIZ... 8 CREATE SHARDED TABLE Customers ( Cu... 9 CREATE SHARDED TABLE Orders ( Order... 10 CREATE SHARDED TABLE LineItems ( Or... 11 create tablespace products_tsp datafi... 12 CREATE MATERIALIZED VIEW "APP_SCHEMA"...

注意:

show ddlコマンドの出力は切り捨てられることがあります。出力内容の完全なテキストを表示するには、カタログでSELECT ddl_text FROM gsmadmin_internal.ddl_requestsを実行します。


構成の各シャードでconfig shardコマンドおよびconfig chunksコマンドを実行します。GDSCTL> config shard -shard sh1

Name: sh1Shard space: shspace1Status: OkState: DeployedRegion: region1Connection string: shard_host_1:1521/sh1:dedicated

122

SCAN address: ONS remote port: 0Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Last Failed DDL: DDL Error: ---Failed DDL id: Availability: ONLINERack:

Supported services------------------------Name Preferred Status ---- --------- ------ oltp_ro_srvc Yes Enabled oltp_rw_srvc Yes Enabled


10. シャード表ファミリのために作成した表領域、および重複表のために作成した表領域が、すべてのシャードに作成されたことを確認します。


シャード・カタログの作成例で指定した12個のチャンクのうちの最初の6個のチャンクを持つ表領域セット、および複製されたProductsの表領域を次の例に示します。$ sqlplus / as sysdba


TABLESPACE_NAME MB----------------------- ----------C1_TSP 100PRODUCTS_TSP 10SYSAUX 722.1875SYSEXT 39SYSTEM 782.203125SYS_SHARD_TS 100UD1 470

7 rows selected.


11. チャンクおよびチャンク表領域がすべてのシャードに作成されたことを確認します。SQL> set linesize 140SQL> column table_name format a20SQL> column tablespace_name format a20SQL> column partition_name format a20SQL> show parameter db_unique_name

NAME TYPE VALUE---------------- ----------- ------------------------------db_unique_name string sh1

SQL> select table_name, partition_name, tablespace_name from dba_tab_partitions where tablespace_name like 'C%TSP_SET_1'

123

order by tablespace_name;

TABLE_NAME PARTITION_NAME TABLESPACE_NAME---------------- ---------------- --------------------CUSTOMERS CK1 C1_TSPORDERS CK1 C1_TSPLINEITEMS CK1 C1_TSP




次の例は、app_schemaユーザーとしてデータベース・シャード上の表に問い合せています。$ sqlplus app_schema/app_schema_passwordConnected.

SQL> select table_name from user_tables;

TABLE_NAME-----------------------------------------------------------------------CUSTOMERSORDERSLINEITEMSPRODUCTSUSLOG$_PRODUCTS

13. Data Guard Brokerの自動ファスト・スタート・フェイルオーバー構成が設定されたことを確認します。$ ssh os_username@shard_host_1$ dgmgrl

DGMGRL> connect sys/passwordConnected to "sh1"Connected as SYSDG.DGMGRL> show configuration

Configuration - sh1

Protection Mode: MaxPerformance Members: sh1 - Primary database sh2 - (*) Physical standby database


Configuration Status:SUCCESS (status updated 15 seconds ago)


Database - sh1

Role: PRIMARY Intended State: TRANSPORT-ON Instance(s): sh1



Database - sh2

Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 0 seconds ago)

124

Apply Lag: 0 seconds (computed 0 seconds ago) Average Apply Rate: 2.00 KByte/s Real Time Query: ON Instance(s): sh2


DGMGRL> show fast_start failover


Threshold: 30 seconds Target: sh2 Observer: shard_director_host Lag Limit: 30 seconds Shutdown Primary: TRUE Auto-reinstate: TRUE Observer Reconnect: (none) Observer Override: FALSE

Configurable Failover Conditions Health Conditions: Corrupted Controlfile YES Corrupted Dictionary YES Inaccessible Logfile NO Stuck Archiver NO Datafile Write Errors YES

Oracle Error Conditions: (none)

14. ファスト・スタート・フェイルオーバーのオブザーバを見つけます。

シャード・カタログ・データベースに接続して、次のコマンドを実行します。$ ssh oracle@shard6

$ ps -ef |grep dgmgrloracle 8210 8089 0 22:18 pts/4 00:00:00 grep dgmgrloracle 20189 1 0 02:57 ? 00:02:40 dgmgrl -delete_script @/u01/app/oracle/product/18.0.0/gsmhome_1/network/admin/gsm_observer_1.cfgoracle 20193 1 0 02:57 ? 00:02:43 dgmgrl -delete_script @/u01/app/oracle/product/18.0.0/gsmhome_1/network/admin/gsm_observer_2.cfg

関連項目:


親トピック: ユーザー定義のSDBの作成およびデプロイ

8.9 コンポジットSDBの作成およびデプロイ

コンポジットSDBをデプロイするには、必要なOracle Shardingソフトウェア・コンポーネントをインストールし、コンポジットSDBにオブジェクトを構成して、スキーマを作成する必要があります。

コンポジット・シャーディング方法では、コンシステント・ハッシュによりパーティション化された表のデータの異なるサブセットについて、複数のシャード領域を作成できます。シャード領域はシャードのセットで、キーの値の範囲またはリストに対応するデータが格納されます。

次の項は、コンポジットSDBをデプロイするためのタスクについて説明しています。

コンポジットSDBのデプロイ

125




コンポジットSDBをデプロイするには、シャードグループとシャードを作成し、DEPLOYコマンドを実行して、ロールベースのグローバル・サービスを作成します。コンポジットSDBのスキーマの作成SDBのスキーマ・ユーザー、表領域セット、シャード表および重複表を作成します。DDLがすべてのシャードに伝播されたことを確認し、シャードに接続されている状態で、ファスト・スタート・フェイルオーバーを使用した自動Data Guard Broker構成を検証します。


8.9.1 コンポジットSDBのデプロイ

コンポジットSDBをデプロイするには、シャードグループとシャードを作成し、DEPLOYコマンドを実行して、ロールベースのグローバル・サービスを作成します。

このデプロイメント手順で使用される例は、アメリカとヨーロッパの個別のシャード領域およびシャードグループが作成されるグローバル分散シナリオに基づいています。

1. シャード・ディレクタのホストに接続して、環境変数を確認します。$ ssh os_user@shard_director_home$ env |grep ORAORACLE_BASE=/u01/app/oracleORACLE_HOME=/u01/app/oracle/product/18.0.0/gsmhome_1


3. ビジネスで必要なカスタマイズされたシャードの各グループのためのシャード領域とシャードグループを追加します。

この例では、アメリカとヨーロッパの顧客のためのシャード領域とシャードグループが作成されます。名前は自分で選択できます。GDSCTL> add shardspace -shardspace cust_americaGDSCTL> add shardgroup -shardspace cust_america -shardgroup america_shgrp1 -deploy_as primary -region region1

GDSCTL> add shardspace -shardspace cust_europeGDSCTL> add shardgroup -shardspace cust_europe -shardgroup europe_shgrp1 -deploy_as primary -region region2

注意:

本番デプロイメントの場合は、高可用性のためにadd shardgroupコマンドを使用して追加のシャードグループを作成する必要があります

4. シャード領域およびシャードグループの構成を確認します。GDSCTL> config shardspaceSHARDSPACE Chunks ---------- ------ cust_america 12 cust_europe 12 shardspaceora 12 GDSCTL>config shardgroupShard Group Chunks Region SHARDSPACE ----------- ------ ------ ----------

126

america_shgrp1 12 region1 cust_america europe_shgrp1 12 region2 cust_europe

5. シャード・データベースの構成を確認します。GDSCTL> config

Regions------------------------region1 region2

GSMs------------------------sharddirector1 sharddirector2

Sharded Database------------------------cust_sdb_comp

Databases------------------------

Shard Groups------------------------america_shgrp1 europe_shgrp1

Shard spaces------------------------cust_america cust_europe shardspaceora

Services------------------------

GDSCTL pending requests------------------------Command Object Status------- ------ ------

Global properties------------------------Name: oradbcloudMaster GSM: sharddirector1DDL sequence #: 0

6. 各シャードのホスト・アドレスをカタログ内の登録に関する有効ノード・チェック(VNCR)リストに追加し、次の例に示すように、プライマリまたはスタンバイのシャードグループにシャードを作成します。

注意:

登録に関する有効ノード・チェック(VNCR)機能では、シャード・ディレクタによって許可された登録リクエストのIPアドレス、ホスト名またはサブネットのセットの構成や動的な更新が可能になります。シャード・ディレクタへのデータベース・インスタンスの登録は、リクエスト元が有効なノードである場合にのみ成功します。デフォルトでは、create shardまたはaddshardが実行されるたびに、シャード管理層(Oracle Global Data Servicesフレームワークに基づく)は、リモート・データベースが実行されているホストのVNCRエントリを自動的に追加します。自動化(自動VNCRと呼ばれます)によってターゲット・ホストのパブリックIPアドレスが検索され、そのIPアドレスのVNCRエントリが自動的に追加されます。ホストに複数のパブリックIPアドレスがある場合は、データベースに登録されたアドレスが自動VNCRを使用して追加されたアドレスと同じではないことがあり、登録が拒否されることがあります。ターゲット・データベースのホストに複数のパブリックIPアドレスがある場合は、GDSCTLでaddinvitednodeコマンドまたはadd invitedsubnetコマンドを使用して、このホストのVNCRを手動で構成することをお薦めします。

127



この例は、4つのシャードを作成する方法を示しています。そのうちの2つはアメリカ・シャードグループにあり、他の2つはヨーロッパ・シャードグループにあります。os_credentialは、各ホストに作成したオペレーティング・システムの資格証明です。

シャードを作成するときに、次の例に示すようにCREATE SHARDで-sys_passwordを使用してSYSのパスワードを設定することもできます。これにより、シャードが作成されてDEPLOYを実行したときに、SYSのパスワードが設定されます。CREATE SHARDには、他にもデータベース・パラメータ、記憶域とファイルの場所、リスナー・ポート番号などをカスタマイズできるオプションのパラメータがあります。詳細は、Oracle Database Global Data Services概要および管理ガイドの付録を参照してください。GDSCTL> add invitednode shard_host_1 GDSCTL> create shard -shardgroup america_shgrp1 -destination shard_host_1 -credential os_credential-sys_password

GDSCTL> add invitednode shard_host_2GDSCTL> create shard -shardgroup america_shgrp1 -destination shard_host_2 -credential os_credential-sys_password

GDSCTL> add invitednode shard_host_3 GDSCTL> create shard -shardgroup europe_shgrp1 -destination shard_host_3 -credential os_credential-sys_password

GDSCTL> add invitednode shard_host_4GDSCTL> create shard -shardgroup europe_shgrp1 -destination shard_host_4 -credential os_credential-sys_password

シャード・データベースのデプロイの概要で説明されているADD SHARD方法を使用している場合は、前述の例のCREATE SHARDコマンドのかわりに次のコマンドを使用します。追加されるシャード・データベースがプラガブル・データベース(PDB)である場合は、ADD SHARDで-cdbオプションを使用して、PDBシャードが含まれているコンテナ・データベース(CDB)を指定する必要があります。また、ADD SHARDコマンドの前にADD CDBを使用してカタログにCDBを追加する必要があります。ADD CDBおよびADD SHARDの構文は、Oracle Database Global Data Services概要および管理ガイドを参照してください。Oracle Database 18cでは、各CDB内の1つのPDBのみをシャードにすることができます。GDSCTL> add shard –shardgroup america_shgrp1 –connect shard_host:TNS_listener_port/shard_database_name –pwd GSMUSER_password

7. シャード・ディレクタから構成を確認します。

シャード名sh1、sh2、sh3およびsh4はシステムによって生成されたシャード名です。GDSCTL> config shardName Shard Group Status State Region Availability---- ----------- ------ ----- ------ ------------sh1 america_shgrp1 U none region1 - sh2 america_shgrp1 U none region1 - sh3 europe_shgrp1 U none region2 - sh4 europe_shgrp1 U none region2 -

128

GDSCTL> config vncrName Group ID ---- --------shard_host_1shard_host_2shard_host_3shard_host_4shard_catalog_host_IP

8. DEPLOYコマンドを実行して、シャードを作成します。GDSCTL> deploy

DEPLOYコマンドは実行に約15-30分かかります。DEPLOYコマンドはDBCAを使用してシャードを作成します。

9. すべてのシャードがデプロイされたことを確認します。GDSCTL> config shardName Shard Group Status State Region Availability ---- ----------- ------ ----- ------ ------------ sh1 america_shgrp1 Ok Deployed region1 ONLINE sh2 america_shgrp1 Ok Deployed region1 ONLINE sh3 europe_shgrp1 Ok Deployed region2 ONLINE sh4 europe_shgrp1 Ok Deployed region2 ONLINE

10. すべてのシャードが登録されたことを確認します。GDSCTL> databasesDatabase: "sh1" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region1 Registered instances: cust_sdb_comp%1Database: "sh2" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region1 Registered instances: cust_sdb_comp%11Database: "sh3" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region2 Registered instances: cust_sdb_comp%21Database: "sh4" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region2 Registered instances: cust_sdb_comp%31

11. シャードの構成を確認します。GDSCTL> config shard -shard sh1

Name: sh1Shard Group: america_shgrp1Status: OkState: DeployedRegion: region1Connection string: shard1:1521/sh1:dedicatedSCAN address: ONS remote port: 0Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Last Failed DDL: DDL Error: ---Failed DDL id: Availability: ONLINE

Supported services------------------------Name Preferred Status ---- --------- ------


129

oltp_rw_srvcグローバル・サービスは、クライアントからの接続を実際のデータベースにルーティングするために使用されるグローバル・データ・サービスのリスナーです。oltp_rw_srvcサービスはプライマリ・シャードでOLTPトランザクションを実行します。GDSCTL> add service -service oltp_rw_srvcGDSCTL> config service

Name Network name Pool Started Preferred all ---- ------------ ---- ------- ------------- oltp_rw_srvc oltp_rw_srvc.cust_sdb_comp.or cust_sdb_comp No Yes adbcloud


GDSCTL> status serviceService "oltp_rw_srvc.cust_sdb_comp.oradbcloud" has 4 instance(s). Affinity: ANYWHERE Instance "cust_sdb_comp%1", name: "sh1", db: "sh1", region: "region1", status: ready. Instance "cust_sdb_comp%11", name: "sh2", db: "sh2", region: "region1", status: ready. Instance "cust_sdb_comp%21", name: "sh3", db: "sh3", region: "region2", status: ready. Instance "cust_sdb_comp%31", name: "sh4", db: "sh4", region: "region2", status: ready.

関連項目:


親トピック: コンポジットSDBの作成およびデプロイ

8.9.2 コンポジットSDBのスキーマ作成

SDBのスキーマ・ユーザー、表領域セット、シャード表および重複表を作成します。DDLがすべてのシャードに伝播されたことを確認し、シャードに接続されている状態で、ファスト・スタート・フェイルオーバーを使用した自動Data Guard Broker構成を検証します。

1. シャード・カタログのホストに接続し、ORACLE_SIDにシャード・カタログ名を設定します。2. シャード・カタログ・データベースに接続し、アプリケーション・スキーマのユーザーを作成して、そのユーザーに権限とロールを付与します。


SQL> connect / as sysdbaSQL> alter session enable shard ddl;SQL> create user app_schema identified by app_schema_password;SQL> grant connect, resource, alter session to app_schema;SQL> grant execute on dbms_crypto to app_schema;SQL> grant create table, create procedure, create tablespace, create materialized view to app_schema;SQL> grant unlimited tablespace to app_schema;SQL> grant select_catalog_role to app_schema;SQL> grant all privileges to app_schema;SQL> grant gsmadmin_role to app_schema;SQL> grant dba to app_schema;

3. シャード表の表領域セットを作成します。SQL> CREATE TABLESPACE SET TSP_SET_1 in shardspace cust_america using template

130



(datafile size 100m autoextend on next 10M maxsize unlimited extent management local segment space management auto );

SQL> CREATE TABLESPACE SET TSP_SET_2 in shardspace cust_europe using template (datafile size 100m autoextend on next 10M maxsize unlimited extent management local segment space management auto );

表領域セットを作成する場合、シャード領域の指定はオプションです。コマンドにシャード領域を指定しない場合は、デフォルトのシャード領域が使用されます。

4. 列にLOBを使用する場合は、LOBの表領域セットを指定できます。SQL> CREATE TABLESPACE SET LOBTS1 in shardspace cust_america ... ;

SQL> CREATE TABLESPACE SET LOBTS2 in shardspace cust_europe ... ;

注意:

コンポジット・シャーディングでは、LOBの表領域セットをサブパーティション・レベルで指定できません。


この例では、重複表はサンプルのCustomers-Orders-ProductsスキーマのProducts表です。CREATE TABLESPACE products_tsp datafile size 100m autoextend on next 10M maxsize unlimited extent management local uniform size 1m;


この例では、ルート表はサンプルのCustomers-Orders-ProductsスキーマのCustomers表です。connect app_schema/app_schema_passwordalter session enable shard ddl;

CREATE SHARDED TABLE Customers( CustId VARCHAR2(60) NOT NULL, FirstName VARCHAR2(60), LastName VARCHAR2(60), Class VARCHAR2(10), Geo VARCHAR2(8), CustProfile VARCHAR2(4000), Passwd RAW(60), CONSTRAINT pk_customers PRIMARY KEY (CustId), CONSTRAINT json_customers CHECK (CustProfile IS JSON)) partitionset by list(GEO)partition by consistent hash(CustId)partitions auto(partitionset america values ('AMERICA') tablespace set tsp_set_1,partitionset europe values ('EUROPE') tablespace set tsp_set_2);

注意:

シャード表の列にLOBが含まれる場合は、次に示すようにCREATE SHARDED TABLE文にLOB表領域セットを含めることができます。CREATE SHARDED TABLE Customers( CustId VARCHAR2(60) NOT NULL, FirstName VARCHAR2(60), LastName VARCHAR2(60), Class VARCHAR2(10),

131

Geo VARCHAR2(8) NOT NULL, CustProfile VARCHAR2(4000), Passwd RAW(60), image BLOB, CONSTRAINT pk_customers PRIMARY KEY (CustId), CONSTRAINT json_customers CHECK (CustProfile IS JSON)) partitionset by list(GEO)partition by consistent hash(CustId)partitions auto(partitionset america values ('AMERICA') tablespace set tsp_set_1 lob(image) store as (tablespace set lobts1),partitionset europe values ('EUROPE') tablespace set tsp_set_2 lob(image) store as (tablespace set lobts2));



OrderId列に使用される順序を作成します。CREATE SEQUENCE Orders_Seq;

Ordersシャード表を最初に作成します。CREATE SHARDED TABLE Orders( OrderId INTEGER NOT NULL, CustId VARCHAR2(60) NOT NULL, OrderDate TIMESTAMP NOT NULL, SumTotal NUMBER(19,4), Status CHAR(4), constraint pk_orders primary key (CustId, OrderId), constraint fk_orders_parent foreign key (CustId) references Customers on delete cascade) partition by reference (fk_orders_parent);

LineItemsのシャード表を作成します。CREATE SHARDED TABLE LineItems( OrderId INTEGER NOT NULL, CustId VARCHAR2(60) NOT NULL, ProductId INTEGER NOT NULL, Price NUMBER(19,4), Qty NUMBER, constraint pk_items primary key (CustId, OrderId, ProductId), constraint fk_items_parent foreign key (CustId, OrderId) references Orders on delete cascade) partition by reference (fk_items_parent);


この例では、Products表は重複しているオブジェクトです。CREATE DUPLICATED TABLE Products( ProductId INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, Name VARCHAR2(128), DescrUri VARCHAR2(128), LastPrice NUMBER(19,4)) tablespace products_tsp;

9. シャード・ディレクタのホストから、表領域の作成中に障害が発生しなかったことを確認します。GDSCTL> show ddlid DDL Text Failed shards -- -------- ------------- 11 CREATE TABLESPACE SET TSP SET 2 in s...

132

12 CREATE TABLESPACE products_tsp datafi... 13 CREATE SHARDED TABLE Customers ( Cu... 14 CREATE SEQUENCE Orders_Seq;15 CREATE SHARDED TABLE Orders ( Order... 16 CREATE SHARDED TABLE LineItems ( Or... 17 create database link "PRODUCTSDBLINK@... 18 CREATE MATERIALIZED VIEW "PRODUCTS" ... 19 CREATE OR REPLACE FUNCTION PasswCreat... 20 CREATE OR REPLACE FUNCTION PasswCheck...


構成の各シャードでconfig shardコマンドおよびconfig chunksコマンドを実行します。GDSCTL> config shard -shard sh1

Name: sh1Shard Group: america_shgrp1Status: OkState: DeployedRegion: region1Connection string: shard1:1521/sh1:dedicatedSCAN address: ONS remote port: 0Disk Threshold, ms: 20CPU Threshold, %: 75Version: 18.0.0.0Last Failed DDL: DDL Error: ---Failed DDL id: Availability: ONLINE

Supported services------------------------Name Preferred Status ---- --------- ------ oltp_rw_srvc Yes Enabled


11. シャード表ファミリのために作成した表領域セットの表領域、および重複表のために作成した表領域が、すべてのシャードに作成されたことを確認します。


シャード・カタログの作成例で指定した12個のチャンクのうちの最初の6個のチャンクを持つ表領域セット、および複製されたProductsの表領域を次のshard_host_1の例に示します。$ sqlplus / as sysdba


TABLESPACE_NAME MB------------------------------ ----------C001TSP_SET_1 100C002TSP_SET_1 100C003TSP_SET_1 100C004TSP_SET_1 100C005TSP_SET_1 100C006TSP_SET_1 100

133

PRODUCTS_TSP 100SYSAUX 650SYSTEM 890SYS_SHARD_TS 100TSP_SET_1 100

TABLESPACE_NAME MB------------------------------ ----------TSP_SET_2 100UNDOTBS1 110USERS 5

14 rows selected.


12. チャンクおよびチャンク表領域がすべてのシャードに作成されたことを確認します。SQL> set linesize 140SQL> column table_name format a20SQL> column tablespace_name format a20SQL> column partition_name format a20SQL> show parameter db_unique_nameNAME TYPE VALUE------------------------------------ ----------- ------------------------------db_unique_name string sh2

SQL> select table_name, partition_name, tablespace_name from dba_tab_partitions where tablespace_name like 'C%TSP_SET_1' order by tablespace_name;

TABLE_NAME PARTITION_NAME TABLESPACE_NAME-------------------- -------------------- --------------------LINEITEMS CUSTOMERS_P7 C007TSP_SET_1CUSTOMERS CUSTOMERS_P7 C007TSP_SET_1ORDERS CUSTOMERS_P7 C007TSP_SET_1CUSTOMERS CUSTOMERS_P8 C008TSP_SET_1LINEITEMS CUSTOMERS_P8 C008TSP_SET_1ORDERS CUSTOMERS_P8 C008TSP_SET_1LINEITEMS CUSTOMERS_P9 C009TSP_SET_1CUSTOMERS CUSTOMERS_P9 C009TSP_SET_1ORDERS CUSTOMERS_P9 C009TSP_SET_1CUSTOMERS CUSTOMERS_P10 C00ATSP_SET_1LINEITEMS CUSTOMERS_P10 C00ATSP_SET_1

TABLE_NAME PARTITION_NAME TABLESPACE_NAME-------------------- -------------------- --------------------ORDERS CUSTOMERS_P10 C00ATSP_SET_1CUSTOMERS CUSTOMERS_P11 C00BTSP_SET_1LINEITEMS CUSTOMERS_P11 C00BTSP_SET_1ORDERS CUSTOMERS_P11 C00BTSP_SET_1CUSTOMERS CUSTOMERS_P12 C00CTSP_SET_1LINEITEMS CUSTOMERS_P12 C00CTSP_SET_1ORDERS CUSTOMERS_P12 C00CTSP_SET_1

18 rows selected.


13. シャード・カタログ・データベースに接続して、チャンクが均等に配分されていることを確認します。$ sqlplus / as sysdba

SQL> set echo offSQL> select a.name Shard, count( b.chunk_number) Number_of_Chunks from gsmadmin_internal.database a, gsmadmin_internal.chunk_loc b where a.database_num=b.database_num group by a.name;

SHARD NUMBER_OF_CHUNKS------------------------------ ----------------sh1 6

134

sh2 6sh3 6sh4 6



次の例は、app_schemaユーザーとしてデータベース・シャード上の表に問い合せています。$ sqlplus app_schema/app_schema_passwordConnected.SQL> select table_name from user_tables;

TABLE_NAME-----------------------------------------------------------------------CUSTOMERSORDERSLINEITEMSPRODUCTS

4 rows selected.

親トピック: コンポジットSDBの作成およびデプロイ

8.10 Oracle Shardingでの透過的データ暗号化の使用Oracle Shardingでは透過的データ暗号化(TDE)がサポートされますが、TDEを有効にした状態でシャード・データベース内のチャンクを正常に移行できるように、すべてのシャードが暗号化された表領域に対する同じ暗号化鍵を共有して使用する必要があります。

シャード・データベースは、複数の独立したデータベースと1つのカタログ・データベースで構成されます。特にシャード間でデータを移動するときにTDEが正しく機能するように、一定の制限が適用されます。データが暗号化されているときにシャード間のチャンク移動が正常に機能するためには、すべてのシャードで同じ暗号化鍵を使用する必要があります。

これを実現するには、次の2つの方法があります。

シャード・カタログから暗号化鍵を作成してエクスポートし、すべてのシャードに個々にキーをインポートしてアクティブ化します。

ウォレットを共有の場所に格納し、シャード・カタログおよびすべてのシャードで同じウォレットを使用します。

シャードDDLを有効にしたシャード・カタログで次のTDE文を実行すると、その操作がシャードに自動的に伝播されます。

alter system set encryption wallet open/close identified by password

alter system set encryption key

administer key management set keystore [open|close] identified by password

administer key management set key identified by password

administer key management use key identified by password

administer key management create key store identified by password

135

制限事項

Oracle ShardingでのTDEの使用には、次の制限事項が適用されます。

MOVE CHUNKが正常に機能するには、すべてのシャード・データベース・ホストが同じプラットフォームに存在する必要があります。

MOVE CHUNKでは、データ転送中にパフォーマンスに影響を及ぼす可能性がある圧縮を使用できません。

表領域レベルでの暗号化のみがサポートされます。特定の列に対する暗号化はサポートされません。

すべてのシャードに対する単一の暗号化鍵の作成シャード・データベース構成内のすべてのデータベースに単一の暗号化鍵を伝播するには、シャード・カタログでマスター暗号化鍵を作成し、ウォレットをエクスポートしてシャードにインポートし、鍵をアクティブ化する必要があります。

関連項目:

TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。


8.10.1 すべてのシャードに対する単一の暗号化鍵の作成

シャード・データベース構成内のすべてのデータベースに単一の暗号化鍵を伝播するには、シャード・カタログでマスター暗号化鍵を作成し、ウォレットをエクスポートしてシャードにインポートし、鍵をアクティブ化する必要があります。

注意:

この手順は、キーストア・パスワードとウォレット・ディレクトリ・パスがシャード・カタログおよびすべてのシャードで同じであることを前提としています。異なるパスワードとディレクトリ・パスが必要な場合は、各シャードとシャード・カタログで、シャードDDLを無効化し、シャードの独自のパスワードとパスを使用して、すべてのコマンドを個別に発行する必要があります。

次の手順は、データの暗号化を実行する前に行う必要があります。

1. シャード・カタログで暗号化鍵を作成します。

シャードDDLを有効にして、次の文を発行します。ADMINISTER KEY MANAGEMENT CREATE KEYSTORE wallet_directory_path IDENTIFIED BY keystore_password;ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;

ウォレットのオープンおよびクローズ・コマンドをカタログから一元的に発行する場合は、keystore_passwordが同じである必要があります。

注意:

ウォレット・ディレクトリ・パスは、対応するsqlnet.oraのENCRYPTION_WALLET_LOCATIONと一致す

136

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=ASOAG-GUID-F2F6CF9A-8F59-49AE-B378-556DCDACC856



る必要があります。

ENCRYPTION_WALLET_LOCATIONパラメータは非推奨です。かわりに、WALLET_ROOT静的初期化パラメータおよびTDE_CONFIGURATION動的初期化パラメータを使用することをお薦めします。

シャードDDLを無効にして、次の文を発行します。ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password WITH BACKUP;

シャード・カタログ・データベースのウォレットに暗号化鍵が作成され、アクティブ化されます。

DDLを有効にしてこの文を発行すると、各シャードのウォレットにもカタログの鍵とは異なる暗号化鍵が作成されます。データ移動を正常に実行するには、各シャード上の異なる暗号化鍵を使用しないでください。

2. シャード・カタログのキーストアからマスター鍵のIDを取得します。SELECT KEY_ID FROM V$ENCRYPTION_KEYS WHERE ACTIVATION_TIME = (SELECT MAX(ACTIVATION_TIME) FROM V$ENCRYPTION_KEYS WHERE ACTIVATING_DBID = (SELECT DBID FROM V$DATABASE));

3. シャードDDLを無効にして、カタログの暗号化鍵を含むウォレットをエクスポートします。ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET secret_phrase TO wallet_export_file IDENTIFIED BY keystore_password;

(オプション)ここで手順の結果を入力します。4. ウォレット・ファイルを各シャード・ホストの対応するウォレット・エクスポート・ファイルの場所に物理的にコピーするか、すべてのシャードがアクセスできる共有ディスクに格納します。

5. シャードDDLを無効にして、各シャードにログオンし、鍵を含むウォレットをインポートします。ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET secret_phrase FROM wallet_export_file IDENTIFIED BY keystore_password WITH BACKUP;

6. シャード・データベースを再起動します。7. すべてのシャード上の鍵をアクティブ化します。

カタログでシャードDDLを有効にして、次のコマンドを実行します。ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;ADMINISTER KEY MANAGEMENT USE KEY master_key_id IDENTIFIED BY keystore_password WITH BACKUP;

これで、すべてのシャードとシャード・カタログ・データベースで同じ暗号化鍵がアクティブ化され、データの暗号化に使用する準備が完了しました。シャード・カタログで、(シャードDDLを有効にして)次のようなTDE DDLを発行できます。

暗号化された表領域および表領域セットを作成します。

暗号化された表領域を使用してシャード表を作成します。

暗号化された列を含むシャード表を作成します(制限があります)。

すべてのシャード上のキーIDがシャード・カタログ上のIDと一致していることを検証します。

137

SELECT KEY_ID FROM V$ENCRYPTION_KEYS WHERE ACTIVATION_TIME = (SELECT MAX(ACTIVATION_TIME) FROM V$ENCRYPTION_KEYS WHERE ACTIVATING_DBID = (SELECT DBID FROM V$DATABASE));

親トピック: Oracle Shardingでの透過的データ暗号化の使用

138


1. Oracle Shardingの使用2. シャード・データベースへのデータの移行

9 シャード・データベースへのデータの移行非シャード・データベースからOracle Shardingシャード・データベースにデータを移行する際には、ここで説明する方法を使用してください。

ここに示すデータのロード方法は、シャード・データベースに移行する時点で、非シャードOracleデータベースを使用していることを想定しています。また、ここで提案する方法は、その他のデータベース・システムからのデータの移行や、新規のデータベース・ユーザーにも適用されます。

シャード・データベースへのデータの移行についてOracle Shardingソフトウェアのインストール後に、シャード・データベースを構成して作成すると、シャード・データベースにデータを移行できるようになります。シャード・データベースへのデータのロードに関する一般的なガイドライン非シャード・データベースからシャード・データベースに移行するときには、非シャード表のデータをシャード表と重複表に移動する必要があります。非シャード表から重複表にデータを移動するときには複雑なことはありませんが、非シャード表からシャード表にデータを移動するときには特別な注意が必要です。スキーマの移行既存のデータベースをシャード・データベースに移行する前に、シャードの数とレプリケーションの計画を含めてシャード・データベースの編成方法を決定し、アプリケーションのどの表をシャード表にして、どの表を重複表にするかを決定する必要があります。シャード表については、シャーディング方法と、表ファミリでのシャード表間の親子関係を決定する必要があります。ソース・データベースの準備シャード・データベース・スキーマへの移行を円滑に進めるために、ターゲットのシャード・データベースの表定義と一致するように、ソースの非シャード・データベースを変更できます。ターゲット・シャード・データベースの準備シャード・データベースへのデータの移行を開始する前に、シャード・データベース・スキーマを設計に従って作成する必要があります。データの移行1つまたは複数のシャードを含むターゲット・シャード・データベースを作成して、シャード表と重複表を定義したら、シャード・データベースへのデータの移行を開始できます。アプリケーションの移行シャード・データベースのオペレーティング環境では、アプリケーションはシャードに直接アクセスできるようになります。この機能により、本当の線形スケーラビリティが得られますが、アプリケーション・コードへのわずかな変更という少しの手間がかかります。

9.1 シャード・データベースへのデータの移行についてOracle Shardingソフトウェアのインストール後に、シャード・データベースを構成して作成すると、シャード・データベースにデータを移行できるようになります。

次に、シャード・データベース環境に移行する際の手順の概要を示します。

139

1. シャード・データベース・スキーマを設計して作成します。2. データを移行します。3. アプリケーションを移行します。

関連項目:

シャーディングに対するアプリケーションの適合性: シャード・データベース・アプリケーションへの移行に関する制約について理解してください。

親トピック: シャード・データベースへのデータの移行

9.2 シャード・データベースへのデータのロードに関する一般的なガイドライン

非シャード・データベースからシャード・データベースに移行するときには、非シャード表のデータをシャード表と重複表に移動する必要があります。非シャード表から重複表にデータを移動するときには複雑なことはありませんが、非シャード表からシャード表にデータを移動するときには特別な注意が必要です。

重複表へのデータのロード

重複表へのデータのロードは、既存のデータベース・ツール(データ・ポンプ、SQL LoaderまたはプレーンSQL)を使用して実行できます。データのロードには、シャード・カタログ(コーディネータ)データベース・ノードを使用する必要があります。つまり、シャード・カタログ・データベースには重複表のすべての内容が格納されることになります。重複表の内容はマテリアライズド・ビューを使用してデータベース・シャードに完全にレプリケートされるため、重複表のロードにかかる時間は同じデータを非シャード表にロードするよりも長くなる場合があります。

図9-1 重複表のロード

「図9-1 重複表のロード」の説明

シャード表へのデータのロード

シャード表をロードする場合は、各データベース・シャードがデータ・セット全体のサブセット(シャード)を個別に収容するため、データを分割(シャッフル)してから各サブセットを特定のシャードにロードする必要があります。

図9-2 シャード・カタログを使用したシャード表のロード

140

「図9-2 シャード・カタログを使用したシャード表のロード」の説明

データベース・シャードのすべてにサブセットのデータをロードするには、Oracle Data Pumpユーティリティを使用する必要があります。次の2つのオプションについて考えてみます。

上の図に示すように、シャーディング・コーディネータ(カタログ)ノード経由でデータをロードします。次の図に示すように、データベース・シャードにデータを直接ロードします。

図9-3 データベース・シャードへのシャード表の直接ロード

「図9-3 データベース・シャードへのシャード表の直接ロード」の説明

シャーディング・コーディネータを使用してシャード・データベースにデータをロードすると、シャーディング・コーディネータ(カタログ)ノードで実行される分割ロジックと、データをシャードにプッシュする追加のオーバーヘッドにより、非シャード表にデータ・セット全体をロードするよりも時間がかかります。

データベース・シャードに直接データをロードすると、各シャードが個別にロードされるためロード

141

時間は大幅に短くなります。つまり、各シャードでデータ・ポンプを実行することで、データ・セット全体のうち最大のサブセットのシャードをロードするために必要な期間内でデータ・ロード操作を完了できます。一般に、このロード時間は、データ・セット全体を非シャード・データベースにロードする場合に必要な時間をシャード・データベース内のシャード数で除算することで概算できます。

Oracle Data Pumpユーティリティに依存してロード・データ・セットを個別のサブセットに分割するかわりに、アプリケーションに分割(シャッフル)ロジックを統合するオープンのソース・シャード分割ライブラリが使用できます。シャード分割ライブラリのソース・コードと使用例は、OracleSharding Tools Library (https://github.com/oracle/db-sharding/)で入手できます。このシャード分割ライブラリを基にして、OracleではOracle Cloudで使用するための汎用ストリーミング・ロード・ライブラリを開発しています。現時点では、このストリーミング・ロード・ライブラリは請求した場合にのみ利用できます。


9.3 スキーマの移行

既存のデータベースをシャード・データベースに移行する前に、シャードの数とレプリケーションの計画を含めてシャード・データベースの編成方法を決定し、アプリケーションのどの表をシャード表にして、どの表を重複表にするかを決定する必要があります。シャード表については、シャーディング方法と、表ファミリでのシャード表間の親子関係を決定する必要があります。

シャード・データベース環境へのスキーマの移行については、サンプル・アプリケーションを使用して説明します。このアプリケーションはデータ・モデルによって定義され、いくつかの制約が適用されます。シャード・データベースへの移行がアプリケーションに与える影響については、サンプル・プログラム・コードを使用して分析します。次の図は、サンプル・アプリケーションのデータ・モデルを示しています

図9-4

「図9-4」の説明

このデータ・モデルは、4つの表Customers、Orders、StockItemsおよびLineItemsで構成され、次の主

142

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=sharding_tools_library

キー制約が適用されます。

Customer.(CustNo)

Orders.(PONo)

StockItems.(StockNo)

LineItems.(LineNo, PONo)

このデータ・モデルでは、次の参照整合性制約が定義されます。

Customers.CustNo -> Orders.CustNo

Orders.PONo -> LineItems.PONo

StockItems.StockNo -> LineItems.StockNo

次のDDL文では、サンプル・アプリケーションのデータベース・スキーマ定義を作成します。CREATE TABLE Customers ( CustNo NUMBER(3) NOT NULL, CusName VARCHAR2(30) NOT NULL, Street VARCHAR2(20) NOT NULL, City VARCHAR2(20) NOT NULL, State CHAR(2) NOT NULL, Zip VARCHAR2(10) NOT NULL, Phone VARCHAR2(12), PRIMARY KEY (CustNo));

CREATE TABLE Orders ( PoNo NUMBER(5), CustNo NUMBER(3) REFERENCES Customers, OrderDate DATE, ShipDate DATE, ToStreet VARCHAR2(20), ToCity VARCHAR2(20), ToState CHAR(2), ToZip VARCHAR2(10), PRIMARY KEY (PoNo));

CREATE TABLE StockItems ( StockNo NUMBER(4) PRIMARY KEY Description VARCHAR2(20), Price NUMBER(6,2));

CREATE TABLE LineItems ( LineNo NUMBER(2), PoNo NUMBER(5) REFERENCES Orders, StockNo NUMBER(4) REFERENCES StockItems, Quantity NUMBER(2), Discount NUMBER(4,2), PRIMARY KEY (LineNo, PoNo));

シャーディング・キー

シャーディングは、複数の独立したOracleデータベース間にデータを水平にパーティション化するデータベースのスケーリング手法です。データベース・リクエストは、シャーディング・キー列の値に基づいて適切なシャード・データベースにルーティングされます。シャーディング設計の目標は、単一のシャード操作が最大化されるようになり、シャード間操作が最小化または排除されるようになるシャーディング・キーを選択することです。

143

サンプル・アプリケーションのデータ・モデルで特定される主キーから外部キーへの機能的な依存関係に基づいて、次の表ファミリが形成されます。

Customers – 親表

Orders – 子表

Lineitems – 孫表

残りのStockItems表は単なる参照表で、在庫品目番号を在庫品目の説明と価格にマッピングします(StockNo -> (Description, Price))。

シャード・データベース定義には、参照パーティション化を使用する表ファミリのメンバーごとの次のDDL文と、StockItems参照表を定義する追加のDDL文が必要です。CREATE SHARDED TABLE Customers ( CustNo NUMBER(3) NOT NULL, CusName VARCHAR2(30) NOT NULL, Street VARCHAR2(20) NOT NULL, City VARCHAR2(20) NOT NULL, State CHAR(2) NOT NULL, Zip VARCHAR2(10) NOT NULL, Phone VARCHAR2(12), CONSTRAINT RootPK PRIMARY KEY (CustNo))PARTITION BY CONSISTENT HASH (CustNo)PARTITIONS AUTOTABLESPACE SET ts1;

CREATE SHARDED TABLE Orders ( PoNo NUMBER(5) NOT NULL, CustNo NUMBER(3) NOT NULL, OrderDate DATE, ShipDate DATE, ToStreet VARCHAR2(20), ToCity VARCHAR2(20), ToState CHAR(2), ToZip VARCHAR2(10), CONSTRAINT OrderPK PRIMARY KEY (CustNo, PoNo) CONSTRAINT CustFK Foreign Key (CustNo) REFERENCES Cusomters (CustNo))PARTITION BY REFERENCE (CustFK);

CREATE DUPLICATED TABLE StockItems ( StockNo NUMBER(4) PRIMARY KEY Description VARCHAR2(20), Price NUMBER(6,2));

CREATE SHARDED TABLE LineItems ( LineNo NUMBER(2) NOT NULL, PoNo NUMBER(5) NOT NULL, StockNo NUMBER(4) REFERENCES StockItems, Quantity NUMBER(2), Discount NUMBER(4,2), CONSTRAINT LinePK PRIMARY KEY (CustNo, LineNo, PoNo) CONSTRAINT LineFK FOREIGN KEY (CustNo, PoNo) REFERENCES Orders (CustNo, PoNo))PARTITION BY REFERENCE (LineFK);

前述のシャード・データベースDDLと元の(非シャード)データベースの表を比較すると、次の構造的な表の変更があることがわかります(太字のイタリック体で示しています)。

表ファミリの表に対するCREATE TABLE文には、追加のSHARDEDキーワードが含まれています。

参照表のCREATE TABLE文には、追加のDUPLICATEDキーワードが含まれています。

144

表ファミリのすべての表には、シャーディング・キー列CustNoが主キーの先頭の列として格納されています。これはシャーディング固有の非正規化であり、先頭のコンポーネントとして直接の親キー(レベル・キーとも呼ばれます)が含まれるように、表ファミリ階層の各レベルで複合主キーを拡張しています。

シャード表は、シャーディング・キー列でパーティション化(PARTITIONED BY)されます。この例の場合は、ファミリのルート表がCONSISTENT HASHでパーティション化されています。このパーティション化スキーマは、BY REFERENCE (参照パーティション化)によって階層の下位レベルに伝播されます。CONSISTENT HASHによるデータのパーティション化は、システム管理のシャーディング方法と呼ばれます(これは、ユーザー定義のシャーディングと対になる用語です)。

システム管理のシャーディングでは、シャード表に表領域セットが定義されます。表領域の最初のセットは、SHARDED表に使用されます。表領域セットは、1つ以上のシャード表と索引の論理的な記憶域単位として、シャード・データベースで使用されるものです。表領域セットは、シャード領域内のシャード間で分散される複数の表領域で構成されます。表領域は、データベースによって表領域セットとして自動的に作成されます。表領域の数は自動的に決定され、対応するシャード領域のチャンクの数と等しくなります。

シャード表のCREATE TABLESPACE SET tbs1;

この例では、Customers、OrdersおよびLineItemsは表領域セットのtbs1に配置されます。つまり、表ファミリの3つの表に対応するパーティションは、同じ表領域セットtbs1に格納されるということです(参照によるパーティション)。ただし、各表に個別の表領域セットを指定できます。

関連項目

パーティション、表領域およびチャンク


9.4 ソース・データベースの準備

シャード・データベース・スキーマへの移行を円滑に進めるために、ターゲットのシャード・データベースの表定義と一致するように、ソースの非シャード・データベースを変更できます。

理想としては、ターゲット・シャード・データベースの表定義(表名、列名およびそのデータ型)と、ソース・データベースの表定義を完全に同じにします。ただし、シャード・データベースへの移行の一環として、シャード・データベースで使用する表定義の変更が必要になることがあります。その場合は、新しいシャード・データベースの表定義と一致するように、ソースの非シャード・データベースを変更できます。変更の範囲によっては、アプリケーション・コードの変更が必要になることもあります。移行プロセスの前に、ターゲットのシャード・データベース・スキーマと一致するようにソースのデータベース・スキーマを変更しておくことで、元の非シャード・データベースから新しいシャード・データベースへの中断のない移行のための条件を整えます。このような準備は、停止時間が発生したとしても、停止時間を最小にするための前提条件になります。また、サンプル・アプリケーションで示すように、移行の準備はシームレスな簡単に元に戻せるプロセスです。ソース・データベースを準備することは非常に望ましい行動ですが、必須ではありません。なんらかの理由でソース・データベースのオペレーティング環境を変更できない場合は、このトピックをスキップしてもかまいません。

ここに示す手順は、前のトピックで定義したものと同じサンプル・スキーマに従います。

サンプル・データベースを移行するために、次の例に示すようにALTER TABLEを使用して、ソース・

145

データベースのLineItems表にシャーディング・キー列CustNoを追加する必要があります。ALTER TABLE LineItems ADD (CustNo NUMBER(3));

この追加の列により、ソース表の行データ・レイアウトとターゲットのシャード表の目的とするレイアウトが同じになります。これで、この新しい列に一致するデータを設定する準備ができました。LineItems表の追加のシャーディング・キー列CustNoの値は、親子関係のOrdersとLineItemsの結合から導出する必要があります。SELECT Orders.CustNo FROM Orders JOIN LineItems ON Orders.PONo = LineItems.PONo;

この例では、MERGE文を使用してCustNo列に移入しています。標準SQLを使用して、同じ目標を達成することもできます。ここに示した例では、MERGE文は次のようになります。SQL> BEGIN 2 MERGE INTO LineItems l 3 USING Orders o 4 ON (l.PONo = o.PONo) 5 WHEN MATCHED THEN 6 UPDATE SET l.CustNo = o.CustNo; 7 END; 8 /

この時点で、CustNo列に対する参照整合性が維持されることがわかります。新しい列が正しく移入されるようにするには、MERGE文の実行後に、次に示すようにNOT NULL制約を追加する必要があります。ALTER TABLE LineItems MODIFY CustNo NOT NULL;

前述のMERGE文を実行すると、LineItems表の行レイアウトと行データが目的の状態になります。追加のCustNo列により、LineItems表が表ファミリのルート(Customers)と同じ方法でシャーディングされます。この変更は、実際の移行前の最後のアクションの1つとして使用することを検討してください。そうしない場合は、アプリケーション内で、この新しい列を維持管理する必要があります。その結果として、追加されたシャーディング・キー列の参照整合性を既存のデータベースで維持管理することも必要になります。一致するCustNo列の参照整合性制約は、次に示すようにLineItems表で定義します。ALTER TABLE LineItems ADD CONSTRAINT LineFk FOREIGN KEY (CustNo, PONo) REFERENCES Orders (CustNo, PONo);

LineItems表の参照整合性を変更する前に、Orders表を参照する既存のFOREIGN KEY制約を削除する必要があります。この操作を安全に完了するには、DROP CONSTRAINT文と後続のADD CONSTRAINT文をALTERTABLE LineItems READ ONLY;とALTER TABLE LineItems READ WRITE;で囲むか、制約の変更中は単に表をLOCK TABLE LineItems IN SHARE MODEでロックします。

CustNo列はLineItems表の外部キー定義の一部として追加するため、Orders表の主キーの変更が必要になります。主キーを変更すると、索引の再構築が必要になるため、この作業の完了までには時間がかかる場合があります。この作業は、シャード・データベースに移行する前の一定期間、この新しいスキーマに対してアプリケーションを実行する予定がある場合にのみ意味があります。

次の例は、LineItems表にシャーディング・キーを追加した結果としてのLineItemsおよびOrdersスキーマの変更操作を示しています。LineItems表の既存の外部キー制約を削除して、Orders表の主キー制約を削除する前に、次に示すように、それぞれの制約名を取得しておく必要があります。SQL> SELECT a.table_name, a.column_name, a.constraint_name 2 FROM ALL_CONS_COLUMNS A, ALL_CONSTRAINTS C 3 WHERE A.CONSTRAINT_NAME = C.CONSTRAINT_NAME 4 and a.table_name='LINEITEMS' and C.CONSTRAINT_TYPE = 'R';

LINEITEMS

146

PONOSYS_C009087

LINEITEMSSTOCKNOSYS_C009088

SQL> SELECT cols.table_name, cols.column_name, cols.constraint_name, cols.position 2 FROM all_constraints cons, all_cons_columns cols 3 WHERE cons.constraint_type = 'P' 4 AND cons.constraint_name = cols.constraint_name 5 AND cols.table_name = 'ORDERS' 6 ORDER BY cols.table_name, cols.position;

ORDERSORDER_IDORDER_PK 1ORDERSPONOSYS_C009148 1

SQL> ALTER TABLE LineItems READ ONLY;

Table altered.

SQL> ALTER TABLE Orders READ ONLY;

Table altered.

SQL> ALTER TABLE LineItems DROP CONSTRAINT SYS_C009087;

Table altered.

SQL> ALTER TABLE ORDERS DROP CONSTRAINT SYS_C009148;

Table altered.

SQL> ALTER TABLE ORDERS ADD CONSTRAINT order_pk PRIMARY KEY (CustNo, PONo);

Table altered.

SQL> ALTER TABLE LineItems ADD CONSTRAINT LineFk FOREIGN KEY (CustNo, PONo) REFERENCES Orders (CustNo, PONo);

Table altered.

SQL> ALTER TABLE Orders READ WRITE;

Table altered.

SQL> ALTER TABLE LineItems READ WRITE;

Table altered.

同様に、次に示すように、先頭の列としてCustNoを含めることで完全なレベル・キーになるようにLineItems表のPRIMARY KEY定義を拡張する必要があります。ALTER TABLE LineItems ADD CONSTRAINT LinePK PRIMARY KEY (CustNo, PONo, LineNo);

繰り返しになりますが、新しい制約を導入する前に、既存のPRIMARY KEY制約を削除する必要があります。データ整合性を維持するために、前述の2つのトランザクション分離戦略のいずれかを使用して、PRIMARY KEY制約とFOREIGN KEY制約を変更します。次の例では、LineItems表が制約の変更の実行中にロックされます。その後、COMMITによってロックが解放されます。SQL> SELECT cols.table_name, cols.column_name, cols.constraint_name, cols.position 2 FROM all_constraints cons, all_cons_columns cols 3 WHERE cons.constraint_type = 'P' 4 AND cons.constraint_name = cols.constraint_name 5 AND cols.table_name = 'LINEITEMS' 6 ORDER BY cols.table_name, cols.position;

LINEITEMS

147

LINENOSYS_C009086

1LINEITEMSPONOSYS_C009086

2

SQL> LOCK TABLE LineItems IN SHARE MODE;

Table(s) Locked.

SQL> ALTER TABLE LINEITEMS DROP CONSTRAINT SYS_C009086;

Table altered.

SQL> ALTER TABLE LineItems ADD CONSTRAINT LinePK PRIMARY KEY (CustNo, PONo, LineNo);

Table altered.

SQL> COMMIT;

Commit complete.

参照整合性に関連する変更はオプションです。この変更案によって、ソース・データベースはターゲットのシャード・データベースとほとんど同じ状態になります。これにより、移行プロセスが容易になります。

参照整合性は、適用できないことや、作成することが望ましくないこともあります。その場合は、参照パーティション化を定義できません。そうした状況では、かわりにPARENT句を使用できます。

最後に、LineItems表の追加のCustNo列は、SELECT * FROM LineItemsなどの既存の問合せに影響する場合があります。この問題を回避するために、次に示すように、CustNo列を不可視に変更できます。SQL> ALTER TABLE LineItems MODIFY CustNo INVISIBLE;

ソース・データベース表に対してこれらの変更を実施することで、既存のサンプル・データベースの移行のための準備が整います。


9.5 ターゲット・シャード・データベースの準備

シャード・データベースへのデータの移行を開始する前に、設計に応じてシャード・データベース・スキーマを作成する必要があります。

非シャード・データベース環境からシャード・データベース環境へのデータの移行は、次の2つの方法で実行できます。

2段階アプローチ: データ移行のためのより慎重な増分アプローチです。1つのシャードのみでシャード・データベースを作成します。シャード・データベースが1つのシャードに格納されているかぎり、アプリケーション・コードの変更なしに関連するごくわずかな変更で、アプリケーションやデータベース・メンテナンスの手順を使用できます。つまり、シャード・データベースは、シャード環境に移行する時点の非シャード・データベースと同じように動作するということです。その後で、シャーディングに対応するようにアプリケーションと操作手順を変更して、データベースを適切な数のシャードにスケール・アウトする作業を進めます。1段階アプローチ: 最初に適切な数のシャードでシャード・データベースを作成します。この場合、アプリケーションと操作手順は、移行する時点でシャーディング操作に対応するように完全に準備する必要があります。

148

より慎重な段階アプローチを使用すると、シャード・データベース環境への移行がスムーズになりますが、かなり長い時間がかかるようにもなります。単一のシャードに対してアプリケーションを実行すると、ダイレクト・ルーティングに向けてアプリケーションを徐々に変更するための時間が得られます。シャード・ディレクタを使用して適切なシャードに接続するように既存のアプリケーションを変更した後にのみ、残りのシャードをインスタンス化できます。

プロセスの最初のステップは、シャードが1つのみのシャード・データベースを作成することです。その後で、次の各項のいずれかで提案されているように既存のアプリケーションを変更します。最後の手順で、シャード・データベースを必要なシャード数までスケールアウトします。この方法では、スケール・アウトの前に、すべてのシャードでデータ・チャンクを分割およびリバランスする機会も得られます。

この2段階の移行方法には、長い時間がかかるだけでなく、多くの領域も必要になります。すべてのデータを1つのシャードに移行する場合は、制限なしでシャード表のデータを単一のシャードに直接ロードできます。複数のシャードにスケール・アウトした後で、シャード表を適切に複数のデータベース・シャードに直接ロードする場合は、データ・ポンプ・ユーティリティを必ず使用する必要があります。重複表はカタログ・データベースに存在しているため、重複表のロードには常にカタログ・データベースを使用することになります。

1段階のアプローチと2段階のアプローチのどちらを使用するにしても、シャード・データベースにデータをロードする前に、データのエクスポートとシャード・データベース・スキーマの作成が必要になります。次の例は、ソフトウェアのインストールが完了していて、シャード用に少なくとも1つのシャーディング・カタログと1つ以上のデータベースを含むシャード・データベース環境を作成していることを想定しています。新しいシャード・カタログを作成することも、既存のシャード・カタログを使用することもできます。移行プロセスを説明するために、この手順の例では次のデータベース・インスタンスを使用します。

orignode: 元の非シャード・データベース・インスタンス(SID=orig)をホストするサイト

catnode: シャード・カタログ・データベース・インスタンス(SID=ctlg)をホストするカタログ・ノード

shrdnodeN: データベース・シャード・インスタンス(SID=shrdN、Nは1、2など)をホストするシャード・ノード

gsmnode: シャード・ディレクタ(GSM)インスタンス(SID=gsm1)をホストするカタログ・ノード

移行の準備でソース・データベースを変更したかどうかに関係なく、移行プロセスでは、少なくともCREATE SHARDED TABLE文とCREATE DUPLICATED TABLE文が含まれているDDL定義に変更を加える必要があります。データベース・スキーマをターゲットのシャード・データベースに移行するには、ソース・データベースからDDL定義を抽出して、SHARDED表およびDUPLICATED表のメタデータを変更する必要があります。ソース・データベースからDDL文を抽出する際の便利な方法は、データ・ポンプ抽出ファイルを作成することです。その後で、次に示すように、データベース・エクスポート・ファイルに対してデータ・ポンプ・インポート・ユーティリティを使用します。impdp uname/pwd@orignode directory=expdir dumpfile=sample.dmp sqlfile=sample_ddl.sql

この例では、impdpコマンドは、実際にはダンプ・ファイルの内容をインポートしません。そのかわりに、sqlfileパラメータによって、sample_ddl.sqlという名前のスクリプトの作成がトリガーされます。このスクリプトには、エクスポート・ダンプ・ファイル内のすべてのDDLが格納されています。このデータベース・エクスポート・ファイルは、次に示すようにして作成します。expdp uname/pwd@orignode full=Y directory=expdir dumpfile=sample.dmp logfile=sample.log

2

149

全データベース・エクスポート・ファイルには、データベースのすべての内容(データとメタデータ)が含まれています。データベース全体のエクスポートには時間がかかることがあります。この手順を短時間で実行するために、この例に示すように、メタデータのみをエクスポートすることも、必要な表のセットが含まれる部分のみをエクスポートすることもできます。expdp uname/pwd directory=DATA_PUMP_DIR dumpfile=sample_mdt.dmp logfile=sample_mdt.log INCLUDE=TABLE:\"IN $ \'CUSTOMERS\', \'ORDERS\', \'STOCKITEMS\', \'LINEITEMS\' $ \" CONSISTENT=Y CONTENT=METADATA_ONLY

このようにエクスポートをトリミングして、時間がかかることがあるデータ・ポンプ・プロセスなしに、データベース・メタデータの一貫したイメージを効率的に取得します。それでも、テキスト形式でDDL文を取得して、シャード・データベース・スキーマ設計で要求されるようにDDLを変更する必要があります。データベース全体をエクスポートする場合は、データをロードするための入力としても使用することになります。

データ・ポンプは、データを転送するための安全な方法を提供します。データベース管理者は、次に示すように、データベース・ユーザーにデータベース・エクスポート・ディレクトリへのアクセスに必要な権限を付与する必要があります。CREATE OR REPLACE DIRECTORY expdir AS ‘/some/directory’; GRANT READ, WRITE ON DIRECTORY expdir TO uname;GRANT EXP_FULL_DATABASE TO uname;

全データベース・エクスポートでは、データベース管理者がユーザーunameにEXP_FULL_DATABASEロールを付与する必要があります。表レベルのエクスポートには、追加のロールは必要ありません。データ・ポンプ・ユーティリティの詳細は、後述の関連項目に示したデータベース・ユーティリティのドキュメントを参照してください。

ターゲット(シャード)データベースの行レイアウトと一致するようにソース(非シャード)データベースを変更した場合は、全データベースまたは表レベルのエクスポートは必要ありません。データは、中間ダンプ・ファイルなしでそのまま効率的に転送できます。

シャード・データベース・スキーマを完成させたら、データベース管理者の資格証明を使用して、シャーディング・カタログ・データベース(ctlg)に対して準備したDDLを実行します。すべてのDDL文をSHARD DDL設定が有効になっているセッションで実行して、すべてのDDL文がカタログ・データベース(ctlg)からシャード・データベース(shrd1、2、...、N)に伝播されるようにする必要があります。ALTER SESSTION ENABLE SHARD DDL;

シャード表と重複表が定義されていると、シャード・データベースはデータ・ロードの準備が整っていることになります。データのロード前に、GDSCTL VALIDATEコマンドを使用してシャーディング構成を検証することをお薦めします。gdsctl validate

検証に成功すると、シャード・データベースはデータ・ロードの準備が整っていることになります。不整合やエラーが見つかった場合は、GDSCTLコマンドのSHOW DDLおよびRECOVERを使用して問題を修正する必要があります。

データ・ポンプ・エクスポート・ユーティリティのファイルは、デフォルトで表ごとの一貫性が確保されます。エクスポート内のすべての表に同じ時点での一貫性を持たせる場合は、FLASHBACK_SCNパラメータまたはFLASHBACK_TIMEパラメータを使用する必要があります。「特定」の時点での一貫性があるデータベース・エクスポート・ファイルを用意することをお薦めします。これは、非シャード・データベースからシャード・データベースへの中断のない移行を選択した場合、つまり、移行中にも継続的なデータベース操作を提供する場合は特に重要です。データ・ポンプを使用した継続的な操作時のシャード・データベースへの移行は、Oracle GoldenGateによって補完されます。一貫性のある

150

データベース・スナップショットを生成するエクスポート・コマンドは、次のようになります。expdp uname/pwd@orignode full=Y directory=expdir dumpfile=sample.dmp logfile=sample.log CONSISTENT=Y FLASHBACK_TIME=SYSTIMESTAMP

一貫性のあるスナップショット・データベース・イメージには、追加のパラメータCONSISTENTまたはFLASHBACK_TIMEが必要です。このコマンドを実行すると、CONSISTENTとFLASHBACK_TIMEのどちらのパラメータも意味が同じになることがわかります。次に示すように、タイムスタンプがシステム変更番号(SCN)に変換される点に注意してください。SQL> SELECT TIMESTAMP_TO_SCN(SYSTIMESTAMP) FROM dual; TIMESTAMP_TO_SCN(SYSTIMESTAMP)------------------------------ 1559981

FLASHBACK_TIMEではなくFLASHBACK_SCNを使用すると、現在のSCNは、次に示すようにV$DATABASEから選択することで取得できます。SQL> SELECT current_scn FROM v$database;CURRENT_SCN----------- 1560005

または、次に示すように宣言することもできます。SQL> SET SERVEROUTPUT ONSQL> DECLARE SCN NUMBER; 2 BEGIN 3 SCN := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER; 4 DBMS_OUTPUT.PUT_LINE(SCN); 5 END; 6 /1560598

データベース管理者に、DBMS_FLASHBACKへのアクセス許可を求めることが必要になる場合があります。

データ・ポンプの実行は、PARALLELパラメータを使用すると高速化できます。次の例に示すように、このパラメータはDUMPFILEパラメータの%Uワイルドカードとともに使用して、複数のダンプ・ファイルを作成できるようにします。expdp uname/pwd@orignode full=Y directory=expdir dumpfile=samp_%U.dmp logfile=samp.log CONSISTENT=Y PARALLEL=3

前述のコマンドでは、4つのパラレル・ワーカーを使用して、接尾辞として_01、_02、_03が付いた4つのダンプ・ファイルを作成します。インポート時に同じワイルドカードを使用すると、複数の入力ファイルを参照できるようになります。前述の例では1つの出力ファイルsample.dmpが作成されましたが、並列エクスポートによって3つのダンプ・ファイルsamp_01.dmp、samp_02.dmpおよびsamp_03.dmpが作成される点に注目してください。また、並列エクスポートの経過時間は、シリアル実行(1つのダンプ・ファイル出力)の経過時間の1/3未満になります。

関連項目:

シャード・データベースのデプロイ

『Oracle Databaseユーティリティ』



151

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SUTIL-GUID-501A9908-BCC5-434C-8853-9A6096766B5A





9.6 データの移行1つまたは複数のシャードを含むターゲット・シャード・データベースを作成して、シャード表と重複表を定義したら、シャード・データベースへのデータの移行を開始できます。

ソースからシャード・データベースにデータを移行する前に、次に示すデータ・ロードの考慮事項を理解しておいてください。

複製表とシャード表の移行の相違点

重複表はシャード・カタログに存在していて、その表は使用可能なデータ・ロード・ユーティリティまたはプレーンSQLを使用して常にシャード・カタログ・データベースにロードされます。ただし、シャード表をロードするためのオプションは2つあります。シャード表は、シャーディング・コーディネータ(カタログ)を使用してロードすることも、データ・ポンプ・ユーティリティを使用してシャードに直接ロードすることもできます。

コーディネータを使用したシャード表の移行またはシャードへのダイレクト・ロード

シャード・データベースにシャード表を直接ロードすると、同時に複数のシャードをロードできるため常に高速になります。

複数のシャードへの移行または1つのシャードへの移行

非シャード・データベースをシャードが1つのシャード・データベースに移行する場合は、アプリケーションとデータベースのメンテナンス手順に大幅な変更は必要ありません。データをシャードに分割する準備が整うまで、大幅な変更なしに現在の操作を継続できます。ただし、非シャード・データベースをシャードが複数あるシャード・データベースに移行する場合は、かなりの準備プロセスが必要になります。最も時間がかかる前提条件は、アプリケーション・ソース・コードの変更です。シャードが1つのシャード・データベースに移行する場合は、データベースを複数のシャードにスケーリングするための計画を立てる必要もあります。つまり、ある程度の時間をおいてから、複数のシャード全体にデータベース・チャンクを分散するということです。その間に、複数のシャードがあるシャード・データベースで実行するために必要なアプリケーションの変更などの作業を進めることができます。

停止時間のある移行または中断のない移行

非シャード・データベースからシャードが1つのみのシャード・データベースへの中断のない移行は、シャードが複数あるシャード・データベースへの移行よりも簡単です。その後の1つのシャードから複数のシャードへのスケール・アウトは、データベースの実行中に実施されます。

非シャード・データベースからターゲットのマルチシャード・データベースに1段階で移行する場合は、その移行を最初にテスト環境で試してみて、テスト環境の移行に問題がないことを確認してからのみ、本番環境への移行を開始するようにしてください。

ターゲットの行データ・レイアウトがソース・データベースで準備されているかどうかに関係なく、効率的なデータ移行のための様々な方法があります。様々な条件(使用可能なディスク領域、リモート・ファイル・アクセス、ネットワーク・スループットなど)に最適な方法を選択してください。

移行時の停止時間の検討

データベースの停止時間をなくすには、移行計画にOracle GoldenGateを含める必要があります。ターゲット(シャード)データベースとソース(非シャード)データベースの同期を維持するには、Oracle

152

GoldenGateを使用して、移行プロセス中にソース・データベースに加えられた変更を処理する必要があります。

停止時間ゼロの移行という利点に加えて、Oracle GoldenGateはシャード・データベースのアクティブ-アクティブ・レプリケーションの際にも使用できます。シャード・データベースに対してOracleGoldenGateアクティブ-アクティブ・レプリケーションを定義していると、すべてのデータ移行のアクティビティがシャード・カタログ・データベースに制限されるようになります。

シャード表への停止時間のあるデータ移行

Oracle GoldenGateを使用しない場合は、移行時に可能なかぎりデータベースが使用できる状態を保つための対策を取る必要があり、停止時間についての計画を立てる必要があります。

移行前にソースの非シャード・データベースの表を変更して、表スキーマがターゲットのシャード・データベース・スキーマと一致するようにしておくと、この移行前の手順を実行しなかった場合よりもデータ移行のプロセスが円滑に進みます。このアプローチにより、ソース・データベースの行データ・レイアウトが、ターゲット・シャード・データベースの対応するレイアウトと同じになるため、データベースの内容を直接コピーできます。

1. データベース表からデータをエクスポートします。expdp uname/pwd@non_sharded_db directory=file_dir dumpfile=original_tables.dmp logfile=original_table.log INCLUDE=TABLE:\"IN $ \'CUSTOMERS\', \'ORDERS\', \'STOCKITEMS\', \'LINEITEMS\' $ \" CONSISTENT=Y CONTENT=DATA_ONLY

このデータ・ポンプ・エクスポートの例は、Oracle Shardingサンプル・アプリケーションで使用される表に制限されています。SHARDED表とDUPLICATED表は、すでにサンプルで作成されているため、表のコンテンツのみをエクスポートします(DATA_ONLY)。

2. ターゲットのデータベース・ノードでエクスポート・ファイル(original_tables.dmp)にアクセスできるようにしてから、シャード・データベースへのデータのインポートを開始します。

このファイル(並列エクスポートの場合は複数のファイル)は、ターゲット・データベース・システムに移動することも、ネットワーク経由で共有することもできます。

3. エクスポートが完了すると、シャード・データベースへの内容のインポートが開始できます。

DUPLICATED表(StockItems)は、シャード・カタログを使用してロードする必要があります。次に、インポート・コマンドの例を示します。impdp uname/pwd@catnode:1521/ctlg directory=data_pump_dir dumpfile=original_tables.dmp logfile=imp.log tables=StockItems content=DATA_ONLY

4. シャードを直接ロードするか、シャード・カタログを使用してシャードをロードします。

SHARDED表(Customers、OrdersおよびLineItems)をロードするための最適な方法は、各シャード(shrd1、2、...、N)でデータ・ポンプを直接実行することです。次に、最初のシャードでのインポート・コマンドの例を示します。impdp uname/pwd@shrdnode:1521/shrd1 directory=data_pump_dir dumpfile=original_tables.dmp logfile=imp.log tables=Customers, Orders, LineItems content=DATA_ONLY

または、シャード・カタログでデータ・ポンプを実行して、すべての表をロードすることもできます。次の例は、そのインポート・コマンドを示しています。

153

impdp uname/pwd@catnode:1521/ctlg directory=data_pump_dir dumpfile=original_tables.dmp logfile=imp.log tables=Customers, Orders, LineItems, StockItems content=DATA_ONLY

シャード表への停止時間のないデータ移行

Oracle Shardingを使用すると、Oracle GoldenGateレプリケーションとデータ・ポンプ・エクスポートおよびインポート・ユーティリティが密接に統合されます。Oracle GoldenGateがソース・データベースとターゲット・シャード・データベースのどちらにも存在しない場合は、それをインストールする前に、ソース・データベースとターゲット・データベースの両方で最新リリースのOracle Databaseにデータベースをアップグレードしておく必要があります。データベースをアップグレードすると、最大限の機能が使用できるようになり、設定が簡単になります。Oracle Database 12cリリース2以降の場合は、非シャード・ソースで統合キャプチャが使用可能になり、ターゲット・シャード・データベースで統合レプリケートが使用可能になります。

データベース全体の再作成にデータ・ポンプ・エクスポートとインポートを使用すれば、エクスポートおよびインポートの実行中と実行後のデータベースの変更が、Oracle GoldenGateによって確実に移行されます。移行プロセス中にOracle GoldenGateでレプリケートする必要のあるものは、ユーザーが決定します。アプリケーションで必要としないデータベースの変更は、レプリケートしないようにしてください。

ソース・データベースとターゲット・データベースに対してOracle GoldenGateが構成されている場合は、本番移行をスケジュールする前に、ライブ・データを使用してテストすることをお薦めします。ソース・データベースがクローニングされている場合は、そのクローンを使用することで本番環境に影響を与えずに移行のテストを実行できます。

図9-5 停止時間のない移行

154

「図9-5 停止時間のない移行」の説明

上の図は、データ・ポンプとOracle GoldenGateを組み合せて使用する移行プロセスです。データ移行の大部分はデータ・ポンプを使用して実行され、シャード・カタログとシャードにデータを直接移動しています。データ・ポンプ実行中のデータベースの変更は、Oracle GoldeGateのローカル証跡ファイルに収集され、シャード・カタログ・データベースに移動されます。シャード表に対する変更は、シャード・カタログ・データベースからシャードに伝播されます。

データ・ポンプの観点からは、impdpの非シャード・プロセスとimpdpのシャード・プロセスを使用して、ソース・データベース(ORIG)がシャード・カタログ(CTLG)とシャード・データベース(SHRD1、SHRD2およびSHRD3)に分割されます。impdpの非シャード・プロセスでは、重複表をシャード・カタログ・データベースに移行します。3つのimpdpシャード・パラレル・プロセスによって、シャード表がシャードSHRD1、SHRD2およびSHRD3に直接移行されます。

Oracle GoldenGateの観点からは、すべてのデータベースがExtractルート・プロセスから分岐した抽出(exsh)、ポンプ(pmsh)およびレプリケート(rpsh)プロセスのパイプラインを共有しています。

上の図に対応するobeyファイルを準備してあるとすると、ソース・データベース・ノード(orignode)からシャード・カタログ・ノード(catnode)へのOracle GoldenGateパイプラインのGGSCIターミナル・セッションは、次の例のようになります。view params ./dirprm/add_exsh_2pumps.oby-- add a change data extract process group named exsh -- exsh reads DUPLICATED and SHARDED tables from orig database redo logsadd extract exsh, tranlog, begin now-- associate the trail file as output from exsh process groupadd exttrail ./dirdat/et, extract exsh-- add SHARDED and DUPLICATE change data extract pump process pmsh-- pmsh copies local trail data to ctlgnode remote trail locationadd extract pmsh, exttrailsource ./dirdat/et-- associate the remote trail with pmshadd rmttrail ./dirdat/et, extract pmsh-- connect to the database and add table level supplemental logging for:-- Customers, Orders, LineItems, and StockItems tablesadd trandata uname.Customersadd trandata uname.Ordersadd trandata uname.LineItemsadd trandata uname.StockItems

パイプラインに対してGGSCI obeyコマンドを実行してから、info allを実行します。obey ./dirprm/add_exsh_2pumps.obyinfo all

非シャード・パイプラインおよびシャード・パイプラインの抽出プロセスが初期化されて、停止状態で待機していることがわかります。…EXTRACT STOPPED exsh …EXTRACT STOPPED pmsh ……

シャード表およびカタログ表のプロセス・グループ・パラメータEXTRACTを確認します。view params exsh-- first line must be extract followed the nameextract exsh-- login info to get metadatauserid uname@orignode, password pwd-- export is writing to trail infoexttrail ./dirdat/exsh-- checkpoint time interval with sourcecheckpointsecs 1

155

-- source tabletable uname.Customerstable uname.Orderstable uname.LineItemstable uname.StockItems

すべての表のPumpプロセス・グループ(pmsh)のパラメータを表示します。view parms pmsh-- first line must be extract followed the nameextract pmsh-- no need to log into the database passthru-- connect to remote host, write and talk to the manager therermthost shrdnode, mgrport 7810-- where is the trail on remote hostrmttrail ./dirdat/rt-- checkpoint time interval with targetcheckpointsecs 1-- tablestable uname.Customerstable uname.Orderstable uname.LineItemstable uname.StockItems

Oracle GoldenGateのPumpプロセスは、シャード・カタログ・ノード(catnode)のマネージャ・プロセスがポート番号7810を使用しているという想定で作成されています。シャード・カタログおよびシャード・データベースは別のマシンで実行されるため、これは適切な想定です。

シャード・カタログ・ノード(catnode)の定義を確認します。view params mgrPORT 7810-- used by the PUMP process on the source side for the collector on the targetDYNAMICPORTLIST 8000-8010SYSLOG NONE

シャード・カタログ・ノード(catnode)で、準備したReplicatプロセスのobeyコマンド・ファイルを確認します。view params ./dirprm/add_rpsh.oby-- connect to the databasedblogin userid uname@catnode, password pwd-- add checkpoint tableadd checkpointtable uname.gg_checkpoint-- add replicat process rpsh that will convert remote trail into SQL continuouslyadd replicat rpsh, exttrail ./dirdat/rt, checkpointtable uname.gg_checkpoint

移行の準備で、シャード行データ・レイアウトと一致するようにソース・データベースを変更した場合、不可視の列を導入している可能性があります。不可視の列は、ReplicatプロセスのパラメータとしてMAPINVISIBLECOLUMNSを追加することで、レプリケーション・プロセス中に保持できます。

シャード・カタログ・ノード(catnode)で、obeyファイル./dirprm/add_rpsh.obyを実行します。

この時点で、システムは停止時間なしのデータ移行用に構成されます。ロードの大部分は、データ・ポンプ・エクスポート(expdp)およびインポート(impdp)データベース・ユーティリティによって実行されます。エクスポートおよびインポート・プロセス中の最終的なデータベース変更は、OracleGoldenGateプロセスによって同期されます。Oracle GoldenGateのPumpプロセスは、データ・ポンプ・プロセスのいずれとも関係ない点に注意してください。

データ・ポンプ・エクスポートを開始する前に、Oracle GoldenGateのレプリケーション・プロセスがデータ・ポンプ・エクスポートに含まれる各表のインスタンス化コミット順序番号(CSN)で指定されている必要があります。そうするには、前述したように、expdpの実行時にCONSISTENT=YとFLASBACK_SCN=scn_numを指定します。FLASHBACK_SCNは、次の文で取得できます。

156

SELECT current_scn from v$database;

expdpの実行にCONSISTENT=Yを指定したため、すべての表イメージが「scn_numの時点」を表すようになり、レプリケーション・プロセスは同じCSN番号(この例の場合)から開始できるようになります。

シャード・カタログ・ノードでのレプリケートに適切なGGSCIコマンドは、次のようになります。START REPLICAT rpsh, AFTERCSN scn_num

これは、ソース・ノードでADD SCHEMATRANDATA GGSCIコマンドを使用すると、さらに簡単になります。このコマンドは、インポート時にインスタンス化CSNを使用できるようにして、システム表およびビューを移入します。これにより、データベースのコミット済バージョンを表す2つのスタンプを照合することで、Oracle GoldenGate CSNがデータ・ポンプSCNと同期されるようになります。つまり、エクスポート・プロセス用のFLASHBACK_SCNとレプリケート・プロセス用のAFTERCSNは、次に示すように自動的に定義されるということです。ADD SCHEMATRANDATA uname PREPARESCN ALLCOLS

ADD SCHEMATRANDATAコマンドにより、ORIGデータベースの特定の'uname'スキーマに含まれるすべての表に対する現在および将来のスキーマ・レベルのサプリメンタル・ロギングを有効にして、OracleGoldenGateが行の識別に使用するキーのスーパーセットを自動的にログ記録します。PREPARESCNパラメータは、データ・ポンプ・エクスポート(expdp)に対して、インポート(impdp)時にターゲットの各表にインスタンス化CSNを設定するアクション(GGSCI コマンドのSET_INSTANTIATION_CSN)を自動的に生成するように指示します。ALLCOLSパラメータでは、指定のスキーマに含まれる現在および将来のすべての表について、すべてのサポートされているキー列と非キー列の無条件サプリメンタル・ロギングを有効にします。このオプションでは、依存性の計算に必要なキーのロギングと、フィルタリングや競合解決などの目的に必要な列のロギングを有効にします。シャーディング関連のデータ移行は特定の表セットに制限され、それ以外のデータベースの(増分)変更はシャード・カタログに伝播されない点に十分注意してください。

ターゲット・データベースのレプリケーションは、データ・ポンプ・エクスポートの開始前に停止しておく必要があります。ターゲット・データベースは新規作成されるため、これは常に当てはまります。シャード・カタログ・ノードのレプリケート・プロセスを停止するGGSCIコマンドは、次のとおりです。STOP REPLICAT rpsh

このコマンドでは、次回のレプリケート・プロセスの開始のために同期の状態を保持して、OracleGoldenGateマネージャがレプリケート・プロセスを自動的に開始しないようにします。

ソース・データベースの抽出プロセスは、データ・ポンプ・エクスポートの開始前にアクティブにしておく必要があります。抽出がアクティブになっているかどうかを確認するには、INFO EXTRACTコマンドまたはSTATUS EXTRACTコマンドを使用します。次のコマンドでは、抽出プロセスを開始します(まだ開始されていない場合)。START EXTRACT exsh, BEGIN NOW

この時点から、抽出プロセスは、シャーディング・プロセスに関係するすべての表について、ソース・データベースに対する変更を収集するため、データ・ポンプ・エクスポートを安全に開始できます。expdp uname/pwd@orignode full=Y directory=expdir dumpfile=sample.dmp logfile=sample.log

エクスポート・ユーティリティexpdpのFLASHBACK_SCNパラメータが自動的に追加されていることを確

157

認するようにしてください。expdpコマンドの出力に、「FLASHBACKでは、データベース整合性が自動的に維持されます。」というメッセージがあります。エクスポートの完了後は、シャード・カタログについて前述したように、すぐにターゲット・データベースでデータ・ポンプ・インポートを続行します。impdp uname/pwd@catnode:1521/ctlg directory=data_pump_dir dumpfile=sample.dmp logfile=imp.log tables=Customers,Orders,LineItems,StockItems content=DATA_ONLY

この時点では、シャード・カタログ・ノードで安全にレプリケート・プロセスを開始できます。START REPLICAT rpsh

この時点から、ソース・データベースの選択した表セット(Customers、Orders、LineItemsおよびStockItems)は、シャードのCustomers表、Orders表およびLineItems表、シャード・カタログ・データベースの重複表StockItemsと同期するようになります。レプリケート・プロセスの開始後に、そのレプリケート・プロセスに関するレポート・ファイルを確認するようにしてください。エクスポートの進行中に、レプリケート・プロセスがデータベースに存在するSCNまたはCSN番号を認識していて、そのSCN以降の変更をターゲット表に適用する必要があることがわかっていることを確認します(その確認のために、「Instantiation CSN filtering is enabled on table uname.Customers, uname,Orders, …」を見つけてください)。


9.7 アプリケーションの移行

シャード・データベースのオペレーティング環境では、アプリケーションはシャードに直接アクセスできるようになります。この機能により、本当の線形スケーラビリティが得られますが、アプリケーション・コードへのわずかな変更という少しの手間がかかります。

次の各例では、アプリケーションの移行方法を示します。この例は、移行したデータベース・スキーマとデータに対応するサンプル・アプリケーションのスケルトンです。サンプル・アプリケーションの主要部分には、オーダー管理およびレポート機能を組み込みます(JavaクラスPOManagerに含めます)。このクラスの最初の静的メソッドでは、addCustomer()メソッドを使用してCustomers表に新しい行を導入します。次に示すように、この関数には、パラメータ・リストを使用して列値が渡されます。import java.sql.*;import java.io.*;import oracle.jdbc.driver.*;

public class POManager { public static void addCustomer (int custNo, String custName, String street, String city, String state, String zipCode, String phoneNo) throws SQLException { String sql = "INSERT INTO Customers VALUES (?,?,?,?,?,?,?)"; try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, custNo); pstmt.setString(2, custName); pstmt.setString(3, street); pstmt.setString(4, city); pstmt.setString(5, state); pstmt.setString(6, zipCode); pstmt.setString(7, phoneNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }

158

POManagerクラスの2番目の静的メソッドaddStockItem()では、StockItem表に行を追加します。次の例に示すように、列の値はパラメータ値として渡されます。 public static void addStockItem (int stockNo, String description, float price) throws SQLException { String sql = "INSERT INTO StockItems VALUES (?,?,?)"; try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, stockNo); pstmt.setString(2, description); pstmt.setFloat(3, price); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }

POManagerクラスの3番目の静的メソッドenterOrder()では、Orders表に行を追加します。列値は、次に示すようにパラメータ・リストで指定します。 public static void enterOrder (int orderNo, int custNo, String orderDate, String shipDate, String toStreet, String toCity, String toState, String toZipCode) throws SQLException { String sql = "INSERT INTO Orders VALUES (?,?,?,?,?,?,?,?)"; try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, orderNo); pstmt.setInt(2, custNo); pstmt.setString(3, orderDate); pstmt.setString(4, shipDate); pstmt.setString(5, toStreet); pstmt.setString(6, toCity); pstmt.setString(7, toState); pstmt.setString(8, toZipCode); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }

その次のPOManagerクラスの静的メソッドaddLineItem()では、LineItems表に行を追加します。次の例に示すように、列値はパラメータ値として渡されます。public static void addLineItem (int lineNo, int orderNo, int stockNo, int quantity, float discount) throws SQLException { String sql = "INSERT INTO LineItems VALUES (?,?,?,?,?)"; try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, lineNo); pstmt.setInt(2, orderNo); pstmt.setInt(3, stockNo); pstmt.setInt(4, quantity); pstmt.setFloat(5, discount); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }

その次のPOManagerクラスの静的メソッドtotalOrders()では、Orders表のすべての注文の合計注文値を生成します。次に示すように、結果セットの関係はprintResult()メソッドを使用して出力されます。public static void totalOrders () throws SQLException { String sql = "SELECT O.PONo, ROUND(SUM(S.Price * L.Quantity)) AS TOTAL " + "FROM Orders O, LineItems L, StockItems S " + "WHERE O.PONo = L.PONo AND L.StockNo = S.StockNo " + "GROUP BY O.PONo";

159

try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); ResultSet rset = pstmt.executeQuery(); printResults(rset); rset.close(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }

次に示すヘルパー・メソッドprintResults()は、totalOrders()メソッドによって生成された結果セットの関係を出力するために使用されます。結果セットの関係への参照がパラメータとして渡されます。static void printResults (ResultSet rset) throws SQLException { String buffer = ""; try { ResultSetMetaData meta = rset.getMetaData(); int cols = meta.getColumnCount(), rows = 0; for (int i = 1; i <= cols; i++) { int size = meta.getPrecision(i); String label = meta.getColumnLabel(i); if (label.length() > size) size = label.length(); while (label.length() < size) label += " "; buffer = buffer + label + " "; } buffer = buffer + "\n"; while (rset.next()) { rows++; for (int i = 1; i <= cols; i++) { int size = meta.getPrecision(i); String label = meta.getColumnLabel(i); String value = rset.getString(i); if (label.length() > size) size = label.length(); while (value.length() < size) value += " "; buffer = buffer + value + " "; } buffer = buffer + "\n"; } if (rows == 0) buffer = "No data found!\n"; System.out.println(buffer); } catch (SQLException e) {System.err.println(e.getMessage());} }

次に示す静的メソッドcheckStockItem()は、指定された在庫品目のすべてのオーダー、顧客および明細品目詳細を取得します。在庫品目はパラメータとして渡されます。前述のヘルパー・メソッドprintResults()は、checkStockItem()メソッドによって生成された結果セットの関係を出力するために使用されます。public static void checkStockItem (int stockNo) throws SQLException { String sql = "SELECT O.PONo, O.CustNo, L.StockNo, " + "L.LineNo, L.Quantity, L.Discount " + "FROM Orders O, LineItems L " + "WHERE O.PONo = L.PONo AND L.StockNo = ?"; try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, stockNo); ResultSet rset = pstmt.executeQuery(); printResults(rset); rset.close(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }

静的メソッドchangeQuantity()では、指定のオーダーおよび在庫品目の明細品目数量を更新します。次に示すように、特定のオーダー番号と在庫品目を入力パラメータとして指定します。 public static void changeQuantity (int newQty, int orderNo, int stockNo) throws SQLException {

160

String sql = "UPDATE LineItems SET Quantity = ? " + "WHERE PONo = ? AND StockNo = ?"; try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, newQty); pstmt.setInt(2, orderNo); pstmt.setInt(3, stockNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }

最後の静的メソッドdeleteOrder()では、Orders表から特定のオーダーと関連するすべての明細品目を削除します。次の例に示すように、削除するオーダーは入力パラメータとして指定します。public static void deleteOrder (int orderNo) throws SQLException { String sql = "DELETE FROM LineItems WHERE PONo = ?"; try { Connection conn = DriverManager.getConnection("jdbc:default:connection:"); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, orderNo); pstmt.executeUpdate(); sql = "DELETE FROM Orders WHERE PONo = ?"; pstmt = conn.prepareStatement(sql); pstmt.setInt(1, orderNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} }}

ここで、シャーディング用に変更したサンプル・アプリケーションのプログラム・コードを確認します。最初の注目点は、OracleShardingKey以降のシャーディングに関連するJavaパッケージの追加インポートです。import java.sql.*;import java.io.*;import oracle.jdbc.driver.*;

//// import sharding and related packages//import oracle.jdbc.OracleShardingKey;import oracle.jdbc.OracleType;import oracle.jdbc.pool.OracleDataSource;

// // Sample App: order management and reporting// modified for sharding//public class POManager { // Connection factory for the sharded database used by Sample App private OracleDataSource ods;

// // Construct POManager class using Sharded database connection properties. // Use service name when connecting to sharded database, something like: // "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(HOST=myhost)(PORT=3216)” // “(PROTOCOL=tcp))(CONNECT_DATA=(SERVICE_NAME=myservice)(REGION=east)))" // public POManager(String yourURL, String yourUser, String yourPwd) throws SQLException { ods = new OracleDataSource(); ods.setURL(yourURL); ods.setUser(yourUser); ods.setPassword(yourPwd); } // POManager

161

前述したように、POManagerクラスには、ConnectionオブジェクトのためのOracleDataSourceファクトリが含まれるようになりました。次の2つのメソッドは、接続ファクトリを使用して直接ルーティングとプロキシ・ルーティングの接続を作成する方法を示しています。getCatConn()メソッドは、シャーディング・カタログへの接続を返します。getShardConn()メソッドは、パラメータとして指定されたシャーディング・キーと一致するシャードへの接続を返します。 // // Connect to the Sharding Catalog database. // public static Connection getCatConn() throws SQLException { Connection catConn = ods.getConnection(); } // getCatConn

// // Connect to Shard database using sharding key. // public static Connection getShardConn(int custNo) throws SQLException { OracleShardingKey shardKey = ods.createShardingKeyBuilder().subkey(custNo, JDBCType.NUMERIC).build(); OracleConnection shardConn = ods.createConnectionBuilder().shardingKey(shardingKey); return shardConn; } // getShardConn

これらすべてのことに注意して、次に示すように、シャーディング環境用にgetShardConn()を使用してaddCustomer()メソッドをリライトします。 // // Connect to Shard database to add a customer. // public static void addCustomer (int custNo, String custName, String street, String city, String state, String zipCode, String phoneNo) throws SQLException { String sql = "INSERT INTO Customers VALUES (?,?,?,?,?,?,?)"; try { Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, custNo); pstmt.setString(2, custName); pstmt.setString(3, street); pstmt.setString(4, city); pstmt.setString(5, state); pstmt.setString(6, zipCode); pstmt.setString(7, phoneNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // addCustomer

addStockItem()では、getCatConn()を使用してシャード・カタログ・データベースに接続し、重複表StockItemsに挿入します。// // Connect to Sharding Catalog to add a stock item. // public static void addStockItem (int stockNo, String description, float price) throws SQLException { String sql = "INSERT INTO StockItems VALUES (?,?,?)"; try { Connection conn = getCatConn(); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, stockNo); pstmt.setString(2, description); pstmt.setFloat(3, price); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // addStockItem

162

Orders表は、Customers表の子です。Orders表に挿入するには、次の例に示すように、指定されたシャーディング・キーに基づいてシャード・データベースに接続します。// // Connect to Shard database to add an order for a customer. // public static void enterOrder (int orderNo, int custNo, String orderDate, String shipDate, String toStreet, String toCity, String toState, String toZipCode) throws SQLException { String sql = "INSERT INTO Orders VALUES (?,?,?,?,?,?,?,?)"; try { Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, orderNo); pstmt.setInt(2, custNo); pstmt.setString(3, orderDate); pstmt.setString(4, shipDate); pstmt.setString(5, toStreet); pstmt.setString(6, toCity); pstmt.setString(7, toState); pstmt.setString(8, toZipCode); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // enterOrder

表ファミリのルートのCustomersと、直接の子レベルのOrdersのルートについては、パラメータとしてシャーディング・キーを指定します。直接の子より下のレベルについては、完全なレベル・キーがないことがあるため、直接の親から取得する必要があります。次の例には、Order表のキー値orderNoに基づいて、Order表からシャーディング・キーcustNoを取得するヘルパー・メソッドのgetCustomerFromOrder()があります。それぞれの子表の行には、単一の親行が必要です。そのため、親を持たない子、または複数の親を持つ子に対して整合性違反の例外が発生します。// // Determine which shard order is in // static int getCustomerFromOrder(int orderNo) throws SQLException { String sql = "SELECT O.CustNo FROM Orders O " + "WHERE O.PONo = ?"; int custNo; int rsSize = 0; Exception exception; try { Connection conn = getCatConn(); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, orderNo); PreparedStatement pstmt = conn.prepareStatement(sql); ResultSet rset = pstmt.executeQuery(); while(rset.next() && rsSize < 3) { custNo = rs.getInt(“CustNo); rsSize++; } rset.close(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} if (rsSize == 0) { throw new SQLIntegrityConstraintViolationException( “No matching parent level key”); If (rsSize == 2) { throw new SQLIntegrityConstraintViolationException( “More than one parent level key”); } return custNo; } // getCustomerFromOrder

注意:

163

コードでは、シャード・データベースに含まれるシャードの数を仮定しないでください。

次の例は、リライトしたaddLineItem()メソッドを示しています。このメソッドは、元のPOManagerクラスにあったものですが、getCustomerFromOrder()ヘルパー・メソッドを使用するようになっています。特定のorderNoについて、一致するcustNo値のシャード・カタログを問い合せます。問合せのこの部分は、プロキシ・ルーティングを使用するすべてのシャードに伝播されます。このヘルパー関数は、1つのcustNo値を返します。この値に基づいて、シャードへの直接ルートを使用してLineItems表の行を挿入します。 // // Get customer (parent) from the catalog, then insert into a shard! // public static void addLineItem (int lineNo, int orderNo, int stockNo, int quantity, float discount) throws SQLException { String sql = "INSERT INTO LineItems VALUES (?,?,?,?,?,?)"; try { int custNo = getCustomerFromOrder(orderNo); Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, custNo); pstmt.setInt(2, lineNo); pstmt.setInt(3, orderNo); pstmt.setInt(4, stockNo); pstmt.setInt(5, quantity); pstmt.setFloat(6, discount); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // addLineItem

// // You’ve got whole level key handy, insert into a shard directly. // public static void addLineItemWithinParent (int lineNo, int orderNo, int custNo, int stockNo, int quantity, float discount) throws SQLException { String sql = "INSERT INTO LineItems VALUES (?,?,?,?,?,?)"; try { Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, custNo); pstmt.setInt(2, lineNo); pstmt.setInt(3, orderNo); pstmt.setInt(4, stockNo); pstmt.setInt(5, quantity); pstmt.setFloat(6, discount); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // addLineItemWithinParent

注意:

ほとんどの場合、完全なレベル・キー・コンテキストがアプリケーション・コンテキストで使用可能になります。そのため、LineItems表の先頭列custNoコンポジット・レベル・キーに基づいて、シャードに直接接続する追加のメソッドaddLineItemWithinParent()を導入しています。これにより、シャード・カタログへのラウンドトリップがなくなります。ここに示したヘルパー関数getCustomerFromOrder()と同様のコストの高いシャーディング・プログラミング手法は、可能なかぎり使用しないでください。

集計問合せの大部分は、シャード・カタログ接続を使用して実行する必要があります。シャード・カタログ・データベースは、プロキシ・ルーティングを使用してシャードからの部分的な結果を収集します。最終集計は、シャードによって生成された部分的な結果に基づいて生成されます。そのため、次に示すように、元のPOManagerクラスに導入されたtotalOrders()メソッドは、シャード・カタログ・データベースに接続するようにリライトされています。

164

// // xshard aggregate connects to the shard catalog // public static void totalOrders () throws SQLException { String sql = "SELECT O.PONo, ROUND(SUM(S.Price * L.Quantity)) AS TOTAL " + "FROM Orders O, LineItems L, StockItems S " + "WHERE O.PONo = L.PONo AND L.StockNo = S.StockNo " + "GROUP BY O.PONo"; try { Connection conn = getCatConn(); PreparedStatement pstmt = conn.prepareStatement(sql); ResultSet rset = pstmt.executeQuery(); printResults(rset); rset.close(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // totalOrders

前の手順で導入したprintResults()ヘルパー関数は、データベース構造に依存しないため変更は不要です。 // // helper function – no change required // static void printResults (ResultSet rset) throws SQLException { String buffer = ""; try { ResultSetMetaData meta = rset.getMetaData(); int cols = meta.getColumnCount(), rows = 0; for (int i = 1; i <= cols; i++) { int size = meta.getPrecision(i); String label = meta.getColumnLabel(i); if (label.length() > size) size = label.length(); while (label.length() < size) label += " "; buffer = buffer + label + " "; } buffer = buffer + "\n"; while (rset.next()) { rows++; for (int i = 1; i <= cols; i++) { int size = meta.getPrecision(i); String label = meta.getColumnLabel(i); String value = rset.getString(i); if (label.length() > size) size = label.length(); while (value.length() < size) value += " "; buffer = buffer + value + " "; } buffer = buffer + "\n"; } if (rows == 0) buffer = "No data found!\n"; System.out.println(buffer); } catch (SQLException e) {System.err.println(e.getMessage());} } // printResults

StockItem表のキー列stockNoの値は、すべてのシャードのOrder表の行と一致する可能性があります。そのため、シャード・カタログに接続するように、元のPOManagerクラスに導入したcheckStockItem()メソッドを変更する必要があります。シャード・カタログ・データベースは、各シャードで実行されたローカル結合の結果として返されるすべての行の結合を返します。 // // xshard query matching duplicated table // public static void checkStockItem (int stockNo) throws SQLException { String sql = "SELECT O.PONo, O.CustNo, L.StockNo, " + "L.LineNo, L.Quantity, L.Discount " + "FROM Orders O, LineItems L " + "WHERE O.PONo = L.PONo AND L.StockNo = ?"; try { Connection conn = getCatConn(); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, stockNo); ResultSet rset = pstmt.executeQuery();

165

printResults(rset); rset.close(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // checkStockItem

元のPOManagerクラスに導入したchangeQuantity()メソッドでは、孫表LineItemsを更新します。繰り返しになりますが、getCustomerFromOrder()ヘルパー・メソッドを使用してシャーディング・キーを取得し、アプリケーションが更新を実行する適切なシャードに接続できるようにします。addLineItem()メソッドの変更と同様に、custNo列の値はアプリケーション・コンテキストでも使用可能であると考えられます。そのため、changeQuantity()でchangeQuantifyWithinParent()を使用して、シャード・カタログへのラウンド・トリップを省くようにします。 // // Get customer (parent) from the catalog then update a shard! // public static void changeQuantity (int newQty, int orderNo, int stockNo) throws SQLException { String sql = "UPDATE LineItems SET Quantity = ? " + "WHERE CustNo = ? AND PONo = ? AND StockNo = ?"; try { int custNo = getCustomerFromOrder(orderNo); Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, newQty); pstmt.setInt(2, custNo); pstmt.setInt(3, orderNo); pstmt.setInt(4, stockNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // changeQuantity

// // You’ve got the full level key handy, update shard directly. // public static void changeQuantityWithinParent (int newQty, int custNo, int orderNo, int stockNo) throws SQLException { String sql = "UPDATE LineItems SET Quantity = ? " + "WHERE CustNo = ? AND PONo = ? AND StockNo = ?"; try { Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, newQty); pstmt.setInt(2, custNo); pstmt.setInt(3, orderNo); pstmt.setInt(4, stockNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // changeQuantityWithinParent

最後のメソッドdeleteOrder()に対する変更は、addLineItem()およびchangeQuantity()に適用したものと同じガイドラインに従います。LineItems表から行を削除する前に、アプリケーションでは、まず、リクエストされたオーダーに対応するcustNoシャーディング・キー値についてシャード・カタログを参照する必要があります。シャーディング・キーを取得したら、シャードに接続して削除を実行します。繰り返しになりますが、アプリケーション・コンテキストでもシャーディング・キー値が使用可能であると考えて、deleteOrderWithinParent()メソッドを使用します。 // // Get customer (parent) first from the catalog, delete in a shard! // public static void deleteOrder (int orderNo) throws SQLException { String sql = "DELETE FROM LineItems WHERE CustNo = ? AND PONo = ?"; try { int custNo = getCustomerFromOrder(orderNo);

166

Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, orderNo); pstmt.executeUpdate(); sql = "DELETE FROM Orders WHERE PONo = ?"; pstmt = conn.prepareStatement(sql); pstmt.setInt(1, custNo); pstmt.setInt(2, orderNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // deleteOrder

// // You’ve got whole level key handy, delete in shard directly // public static void deleteOrderWithinParent (int custNo, int orderNo) throws SQLException { String sql = "DELETE FROM LineItems WHERE CustNo = ? AND PONo = ?"; try { Connection conn = getShardConn(custNo); PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setInt(1, orderNo); pstmt.executeUpdate(); sql = "DELETE FROM Orders WHERE PONo = ?"; pstmt = conn.prepareStatement(sql); pstmt.setInt(1, custNo); pstmt.setInt(2, orderNo); pstmt.executeUpdate(); pstmt.close(); } catch (SQLException e) {System.err.println(e.getMessage());} } // deleteOrderWithinParent

} // POManager


167


1. Oracle Shardingの使用2. シャード・データベースの管理

10 シャード・データベースの管理Oracle Shardingは、シャード・データベースの管理のためのツールおよびいくつかの自動化を提供しています。

次のトピックでは、シャード・データベースの管理についてさらに詳しく説明します。

シャーディング対応スタックの管理Oracle Shardingデータベース・ユーザーの管理シャード・データベースの監視Enterprise Manager Cloud ControlまたはGDSCTLを使用して、シャード・データベースを監視できます。シャード・データベースのバックアップおよびリカバリシャードは個別のOracleデータベースでホストされるため、Oracle Maximum Availabilityのベスト・プラクティスを使用してシャードを個別にバックアップおよびリストアできます。シャード・データベース・スキーマの変更シャード・データベースの重複表またはシャード表を変更する場合、それらの変更はシャード・カタログ・データベースから行う必要があります。シャード間のパラメータ設定の伝播シャード・カタログでシステム・パラメータ設定を構成すると、シャード・データベースのすべてのシャードに自動的に伝播されます。シャード・データベースのソフトウェア・バージョンの管理シャード管理Oracle Enterprise Manager Cloud ControlおよびGDSCTLを使用したOracle Shardingデプロイメントのシャードを管理できます。チャンク管理Oracle Enterprise Manager Cloud ControlおよびGDSCTLを使用したOracle Shardingデプロイメントのチャンクを管理できます。シャード・ディレクタ管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのシャード・ディレクタを追加、編集および削除できます。リージョン管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのリージョンを追加、編集および削除できます。シャード領域管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのシャード領域を追加、編集および削除できます。シャードグループ管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのシャードグループを追加、編集および削除できます。サービス管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのサービスを管理できます。

10.1 シャーディング対応スタックの管理

168

この項では、シャード・データベース構成内のコンポーネントの起動および停止について説明します。次の項目が含まれます。

シャーディング対応スタックの起動シャーディング対応スタックの停止

親トピック: シャード・データベースの管理

10.1.1 シャーディング対応タックの起動

シャーディング対応スタックの推奨される起動順序は次のとおりです。

シャード・カタログ・データベースとローカル・リスナーを起動します。

シャード・ディレクタ(GSM)を起動します。

シャード・データベースとローカル・リスナーを起動します。

グローバル・サービスを起動します。

接続プールとクライアントを起動します。

親トピック: シャーディング対応スタックの管理

10.1.2 シャーディング対応スタックの停止

シャーディング対応スタックの推奨される停止手順は次のとおりです。

接続プールとクライアントを停止します。

グローバル・サービスを停止します。

シャード・データベースとローカル・リスナーを停止します。

シャード・ディレクタ(GSM)を停止します。

シャード・カタログ・データベースとローカル・リスナーを停止します。

親トピック: シャーディング対応スタックの管理

10.2 Oracle Shardingデータベース・ユーザーの管理

この項では、Oracle Shardingに固有のデータベース・ユーザーについて説明します。次の項目が含まれます。

GSMUSERアカウントについてGSMUSERアカウントは、GDSCTLおよびグローバル・サービス・マネージャがGDS構成のデータベースに接続するために使用されます。GSMROOTUSERアカウントについてGSMROOTUSERは、プラガブル・データベース(PDB)シャードが存在する場合にのみ使用されるOracle Shardingに固有のデータベース・アカウントです。アカウントは、GDSCTLおよびグローバル・サービス・マネージャがコンテナ・データベース(CDB)のルート・コンテナに接続し

169

て管理タスクを実行するために使用されます。


10.2.1 GSMUSERアカウントについて

GSMUSERアカウントは、GDSCTLおよびグローバル・サービス・マネージャがGDS構成のデータベースに接続するために使用されます。

GSMUSERは、デフォルトでOracleデータベースに存在します。Oracle Sharding構成では、このアカウントはプール・データベースのかわりにシャードへの接続に使用され、アカウントがロック解除された後、SYSDGおよびSYSBACKUPシステム権限の両方を付与する必要があります。

GSMUSERアカウントに指定されたパスワードは、gdsctl add shardコマンドで使用されます。新しいシャードでGSMUSERにSYSDGおよびSYSBACKUPを付与しないと、gdsctl add shardがORA-1031: 権限が不足していますのエラーで失敗します。

gdsctl create shardコマンドを使用してDatabase Configuration Assistant (DBCA)で新しいシャードを作成すると、デプロイメント・プロセス中にGSMUSERアカウントに自動的にSYSDG権限とSYSBACKUP権限が付与され、ランダム・パスワードが割り当てられます。GSMUSERアカウントは対話的にログインする必要がないため、管理者がパスワードの値を認識する必要はありません。ただし、シャードでalter user SQLコマンドをgdsctl modify shard -pwdコマンドと組み合せて使用すると、必要に応じてパスワードを変更できます。

関連項目:

Global Data Services概要および管理ガイドのシャードの追加

親トピック: Oracle Shardingデータベース・ユーザーの管理

10.2.2 GSMROOTUSERアカウントについて

GSMROOTUSERは、プラガブル・データベース(PDB)シャードが存在する場合にのみ使用されるOracleShardingに固有のデータベース・アカウントです。アカウントは、GDSCTLおよびグローバル・サービス・マネージャがコンテナ・データベース(CDB)のルート・コンテナに接続して管理タスクを実行するために使用されます。

PDBシャードが使用されていない場合、GSMROOTUSERユーザーはロック解除されず、どのデータベースでもパスワードを割り当てられません。ただし、PDBシャードを含むシャード構成では、gdsctl add cdbコマンドを実行する前に、GSMROOTUSERをロック解除し、SYSDGおよびSYSBACKUP権限を付与する必要があります。GSMROOTUSERアカウントのパスワードは、CDBのルート・コンテナ内でalter user SQLコマンドをgdsctl modify cdb -pwdコマンドと組み合せて使用することで、デプロイメント後に必要に応じて変更できます。

関連項目:

Global Data Services概要および管理ガイドのcdbの追加

親トピック: Oracle Shardingデータベース・ユーザーの管理

10.3 シャード・データベースの監視

170

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-8371BD52-60E3-45AC-A32F-938BD7B7B373

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-3C0D9A90-002B-4F7F-91B6-3F0DA6A65F54

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-3C0D9A90-002B-4F7F-91B6-3F0DA6A65F54

Enterprise Manager Cloud ControlまたはGDSCTLを使用して、シャード・データベースを監視できます。

Enterprise Manager Cloud ControlまたはGDSCTLを使用してシャード・データベースを監視するには、次の各トピックを参照してください。

GDSCTLによるシャード・データベースの監視個別のシャード、シャードグループ、シャード領域およびシャード・ディレクタのヘルス・ステータスを取得するために使用できる多数のGDSCTL CONFIGコマンドがあります。Enterprise Manager Cloud Controlによるシャード・データベースの監視Oracle Enterprise Manager Cloud Controlを使用すると、シャード・データベースのコンポーネントを検出、監視および管理できます。シャード間のシステム・オブジェクトの問合せV$ビューおよびDBA_*ビューからパフォーマンス、診断および監査データを収集するには、SHARDS()句を使用してOracle提供の表を問い合せます。


10.3.1 GDSCTLによるシャード・データベースの監視

個別のシャード、シャードグループ、シャード領域およびシャード・ディレクタのヘルス・ステータスを取得するために使用できる多数のGDSCTL CONFIGコマンドがあります。

シャードの監視は通常のデータベースの監視と同様であり、標準のOracleのベスト・プラクティスを使用して、単一のシャードの個別の状態を監視してください。ただし、シャード環境全体の状態を監視することも重要です。GDSCTLコマンドは、スクリプトに記述し、スケジューラを使用して定期的に実行することによって、すべてが円滑に実行されていることを確認することもできます。レプリケーションにOracle GoldenGateを使用している場合は、各レプリケーション・ストリームのラグを監視することも重要です。

関連項目:

GDSCTL CONFIGコマンドの使用方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください

親トピック: シャード・データベースの監視

10.3.2 Enterprise Manager Cloud Controlによるシャード・データベースの監視

Oracle Enterprise Manager Cloud Controlを使用すると、シャード・データベースのコンポーネントを検出、監視および管理できます。

シャード・データベース・ターゲットは、「すべてのターゲット」ページで見つけます。

図10-1 「すべてのターゲット」の「検索の絞込み」ペインのシャード・データベース

171

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-1BA69DEA-66A1-45EB-BA86-E24957C10CF3



「図10-1 「すべてのターゲット」の「検索の絞込み」ペインのシャード・データベース」の説明

シャード・データベースのターゲット・ホーム・ページには、シャード・データベースのコンポーネントとそのステータスの概要が表示されます。

シャード・データベースのコンポーネントを監視するには、まず、それらを検出する必要があります。詳細は、「シャード・データベースのコンポーネントの検出」を参照してください。

サマリー

ページの左上にある「サマリー」ペインには、次の情報が表示されます。

シャード・データベース名

シャード・データベース・ドメイン名

シャード・カタログ名。名前をクリックすると、シャード・カタログの詳細を表示できます。

シャード・カタログ・データベースのバージョン

データベースのシャードに使用されたシャーディング方法

高可用性のために使用されたレプリケーション・テクノロジ

シャード・ディレクタの数とステータス

172

マスター・シャード・ディレクタ名。名前をクリックすると、マスター・シャード・ディレクタの詳細を表示できます。

図10-2 シャード・データベースの「サマリー」ペイン

「図10-2 シャード・データベースの「サマリー」ペイン」の説明

シャードのロード・マップ

ページの右上にある「シャードのロード・マップ」には、シャード間でトランザクションがどのように分散されているかを図示したグラフが表示されます。

図10-3 シャード・データベースの「シャードのロード・マップ」

「図10-3 シャード・データベースの「シャードのロード・マップ」」の説明

グラフの上にある「表示レベル」で別のレベルを選択できます。

データベース

データベース・ビューは、Oracle RACクラスタ・データベース内のデータベース・インスタンスを、Oracle RACクラスタ・データベース・ターゲット名でラベルが付けられた単一のセルに集約します。これにより、Oracle RAC環境のデータベース負荷の合計を簡単に比較できます。

インスタンス

インスタンス・ビューには、すべてのデータベース・インスタンスが個別に表示されます

173

が、インスタンスはデータベース・ターゲットのサブセルとしてグループ化されています。このビューは、基本的には2レベルのツリー・マップであり、データベース・レベルがプライマリ区分で、データベース内のインスタンスがセカンダリ区分です。これにより、Oracle RACデータベース内のインスタンスの負荷を比較できます。たとえば、インスタンス間での負荷の不均衡を簡単に特定できます。

プラガブル・データベース

PDBオプションが表示されますが、現行リリースではPDBはOracle Shardingに対してサポートされていません。

グラフのセルは、サイズが同じでないことに注意してください。各セルは、シャード・ターゲット(インスタンスまたはクラスタ・データベース)に対応します。セル・サイズ(領域)は、平均的なアクティブ・セッションで測定されたターゲット・データベースの負荷に比例するため、負荷の高いターゲットほどセル・サイズが大きくなります。セルは、サイズ順に左から右、上から下に並べられます。したがって、最も負荷の高いターゲットが常にグラフの左上端のセルとして表示されます。

グラフの特定のセルの上にマウス・ポインタを置くと、合計アクティブ・ロード(CPUに対するI/Oの比率)、CPU、I/Oおよび待機時間を表示できます。グラフの区分は、優位を占める負荷を示すように色付けされます。

緑は、CPU時間が負荷の大半を占めていることを示します。

青は、I/Oが負荷の大半を占めていることを示します。

黄色は、待機時間が負荷の大半を占めていることを示します。

メンバー

ページの左下にある「メンバー」ペインには、各コンポーネントの関連情報の一部が表示されます。

図10-4 シャード・データベースの「メンバー」ペイン

「図10-4 シャード・データベースの「メンバー」ペイン」の説明

このペインは、各コンポーネントのタブ「シャード領域」、「シャードグループ」、「シャード・ディレクタ」および「シャード」に分かれています。各種コンポーネントの情報を表示するには、タ

Oracle RAC Oracle RAC

174

ブをクリックします。

シャード領域

「シャード領域」タブには、シャード領域名、ステータス、チャンク数およびData Guard保護モードが表示されます。シャード領域名をクリックすると、選択したシャード領域の詳細を表示できます。

シャードグループ

「シャードグループ」タブには、シャードグループ名、ステータス、所属するシャード領域、チャンク数、Data Guardロールおよび所属するリージョンが表示されます。シャードグループ名およびシャード領域名をクリックすると、選択したコンポーネントの詳細を表示できます。

シャード・ディレクタ

「シャード・ディレクタ」タブには、シャード・ディレクタ名、ステータス、リージョン、ホストおよびOracleホームが表示されます。シャード・ディレクタ名をクリックすると、選択したシャード・ディレクタの詳細を表示できます。

シャード

「シャード」タブには、シャード名、デプロイ・ステータス、ステータス、所属するシャード領域およびシャードグループ、Data Guardロールおよび所属するリージョンが表示されます。「名前」列で、プライマリ・シャードを展開すると、対応するスタンバイ・シャードの情報を表示できます。「デプロイ済」列のアイコンの上にマウスを置くと、デプロイメント・ステータスの詳細を表示できます。シャード名、シャード領域名およびシャードグループ名をクリックすると、選択したコンポーネントの詳細を表示できます。

サービス

ページの右下にある「サービス」ペインには、シャード・データベース・サービスの名前、ステータスおよびData Guardロールが表示されます。リストの上にはサービスの合計数と、特定のステータスにあるサービスの数を示すアイコンが表示されます。アイコンの上にマウス・ポインタを置くと、ステータス・アイコンの説明を表示できます。

図10-5 シャード・データベースの「サービス」ペイン

175

「図10-5 シャード・データベースの「サービス」ペイン」の説明

インシデント

「インシデント」ペインには、シャード・データベース環境の様々なコンポーネントに関するメッセージおよび警告が表示されます。このペインの使用方法の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

「シャードされたデータベース」メニュー

左上隅にある「シャードされたデータベース」メニューを使用すると、シャード・データベースのコンポーネントを管理するためにアクセスできるようになります。

ターゲット・ナビゲーション

「ターゲット・ナビゲーション」ペインを使用すると、シャード・データベースのどのコンポーネントの詳細にも簡単にアクセスできるようになります。

図shard_em_navicon.pngの説明

ページの左上隅にあるナビゲーション・ツリー・アイコンをクリックすると、「ターゲット・ナビゲーション」ペインが開きます。このペインには、シャード・データベースで検出されたすべてのコンポーネントがツリー形式で表示されます。

シャード領域を展開すると、その領域内のシャードグループが表示されます。シャードグループを展開すると、そのシャードグループ内のシャードが表示されます。

コンポーネント名をクリックすると、その詳細を表示できます。

シャード・データベースのコンポーネントの検出Enterprise Manager Cloud Controlでは、シャード・カタログおよびシャード・データベースを検出し、ガイドされた検出を使用してシャード・ディレクタ、シャード・データベース、シャード領域およびシャードグループを追加できます。

176


10.3.2.1 シャード・データベースのコンポーネントの検出

Enterprise Manager Cloud Controlでは、シャード・カタログおよびシャード・データベースを検出し、ガイドされた検出を使用してシャード・ディレクタ、シャード・データベース、シャード領域およびシャードグループを追加できます。

前提条件として、Cloud Controlを使用してシャード・ディレクタ・ホストおよびシャード・カタログ・データベースを検出しておく必要があります。カタログ・データベースおよび各シャードはデータベースそのものであるため、標準のデータベース検出プロシージャを使用できます。

シャードの監視は、データベース検出を使用して個々のシャードを検出する場合のみ可能です。シャードの検出は、シャードなしのシャード・データベース構成にすることもできるため、シャード・データベースの検出ではオプションです。

1. Enterprise Manager Cloud Controlで「設定」、「ターゲットの追加」、「ターゲットの手動追加」の順に選択します。

2. 「ターゲットの手動追加」ページで、「ガイド付きプロセスを使用して非ホスト・ターゲットを追加」パネルで「ガイド付きプロセスを使用した追加」をクリックします。

3. 「ガイド付きプロセスを使用した追加」ダイアログで、「シャードされたデータベース」を探して選択し、「追加」をクリックします。

4. 「シャードされたデータベースの追加: カタログ・データベース」ページで、「カタログ・データベース」の横にある参照アイコンをクリックしてSDBカタログ・データベースを探します。

5. 「ターゲットの選択」ダイアログで、カタログ・データベースに対応するターゲット名をクリックし、「選択」をクリックします。

「カタログ・データベース」フィールドと「モニタリング資格証明」フィールドは、存在する場合、自動入力されます。モニタリング資格証明は、カタログ・データベースに問い合せて構成情報を取得する場合に使用されます。モニタリング・ユーザーは、GDS_CATALOG_SELECTロールが付与され、カタログ・リポジトリ表に対して読取り専用権限があります。

「次へ」をクリックして次の手順に進みます。

「シャードされたデータベースの追加: コンポーネント」ページには、シャード・データベース名、ドメイン名、シャード・データベースで採用されているシャーディング方法、検出されたシャード・ディレクタのリストなど、カタログ・データベースで管理されるシャード・データベースに関する情報が表示されます。

6. モニタリング資格証明をシャード・ディレクタに設定するには、リスト・エントリの右側にあるプラス記号アイコンをクリックします。

ダイアログが開き、資格証明を設定できます。

「OK」をクリックしてダイアログを閉じ、「次」をクリックして次の手順に進みます。

7. 「シャードされたデータベースの追加: 確認」ページで、シャード・ディレクタ、シャード領域およびシャードグループがすべて検出されたことを確認します。

8. 「発行」をクリックして、手順を終了します。

Enterprise Managerデプロイメント・プロシージャが発行され、「ターゲットの手動追加」ペー

177

ジに戻ります。

ページ上部に、検出されたすべてのコンポーネントをCloud Controlに追加するために発行されたスクリプトに関する情報が表示されます。

9. リンクをクリックして、シャード・データベースのコンポーネントのプロビジョニング・ステータスを表示します。

別のブラウザ・ウィンドウで、Cloud Controlの「すべてのターゲット」ページに移動してシャード・データベースのステータスを監視できます。

ターゲット検出プロシージャが終了すると、シャード・データベース・ターゲットがCloud Controlに追加されます。Cloud Controlでシャード・データベースを開き、コンポーネントを監視および管理できます。

親トピック: Enterprise Manager Cloud Controlによるシャード・データベースの監視

10.3.3 シャード間のシステム・オブジェクトの問合せ

SHARDS()句を使用して、V$ビューとDBA_*ビューからパフォーマンス、診断および監査データを収集するためにOracle提供の表を問い合せることができます。

SQLのSHARDS()句を使用して、シャード・カタログ・データベースを一元化された診断操作のエントリ・ポイントとして使用できます。SHARDS()句を使用して、すべてのシャードに対して同じOracle提供オブジェクト(V$、DBA/USER/ALLビュー、ディクショナリ・オブジェクトおよび表など)を問い合せ、集計結果を返すことができます。

次の例に示すように、SELECT文のFROM部分のオブジェクトをSHARDS()句でラップすることにより、これがローカル・オブジェクトに対する問合せではなく、シャード・データベース構成内のすべてのシャード上のオブジェクトに対する問合せであることを指定します。結果に含まれるすべての行のソースを示すため、マルチシャード問合せの実行時にSHARD_IDという名前の仮想列がSHARDS()でラップされたオブジェクトに自動的に追加されます。同じ列を、問合せをプルーニングするための述語で使用できます。

SHARDS()句を含む問合せは、シャード・カタログ・データベースに対してのみ実行できます。

例

次の文は、パフォーマンス・ビューを問い合せます。SQL> SELECT shard_id, callspersec FROM SHARDS(v$servicemetric) WHERE service_name LIKE 'oltp%' AND group_id = 10;

次の文は、統計情報を収集します。SQL> SELECT table_name, partition_name, blocks, num_rows FROM SHARDS(dba_tab_partition) p WHERE p.table_owner= :1;

次の例の文は、各シャードのSHARD_ID値を見つける方法を示しています。SQL> select ORA_SHARD_ID, INSTANCE_NAME from SHARDS(sys.v_$instance);

ORA_SHARD_ID INSTANCE_NAME ------------ ---------------- 1 sh1 11 sh2

178

21 sh3 31 sh4

次の例の文は、SHARD_IDを使用して問合せをプルーニングする方法を示しています。SQL> select ORA_SHARD_ID, INSTANCE_NAME from SHARDS(sys.v_$instance) where ORA_SHARD_ID=21;

ORA_SHARD_ID INSTANCE_NAME ------------ ---------------- 21 sh3

関連項目:

Oracle Database SQL言語リファレンス(SHARDS()句の詳細)


10.4 シャード・データベースのバックアップおよびリカバリ

シャードは個別のOracleデータベースでホストされるため、Oracle Maximum Availabilityのベスト・プラクティスを使用してシャードを個別にバックアップおよびリストアできます。

SDBの高可用性のためにData GuardおよびOracle Active Data Guardを使用している場合は、プライマリ・データベースまたはスタンバイ・データベースをオフラインにする前に、オブザーバをオフラインにして、ファスト・スタート・フェイルオーバーを無効にします。

災害が発生した場合にシャードをリカバリするための具体的な手順については、Oracleサポートにお問合せください。

関連項目:

MAAベスト・プラクティス・ホワイト・ペーパーについては、Oracle Maximum Availabilityアーキテクチャを参照してください


10.5 シャード・データベース・スキーマの変更

シャード・データベースの重複表またはシャード表を変更する場合、それらの変更はシャード・カタログ・データベースから行う必要があります。

シャード・データベースに対してDDL操作を実行する前に、次のコマンドを使用してSHARD DDLを有効にします。ALTER SESSION ENABLE SHARD DDL;

この文は、DDLによる変更がシャード・データベース内の各シャードに伝播されるようにします。

伝播されるDDLによる変更は、ALTER TABLE、CREATE TRIGGERなどの操作を含む「スキーマ関連」として定義されているコマンドです。各シャードに伝播される他の操作には、ユーザー管理を簡略化するためのCREATE、ALTER、DROPユーザー・コマンド、複数のシャードでの表領域の作成を簡略化するためのTABLESPACE操作などがあります。

GRANTおよびREVOKE操作はシャード・カタログから行うことができ、セッションでSHARD DDLを有効

179

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SQLRF-GUID-CFA006CA-6FF1-4972-821E-6996142A51C6

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SQLRF-GUID-CFA006CA-6FF1-4972-821E-6996142A51C6




にしている場合は各シャードに伝播されます。より細かい制御が必要な場合は、各シャードに対してコマンドを直接発行できます。

DBMSパッケージ・コール(または同様の操作)などの操作は伝播されません。たとえば、シャード・カタログで統計を収集する操作は各シャードに伝播されません。

表に対するロックを必要とする操作(NOT NULL列の追加など)を実行する場合、DDL操作を実行するには各シャードで表に対するロックを取得する必要があることに留意することが重要です。単一インスタンスにDDLを適用するためのOracleのベスト・プラクティスがシャード環境に適用されます。

シャード・カタログで実行されるマルチシャード問合せは、各シャードのデータベース接続でリモート問合せを発行します。この場合、問合せによってそのシャードからデータを返されるかどうかにかかわらず、ユーザーが各シャードに対する適切な権限を持つようにすることが重要です。

関連項目:

重複表およびシャード表に使用する操作の詳細は、Oracle Database SQL言語リファレンスを参照してください


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

シャード・カタログでシステム・パラメータ設定を構成すると、シャード・データベースのすべてのシャードに自動的に伝播されます。

Oracle Database 19cより前は、シャード・データベースの各シャードでALTER SYSTEMパラメータ設定を構成する必要がありました。Oracle Database 19cでは、Oracle Shardingはシャード・カタログでパラメータを設定できるようにすることで集中管理を提供します。その後、設定はシャード・データベースのすべてのシャードに自動的に伝播されます。

システム・パラメータの伝播は、シャード・カタログに対してENABLE SHARD DDLで行われた場合にのみ発生します。その後、ALTER文にSHARD=ALLを含めます。SQL>alter session enable shard ddl;SQL>alter system set enable_ddl_logging=true shard=all;

注意:

enable_goldengate_replicationパラメータ設定の伝播はサポートされていません。


10.7 シャード・データベースのソフトウェア・バージョンの管理

この項では、シャード・データベース構成内のソフトウェア・コンポーネントのバージョン管理について説明します。次の項目が含まれます。

シャード・データベースへのパッチ適用およびアップグレードシャード・データベース環境へのOracleパッチの適用は、単一のシャードまたはすべてのシャードに対して行うことができます。ただし、使用する方法は、その環境で使用されているレプリケーション・オプションおよび適用されるパッチのタイプによって異なります。シャード・データベースのコンポーネントのアップグレード

180

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SQLRF-GUID-B7052D25-F224-459A-A17B-FA5A37BFD237

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SQLRF-GUID-B7052D25-F224-459A-A17B-FA5A37BFD237

コンポーネントが停止してオンライン状態に戻る際の停止時間を制限し、エラーを回避するためには、シャード・データベースのコンポーネントをアップグレードする順序が重要です。シャード・データベースのダウングレードOracle Shardingはダウングレードをサポートしていません。


10.7.1 シャード・データベースへのパッチ適用およびアップグレード

シャード・データベース環境へのOracleパッチの適用は、単一のシャードまたはすべてのシャードに対して行うことができます。ただし、使用する方法は、その環境で使用されているレプリケーション・オプションおよび適用されるパッチのタイプによって異なります。

シャード・データベースへのパッチ適用

ほとんどのパッチは、単一のシャードに一度に適用できます。ただし、一部のパッチはすべてのシャードに適用する必要があります。SDBに使用されているレプリケーション方法に留意して、非シャード・データベースの場合と同様に、Oracleのベスト・プラクティスを使用して単一のシャードにパッチを適用してください。Oracleのopatchautoは、複数のシャードに一度にパッチを適用するために使用でき、ローリング形式で行うことができます。Data Guard構成は1つずつ適用され、場合によっては(パッチによって異なります) Standby Firstパッチ適用を使用できます。Oracle GoldenGateを使用する場合は、必ずシャード領域全体で並列にパッチを適用してください。パッチがマルチシャード問合せ、レプリケーションまたはシャーディング・インフラストラクチャの問題に対処するものである場合は、SDB内のすべてのシャードに適用する必要があります。

シャード・データベースへのアップグレード

Oracle Sharding環境のアップグレードは、他のOracle Databaseとグローバル・サービス・マネージャの環境のアップグレードと大きな違いはありません。ただし、コンポーネントを特定の順序(最初にシャード・カタログ、次にシャード・ディレクタ、最後にシャードの順)でアップグレードする必要があります。

関連項目:

Oracle OPatchユーザーズ・ガイド

Oracle Database Global Data Services概要および管理ガイド(シャード・ディレクタのアップグレードの詳細)

Oracle Data Guard概要および管理(Oracle Data Guard構成内のパッチ適用およびアップグレードの詳細)

親トピック: シャード・データベースのソフトウェア・バージョンの管理

10.7.2 シャード・データベースのコンポーネントのアップグレード

コンポーネントが停止してオンライン状態に戻る際の停止時間を制限し、エラーを回避するためには、シャード・データベースのコンポーネントをアップグレードする順序が重要です。

シャード・データベースのコンポーネントをアップグレードするときは、次の点に注意する必要があります。

保留中のMOVE CHUNK操作が進行中の場合は、完了してください。

181

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=OPTCH149

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=OPTCH149

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-39AD169B-86B6-4968-A126-2C61109857A8

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-39AD169B-86B6-4968-A126-2C61109857A8

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SBYDB-GUID-A4FBE490-7E7E-4998-B80E-01C93C77AE2F


新しいMOVE CHUNK操作を開始しないでください。

アップグレード・プロセス中に新しいシャードを追加しないでください。

プラガブル・データベース(PDB)シャードを含むOracle Database 18cシャード・データベース構成をアップグレードする場合は、Oracle ShardingでのOracle Multitenantの使用のPDB固有のアップグレード手順に従います。

1. 次の点に注意しながら、シャードをアップグレードします。

システム管理のシャード・データベースの場合: Data Guard Broker構成内のシャードの各セットをローリング方式でアップグレードします。

ユーザー定義のシャード・データベースの場合: シャード領域内のシャードの各セットをローリング方式でアップグレードします。

コンポーネント・シャード・データベースの場合: 特定のシャード領域で、Data GuardBroker構成内のシャードの各セットをローリング方式でアップグレードします。

2. カタログ・データベースをアップグレードします。

最高の結果を得るには、ローリング・データベース・アップグレードを使用してカタログをアップグレードする必要があります(ただし、カタログが使用できない場合、アップグレード中にグローバル・サービスは引き続き使用可能ですが、サービス・フェイルオーバーは発生しません)。

3. GDSCTLクライアントを実行するために使用されるシャード・ディレクタをアップグレードします(グローバル・サービス・マネージャ・サーバーは実行しません)。

シャード・ディレクタのアップグレードはインプレースで実行する必要がありますが、次のプラットフォームの各ファイルに対するアクセス権が755に更新されていない場合、インプレース・アップグレードによって間違ったエラー・メッセージが表示されます。

Linux、Solaris64およびSolaris Sparc64の場合:

$ORACLE_HOME/QOpatch/qopiprep.bat$ORACLE_HOME/jdk/bin/jcontrol$ORACLE_HOME/jdk/jre/bin/jcontrol

AIXの場合:

$ORACLE_HOME/QOpatch/qopiprep.bat$ORACLE_HOME/jdk/jre/bin/classic/libjvm.a$ORACLE_HOME/jdk/bin/policytool

HPIの場合:

$ORACLE_HOME/jdk/jre/lib/IA64N/server/Xusage.txt$ORACLE_HOME/jdk/jre/bin/jcontrol$ORACLE_HOME/QOpatch/qopiprep.bat

Windowsでは、エラー・メッセージは予期されません。

4. すべてのシャード・ディレクタ・サーバーを一度に1つずつ停止、アップグレードおよび再起動します。

停止時間をゼロにするには、1つ以上のシャード・ディレクタ・サーバーが常に稼働している必

182

要があります。カタログより前のバージョンのシャード・ディレクタ・サーバーは、カタログに変更が発生するまで完全に動作し続けます。

関連項目:

DBMS_ROLLINGを使用してローリング・アップグレードを実行する方法の詳細は、Oracle DataGuard概要および管理を参照してください。

Oracle Data Guard概要および管理(Oracle Data Guard構成内のデータベースのパッチ適用およびアップグレードの詳細)


10.7.3 シャード・データベースのダウングレード

Oracle Shardingはダウングレードをサポートしていません。

シャード・データベース・カタログおよびシャードはダウングレードできません。


10.8 シャード管理Oracle Enterprise Manager Cloud ControlおよびGDSCTLを使用したOracle Shardingデプロイメントのシャードを管理できます。

次のトピックでは、シャード管理の概念およびタスクについて説明します。

シャードの追加について既存のシャード・データベース環境に新しいシャードを追加することによって、スケール・アウトしたり、フォルト・トレランスを向上させたりできます。再シャーディングおよびホット・スポット回避シャード数の変化によってトリガーされてデータがシャード間に再分散されるプロセスを再シャーディングと呼びます。自動再シャーディングは、システム管理のシャーディング方法の機能であり、SDBに柔軟なスケーラビリティを提供します。プールからのシャードの削除シャードにあるデータを失うことなくシャード・データベース環境からシャードを一時的または永続的に削除することが必要となる場合があります。スタンバイ・シャードの追加Data Guardのスタンバイ・シャードをOracle Sharding環境に追加できます。ただし、制限があります。Oracle Enterprise Manager Cloud Controlを使用したシャードの管理Oracle Enterprise Manager Cloud Controlを使用して、データベース・シャードを管理できますGDSCTLを使用したシャードの管理GDSCTLコマンドライン・ユーティリティを使用して、Oracle Shardingデプロイメントのシャードを管理できます。


10.8.1 シャードの追加について

既存のシャード・データベース環境に新しいシャードを追加することによって、スケール・アウトし

183

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SBYDB-GUID-70C09F5B-90BE-4C8C-96A5-45A52E05D380





たり、フォルト・トレランスを向上させたりできます。

フォルト・トレランスのためには、少数の非常に大きいシャードを使用するより、多数の小さいシャードを使用するほうが効果的です。アプリケーションが長期間使用されてデータ量が増えた場合、1つ以上のシャードをSDBに追加して容量を増やすことができます。

シャード・データベースにシャードを追加するときに、環境がコンシステント・ハッシュによってシャーディングされている場合は、既存のシャードからのチャンクが新しいシャードに自動的に移動されて、シャード環境がリバランスされます。

ユーザー定義シャーディングを使用する場合、新しいシャードにデータを移入するには、GDSCTLのsplit chunkおよびmove chunkコマンドを使用して、既存のシャードから新しいシャードにチャンクを手動で移動する必要がある場合があります。

Oracle Enterprise Manager Cloud Controlを使用して、新しいシャードに移動するか、分割して移動するよい候補となるチャンクを識別できます。

環境にシャードを追加する場合は、スタンバイ・サーバーが準備完了状態であることを確認し、新しいシャードが配置された後に、move chunk操作に関係したすべてのシャードのバックアップを取得します。

親トピック: シャード管理

10.8.2 再シャーディングおよびホット・スポット回避

シャード数の変化によってトリガーされてデータがシャード間に再分散されるプロセスを再シャーディングと呼びます。自動再シャーディングは、システム管理のシャーディング方法の機能であり、SDBに柔軟なスケーラビリティを提供します。

ときには、SDBのデータを1つのシャードから他のシャードに移行する必要があります。シャード間のデータ移行は次のような場合に必要です。

SDBに対して1つ以上のシャードを追加または削除した場合

シャード間のデータ分散またはワークロード分散にスキューがある場合

シャード間のデータ移行の単位はチャンクです。チャンクでデータを移行することにより、異なるシャード・データベースの関連するデータが確実に一緒に移動されます。

SDBに対してシャードを追加または削除すると、複数のチャンクが移行されて、シャード間のチャンクとワークロードのバランスのとれた分散が維持されます。

シャーディング方法に応じて、再シャーディングが自動的に行われるか(システム管理)、ユーザーが指示します(コンポジット)。次の図は、3つのシャードを含むSDBにシャードを追加したときの自動再シャーディングの段階を示しています。

図 10-6 SDBの再シャーディング

184

「図10-6 SDBの再シャーディング」の説明

データまたはワークロードのスキューが発生したときに、シャード数を変更せずに、特定のチャンクを1つのシャードから他へ移動することもできます。この場合、ホット・スポットを回避するために、データベース管理者がチャンクの移動を開始できます。

RMAN増分バックアップ、トランスポータブル表領域およびOracle Notification Serviceテクノロジを使用して、アプリケーションの可用性へのチャンク移行の影響を最小限に抑えます。チャンク移行中、チャンクはオンラインのままです。短時間(数秒間)は、チャンクに格納されたデータが読取り専用アクセスのみになります。

FAN対応クライアントは、ソース・シャードでチャンクが読取り専用になる直前に通知を受信し、チャンク移行が完了して宛先シャードでチャンクが完全に使用可能になると、再度、通知を受信します。chunk read-onlyイベントを受信すると、クライアントはチャンク移行が完了するまで接続の試行を繰り返すか、ソース・チャンクの読取り専用チャンクにアクセスできます。後者の場合、チャンクに書き込もうとすると、ランタイム・エラーが発生します。

注意:

シャード・データベースの再シャーディング中にマルチシャード問合せを実行すると、エラーが発生する可能性があるため、マルチシャードのワークロード中に新しいシャードをデプロイしないことをお薦めします。

185

関連項目:

システム管理のSDBへのシャードの追加

シャーディング方法


10.8.3 プールからのシャードの削除

シャードにあるデータを失うことなく、シャード・データベース環境からシャードを一時的または永続的に削除することが必要となる場合があります。

たとえば、忙しい休日の後にシャード環境がスケール・ダウンされる場合、またはデータ・センター内のサーバーまたはインフラストラクチャを交換する場合、シャードの削除が必要となることがあります。シャードを削除する前に、すべてのチャンクをそのシャードからオンラインの状態に維持される他のシャードに移動する必要があります。それらを移動するときは、すべてのシャード間でデータおよびアクティビティのバランスが維持されるようにします。

シャードを一時的に削除するだけの場合は、保守が完了した後に簡単に識別して元に戻すことができるように、各シャードに移動したチャンクを追跡します。

関連項目:

チャンクの移動について

GDSCTL REMOVE SHARDコマンドの使用方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください


10.8.4 スタンバイ・シャードの追加

Data Guardのスタンバイ・シャードをOracle Sharding環境に追加できます。ただし、制限があります。

シャード・データベースのレプリケーション方法としてData Guardを使用する場合、Oracle Shardingでは、プライマリまたは物理スタンバイ・シャードの追加のみサポートします。新しいスタンバイをシャード・データベースに追加する場合、他のタイプのData Guardスタンバイ・データベースはサポートされません。ただし、すでにシャード・データベースの一部であるシャードは、物理スタンバイからスナップショット・スタンバイに変換できます。物理スタンバイからスナップショット・スタンバイに変換する場合、次の手順に従う必要があります。

1. GDSCTLコマンドSTOP SERVICEを使用して、シャードのすべてのグローバル・サービスを停止します。

2. GDSCTLコマンドDISABLE SERVICEを使用して、シャードのすべてのグローバル・サービスを無効化します。

3. Data Guardドキュメントで説明されている手順を使用して、シャードをスナップショット・スタンバイに変換します。

この時点で、シャードはシャード・データベースの一部のままですが、シャーディング・キーを使用する接続を受け入れません。

186

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-417F8D04-908C-4A35-A24E-7722742A09DB



データベースが物理スタンバイに逆変換される場合、グローバル・サービスを有効化して再開できます。シャードはシャード・データベースのアクティブなメンバーになります。

関連項目:

『Oracle Data Guard概要および管理』


10.8.5 Oracle Enterprise Manager Cloud Controlを使用したシャードの管理

Oracle Enterprise Manager Cloud Controlを使用してデータベース・シャードを管理できます

Cloud Controlを使用してシャードを管理するには、最初に検出する必要があります。各データベース・シャードはデータベース自体であるため、標準のCloud Controlデータベース検出プロシージャを使用できます。

次のトピックでは、Oracle Enterprise Manager Cloud Controlを使用したシャード管理について説明します。

シャードの検証Oracle Shardingデプロイメントに追加する前に、シャードを検証します。プライマリ・シャードの追加Oracle Enterprise Manager Cloud Controlを使用して、プライマリ・シャードをOracle Shardingデプロイメントに追加します。スタンバイ・シャードの追加Oracle Enterprise Manager Cloud Controlを使用して、スタンバイ・シャードをOracle Shardingデプロイメントに追加します。シャードのデプロイOracle Enterprise Manager Cloud Controlを使用して、Oracle Sharding環境に追加されているシャードをデプロイします。


10.8.5.1 シャードの検証

Oracle Shardingデプロイメントに追加する前に、シャードを検証します。

Oracle Shardingデプロイメントに追加する前に、Oracle Enterprise Manager Cloud Controlを使用してシャードを検証できます。デプロイメントした後にシャードを検証して、シャードのその後のライフサイクルでも設定が引き続き有効であることを確認することもできます。たとえば、ソフトウェアのアップグレード後に、既存のシャードを検証して、パラメータおよび構成が正しいことを確認できます。

Cloud Controlを使用してシャードを検証するには、Cloud Controlで監視している既存のターゲットである必要があります。

1. シャードグループ管理ページから、シャードグループ・ターゲット・ページの左上隅にある「シャードグループ」メニューを開き、「シャードの管理」を選択します。

2. 要求された場合、シャード・カタログ資格証明を入力し、「シャード・ディレクタ資格証明」で管理するシャード・ディレクタを選択し、シャード・ディレクタ・ホスト資格証明を選択してログインします。

187

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=SBYDB-GUID-CE30E2D6-5B53-4389-8B02-FC0F341C8C1A



3. リストからシャードを選択して、「検証」をクリックします。4. 「OK」をクリックして、シャードを検証することを確認します。5. ページ上部にある「情報」ボックスのリンクをクリックして、シャードのプロビジョニング・ステータスを表示します。

シャード検証スクリプトが正常に実行されると、出力にレポートされるエラーを確認します。

親トピック: Oracle Enterprise Manager Cloud Controlを使用したシャードの管理

10.8.5.2 プライマリ・シャードの追加

Oracle Enterprise Manager Cloud Controlを使用して、プライマリ・シャードをOracle Shardingデプロイメントに追加します。

プライマリ・シャードは、Cloud Controlで監視している既存のターゲットである必要があります。

Oracle Sharding環境に追加する前にシャードを検証することを強くお薦めします。Cloud Controlを使用してシャードを検証するか(「シャードの検証」を参照)、またはSQL*Plusを使用してシャードに対してDBMS_GSM_FIX.validateShardプロシージャを実行します(「シャードの検証」を参照)。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「プライマリ・シャードの追加」を選択します。


3. 「シャードされたデータベースにすべてのシャードをデプロイ」を選択して、シャード・データベース構成に追加されたすべてのシャードをデプロイします。

デプロイメント操作は、シャードの構成を検証し、最終構成手順を実行します。シャードはデプロイ後にのみ使用できます。

4. 「追加」をクリックします。5. 「シャードの詳細」ダイアログの「データベース」フィールドで、シャードを選択して、「選択」をクリックします。

6. コンポジットOracle Sharding環境で、シャードを追加するシャード領域を選択できます。7. 「OK」をクリックします8. 必要に応じてGSMUSER資格証明を入力し、「次」をクリックします。9. ADD SHARD操作が発生する時間を示し、「次」をクリックします。

即時: 確認後にシャードがプロビジョニングされます

後で: 隣接しているフィールドのカレンダ・ツールを使用して、シャードを追加するタイミングをスケジュールします

10. 追加するシャードの構成を確認し、「送信」をクリックします。11. ページ上部にある「情報」ボックスのリンクをクリックして、シャードのプロビジョニング・ステータスを表示します。

上記の手順の「シャードされたデータベースにすべてのシャードをデプロイ」を選択しなかった場合、シャードのデプロイ・タスクを使用して、Oracle Shardingデプロイメントにシャードをデプロイします。


188

10.8.5.3 スタンバイ・シャードの追加

Oracle Enterprise Manager Cloud Controlを使用して、スタンバイ・シャードをOracle Shardingデプロイメントに追加します。

スタンバイ・シャードは、Cloud Controlで監視している既存のターゲットである必要があります。

Oracle Sharding環境に追加する前にシャードを検証することを強くお薦めします。Cloud Controlを使用してシャードを検証するか(「シャードの検証」を参照)、またはSQL*Plusを使用してシャードに対してDBMS_GSM_FIX.validateShardプロシージャを実行します(「シャードの検証」を参照)。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「スタンバイ・シャードの追加」を選択します。


3. 「シャードされたデータベースにすべてのシャードをデプロイ」を選択して、シャード・データベース構成に追加されたすべてのシャードをデプロイします。

デプロイメント操作は、シャードの構成を検証し、最終構成手順を実行します。シャードはデプロイ後にのみ使用できます。

4. 新しいシャードが「プライマリ・シャード」リストのスタンバイとして動作するプライマリ・シャードを選択します。

5. 「追加」をクリックします。6. 「シャードの詳細」ダイアログの「データベース」フィールドで、スタンバイ・シャードを選択します。

7. シャードを追加するシャードグループを選択します。

選択したプライマリのスタンバイがまだ含まれていないシャードグループのみ表示されます。

8. 「OK」をクリックします9. 必要に応じてGSMUSER資格証明を入力し、「次」をクリックします。

10. ADD SHARD操作が発生する時間を示し、「次」をクリックします。

即時: 確認後にシャードがプロビジョニングされます

後で: 隣接しているフィールドのカレンダ・ツールを使用して、シャードを追加するタイミングをスケジュールします

11. 追加するシャードの構成を確認し、「送信」をクリックします。12. ページ上部にある「情報」ボックスのリンクをクリックして、シャードのプロビジョニング・ステータスを表示します。

上記の手順の「シャードされたデータベースにすべてのシャードをデプロイ」を選択しなかった場合、シャードのデプロイ・タスクを使用して、Oracle Shardingデプロイメントにシャードをデプロイします。


10.8.5.4 シャードのデプロイ

189

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Sharding環境に追加されているシャードをデプロイします。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「シャードのデプロイ」を選択します。


3. 「リバランスの実行」チェック・ボックスを選択して、シャードのデプロイ後に自動的にシャード間のデータを再配分します。

チャンクをシャードに手動で移動する場合、このボックスの選択を解除します。

4. 「送信」をクリックします5. ページ上部にある「情報」ボックスのリンクをクリックして、シャードのプロビジョニング・ステータスを表示します。


10.8.6 GDSCTLを使用したシャードの管理

GDSCTLコマンドライン・ユーティリティを使用して、Oracle Shardingデプロイメントのシャードを管理できます。

次のトピックでは、GDSCTLを使用したシャードの管理について説明します。

シャードの検証新しく作成したシャードをシャーディング構成に追加する前に、シャードがシャーディング環境用に正しく構成されていることを検証する必要があります。システム管理のSDBへのシャードの追加システム管理のSDBにシャードを追加すると、SDBを柔軟に拡張できます。システム管理のSDBのチャンクは、新しいシャードが追加された後に自動的にリバランスされます。シャードの置換シャードで障害が発生してリカバリ不能になった場合、またはその他の理由で新しいホストにシャードを移動する必要がある場合は、GDSCTLでADD SHARD -REPLACEコマンドを使用して、シャードを置き換えることができます。


10.8.6.1 シャードの検証

新しく作成したシャードをシャーディング構成に追加する前に、シャードがシャーディング環境用に正しく構成されていることを検証する必要があります。

ADD SHARDを実行する前に、シャードとして追加されるデータベースに対してvalidateShardプロシージャを実行します。validateShardプロシージャは、シャードとして正常に動作するために必要な初期化パラメータおよび特性がターゲット・データベースにあることを検証します。

validateShardプロシージャはターゲット・データベースを分析し、そのデータベースに対してGDSCTLADD SHARDを実行する前に対処する必要がある問題を報告します。validateShardプロシージャはデータベースまたはパラメータを変更しません。情報および起こり得る問題を報告するだけです。

190

validateShardプロシージャは、シャードをシャード・カタログに追加するときに使用するレプリケーション・テクノロジとしてData GuardとOracle GoldenGateのどちらかを指定するオプションのパラメータを1つ取ります。Data Guardを使用する場合は、validateShard('DG')を呼び出します。OracleGoldenGateを使用する場合は、validateShard('OGG')を使用します。validateShardにパラメータを渡さない場合のデフォルト値は、Data Guardです。

validateShardプロシージャは、シャードをデプロイメントした後に実行して、シャードのその後のライフサイクルでも設定が引き続き有効であることを確認することもできます。たとえば、ソフトウェアのアップグレード後またはシャードのデプロイメント後に、既存のシャードに対してvalidateShardを実行し、パラメータおよび構成が正しいことを確認できます。

次のようにvalidateShardを実行します。sqlplus / as sysdbaSQL> set serveroutput onSQL> execute dbms_gsm_fix.validateShard

出力例を次に示します。INFO: Data Guard shard validation requested.INFO: Database role is PRIMARY.INFO: Database name is DEN27B.INFO: Database unique name is den27b.INFO: Database ID is 718463507.INFO: Database open mode is READ WRITE.INFO: Database in archivelog mode.INFO: Flashback is on.INFO: Force logging is on.INFO: Database platform is Linux x86 64-bit.INFO: Database character set is WE8DEC. This value must match the character set of the catalog database.INFO: 'compatible' initialization parameter validated successfully.INFO: Database is not a multitenant container database.INFO: Database is using a server parameter file (spfile).INFO: db_create_file_dest set to: '<ORACLE_BASE>/oracle/dbs2'INFO: db_recovery_file_dest set to: '<ORACLE_BASE>/oracle/dbs2'INFO: db_files=1000. Must be greater than the number of chunks and/or tablespaces to be created in the shard.INFO: dg_broker_start set to TRUE.INFO: remote_login_passwordfile set to EXCLUSIVE.INFO: db_file_name_convert set to: '/dbs/dt, /dbs/bt, dbs2/DEN27D/, dbs2/DEN27B/'INFO: GSMUSER account validated successfully.INFO: DATA_PUMP_DIR is '<ORACLE_BASE>//oracle/dbs2'.

INFOがタグ付けされている行は、基本的に情報であり正しい設定であることを示しています。WARNINGがタグ付けされている行は、構成によって問題である場合と問題ではない場合があります。たとえば、Data Guardパラメータに関する問題が報告されても、構成にプライマリ・データベースのみが含まれている場合は、Data Guardの問題を無視できます。最後に、そのシャードをシャーディング構成にデプロイして正常に稼働させるには、ERRORタグが付けられている出力を修正する必要があります。

親トピック: GDSCTLを使用したシャードの管理

10.8.6.2 システム管理のSDBへのシャードの追加

システム管理のSDBにシャードを追加すると、SDBを柔軟に拡張できます。システム管理のSDBのチャンクは、新しいシャードが追加された後に自動的にリバランスされます。

新しいシャードのホストを準備するには、最初にシャード・データベース環境を準備したときと同じすべてのセットアップ手順(次の手順を含む)を行います。

191

Oracle Databaseソフトウェアのインストール

Oracle Shardingの管理およびルーティング層のセットアップの説明に従って、リモート・スケジューラ・エージェントを登録します

1. シャード・ディレクタのホストに接続して、環境変数を確認します。$ ssh os_user@shard_director_home$ env |grep ORAORACLE_BASE=/u01/app/oracleORACLE_HOME=/u01/app/oracle/product/18.0.0/gsmhome_1


3. 現在のシャードの構成を確認します。GDSCTL> config shardName Shard Group Status State Region Availability ---- ----------- ------ ----- ------ ------------ sh1 primary_shardgroup Ok Deployed region1 ONLINE sh2 standby_shardgroup Ok Deployed region2 READ_ONLY sh3 primary_shardgroup Ok Deployed region1 ONLINE sh4 standby_shardgroup Ok Deployed region2 READ_ONLY

4. 新しい各シャードのシャード・グループ、宛先および資格証明を指定します。

この例では、新しいシャードはshard5およびshard6という名前で、NETCAおよびDBCAのデフォルト・テンプレートが使用されています。GDSCTL> add invitednode shard5GDSCTL> create shard -shardgroup primary_shardgroup -destination shard5-credential os_credential -sys_password

GDSCTL> add invitednode shard6GDSCTL> create shard -shardgroup standby_shardgroup -destination shard6-credential os_credential -sys_password

シャードを作成するときに、前の例に示すようにcreate shardで-sys_passwordを使用してSYSのパスワードを設定することもできます。これにより、シャードが作成されてDEPLOYされたときに、SYSのパスワードが設定されます。

前述の例では、新しいシャードを作成するためにCREATE SHARDによる方法を使用しています。ADD SHARDコマンドを使用して事前構成済のシャードを追加するには、ADDINVITEDNODEの後で次のコマンドを実行します。GDSCTL> add shard –shardgroup primary_shardgroup–connect shard_host:TNS_listener_port/shard_database_name–pwd GSMUSER_password

追加されるシャードがPDBである場合は、ADD SHARDで-cdbオプションを使用して、PDBシャードが含まれているCDBを指定する必要があります。また、ADD SHARDコマンドの前にADD CDBを使用してカタログにCDBを追加する必要があります。ADD CDBおよびADD SHARDの構文は、OracleDatabase Global Data Services概要および管理ガイドを参照してください。

注意:

自動VNCR登録の詳細は、この注意を参照してください。

192

5. DEPLOYコマンドを実行して、シャードとレプリカを作成します。GDSCTL> deploy

6. 新しいシャードがデプロイされたことを確認します。GDSCTL> config shardName Shard Group Status State Region Availability ---- ----------- ------ ----- ------ ------------ sh1 primary_shardgroup Ok Deployed region1 ONLINEsh2 standby_shardgroup Ok Deployed region2 READ_ONLYsh3 primary_shardgroup Ok Deployed region1 ONLINEsh4 standby_shardgroup Ok Deployed region2 READ_ONLYsh5 primary_shardgroup Ok Deployed region1 ONLINEsh6 standby_shardgroup Ok Deployed region2 READ_ONLY

7. チャンク構成を1-2分ごとにチェックして、チャンクの自動リバランスの進行状況を表示します。$ gdsctl config chunks -show_Reshard

Chunks------------------------Database From To -------- ---- -- sh1 1 4 sh2 1 4 sh3 7 10sh4 7 10sh5 5 6 sh5 11 12sh6 5 6 sh6 11 12

Ongoing chunk movement------------------------Chunk Source Target status----- ------ ------ ------

8. シャード(データベース)が自動的に登録されたことを確認します。$ gdsctl databases

Database: "sh1" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region1 Service: "oltp_ro_srvc" Globally started: Y Started: N Scan: N Enabled: Y Preferred: Y Service: "oltp_rw_srvc" Globally started: Y Started: Y Scan: N Enabled: Y Preferred: Y Registered instances: cust_sdb%1Database: "sh2" Registered: Y State: Ok ONS: N. Role: PH_STNDBY Instances: 1 Region: region2 Service: "oltp_ro_srvc" Globally started: Y Started: Y Scan: N Enabled: Y Preferred: Y Service: "oltp_rw_srvc" Globally started: Y Started: N Scan: N Enabled: Y Preferred: Y Registered instances: cust_sdb%11Database: "sh3" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region1 Service: "oltp_ro_srvc" Globally started: Y Started: N Scan: N Enabled: Y Preferred: Y Service: "oltp_rw_srvc" Globally started: Y Started: Y Scan: N Enabled: Y Preferred: Y Registered instances: cust_sdb%21Database: "sh4" Registered: Y State: Ok ONS: N. Role: PH_STNDBY Instances: 1 Region: region2 Service: "oltp_ro_srvc" Globally started: Y Started: Y Scan: N Enabled: Y Preferred: Y Service: "oltp_rw_srvc" Globally started: Y Started: N Scan: N Enabled: Y Preferred: Y Registered instances: cust_sdb%31

193

Database: "sh5" Registered: Y State: Ok ONS: N. Role: PRIMARY Instances: 1 Region: region1 Service: "oltp_ro_srvc" Globally started: Y Started: N Scan: N Enabled: Y Preferred: Y Service: "oltp_rw_srvc" Globally started: Y Started: Y Scan: N Enabled: Y Preferred: Y Registered instances: cust_sdb%41Database: "sh6" Registered: Y State: Ok ONS: N. Role: PH_STNDBY Instances: 1 Region: region2 Service: "oltp_ro_srvc" Globally started: Y Started: Y Scan: N Enabled: Y Preferred: Y Service: "oltp_rw_srvc" Globally started: Y Started: N Scan: N Enabled: Y Preferred: Y Registered instances: cust_sdb%51

9. サービスが新しいシャードで自動的に起動されたことを確認します。$ gdsctl services

Service "oltp_ro_srvc.cust_sdb.oradbcloud" has 3 instance(s). Affinity: ANYWHERE Instance "cust_sdb%11", name: "sh2", db: "sh2", region: "region2", status: ready. Instance "cust_sdb%31", name: "sh4", db: "sh4", region: "region2", status: ready. Instance "cust_sdb%51", name: "sh6", db: "sh6", region: "region2", status: ready.Service "oltp_rw_srvc.cust_sdb.oradbcloud" has 3 instance(s). Affinity: ANYWHERE Instance "cust_sdb%1", name: "sh1", db: "sh1", region: "region1", status: ready. Instance "cust_sdb%21", name: "sh3", db: "sh3", region: "region1", status: ready. Instance "cust_sdb%41", name: "sh5", db: "sh5", region: "region1", status: ready.

関連項目:



10.8.6.3 シャードの置換

シャードで障害が発生してリカバリ不能になった場合、またはその他の理由で新しいホストにシャードを移動する必要がある場合は、GDSCTLでADD SHARD -REPLACEコマンドを使用して、シャードを置き換えることができます。

シャード・データベースに障害が発生し、同じホスト上で(RMANバックアップ/リストアなどの方法を使用して)データベースをリカバリできる場合は、-replaceパラメータを使用してシャードを置き換える必要はありません。シャードをローカルでリカバリできない場合や、なんらかの理由で別のホストまたはCDBにシャードを再配置する必要がある場合は、新しいホスト上にシャードのレプリカを作成できます。GDSCTLコマンドADD SHARDに-replaceオプションを指定すると、シャーディング構成を新しい情報で更新できます。

ADD SHARD -REPLACEを使用したシャードの置換が有用なケースを次に示します。

シャード・データベースが実行されていたサーバー(マシン)が修復不可能な損害を受け、これを置き換える必要がある場合

正常に機能しているサーバーを別の(たとえば、より強力な)サーバーに置き換える必要がある場合

PDB内のシャードが、あるCDBから別のCDBに再配置された場合

これらのいずれのケースでも、ADD SHARDを実行した後、シャードの数とシャード間のデータ分布は変更されず、シャードは同じデータを保持する別のシャードに置き換えられます。-replaceオプショ

194




ンを指定せずにADD SHARDを使用した場合は、これとは異なり、シャードの数が増加し、データが再分配されます。

ADD SHARD -REPLACEを実行すると、古いシャードのパラメータ(connect_stringやdb_unique_nameなど)は新しい値に置き換えられます。新しいデータベースには、障害が発生したデータベースとは異なるdb_unique_nameを付けることができます。Data Guardでは構成のすべてのメンバーに同じDBIDを付ける必要があるため、Data Guard構成内のスタンバイを置き換える場合は、新しいデータベースのDBIDが古いDBIDと一致している必要があります。

REPLACEを使用する前に

ADD SHARD -REPLACEを使用する前に、次の点を確認してください。

データベースが(RMANリストアなどのメソッドを使用して)正しくリストアされていること。新しいデータベース・シャードは、障害が発生したシャードと同じシャーディング・メタデータを持つ必要があります。間違ったシャードへの接続文字列を指定しないように、基本的な検証を実行してください。

障害の発生したシャードが、障害が発生する前にデプロイ済の状態だったこと。

障害の発生したシャードが、ADD SHARD -REPLACEコマンドの実行時に停止していること。

ファスト・スタート・フェイルオーバー(デフォルトで有効)が有効になっている場合は、ファスト・スタート・フェイルオーバー・オブザーバが実行されていること。

Data Guard環境でのシャードの置換

プライマリがまだ稼働している場合、ADD SHARD -REPLACEコマンドはスタンバイ・シャードを置き換える目的でのみ使用できます。障害が発生したプライマリ・シャードを置き換えるには、残りのいずれかのスタンバイがプライマリ・ロールに切り替わるまで待ってから、障害が発生したシャードを置き換えます。

切り替えができない(プライマリとすべてのスタンバイが停止している)場合は、プライマリから始めて、各メンバーに対してADD SHARD -REPLACEを実行する必要があります。これにより、白紙の状態から新しいブローカ構成が作成されます。

スタンバイが稼働していないMAXPROTECTIONモードでは、保護モードを維持するためにプライマリ・データベースが停止します。この場合、スタンバイが稼働していなければ、プライマリ・データベースをオープンできません。このシナリオで置換操作を処理するには、最初にデータベースをマウント・モードで起動し、DGMGRLを使用してData Guardの保護モードを(MAXAVAILABILITYまたはMAXPERFORMANCEに)ダウングレードする必要があります。保護モードを設定した後、プライマリ・データベースをオープンし、GDSCTLを使用して置換操作を実行します。置換操作の終了後は、DGMGRLを使用して保護モードを前のレベルに戻すことができます。

Data Guardでは構成のすべてのメンバーに同じDBIDを付ける必要があるため、Data Guard構成内のスタンバイを置き換える場合は、新しいデータベースのDBIDが古いDBIDと一致している必要があります。

例10-1 例1: 構成内にスタンバイがない場合のプライマリ・シャードの置換

次の例に示すように、初期構成には2つのプライマリ・シャードがデプロイされており、スタンバイはデプロイされていません。shdcは障害のシナリオで停止しているため、その可用性はダッシュ(-)で表示されています。

195

$ gdsctl config shard

Name Shard Group Status State Region Availability---- ----------- ------ ----- ------ ------------shdb dbs1 Ok Deployed east ONLINE shdc dbs1 Ok Deployed east -

リカバリするには、RMANなどを使用してバックアップからプライマリのレプリカを作成します。この例では、db_unique_name shddと接続文字列inst4を使用して新しいシャードが作成されています。これで、次のように古いシャードshdcを新しいシャードshardに置き換えることができます。$ gdsctl add shard -replace shdc -connect inst4 -pwd password

DB Unique Name: SHDD

次のようにして構成を確認できます。$ gdsctl config shard

Name Shard Group Status State Region Availability---- ----------- ------ ----- ------ ------------shdb dbs1 Ok Deployed east ONLINEshdd dbs1 Ok Deployed east ONLINE

例10-2 例2: スタンバイ・シャードの置換

構成にスタンバイ・シャードが含まれている場合は、プライマリ・シャードを置き換えることができないことに注意してください。このようなケースでプライマリに障害が発生した場合は、スタンバイのいずれかが自動切り替えによって新しいプライマリになった後で、置換操作を実行する必要があります。

初期構成には2つのシャードグループ(1つのプライマリと1つのスタンバイ)があり、それぞれに2つのシャードが含まれています。スタンバイshddが停止したときに、$ gdsctl config shard

Name Shard Group Status State Region Availability---- ----------- ------ ----- ------ ------------shdb dbs1 Ok Deployed east ONLINEshdc dbs1 Ok Deployed east ONLINEshdd dbs2 Ok Deployed east -shde dbs2 Ok Deployed east READ ONLY

新しいスタンバイを作成します。プライマリが実行されているため、この操作はFOR STANDBYオプションを指定したRMAN DUPLICATEコマンドを使用して実行する必要があります。新しいスタンバイshdfの準備が完了したら、次のように古いシャードshddを置き換えます。$ gdsctl add shard -replace shdd -connect inst6 -pwd password

DB Unique Name: shdf

次のようにして構成を確認できます。$ gdsctl config shard

Name Shard Group Status State Region Availability---- ----------- ------ ----- ------ ------------shdb dbs1 Ok Deployed east ONLINEshdc dbs1 Ok Deployed east ONLINEshde dbs2 Ok Deployed east READ ONLYshdf dbs2 Ok Deployed east READ ONLY

Oracle GoldenGate環境でのシャードの置換

GDSCTLコマンドのオプションADD SHARD -REPLACEは、Oracle GoldenGateではサポートされてい

196

ません。

一般的なエラー

ORA-03770: 不正なシャードが置換に指定されています

このエラーは、置換操作で指定されたシャードが元のシャードのレプリカでない場合にスローされます。具体的には、シャーディング・メタデータがこのシャードのシャード・カタログに格納されているメタデータと一致しません。データベースが(できればRMANを使用して)正しくコピーされたことを確認してください。これは包括的なチェックではありません。レプリカが正しく作成されたことを前提としています。

ORA-03768: 置換対象のデータベースがまだ稼働しています: shardc

add shard -replaceコマンドを実行するときは、置換対象のデータベースを停止する必要があります。GDSCTLコマンドconfig shardの出力で、これを確認してください。シャードに障害が発生したにもかかわらず、出力にONLINEと表示される場合は、しばらく(2分程度)待ってから再試行してください。

関連項目:

Oracle Database Global Data Services概要および管理ガイド(ADD SHARDコマンドの詳細)


10.9 チャンク管理Oracle Enterprise Manager Cloud ControlおよびGDSCTLを使用したOracle Shardingデプロイメントのチャンクを管理できます。

次のトピックでは、チャンク管理の概念およびタスクについて説明します。

チャンクの移動についてチャンクをあるシャードから別のシャードに移動することが必要となる場合があります。シャード環境のスケーラビリティを維持するには、すべてのシャード間で負荷とアクティビティが均等に配分されるように維持することが重要です。チャンクの移動Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントの1つのシャードから他のシャードにチャンクを移動できます。チャンクの分割についてチャンクが大きくなりすぎた場合や、チャンクの一部のみを別のシャードに移行する必要がある場合は、シャード・データベースのチャンクを分割する必要があります。チャンクの分割Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのチャンクを分割できます。


10.9.1 チャンクの移動について

チャンクをあるシャードから別のシャードに移動することが必要となる場合があります。シャード環境のスケーラビリティを維持するには、すべてのシャード間で負荷とアクティビティが均等に配分さ

197



れるように維持することが重要です。

コンポジットSDBの環境が長期間使用されると、一部のシャードがよりアクティブになり、他のシャードよりデータが多くなります。環境内のバランスを保つために、よりアクティブなサーバーからアクティブではないサーバーにチャンクを移動する必要があります。チャンクを移動する理由は他にもあります。

あるシャードが他のシャードよりアクティブになった場合は、よりアクティブではないシャードにチャンクを移動して、環境内で負荷が均等に配分されるようにできます。

範囲、リストまたはコンポジット・シャーディングを使用しているときに、シャードをシャードグループに追加する場合。

範囲、リストまたはコンポジット・シャーディングを使用しているときに、シャードグループからシャードを削除する場合。

チャンクを分割したら、分割されたチャンクのいずれかを新しいシャードに移動することを多くの場合お薦めします。

スケーラビリティを維持するためにシャードを移動する場合、チャンクの最適なターゲットはよりアクティブではないシャード、またはより少ないデータがあるシャードです。Oracle EnterpriseManagerおよびAWRのレポートは、シャード間のアクティビティの配分を識別するため、およびチャンクの移動のよい候補となるシャードを識別するために役立ちます。

注意:

チャンクをあるシャードから別のシャードに移動する場合は、その操作に関係するデータベース(チャンクの移動のソースおよびターゲットの両方)のフル・バックアップを取得する必要があります。

関連項目:

GDSCTL MOVE CHUNKコマンドの使用方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください

親トピック: チャンク管理

10.9.2 チャンクの移動

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントの1つのシャードから他のシャードにチャンクを移動できます。

1. シャード領域管理ページから、シャード・データベース・ターゲット・ページの左上隅にある「シャード領域」メニューを開き、「シャードグループの管理」を選択します。

2. リストのシャードグループを選択して、「チャンクの移動」をクリックします。3. 「チャンクの移動」ダイアログで、チャンクを移動するソース・シャードと宛先シャードを選択します。

4. オプションのいずれかを選択して、移動するチャンクを選択します。

IDリストの入力: チャンクID番号のカンマ区切りリストを入力します

表からIDを選択: 表のチャンクIDをクリックします

198

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-79AC416D-E338-446A-AFB1-74137C63F974



5. チャンクの移動が発生する時間を示します。

即時: 確認後にチャンクの移動がプロビジョニングされます

後で: 隣接しているフィールドのカレンダ・ツールを使用して、チャンクを移動するタイミングをスケジュールします

6. 「OK」をクリックします7. ページ上部にある「情報」ボックスのリンクをクリックして、チャンク移動のプロビジョニング・ステータスを表示します。


10.9.3 チャンクの分割について

チャンクが大きくなりすぎた場合や、チャンクの一部のみを別のシャードに移行する必要がある場合は、シャード・データベースのチャンクを分割する必要があります。

Oracle Shardingはチャンクのオンライン分割をサポートします。理論上は、各シャードに1つのチャンクを作成し、データ移行が必要になるたびに分割できます。ただし、チャンクの分割はデータの可用性に影響しないものの、分割するパーティションのすべての行をスキャンしてから、1行ずつ新しいパーティションに挿入するため、時間がかかり、CPUにも負荷がかかる操作です。コンポジット・シャーディングの場合、チャンクの分割には時間がかかり、シャード・キーまたはスーパー・シャード・キーの新しい値を再定義するために停止時間が必要となることがあります。

したがって、各シャードに事前に複数のチャンクを作成し、次のいずれかの場合に分割することをお薦めします。再シャーディング中にデータをバランスよく分散するにはチャンク数が足りない場合、または特定のチャンクがホット・スポットになっている場合です。

システム管理のシャーディングの場合でも、単一のチャンクが他のチャンクより大きくなったり、よりアクティブになったりすることがあります。この場合は、そのチャンクを分割し、分割されたチャンクのいずれかが自動再シャーディングによって別のシャードに移動されることを許可すると、環境内のデータおよびアクティビティがより均等に配分されるように維持されます。

Oracle Enterprise Managerのヒート・マップには、どのチャンクが他のチャンクよりもアクティブになっているかが表示されます。この機能を使用してどのチャンクを分割できるかを識別し、分割されたチャンクのいずれかを別のシャードに移動して環境をリバランスできます。

関連項目:

GDSCTL SPLIT CHUNKコマンドの使用方法の詳細は、Oracle Database Global Data Services概要および管理ガイドを参照してください


10.9.4 チャンクの分割

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのチャンクを分割できます。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「シャード領域」を選択します。

199

https://www.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/19/shard&id=GSMUG-GUID-3FAB0646-22CD-444C-92EF-72B955C4C69E




3. リストのシャード領域を選択して、「チャンクの分割」をクリックします。4. オプションのいずれかを選択して、分割するチャンクを選択します。

IDリストの入力: チャンクID番号のカンマ区切りリストを入力します

表からIDを選択: 表のチャンクIDをクリックします

5. チャンクの分割が発生する時間を示します。

即時: 確認後にチャンクの分割がプロビジョニングされます

後で: 隣接しているフィールドのカレンダ・ツールを使用して、チャンクを分割するタイミングをスケジュールします

6. 「OK」をクリックします7. ページ上部にある「情報」ボックスのリンクをクリックして、チャンク分割のプロビジョニング・ステータスを表示します。

チャンクを正常に分割すると、チャンクの数が「シャード領域」リストで更新されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。


10.10 シャード・ディレクタ管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのシャード・ディレクタを追加、編集および削除できます。

次の各項では、シャード・ディレクタの管理タスクについて説明します。

シャード・ディレクタの作成Oracle Enterprise Manager Cloud Controlを使用して、シャード・ディレクタをOracle Shardingデプロイメントに作成して追加します。シャード・ディレクタ構成の編集Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・ディレクタ構成を編集します。シャード・ディレクタの削除Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントからシャード・ディレクタを削除します。


10.10.1 シャード・ディレクタの作成

Oracle Enterprise Manager Cloud Controlを使用して、シャード・ディレクタをOracle Shardingデプロイメントに作成して追加します。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「シャード・ディレクタ」を選択します。

200


3. 「作成」をクリックするか、リストからシャード・ディレクタを選択して「類似作成」をクリックします。

「作成」を選択すると、フィールドのデフォルトの構成値とともに「シャード・ディレクタの追加」ダイアログが開きます。

「類似作成」を選択すると、フィールドの選択されたシャード・ディレクタの構成値とともに「シャード・ディレクタの追加」ダイアログが開きます。リストからシャード・ディレクタを選択して「類似作成」オプションを有効化する必要があります。

4. 「シャード・ディレクタの追加」ダイアログの必要な情報を入力して、「OK」をクリックします。

注意:

シャード・ディレクタの作成後すぐに実行を開始しない場合、「作成後にシャード・ディレクタを開始」チェックボックスの選択を解除する必要があります。

5. 確認ダイアログで「OK」をクリックします。6. ページ上部にある「情報」ボックスのリンクをクリックして、シャード・ディレクタのプロビジョニング・ステータスを表示します。

シャード・ディレクタが正常に作成されると、「シャード・ディレクタ」リストに表示されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。

親トピック: シャード・ディレクタ管理

10.10.2 シャード・ディレクタ構成の編集

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・ディレクタ構成を編集します。

Cloud Controlのシャード・ディレクタのリージョン、ポート、ローカル・エンドポイントおよびホスト資格証明を変更できます。シャード・ディレクタ名、ホストまたはOracleホームは編集できません。



3. リストからシャード・ディレクタを選択して、「編集」をクリックします。

シャード・ディレクタ名、ホストまたはOracleホームは編集できないことに注意してください。

4. フィールドを編集してGSMCATUSERパスワードを入力し、「OK」をクリックします。5. ページ上部にある「情報」ボックスのリンクをクリックして、シャード・ディレクタ構成変更のプロビジョニング・ステータスを表示します。


201

10.10.3 シャード・ディレクタの削除

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントからシャード・ディレクタを削除します。

「シャード・ディレクタ」リストの列のチェック・マークに示されているように、削除するシャード・ディレクタが管理シャード・ディレクタの場合、削除する前に別のシャード・ディレクタを管理シャード・ディレクタに選択する必要があります。



3. リストからシャード・ディレクタを選択して、「削除」をクリックします。4. ページ上部にある「情報」ボックスのリンクをクリックして、シャード・ディレクタ削除のプロビジョニング・ステータスを表示します。

シャード・ディレクタが正常に削除されると、「シャード・ディレクタ」リストに表示されなくなります。変更内容を参照するには、ページのリフレッシュが必要な場合があります。


10.11 リージョン管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのリージョンを追加、編集および削除できます。

次の各項では、リージョンの管理タスクについて説明します。

リージョンの作成Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・データベース・リージョンを作成します。リージョン構成の編集Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・データベース・リージョン構成を編集します。リージョンの削除Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・データベース・リージョンを削除します。


10.11.1 リージョンの作成

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・データベース・リージョンを作成します。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「リージョン」を選択します。

2. 要求された場合、シャード・カタログ資格証明を入力し、「シャード・ディレクタ資格証明」で管理するシャード・ディレクタを選択し、シャード・ディレクタ・ホスト資格証明を選

202

択してログインします。3. 「作成」をクリックします。4. 「リージョンの作成」ダイアログのリージョンに一意の名前を入力します。5. オプションで、既存のリージョンからバディ・リージョンを選択します。6. 「OK」をクリックします7. ページ上部にある「情報」ボックスのリンクをクリックして、リージョンのプロビジョニング・ステータスを表示します。

リージョンが正常に作成されると、「リージョン」リストに表示されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。

親トピック: リージョン管理

10.11.2 リージョン構成の編集

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・データベース・リージョン構成を編集します。

Cloud Controlのシャード・データベース・リージョンのバディ・リージョンを変更できます。リージョン名は編集できません。


2. 要求された場合、シャード・カタログ資格証明を入力し、「シャード・ディレクタ資格証明」でシャード・ディレクタを選択し、シャード・ディレクタ・ホスト資格証明を選択してログインします。

3. リストからリージョンを選択して、「編集」をクリックします。4. バディ・リージョンを選択または削除して、「OK」をクリックします。5. ページ上部にある「情報」ボックスのリンクをクリックして、リージョン構成変更のプロビジョニング・ステータスを表示します。

リージョン構成が正常に更新されると、変更が「リージョン」リストに表示されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。


10.11.3 リージョンの削除

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャード・データベース・リージョンを削除します。


2. 要求された場合、シャード・カタログ資格証明を入力し、「シャード・ディレクタ資格証明」でシャード・ディレクタを選択し、シャード・ディレクタ・ホスト資格証明を選択してログインします。

3. リストからリージョンを選択して、「削除」をクリックします。4. ページ上部にある「情報」ボックスのリンクをクリックして、リージョン削除のプロビジョニング・ステータスを表示します。

リージョン構成が正常に削除されると、変更が「リージョン」リストに表示されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。

203


10.12 シャード領域管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのシャード領域を追加、編集および削除できます。

次の各項では、シャード領域の管理タスクについて説明します。

シャード領域の作成Oracle Enterprise Manager Cloud Controlを使用して、コンポジットOracle Shardingデプロイメントのシャード領域を作成します。コンポジット・シャード・データベースへのシャード領域の追加新しいシャード領域の作成、シャード領域へのシャードの追加、新しいシャード領域での表領域セットの作成、追加したシャード領域のシャード表へのパーティションセットの追加について説明します。次に、表内のパーティションが、対応する表領域に新しく追加されたシャードに作成されていることを確認します。


10.12.1 シャード領域の作成

Oracle Enterprise Manager Cloud Controlを使用して、コンポジットOracle Shardingデプロイメントのシャード領域を作成します。

コンポジット方法を使用してシャードされるデータベースのみ、複数のシャード領域を格納できます。システム管理のシャード・データベースは、1つのシャード領域のみ格納できます。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「シャード領域」を選択します。


3. 「作成」をクリックします。

注意:

このオプションは、システム管理のシャード・データベースのシャード領域ページで無効化されます。

4. 「シャード領域の追加」ダイアログのフィールドの値を入力して、「OK」をクリックします。

名前: シャード領域の一意の名前を入力します(必須)

チャンク: シャード領域に作成されるチャンクの数を入力します(デフォルトは120です)

保護モード: Data Guard保護モードを選択します(デフォルトは「最大パフォーマンス」です)

5. ページ上部にある「情報」ボックスのリンクをクリックして、シャード領域のプロビジョニング・ステータスを表示します。

シャード領域が正常に作成されると、「シャード領域」リストに表示されます。更新内容を参照する

204

には、ページのリフレッシュが必要な場合があります。

親トピック: シャード領域管理

10.12.2 コンポジット・シャード・データベースへのシャード領域の追加

新しいシャード領域の作成、シャード領域へのシャードの追加、新しいシャード領域での表領域セットの作成、追加したシャード領域のシャード表へのパーティションセットの追加について説明します。次に、表内のパーティションが、対応する表領域に新しく追加されたシャードに作成されていることを確認します。

既存のシャード・データベースに新しいシャード領域を追加するには、コンポジット・シャード・データベースがデプロイされ、すべてのDDLがシャードに伝播されていることを確認してください。

1. 新しいシャード領域を作成し、シャード領域にシャードを追加し、環境をデプロイします。a. シャード・カタログ・データベースに接続します。

GDSCTL> connect mysdbadmin/mysdbadmin_password

b. シャード領域を追加し、シャードグループをシャード領域に追加します。GDSCTL> add shardspace -chunks 8 -shardspace cust_asiaGDSCTL> add shardgroup -shardspace cust_asia -shardgroup asia_shgrp1 -deploy_as primary -region region3

c. シャードを追加しますGDSCTL> add shard -shardgroup asia_shgrp1 –connect shard_host:TNS_listener_port/shard_database_name –pwd GSMUSER_passwordGDSCTL> add shard asia_shgrp1 –connect shard_host:TNS_listener_port/shard_database_name –pwd GSMUSER_password

d. 環境をデプロイします。GDSCTL> deploy

DEPLOYを実行すると、以前のすべてのDDLが新しいシャードでリプレイされ、すべての表が作成されます。パーティションは、デフォルトのSYS_SHARD_TS表領域に作成されます。

2. シャード・カタログでシャード領域用の表領域セットを作成し、シャード・セットをシャード・ルート表に追加します。

a. 表領域セットを作成します。SQL> CREATE TABLESPACE SET TSP_SET_3 in shardspace cust_asia using template (datafile size 100m autoextend on next 10M maxsize unlimited extent management local segment space management auto );

b. パーティションセットを追加します。SQL> ALTER table customers add PARTITIONSET asia VALUES ('ASIA”') TABLESPACE SET TSP_SET_3 ;

c. LOBが存在する場合は、lobの表領域セットを作成し、add partitionsetコマンドでLOB記憶域情報を記述します。SQL> alter table customers add partitionset asia VALUES ('ASIA') tablespace set TSP_SET_3 lob(docn) store as (tablespace set LOBTSP_SET_4)) ;

d. ルート表にサブパーティションが含まれる場合、ストアを句として使用して、サブパーティションの表領域セットを指定します。

205

SQL> alter table customers add partitionset asia VALUES ('ASIA') tablespace set TSP_SET_3 subpartitions store in(SUB_TSP_SET_1, SUB_TSP_SET_2);

ADD PARTITIONSETコマンドは、子表を適切な表領域に移動します。3. 新しいシャード領域内のパーティションが新しい表領域に移動されていることを確認します。

新しいシャードに接続し、パーティションが新しい表領域セットに作成されていることを確認します。SQL> select table_name, partition_name, tablespace_name, read_only from dba_tab_partitions;

親トピック: シャード領域管理

10.13 シャードグループ管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのシャードグループを追加、編集および削除できます。

次の各項では、シャードグループの管理タスクについて説明します。

シャードグループの作成Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャードグループを作成します。


10.13.1 シャードグループの作成

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのシャードグループを作成します。

1. シャードグループを追加するシャード領域を選択します。2. シャード領域ターゲット・ページの左上隅にある「シャード領域」メニューを開き、「シャードグループの管理」を選択します。

3. 「作成」をクリックします。4. 「シャードグループの作成」ダイアログで値を入力して、「OK」をクリックします。5. ページ上部にある「情報」ボックスのリンクをクリックして、シャードグループのプロビジョニング・ステータスを表示します。

たとえば、前述のスクリーンショットの入力された値を使用して、次のコマンドを実行します。GDSCTL Command: ADD SHARDGROUP -SHARDGROUP 'north' -SHARDSPACE 'shardspaceora' -REGION 'north' -DEPLOY_AS 'STANDBY'

シャードグループが正常に作成されると、「シャードグループの管理」リストに表示されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。

親トピック: シャードグループ管理

10.14 サービス管理Oracle Enterprise Manager Cloud Controlを使用したOracle Shardingデプロイメントのサービスを管理で

206

きます。

Oracle Shardingサービスを管理するには、シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「サービス」を選択します。サービスページで、サービスのリストの上部にあるコントロールを使用して、サービスを起動、停止、有効化、無効化、作成、編集および削除できます。

サービスを選択すると、サービスを実行しているホストおよびシャード、ステータス、状態およびそれらの各インスタンスのData Guardロールを表示するサービス詳細リストが開きます。このリストのシャードを選択すると、個々のシャードのサービスを有効化、無効化、起動および停止できます。

次の各項では、サービスの管理タスクについて説明します。

サービスの作成Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのサービスを作成します。


10.14.1 サービスの作成

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Shardingデプロイメントのサービスを作成します。

1. シャード・データベース・ターゲット・ページの左上隅にある「シャードされたデータベース」メニューを開き、「サービス」を選択します。


3. 「作成」をクリックするか、リストからサービスを選択して「類似作成」をクリックします。

「作成」を選択すると、フィールドのデフォルトの構成値とともに「サービスの作成」ダイアログが開きます。

「類似作成」を選択すると、フィールドの選択されたサービスの構成値とともに「サービス{0}の類似作成」ダイアログが開きます。リストからサービスを選択して「類似作成」オプションを有効化する必要があります。

4. ダイアログに必要な情報を入力し、「OK」をクリックします。

注意:

サービスの作成後すぐに実行を開始しない場合、「作成後にすべてのシャードでサービスを開始します。」チェックボックスの選択を解除する必要があります。

5. ページ上部にある「情報」ボックスのリンクをクリックして、サービスのプロビジョニング・ステータスを表示します。

サービスが正常に作成されると、「サービス」リストに表示されます。更新内容を参照するには、ページのリフレッシュが必要な場合があります。

親トピック: サービス管理

207


1. Oracle Shardingの使用2. Oracle Shardingのトラブルシューティング

11 Oracle Shardingのトラブルシューティングトレースの有効化、ログとトレース・ファイルの検索、および一般的な問題のトラブルシューティングを行うことができます。

次の各項では、Oracle Shardingのトラブルシューティングについて詳細に説明します。

Oracle Shardingのトレースおよびデバッグ情報次の各項では、トレースを有効化する方法とログを見つける方法について説明します。シャード・データベースの一般的なエラー・パターンと解決Oracle Shardingの一般的なエラーをトラブルシューティングする方法の詳細は、次の各項を参照してください。

11.1 Oracle Shardingのトレースおよびデバッグ情報

次の各項では、トレースを有効化する方法とログを見つける方法について説明します。

Oracle Shardingに対するトレースの有効化シャード・データベース内の問題を追跡するため、PL/SQLトレースを有効にします。Oracle Shardingのアラート・ログおよびトレース・ファイルの検索場所Oracle Sharding環境には、トレース・ファイルとアラート・ログを検索する場所がいくつかあります。

親トピック: Oracle Shardingのトラブルシューティング

11.1.1 Oracle Shardingに対するトレースの有効化

シャード・データベース内の問題を追跡するため、PL/SQLトレースを有効にします。

完全なトレースを取得するには、次に示すようにGWM_TRACEレベルを設定します。次の文を実行すると、ただちにトレースが有効になりますが、データベースを再起動するとトレースは無効になります。ALTER SYSTEM SET EVENTS 'immediate trace name GWM_TRACE level 7';

次の文を実行すると、永続的に動作するトレースが有効になりますが、データベースを再起動しないと起動しません。ALTER SYSTEM SET EVENT='10798 trace name context forever, level 7' SCOPE=spfile;

前述の両方のトレースを完全に設定することをお薦めします。

Oracle Sharding環境のすべてをトレースするには、シャード・カタログとすべてのシャードでトレースを有効にする必要があります。トレースは、シャード・カタログのGDSCTLセッションまたは個々のシャードでシャード・ディレクタ(GSMとも呼びます)によって作成されたセッションのRDBMSセッション・トレース・ファイルに書き込まれます。

208

親トピック: Oracle Shardingのトレースおよびデバッグ情報

11.1.2 Oracle Shardingのアラート・ログおよびトレース・ファイルの検索場所

Oracle Sharding環境には、トレース・ファイルとアラート・ログを検索する場所がいくつかあります。

diag/rdbms/..にある標準RDBMSトレース・ファイルには、トレース出力が格納されます。

「deploy」の出力は、ジョブ・キューのトレース・ファイルdb_unique_name_jXXX_PID.trcに格納されます。

他のGDSCTLコマンドの出力は、使用される接続文字列に応じて、共有サーバー・トレース・ファイルdb_unique_name_sXXX_PID.trcまたは専用トレース・ファイルdb_unique_name_ora_PID.trcのいずれかに格納されます。

通常、カタログおよびシャードへの接続の多くに共有サーバーが使用されるため、トレースはSID_s00*.trcという名前の共有サーバー・トレース・ファイルに含まれています。

GDSCTLには、ステータスおよびエラー情報を表示できるコマンドがいくつか用意されています。

シャード・ディレクタ(GSM)のトレース・ファイルとログ・ファイルの場所を表示するには、GDSCTLSTATUS GSMを使用します。GDSCTL> statusAlias SHARDDIRECTOR1Version 18.0.0.0.0Start Date 25-FEB-2016 07:27:39Trace Level supportListener Log File /u01/app/oracle/diag/gsm/slc05abw/sharddirector1/alert/log.xmlListener Trace File /u01/app/oracle/diag/gsm/slc05abw/sharddirector1/trace/ora_10516_139939557888352.trcEndpoint summary (ADDRESS=(HOST=shard0)(PORT=1571)(PROTOCOL=tcp))GSMOCI Version 2.2.1Mastership NConnected to GDS catalog YProcess Id 10535Number of reconnections 0Pending tasks. Total 0Tasks in process. Total 0Regional Mastership TRUETotal messages published 71702Time Zone +00:00Orphaned Buddy Regions: NoneGDS region region1Network metrics: Region: region2 Network factor:0

非XMLバージョンのalert.logファイルは、次に示す/traceディレクトリにあります。/u01/app/oracle/diag/gsm/shard-director-node/sharddirector1/trace/alert*.log

GSMのログ出力を復号化するには、次のコマンドを使用します。GDSCTL> set _event 17 -config_only

マスター・シャード・ディレクタ(GSM)のトレース/アラート・ファイルには、すべての非同期コマンドまたはバックグラウンド・タスク(move chunk、split chunk、deploy、シャード登録、Data Guard構成、シャードDDLの実行など)のステータスとエラーが含まれています。

シャード・ディレクタのエラー・ステータスを含む保留中のAQリクエストを見つけるに

209

は、GDSCTL CONFIGを使用します。

進行中およびスケジュール済のチャンク移行を表示するには、GDSCTL CONFIG CHUNKS -show_reshardを使用します。

DDLが失敗したシャードを表示するには、GDSCTL SHOW DDL -failed_onlyを使用します。

特定のシャードのDDLエラー情報を表示するには、GDSCTL CONFIG SHARD -shard shard_nameを使用します。

親トピック: Oracle Shardingのトレースおよびデバッグ情報

11.2 シャード・データベースの一般的なエラー・パターンおよび解決Oracle Shardingの一般的なエラーをトラブルシューティングする方法の詳細は、次の各項を参照してください。

リモート・スケジューラ・エージェントの起動時の問題すべてのシャード・ホストでリモート・スケジューラ・エージェントの起動時に問題が発生した場合は、次の操作を試行します。シャード・ディレクタの起動時の障害シャード・ディレクタの起動時に問題が発生した場合は、次の操作を試行します。CREATE SHARDで作成されたシャードのエラーGDSCTL CREATE SHARDコマンドで作成されたシャードのDEPLOY実行中に発生したエラーについては、次の項目を確認します。CREATE SHARDの使用時の問題GDSCTL CREATE SHARDコマンドの使用時に発生した問題には、次のような解決策があります。deployコマンドの使用時の問題

親トピック: Oracle Shardingのトラブルシューティング

11.2.1 リモート・スケジューラ・エージェントの起動時の問題

すべてのシャード・ホストでリモート・スケジューラ・エージェントの起動時に問題が発生した場合は、次の操作を試行します。

スケジューラを起動するには、各シャード・サーバーのORACLE_HOMEに移動する必要があります。[oracle@shard2 ~]$ echo welcome | schagent -registerdatabase 192.0.2.24 8080Agent Registration Password?Failed to get agent Registration Info from db: No route to host

Solution: Disable firewall

service ipchains stopservice iptables stopchkconfig ipchains offchkconfig iptables off

親トピック: シャード・データベースの一般的なエラー・パターンおよび解決

11.2.2 シャード・ディレクタの起動時の障害

210

シャード・ディレクタの起動時に問題が発生した場合は、次の操作を試行します。

スケジューラを起動するには、各シャード・サーバーのORACLE_HOMEに移動する必要があります。GDSCTL>start gsm -gsm shardDGdirectorGSM-45054: GSM errorGSM-40070: GSM is not able to establish connection to GDS catalog

GSM alert log, /u01/app/oracle/diag/gsm/shard1/sharddgdirector/trace/alert_gds.logGSM-40112: OCI error. Code (-1). See GSMOCI trace for details.GSM-40122: OCI Catalog Error. Code: 12514. Message: ORA-12514: TNS:listener does not currently know of service requested in connect descriptorGSM-40112: OCI error. Code (-1). See GSMOCI trace for details.2017-04-20T22:50:22.496362+05:30Process 1 in GSM instance is downGSM shutdown is successfulGSM shutdown is in progressNOTE : if not message displayed in the GSM log then enable GSM trace level to 16 while adding GSM itself.

1. 起動に失敗した新規作成のシャード・ディレクタ(GSM)を削除します。GDSCTL> remove gsm -gsm shardDGdirector

2. トレース・レベル16を使用してシャード・ディレクタを追加します。GDSCTL> add gsm -gsm shardDGdirector -listener port_num -pwd gsmcatuser_password -catalog hostname:port_num:shard_catalog_name -region region1 -trace_level 16

3. シャード・カタログ・データベースがデフォルト以外のポート(1521以外)で実行されている場合は、リモート・リスナーを設定します。SQL> alter system set local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=port_num)))';


11.2.3 CREATE SHARDで作成されたシャードのエラー

GDSCTL CREATE SHARDコマンドで作成されたシャードのDEPLOY実行中に発生したエラーについては、次の項目を確認します。

シャード・ホスト上のリモート・スケジューラ・エージェントのログ

シャード・カタログのDBA_SCHEDULER_JOB_RUN_DETAILSビュー

シャード・ホスト上の$ORACLE_BASE/cfgtoollogsにあるNETCA/DBCAの出力ファイル


11.2.4 CREATE SHARDの使用時の問題

GDSCTL CREATE SHARDコマンドの使用時に発生した問題には、次のような解決策があります。

次のエラーを回避するには$ORACLE_BASE/oradataおよび$ORACLE_BASE/fast_recovery_areaディレクトリを作成する必要があるGDSCTL> create shard -shardgroup primary_shardgroup -destination che -osaccount oracle -ospassword oracle

211

GSM-45029: SQL errorORA-03710: directory does not exist or is not writeable at destination: $ORACLE_BASE/oradataORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 6920ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 4730ORA-06512: at line 1

GDSCTL>create shard -shardgroup primary_shardgroup -destination che -osaccount oracle -ospassword oracleGSM-45029: SQL errorORA-03710: directory does not exist or is not writeable at destination: $ORACLE_BASE/fast_recovery_areaORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 6920ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 4755ORA-06512: at line 1

解決策: すべてのシャード・ホスト上の$ORACLE_BASEの下に/oradataとfast_recovery_areaを作成します。

権限の問題GDSCTL>create shard -shardgroup primary_shardgroup -destination blr -credential credGSM-45029: SQL errorORA-02610: Remote job failed with error:EXTERNAL_LOG_ID="job_79126_3",USERNAME="oracle",STANDARD_ERROR="Launching external job failed: Login executable not setuid-root"ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 6920ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 4596ORA-06512: at line 1

解決策: 次のディレクトリに対するroot権限があることを確認します。chown root $ORACLE_HOME/bin/extjobchmod 4750 $ORACLE_HOME/bin/extjobchown root $ORACLE_HOME/rdbms/admin/externaljob.orachmod 640 $ORACLE_HOME/rdbms/admin/externaljob.orachown root $ORACLE_HOME/bin/jssuchmod 4750 $ORACLE_HOME/bin/jssu

CREATE SHARDでのエラーGDSCTL>create shard -shardgroup primary_shardgroup -destination mysql02 -osaccount oracle -ospassword oracleGSM-45029: SQL errorORA-03719: Shard character set does not match catalog character set.ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 7469ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 5770ORA-06512: at line 1

解決策: Javaのバージョンを確認します(シャード・カタログおよびすべてのシャード・サーバーで同じである必要があります)。rpm -qa|grep java


11.2.5 deployコマンドの使用時の問題

GDSCTL> deployGSM-45029: SQL errorORA-29273: HTTP request failedORA-06512: at "SYS.DBMS_ISCHED", line 3715ORA-06512: at "SYS.UTL_HTTP", line 1267ORA-29276: transfer timeout

212

ORA-06512: at "SYS.UTL_HTTP", line 651ORA-06512: at "SYS.UTL_HTTP", line 1257ORA-06512: at "SYS.DBMS_ISCHED", line 3708ORA-06512: at "SYS.DBMS_SCHEDULER", line 2609ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 14284ORA-06512: at line 1

解決策: $ORACLE_HOME/data/pendingjobsで正確なエラーを確認します。ウォレットに問題がある場合は、ORA-1017がスローされます。

1. 問題のあるシャード・ホスト上で、リモート・スケジューラ・エージェントを停止します。schagent -stop

2. データベース・ホーム上のウォレット・ディレクトリの名前を変更します。mv $ORACLE_HOME/data/wallet $ORACLE_HOME/data/wallet.old

3. リモート・スケジューラ・エージェントを起動すると、新しいウォレット・ディレクトリが作成されます。schagent -start schagent -status echo welcome | schagent -registerdatabase 10.10.10.10 8080


213


1. 索引

索引A B C D E F G H I K L M O P Q R S T U

A

概要 1.3アカウント

GSMROOTUSER 10.2.2GSMUSER 10.2.1

Active Data Guard 7.1.1利点 1.3アプリケーションの移行 9.7アーキテクチャ 1.3

B

メリット 1.2

C

シャーディングの候補 1.4CDB 8.1.2チャンク 2.1チャンク管理 10.9チャンク

移動 10.9.2分割 10.9.4

接続プール 6.3マルチシャード問合せでの一貫性レベル 6.2.5.1コーディネータ, マルチシャード問合せ 6.2.2

D

データ, ロード 9.2データの暗号化 8.10, 8.10.1Data Guard

Oracle Sharding 10.8.4データの移行 9.1, 9.6データの移行, ソースの準備 9.4

6.1.1データ・ルーティング

214

デプロイメントシャードの追加 8.1.1シャードの作成 8.1.1システム管理 8.7.1

直接ルーティング 6.1.1シャード・データベースの検出 10.3.2.1ダウングレード 10.7.3表の重複 2.3

E

暗号化データ 8.10, 8.10.1Enterprise Manager Cloud Control

Oracle Shardingの監視 10.3.2シャード・データベース検出 10.3.2.1

外部表 9.2

F

機能 1.3

G

GDSCTLADD SHARD 10.8.6.3

グローバルに一意の順序番号 2.7GoldenGate 7.3GSMROOTUSERアカウント 10.2.2GSMUSERアカウント 10.2.1

H

高可用性 7.1.1, 7.3

I

インストールシステム管理 8.7.1

K

215

キー・ベースのルーティング 6.1.1

L

データのロード 9.2

M

中間層ルーティング 6.3データの移行 9.1移行, アプリケーション 9.7移行, データ 9.6移行, 準備 9.5移行, スキーマ 9.3データの移行, ソースの準備 9.4シャードの移動 10.8.6.3MULTISHARD_QUERY_DATA_CONSISTENCY 6.2.5.1マルチシャード問合せの一貫性 6.2.5.1マルチシャード問合せの一貫性レベル 6.2.5.1マルチシャード問合せコーディネータ 6.2.2マルチテナント 8.1.2

O

Oracle Data Guard 7.1.1Oracle Enterprise Manager Cloud Control。

チャンク管理 10.9チャンク

移動 10.9.2分割 10.9.4

リージョン作成 10.11.1編集 10.11.2削除 10.11.3

リージョン管理 10.11サービス

作成 10.14.1サービスの管理 10.14シャード

追加 10.8.5.2, 10.8.5.3デプロイ 10.8.5.4検証 10.8.5.1

シャード・ディレクタ作成 10.10.1削除 10.10.3更新 10.10.2

シャード・ディレクタ管理 10.10

216

シャードグループ作成 10.13.1

シャードグループ管理 10.13シャード管理 10.8シャード領域

作成 10.12.1シャード領域管理 10.12

Oracle GoldenGate 7.1.1, 7.3Oracleマルチテナント 8.1.2Oracle Sharding

>NETのサポート 6.1.2概要 1.1シャードの追加 10.8.1アプリケーション開発 5.2バックアップとリカバリ 10.4チャンク管理 10.9チャンク 3.2

移動 10.9.2分割 10.9.4

Cloud Control 10.3.2コンポジット・シャーディング

メソッドコンポジット・シャーディング 4.3

構成 8.6Data Guardのスタンバイ 10.8.4データ・ルーティング

プロキシ・ルーティング 6.2.1DDL 2.5.1DDLの実行 2.5デプロイメント 8.1

コンポジットSDB 8.9.1ユーザー定義のSDB 8.8.1

Cloud Controlでの検出 10.3.2.1分散パーティショニング 3.1重複しているオブジェクト 2.4柔軟なスケーリング 10.8.6.2ハードウェア 8.2高可用性 7.1, 7.2ホット・スポット 10.8.2インストール


インストールシャード・ディレクタ 8.4

JDBCのサポート 6.1.2メソッド

システム管理 4.1監視 10.3, 10.3.1, 10.3.3Cloud Controlによる監視 10.3.2チャンクの移動 10.9.1マルチシャード問合せ 6.2.5ネットワーク 8.2

217

Oracle Call Interface API 6.1.2Oracleデータベースのインストール 8.3Oracle UCP API 6.1.2パーティション 3.2前提条件 8.2プロキシ・ルーティング 6.2.2.1, 6.2.3, 6.2.5リージョン

作成 10.11.1編集 10.11.2削除 10.11.3

リージョン管理 10.11シャードの削除 10.8.3レプリケーション 7.1, 7.2リクエストのルーティング

文レベル 6.2.3要件 8.2再シャーディング 10.8.2スケーリング 10.8.6.2スキーマ作成


スキーマ設計 2スキーマ設計の考慮事項 5.1サービス


追加 10.8.1, 10.8.5.2, 10.8.5.3デプロイ 10.8.5.4スタンバイ 10.8.4検証 10.8.5.1

シャード・カタログ作成 8.5


シャード・ディレクタ管理 10.10シャードグループ

作成 10.13.1シャードグループ管理 10.13シャード管理 10.8シャード

追加 10.8.6.2シャード領域

作成 10.12.1シャード領域管理 10.12シャード検証 10.8.6.1チャンクの分割 10.9.3SQL 2.5.1スタンバイ・シャード 10.8.4サブパーティション 4.4

218

システム管理 4.1表領域 3.2ユーザー定義

メソッドユーザー定義 4.2

シャードの検証 10.8.6.1Oracle Data Guard 7.1, 7.2Oracle GoldenGate 7.1

Oracle Universal Connection Pool, 中間層ルーティング 6.3概要 1.3

P

パラメータ設定 10.6パッチ適用 10.7.1PDB 8.1.2プロキシ・ルーティング 6.2.4

サポートされる問合せ形態 6.2.6

Q

問合せコーディネータ 6.2.2

R

参照表 2.3リージョン

作成 10.11.1編集 10.11.2削除 10.11.3

リージョン管理 10.11シャードの置換 10.8.6.3レプリケーション 7.3ルート表 2.2ルーティング

直接 6.1.1キー・ベース 6.1.1

S

スキーマの変更 10.5スキーマ作成

システム管理 8.7.2スキーマの移行 9.3セキュリティ 8.10, 8.10.1

219

順序番号, グローバルに一意 2.7サービス


追加 10.8.5.2, 10.8.5.3デプロイ 10.8.5.4検証 10.8.5.1


シャード・ディレクタ管理 10.10シャード・データベース(SDB) 1.1シャード・データベース検出 10.3.2.1シャード表 2.1シャード表 1.1シャードグループ

作成 10.13.1シャードグループ管理 10.13シャード管理 10.8シャードの置換 10.8.6.3シャード 1.1PDBとしてのシャード 8.1.2SHARDS句 10.3.3シャード領域

作成 10.12.1シャード領域, 追加 10.12.2シャード領域管理 10.12単一シャード問合せ 6.2.4スイム・レーン 6.3システム管理

デプロイメント 8.7.1スキーマ 8.7.2

システム・パラメータ 10.6

T

表ファミリ 2.2表, 参照 2.3表領域セット 2.1透過的データ暗号化 8.10, 8.10.1

U

一意の順序番号, グローバル 2.7アップグレード

順序 10.7.2 10.7.1アップグレード

220

oracle® database oracle shardingの使用, 19c · 2019-08-26 · oracle database...

Documents