11 Oracle Shardingのトラブルシューティング
トレースの有効化、ログとトレース・ファイルの検索、および一般的な問題のトラブルシューティングを行うことができます。
次の各項では、Oracle Shardingのトラブルシューティングについて詳細に説明します。
トラブルシューティングのヒント
これらのヒントを使用して、問題のトラブルシューティングに必要なシャード・データベースに関する情報を検出します。
シャーディング方法の確認
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表11-1 config sdb出力のレプリケーション・タイプ
| レプリケーション・タイプ | 出力に表示される値 |
|---|---|
| Oracle Data Guard | Data Guard |
| Oracle GoldenGate | Golden Gate |
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重複表のリフレッシュ率の設定
SHRD_DUPL_TABLE_REFRESH_RATEデータベース・パラメータを設定して、重複表のリフレッシュ率を変更できます。
デフォルトでは、重複表は60秒ごとにリフレッシュされます。次の例では、リフレッシュ間隔を100秒に増やしています。
SQL> show parameter refresh
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
shrd_dupl_table_refresh_rate integer 60
SQL> alter system set shrd_dupl_table_refresh_rate=100 scope=both;
System altered.
SQL> show parameter refresh
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
shrd_dupl_table_refresh_rate integer 100Oracle Shardingのトレースおよびデバッグ情報
次の各項では、トレースを有効化する方法とログを見つける方法について説明します。
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セッション・トレース・ファイルに書き込まれます。
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)のトレース・ファイルとログ・ファイルの場所を表示するには、GDSCTL STATUS GSMを使用します。
GDSCTL> status
Alias SHARDDIRECTOR1
Version 18.0.0.0.0
Start Date 25-FEB-2016 07:27:39
Trace Level support
Listener Log File /u01/app/oracle/diag/gsm/slc05abw/sharddirector1/alert/log.xml
Listener Trace File /u01/app/oracle/diag/gsm/slc05abw/sharddirector1/trace/
ora_10516_139939557888352.trc
Endpoint summary (ADDRESS=(HOST=shard0)(PORT=1571)(PROTOCOL=tcp))
GSMOCI Version 2.2.1
Mastership N
Connected to GDS catalog Y
Process Id 10535
Number of reconnections 0
Pending tasks. Total 0
Tasks in process. Total 0
Regional Mastership TRUE
Total messages published 71702
Time Zone +00:00
Orphaned Buddy Regions: None
GDS region region1
Network metrics:
Region: region2 Network factor:0非XMLバージョンのalert.logファイルは、次に示す/traceディレクトリにあります。
/u01/app/oracle/diag/gsm/shard-director-node/sharddirector1/trace/alert*.logGSMのログ出力を復号化するには、次のコマンドを使用します。
GDSCTL> set _event 17 -config_onlyマスター・シャード・ディレクタ(GSM)のトレース/アラート・ファイルには、すべての非同期コマンドまたはバックグラウンド・タスク(move chunk、split chunk、deploy、シャード登録、Data Guard構成、シャードDDLの実行など)のステータスとエラーが含まれています。
シャード・ディレクタのエラー・ステータスを含む保留中のAQリクエストを見つけるには、GDSCTL CONFIGを使用します。
進行中およびスケジュール済のチャンク移行を表示するには、GDSCTL CONFIG CHUNKS -show_reshardを使用します。
DDLが失敗したシャードを表示するには、GDSCTL SHOW DDL -failed_onlyを使用します。
特定のシャードのDDLエラー情報を表示するには、GDSCTL CONFIG SHARD -shard shard_nameを使用します。
シャード・データベースの一般的なエラー・パターンおよび解決
Oracle Shardingの一般的なエラーをトラブルシューティングする方法の詳細は、次の各項を参照してください。
リモート・スケジューラ・エージェントの起動時の問題
すべてのシャード・ホストでリモート・スケジューラ・エージェントの起動時に問題が発生した場合は、次の操作を試行します。
スケジューラを起動するには、各シャード・サーバーのORACLE_HOMEに移動する必要があります。
[oracle@shard2 ~]$ echo welcome | schagent -registerdatabase 192.0.2.24 8080
Agent Registration Password?
Failed to get agent Registration Info from db: No route to host
Solution: Disable firewall
service ipchains stop
service iptables stop
chkconfig ipchains off
chkconfig iptables off
シャード・ディレクタの起動時の障害
シャード・ディレクタの起動時に問題が発生した場合は、次の操作を試行します。
スケジューラを起動するには、各シャード・サーバーのORACLE_HOMEに移動する必要があります。
GDSCTL>start gsm -gsm shardDGdirector
GSM-45054: GSM error
GSM-40070: GSM is not able to establish connection to GDS catalog
GSM alert log, /u01/app/oracle/diag/gsm/shard1/sharddgdirector/trace/alert_gds.log
GSM-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 descriptor
GSM-40112: OCI error. Code (-1). See GSMOCI trace for details.
2017-04-20T22:50:22.496362+05:30
Process 1 in GSM instance is down
GSM shutdown is successful
GSM shutdown is in progress
NOTE : if not message displayed in the GSM log then enable GSM trace level to 16
while adding GSM itself.-
起動に失敗した新規作成のシャード・ディレクタ(GSM)を削除します。
GDSCTL> remove gsm -gsm shardDGdirector -
トレース・レベル16を使用してシャード・ディレクタを追加します。
GDSCTL> add gsm -gsm shardDGdirector -listener port_num -pwd gsmcatuser_password -catalog hostname:port_num:shard_catalog_name -region region1 -trace_level 16 -
シャード・カタログ・データベースがデフォルト以外のポート(1521以外)で実行されている場合は、リモート・リスナーを設定します。
SQL> alter system set local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=hostname)(PORT=port_num)))';
CREATE SHARDで作成されたシャードのエラー
GDSCTL CREATE SHARDコマンドで作成されたシャードのDEPLOY実行中に発生したエラーについては、次の項目を確認します。
-
シャード・ホスト上のリモート・スケジューラ・エージェントのログ
-
シャード・カタログのDBA_SCHEDULER_JOB_RUN_DETAILSビュー
-
シャード・ホスト上の$ORACLE_BASE/cfgtoollogsにあるNETCA/DBCAの出力ファイル
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
GSM-45029: SQL error
ORA-03710: directory does not exist or is not writeable at destination:
$ORACLE_BASE/oradata
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 6920
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 4730
ORA-06512: at line 1
GDSCTL>create shard -shardgroup primary_shardgroup -destination che -osaccount oracle
-ospassword oracle
GSM-45029: SQL error
ORA-03710: directory does not exist or is not writeable at destination:
$ORACLE_BASE/fast_recovery_area
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 6920
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 4755
ORA-06512: at line 1解決策: すべてのシャード・ホスト上の$ORACLE_BASEの下に/oradataとfast_recovery_areaを作成します。
権限の問題
GDSCTL>create shard -shardgroup primary_shardgroup -destination blr -credential cred
GSM-45029: SQL error
ORA-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 6920
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 4596
ORA-06512: at line 1解決策: 次のディレクトリに対するroot権限があることを確認します。
chown root $ORACLE_HOME/bin/extjob
chmod 4750 $ORACLE_HOME/bin/extjob
chown root $ORACLE_HOME/rdbms/admin/externaljob.ora
chmod 640 $ORACLE_HOME/rdbms/admin/externaljob.ora
chown root $ORACLE_HOME/bin/jssu
chmod 4750 $ORACLE_HOME/bin/jssuCREATE SHARDでのエラー
GDSCTL>create shard -shardgroup primary_shardgroup -destination mysql02 -osaccount
oracle -ospassword oracle
GSM-45029: SQL error
ORA-03719: Shard character set does not match catalog character set.
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 7469
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 79
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 5770
ORA-06512: at line 1解決策: Javaのバージョンを確認します(シャード・カタログおよびすべてのシャード・サーバーで同じである必要があります)。
rpm -qa|grep javadeployコマンドの使用時の問題
GDSCTL> deploy
GSM-45029: SQL error
ORA-29273: HTTP request failed
ORA-06512: at "SYS.DBMS_ISCHED", line 3715
ORA-06512: at "SYS.UTL_HTTP", line 1267
ORA-29276: transfer timeout
ORA-06512: at "SYS.UTL_HTTP", line 651
ORA-06512: at "SYS.UTL_HTTP", line 1257
ORA-06512: at "SYS.DBMS_ISCHED", line 3708
ORA-06512: at "SYS.DBMS_SCHEDULER", line 2609
ORA-06512: at "GSMADMIN_INTERNAL.DBMS_GSM_POOLADMIN", line 14284
ORA-06512: at line 1解決策: $ORACLE_HOME/data/pendingjobsで正確なエラーを確認します。ウォレットに問題がある場合は、ORA-1017がスローされます。
-
問題のあるシャード・ホスト上で、リモート・スケジューラ・エージェントを停止します。
schagent -stop -
データベース・ホーム上のウォレット・ディレクトリの名前を変更します。
mv $ORACLE_HOME/data/wallet $ORACLE_HOME/data/wallet.old -
リモート・スケジューラ・エージェントを起動すると、新しいウォレット・ディレクトリが作成されます。
schagent -start schagent -status echo welcome | schagent -registerdatabase 10.10.10.10 8080