トラブルシューティングのヒント
これらのヒントを使用して、問題のトラブルシューティングに必要なGlobally Distributed Databaseに関する情報を検出します。
配置前ネットワークの検証
いくつかのGDSCTLコマンドには、分散データベースの仕様およびデプロイ中にネットワーク構成の問題を可能なかぎり早く検出するための-validate_networkオプションがあります。
-validate_networkは、分散データベースの次のGDSCTLコマンドで使用できます:
-
add {invitednode | invitedsubnet} -
add shard -
deploy -
start gsm -
validate(-show_errorsも含む)
データ分散方法の確認
gdsctl config sdbを実行して、分散データベースで使用されているデータ分散(シャーディング)方法を確認します。
データ分散方法には、システム管理、コンポジット、ユーザー定義、直接ベースまたはフェデレーテッドがあります。
次に示すように、分散方法は、gdsctl config sdbの出力の「Shard type」の下に表示されます。
gdsctl> config sdb
GDS Pool administrators
------------------------
Replication Type
------------------------
Data Guard
Shard type
------------------------
System-managed
Shard spaces
------------------------
shd1
Services
------------------------
srv1レプリケーション・タイプの確認
gdsctl config sdbを実行して、分散データベースのシャード・レプリケーションに使用されている方法を確認します。
次に示すように、レプリケーション・タイプは、gdsctl config sdbの出力の「Replication Type」の下に表示されます。
gdsctl> config sdb
GDS Pool administrators
------------------------
Replication Type
------------------------
Data Guard
Shard type
------------------------
System-managed
Shard spaces
------------------------
shd1
Services
------------------------
srv1表19-1 config sdb出力のレプリケーション・タイプ
| レプリケーション・タイプ | 出力に表示される値 |
|---|---|
| Oracle Data Guard | Data Guard |
| Raft |
Oracle Data Guard保護モードの確認
DGMGRLに切り替えるのではなく、特定のシャード領域でgdsctl config shardspaceを実行して、GDSCTLセッションでOracle Data Guard保護モードを確認できます。
Data Guardは、MaxProtection、MaxAvailabilityおよびMaxPerformanceの3つの異なる保護モードで構成できます。
次に示すように、Data Guard保護モードは、gdsctl config shardspaceコマンド出力のPROTECTION MODEの下に表示されます。
GDSCTL> config shardspace -shardspace shd1
Shard Group Region Role
----------- ------ ----
dbs1 east Primary
PROTECTION_MODE Chunks
--------------- ------
MaxProtection 6キーにマップされているシャードの確認
gdsctl config chunks -keyを実行して、シャーディング・キーにマップされているシャードを確認できます。
例1: 単一の表ファミリ
次の例では、分散データベース構成に1つの表ファミリのみが存在し、表はデータ型番号でパーティション化(シャード)されています。
この例では、ユーザーは、チャンク・シャーディング・キー値「2」のマップ先を確認します。出力では、シャーディング・キー2がチャンク「3」にマップされ、データベース「aime1b」に存在することが示されています。
GDSCTL> config chunks -key 2
Range Definition
------------------------
Chunks Range Definition
------ ----------------
3 1431655764-2147483646
Databases
------------------------
aime1b同様に、これは、シャーディングが行われるすべてのデータ型に対して実行できます。また、カンマ区切り値を使用して複数列のシャーディング・キーを確認することもできます。
範囲定義はハッシュ値の範囲であり、無視できます。
例2: 複数の表ファミリ
複数の表ファミリ構成で、オプション-table_familyを追加して、指定されたシャーディング・キーが属する表ファミリを指定します。
config chunksコマンドにより、トポロジ内のすべてのシャードグループのシャードがリストされます。この例では、データベース(シャード)リストに「aime1e」が追加されていることからわかるように、Data Guardスタンバイ・シャードグループもリストされています。
GDSCTL> config chunks -key 1 -table_family testuserfam3.customersfam1
Range Definition
------------------------
Chunks Range Definition
------ ----------------
1 0-357913941
Databases
------------------------
aime1b
aime1e例3: 複数列のシャーディング・キーの指定
表が複数列によってシャードされている場合は、次に示すように、シャーディング・キー値をカンマ区切りリストとして指定します。
GDSCTL> config chunks -key 10,mary,2010-04-04
Range Definition
------------------------
Chunks Range Definition
------ ----------------
4 1288490187-1717986916
Databases
------------------------
aime1b
aime1eシャード操作モード(読取り専用または読取り/書込み)の確認
gdsctl config chunks -cross_shardを実行して、シャードが読取り専用モードで実行されているか、または読取り/書込みモードで実行されているかを確認できます。
gdsctl config chunks -cross_shardコマンド出力には、次に示すように、読取り専用モードで実行されているシャード、および読取り/書込みモードで実行されているシャードが「Database」の下にリストされます。このコマンドにより、これらのシャードのチャンク範囲もリストされます。
gdsctl config chunks -cross_shard
Read-Only cross shard targets
------------------------
Database From To
-------- ---- --
tst3b_cdb2_pdb1 1 3
tst3c_cdb3_pdb1 9 10
tst3d_cdb2_pdb1 4 5
tst3e_cdb3_pdb1 6 8
Chunks not offered for cross-shard
------------------------
Shard space From To
----------- ---- --
Read-Write cross-shard targets
------------------------
Database From To
-------- ---- --
tst3b_cdb2_pdb1 1 5
tst3c_cdb3_pdb1 6 10
Chunks not offered for Read-Write cross-shard activity
------------------------
Data N/ADDLテキストの確認
gdsctl show ddl -ddl ddl_idを実行して、指定されたDDLのテキストを取得します。
次に示すように、DDL数値識別子は-ddl ddl_idを使用して指定され、特定のDDLのテキストおよびその他の詳細を取得します。
gdsctl show ddl -ddl 5
DDL Text: CREATE SHARDED TABLE Customers ( CustNo NUMBER NOT NULL, Name VARCHAR2(50), Address VARCHAR2(250), Location VARCHAR2(20), Class VARCHAR2(3), CONSTRAINT RootPK PRIMARY KEY(CustNo)) PARTITION BY CONSISTENT HASH (CustNo) PARTITIONS AUTO TABLESPACE SET ts1
Owner: TESTUSER1
Object name: CUSTOMERS
DDL type: C
Obsolete: 0
Failed shards:ノート:
show ddlコマンドの出力は切り捨てられることがあります。出力内容の完全なテキストを表示するには、シャード・カタログでSELECT ddl_text FROM gsmadmin_internal.ddl_requestsを実行します。
チャンク移行ステータスの確認
gdsctl config chunks -show_reshardを実行して、チャンク移行のステータスを確認します。
チャンク移動は、ユーザーが開始したか内部的に開始されたか(増分デプロイ時)に関係なく、長時間実行される操作であるため、ステータスを確認する必要がある場合は、gdsctl config chunks -show_reshardを使用すると、移動が進行するにつれて、次のステータス・インジケータが表示されます。
-
empty - 進行中のチャンク移動がないことを示します
-
scheduled - チャンクは移動待ちです。これは、別のチャンク移動の完了を待機しているか、なんらかのエラーのために移動が開始されなかったためです
-
running - 現在進行中です
-
failed - チャンク移動に失敗しました。詳細は、GSMトレース、およびソース・データベースとターゲット・データベースのトレースを確認してください。
次の例では、コマンド出力の「Ongoing chunk movement」表にチャンク移動ステータスが表示されています。
gdsctl config chunks -show_reshard
Chunks
------------------------
Database From To
-------- ---- --
tst3b_cdb2_pdb1 1 6
tst3c_cdb3_pdb1 7 10
tst3d_cdb2_pdb1 1 6
tst3e_cdb3_pdb1 7 10
Ongoing chunk movement
------------------------
Chunk Source Target status
----- ------ ------ ------
7 tst3c_cdb3_pdb1 tst3b_cdb2_pdb1 Running
8 tst3c_cdb3_pdb1 tst3b_cdb2_pdb1 scheduled
9 tst3c_cdb3_pdb1 tst3b_cdb2_pdb1 scheduled
10 tst3c_cdb3_pdb1 tst3b_cdb2_pdb1 scheduled表タイプ(シャードまたは重複)の確認
SELECT TABLE_NAME,SHARDED,DUPLICATED FROM user_tables;を使用して、dba/all/user_tablesの表がシャードであるか、重複であるかを確認できます。
次の例では、列「S」は表がシャードかどうかを示し、列「D」は表が重複かどうかを示します。
SQL> select TABLE_NAME,SHARDED,DUPLICATED from user_tables;
TABLE_NAME S D
--------------- - -
CUSTOMERS Y N
DUP1 N Y
LINEITEMS Y N
MLOG$_DUP1 N N
ORDERS Y Nユーザー・タイプ(ローカルまたはALL_SHARD)の確認
dba/all/user_usersでユーザー名およびALL_SHARD列を選択することで、ローカル・ユーザーとして作成されたユーザー、および分散データベース・ユーザーを確認できます。
SQL> select USERNAME,ALL_SHARD from users_users where username='TESTUSER1';
USERNAME ALL_SHARD
--------------- ---------
TESTUSER1 YESシャード表領域として作成された表の識別
dba/all/user_tablespacesでTABLESPACE_NAME列およびCHUNK_TABLESPACE列を選択することで、シャード表に表領域が使用されているかどうかを確認できます。
シャード表の表領域である場合、dba/all/user_tablespacesのCHUNK_TABLESPACE列の値はYになります。
SQL> select TABLESPACE_NAME,CHUNK_TABLESPACE from user_tablespaces;
TABLESPACE_NAME C
------------------------------ -
SYSTEM N
SYSAUX N
TEMP N
SYSEXT N
TS1 YシャードDDLが有効か無効かの確認
現在のSQLセッションでシャードDDLが有効か無効かを確認できます。
これらの例は、シャードDDLを有効および無効にした後に、シャードDDLステータスを確認した結果を示しています。
SQL> alter session enable shard ddl;
Session altered.
SQL> select shard_ddl_status from v$session where AUDSID = userenv('SESSIONID');
SHARD_DD
--------
ENABLEDSQL> alter session disable shard ddl;
Session altered.
SQL> select shard_ddl_status from v$session where AUDSID = userenv('SESSIONID');
SHARD_DD
--------
DISABLEDシャーディング・キーによるデータのフィルタ処理
SHARD_QUERIES_RESTRICTED_BY_KEYパラメータを設定して、指定されたシャーディング・キーによるデータのフィルタ処理を有効または無効にできます。
パラメータSHARD_QUERIES_RESTRICTED_BY_KEYは、システム・レベルまたはセッション・レベルでALTERを使用して設定できます。有効にすると、DMLには、クライアント接続で設定された指定のSHARDING_KEYの選択データのみが表示されます。
次の例では、SHARDING_KEYが「1」と指定されたシャードを使用してクライアント接続が確立されています。ただし、クライアントがcustomers表でSELECTを実行すると、シャード内のその表内のすべての行が表示されます。
connection established for client with sharding_key=1
SQL> select * from customers order by custno;
CUSTNO NAME ADDRESS LOCATION CLA
---------- ---------- ---------- ---------- ---
1 John Oracle KM Bangalore A
50 Larry Oracle HQ SFO B
2 rows selected.
SQL>次に示すように、セッション・レベルのフィルタ処理を有効にすると、同じSELECT文の結果は、クライアント接続で指定されたSHARD_KEYに一致する単一行のみに制限されます。
SQL> alter session set shard_queries_restricted_by_key = true;
Session altered.
SQL> select current_shard_key from dual;
CURRENT_SHARD_KEY
-----------------
1
1 row selected.
SQL> select * from customers;
CUSTNO NAME ADDRESS LOCATION CLA
---------- ---------- ---------- ---------- ---
1 John Oracle KM Bangalore A