| Oracle Streamsレプリケーション管理者ガイド 11g リリース1（11.1） E05776-02 |
|
 戻る |
 次へ |
この章では、Oracle Streamsレプリケーションに関連する静的データ・ディクショナリ・ビューと動的パフォーマンス・ビューについて説明します。これらのビューを使用すると、Oracle Streamsレプリケーション環境を監視できます。この章では、Oracle Streamsレプリケーション環境の監視に使用できる問合せの例も示します。
この章の内容は次のとおりです。
|
注意:
|
|
参照:
|
DBMS_STREAMS_ADVISOR_ADMパッケージを使用すると、Oracle Streamsのトポロジおよびパフォーマンスに関する情報を収集できます。収集した情報を表示するには、次のデータ・ディクショナリ・ビューを問い合せます。
DBA_STREAMS_TP_COMPONENT: 各データベースの各Oracle Streamsコンポーネントに関する情報が含まれています。
DBA_STREAMS_TP_COMPONENT_LINK: Oracle Streamsコンポーネント間でのメッセージの流れに関する情報が含まれています。
DBA_STREAMS_TP_COMPONENT_STAT: 各Oracle Streamsコンポーネントに関する統計が含まれています。
DBA_STREAMS_TP_DATABASE: Oracle Streamsコンポーネントが存在する各データベースに関する情報が含まれています。
DBA_STREAMS_TP_PATH_BOTTLENECK: ストリームの流れを遅くしている可能性があるOracle Streamsコンポーネントに関する情報が含まれています。
DBA_STREAMS_TP_PATH_STAT: Oracle Streamsトポロジに存在する各ストリーム・パスに関する統計が含まれています。
DBMS_STREAMS_ADVISOR_ADMパッケージを使用して情報を収集すると、Oracle Streamsパフォーマンス・アドバイザによって、Oracle Streamsのトポロジおよびパフォーマンスに関する情報がこれらのビューに記録されます。これらのビューを問い合せて、Oracle Streamsコンポーネントの現在の実行状況を判断し、パフォーマンスを向上させる方法について確認できます。
|
参照: DBMS_STREAMS_ADVISOR_ADMパッケージ、トポロジのデータ・ディクショナリ・ビューおよびOracle Streamsパフォーマンス・アドバイザを使用する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
ここでは、ソース・データベースでサプリメンタル・ロギングを監視するために実行できる問合せについて説明します。
データベースでの総合的なサプリメンタル・ロギングは、この項の3つの問合せで表示される結果の組合せによって決定されます。たとえば、「ソース・データベースのサプリメンタル・ログ・グループの表示」の項の問合せで表から結果が戻されなかった場合でも、表内の列に対してサプリメンタル・ロギングを有効化できます。つまり、データベース・サプリメンタル・ロギングが有効化されているか、またはインスタンス化のための準備中にサプリメンタル・ロギングが有効化されたスキーマ内に表がある場合、その表のサプリメンタル・ロギングを有効にできます。
サプリメンタル・ロギングでは、操作が実行されるたびにREDOログに列データが追加されます。取得プロセスは、この追加情報を取得してLCRに含めます。これらの取得LCRを適用する適用プロセスには、変更を適切にスケジュールまたは適用するために、この追加情報が必要となる場合があります。
ソース・データベースで表に対して1つ以上のログ・グループが指定されているかどうかをチェックするには、次の問合せを実行します。
COLUMN LOG_GROUP_NAME HEADING 'Log Group' FORMAT A20
COLUMN TABLE_NAME HEADING 'Table' FORMAT A15
COLUMN ALWAYS HEADING 'Conditional or|Unconditional' FORMAT A14
COLUMN LOG_GROUP_TYPE HEADING 'Type of Log Group' FORMAT A20
SELECT
LOG_GROUP_NAME,
TABLE_NAME,
DECODE(ALWAYS,
'ALWAYS', 'Unconditional',
'CONDITIONAL', 'Conditional') ALWAYS,
LOG_GROUP_TYPE
FROM DBA_LOG_GROUPS;
出力は次のようになります。
Conditional or
Log Group Table Unconditional Type of Log Group
-------------------- --------------- -------------- --------------------
LOG_GROUP_DEP_PK DEPARTMENTS Unconditional USER LOG GROUP
SYS_C002105 REGIONS Unconditional PRIMARY KEY LOGGING
SYS_C002106 REGIONS Conditional FOREIGN KEY LOGGING
SYS_C002110 LOCATIONS Unonditional ALL COLUMN LOGGING
SYS_C002111 COUNTRIES Conditional ALL COLUMN LOGGING
LOG_GROUP_JOBS_CR JOBS Conditional USER LOG GROUP
ログ・グループのタイプの出力がログ・グループの作成方法を示していると想定すると、次のことがいえます。
出力がUSER LOG GROUPの場合、ログ・グループは、ALTER TABLE文のADD SUPPLEMENTAL LOG GROUP句を使用して作成されています。
その他の場合、ログ・グループは、ALTER TABLE文のADD SUPPLEMENTAL LOG DATA句を使用して作成されています。
ログ・グループのタイプがUSER LOG GROUPの場合、DBA_LOG_GROUP_COLUMNSデータ・ディクショナリ・ビューを問い合せることで、ログ・グループの列をリストできます。
|
注意: ログ・グループのタイプがUSER LOG GROUPではない場合、DBA_LOG_GROUP_COLUMNSデータ・ディクショナリ・ビューには、ログ・グループの列に関する情報は含まれません。かわりに、表に操作が実行されると、Oracleは正しい列に対してサプリメンタル・ロギングを実行します。たとえば、ログ・グループのタイプがPRIMARY KEY LOGGINGの場合、Oracleはその表に変更が加えられたときに、現行の主キー列をログに記録します。 |
データベースのサプリメンタル・ロギング指定を表示するには、V$DATABASE動的パフォーマンス・ビューを問い合せます。次に例を示します。
COLUMN log_min HEADING 'Minimum|Supplemental|Logging?' FORMAT A12
COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging?' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging?' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging?' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging?' FORMAT A12
SELECT SUPPLEMENTAL_LOG_DATA_MIN log_min,
SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM V$DATABASE;
出力は次のようになります。
Minimum Primary Key Foreign Key Unique All Columns Supplemental Supplemental Supplemental Supplemental Supplemental Logging? Logging? Logging? Logging? Logging? ------------ ------------ ------------ ------------- ------------ YES YES YES YES NO
この結果は、データベース内のすべての表について、最小値列、主キー列、外部キー列および一意キー列にサプリメンタル・ロギングが実行されていることを示しています。一意キー列にサプリメンタル・ロギングが実行されているため、ビットマップ索引列にもサプリメンタル・ロギングが実行されています。ただし、すべての列にサプリメンタル・ロギングが実行されているわけではありません。
DBMS_CAPTURE_ADMパッケージの3つのうちの1つのプロシージャを使用して、データベース・オブジェクトがインスタンス化のために準備されている場合、サプリメンタル・ロギングを有効化できます。データ･ディクショナリ・ビューには、PREPARE_TABLE_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_GLOBAL_INSTANTIATIONの各プロシージャによって有効化されたサプリメンタル・ロギングが表示されます。
DBA_CAPTURE_PREPARED_TABLESビューには、PREPARE_TABLE_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが表示されます。
DBA_CAPTURE_PREPARED_SCHEMASビューには、PREPARE_SCHEMA_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが表示されます。
DBA_CAPTURE_PREPARED_DATABASEビューには、PREPARE_GLOBAL_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが表示されます。
これらの各ビューには、次の列があります。
SUPPLEMENTAL_LOG_DATA_PK: プロシージャによって主キーのサプリメンタル・ロギングが有効化されたかどうかが表示されます。
SUPPLEMENTAL_LOG_DATA_UI: プロシージャによって一意キーおよびビットマップ索引のサプリメンタル・ロギングが有効化されたかどうかが表示されます。
SUPPLEMENTAL_LOG_DATA_FK: プロシージャによって外部キーのサプリメンタル・ロギングが有効化されたかどうかが表示されます。
SUPPLEMENTAL_LOG_DATA_ALL: プロシージャによってすべての列のサプリメンタル・ロギングが有効化されたかどうかが表示されます。
これらの各列には、次のいずれかの値が表示されます。
IMPLICIT: 関連するプロシージャによって列のサプリメンタル・ロギングが有効化されたことを意味します。
EXPLICIT: ADD SUPPLEMENTAL LOG DATA句を指定したALTER TABLEまたはALTER DATABASE文を使用して、列のサプリメンタル・ロギングが手動で有効化されたことを意味します。
NO: PREPAREプロシージャまたはADD SUPPLEMENTAL LOG DATA句を指定したALTER TABLEまたはALTER DATABASE文を使用して、列のサプリメンタル・ロギングが有効化されていないことを意味します。サプリメンタル・ロギングは、その列に対して有効化されていない場合があります。ただし、サプリメンタル・ロギングは、その列に対して他のレベル（表、スキーマまたはデータベース）で有効化されていたり、ADD SUPPLEMENTAL LOG GROUP句を指定したALTER TABLE文を使用して有効化されている場合があります。
ここでは、これらのプロシージャによって有効化されたサプリメンタル・ロギングを表示する問合せについて説明します。
次の問合せを実行すると、PREPARE_TABLE_INSTANTIATIONプロシージャによってhrスキーマ内の表に対して有効化されたサプリメンタル・ロギングが表示されます。
COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A15
COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging' FORMAT A12
SELECT TABLE_NAME,
SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM DBA_CAPTURE_PREPARED_TABLES
WHERE TABLE_OWNER = 'HR';
出力は次のようになります。
Primary Key Foreign Key Unique All Columns
Supplemental Supplemental Supplemental Supplemental
Table Name Logging Logging Logging Logging
--------------- ------------ ------------ -------------- ------------
COUNTRIES NO NO NO NO
REGIONS IMPLICIT IMPLICIT IMPLICIT NO
DEPARTMENTS IMPLICIT IMPLICIT IMPLICIT NO
LOCATIONS EXPLICIT NO NO NO
EMPLOYEES NO NO NO IMPLICIT
JOB_HISTORY NO NO NO NO
JOBS NO NO NO NO
結果は次のとおりです。
PREPARE_TABLE_INSTANTIATIONプロシージャによって、hr.regionsおよびhr.departments表内の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効化されています。
PREPARE_TABLE_INSTANTIATIONプロシージャによって、hr.employees表内のすべての列のサプリメンタル・ロギングが有効化されています。
ADD SUPPLEMENTAL LOG DATA句を指定したALTER TABLE文によって、hr.locations表の主キーのサプリメンタル・ロギングが有効化されています。
|
注意: データベース内のすべての表の情報を表示するには、問合せでWHERE句を省略します。 |
次の問合せを実行すると、PREPARE_SCHEMA_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが表示されます。
COLUMN SCHEMA_NAME HEADING 'Schema Name' FORMAT A20
COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging' FORMAT A12
SELECT SCHEMA_NAME,
SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM DBA_CAPTURE_PREPARED_SCHEMAS;
出力は次のようになります。
Primary Key Foreign Key Unique All Columns
Supplemental Supplemental Supplemental Supplemental
Schema Name Logging Logging Logging Logging
-------------------- ------------ ------------ -------------- ------------
OUTLN NO NO NO NO
DIP NO NO NO NO
TSMSYS NO NO NO NO
DBSNMP NO NO NO NO
WMSYS NO NO NO NO
CTXSYS NO NO NO NO
SCOTT NO NO NO NO
ADAMS NO NO NO NO
JONES NO NO NO NO
CLARK NO NO NO NO
BLAKE NO NO NO NO
HR NO NO NO IMPLICIT
OE IMPLICIT IMPLICIT IMPLICIT NO
IX NO NO NO NO
ORDSYS NO NO NO NO
ORDPLUGINS NO NO NO NO
SI_INFORMTN_SCHEMA NO NO NO NO
MDSYS NO NO NO NO
PM NO NO NO NO
SH NO NO NO NO
結果は次のとおりです。
PREPARE_SCHEMA_INSTANTIATIONプロシージャによって、hrスキーマ内の表のすべての列のサプリメンタル・ロギングが有効化されています。
PREPARE_SCHEMA_INSTANTIATIONプロシージャによって、oeスキーマ内の表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効化されています。
次の問合せを実行すると、PREPARE_GLOBAL_INSTANTIATIONプロシージャによって有効化されたサプリメンタル・ロギングが表示されます。
COLUMN log_pk HEADING 'Primary Key|Supplemental|Logging' FORMAT A12
COLUMN log_fk HEADING 'Foreign Key|Supplemental|Logging' FORMAT A12
COLUMN log_ui HEADING 'Unique|Supplemental|Logging' FORMAT A12
COLUMN log_all HEADING 'All Columns|Supplemental|Logging' FORMAT A12
SELECT SUPPLEMENTAL_LOG_DATA_PK log_pk,
SUPPLEMENTAL_LOG_DATA_FK log_fk,
SUPPLEMENTAL_LOG_DATA_UI log_ui,
SUPPLEMENTAL_LOG_DATA_ALL log_all
FROM DBA_CAPTURE_PREPARED_DATABASE;
出力は次のようになります。
Primary Key Foreign Key Unique All Columns Supplemental Supplemental Supplemental Supplemental Logging Logging Logging Logging ------------ ------------ -------------- ------------ IMPLICIT IMPLICIT IMPLICIT NO
この結果は、PREPARE_GLOBAL_INSTANTIATIONプロシージャによって、データベース内のすべての表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが有効化されていることを示しています。
ここでは、Streamsレプリケーション環境で適用プロセスを監視するために実行できる問合せについて説明します。
接続先データベースで代替キーを指定できます。代替キーとは、Oracleが適用中に表の各行を識別するために使用できる列または列セットです。代替キー列を使用すると、主キーのない表のキー列を指定できます。また、接続先データベースで表が適用プロセスによって処理されるときには、その表の主キーのかわりに使用できます。
接続先データベースで指定されている代替キー列をすべて表示するには、次の問合せを実行します。
COLUMN OBJECT_OWNER HEADING 'Table Owner' FORMAT A20 COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20 COLUMN COLUMN_NAME HEADING 'Substitute Key Name' FORMAT A20 COLUMN APPLY_DATABASE_LINK HEADING 'Database Link|for Remote|Apply' FORMAT A15 SELECT OBJECT_OWNER, OBJECT_NAME, COLUMN_NAME, APPLY_DATABASE_LINK FROM DBA_APPLY_KEY_COLUMNS ORDER BY APPLY_DATABASE_LINK, OBJECT_OWNER, OBJECT_NAME;
出力は次のようになります。
Database Link
for Remote
Table Owner Table Name Substitute Key Name Apply
-------------------- -------------------- -------------------- ---------------
HR DEPARTMENTS DEPARTMENT_NAME
HR DEPARTMENTS LOCATION_ID
HR EMPLOYEES FIRST_NAME
HR EMPLOYEES LAST_NAME
HR EMPLOYEES HIRE_DATE
|
注意: Oracle以外のリモート・データベースの代替キー列の場合は、この問合せを実行すると、最終列にデータベース・リンクが表示されます。ローカルの接続先データベースの代替キー列が指定されている場合は、最終列がNULLになります。 |
この項では、適用プロセスのDMLハンドラおよびDDLハンドラに関する情報を表示する問合せについて説明します。
|
参照: DMLハンドラおよびDDLハンドラの詳細は、『Oracle Streams概要および管理』を参照してください。 |
接続先データベースでDBMS_APPLY_ADMパッケージのSET_DML_HANDLERプロシージャを使用して、ローカルのDMLハンドラを指定する際に、そのハンドラを特定の適用プロセスで実行するか、または変更をローカルに適用するデータベース内のすべての適用プロセスについて、必要に応じて汎用ハンドラを実行するかを指定できます。特定のDMLハンドラは、汎用DMLハンドラより優先されます。DMLは、特定の表に対する指定した操作について実行されます。
データベース内で変更をローカルに適用する各適用プロセスについて、DMLハンドラを表示するには、次の問合せを実行します。
COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A11
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A10
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A9
COLUMN USER_PROCEDURE HEADING 'Handler Procedure' FORMAT A25
COLUMN APPLY_NAME HEADING 'Apply Process|Name' FORMAT A15
SELECT OBJECT_OWNER,
OBJECT_NAME,
OPERATION_NAME,
USER_PROCEDURE,
APPLY_NAME
FROM DBA_APPLY_DML_HANDLERS
WHERE ERROR_HANDLER = 'N' AND
APPLY_DATABASE_LINK IS NULL
ORDER BY OBJECT_OWNER, OBJECT_NAME;
出力は次のようになります。
Table Apply Process Owner Table Name Operation Handler Procedure Name ----------- ---------- --------- ------------------------- -------------- HR LOCATIONS UPDATE "STRMADMIN"."HISTORY_DML"
strmadmin.history_dml DMLハンドラのApply Process NameはNULLであるため、このハンドラはすべてのローカル適用プロセスについて実行される汎用ハンドラです。
|
注意: Oracle以外のリモート・データベースに関して、変更を処理するDMLハンドラを指定することもできます。この問合せでは、この種のDMLハンドラは表示されません。これは、DMLハンドラが表示されるのは、APPLY_DATABASE_LINK列がNULLの場合のみであるためです。 |
データベース内の各適用プロセスについて、DDLハンドラを表示するには、次の問合せを実行します。
COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A20 COLUMN DDL_HANDLER HEADING 'DDL Handler' FORMAT A40 SELECT APPLY_NAME, DDL_HANDLER FROM DBA_APPLY;
出力は次のようになります。
Apply Process Name DDL Handler -------------------- ---------------------------------------- STREP01_APPLY "STRMADMIN"."HISTORY_DDL"
ここでは、データベース内の仮想依存性定義に関する情報を表示する問合せについて説明します。
データベース内の値依存性を表示するには、次の問合せを実行します。
COLUMN DEPENDENCY_NAME HEADING 'Dependency Name' FORMAT A25
COLUMN OBJECT_OWNER HEADING 'Object Owner' FORMAT A15
COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A15
SELECT DEPENDENCY_NAME,
OBJECT_OWNER,
OBJECT_NAME,
COLUMN_NAME
FROM DBA_APPLY_VALUE_DEPENDENCIES;
出力は次のようになります。
Dependency Name Object Owner Object Name Column Name ------------------------- --------------- -------------------- --------------- ORDER_ID_FOREIGN_KEY OE ORDERS ORDER_ID ORDER_ID_FOREIGN_KEY OE ORDER_ITEMS ORDER_ID KEY_53_FOREIGN_KEY US_DESIGNS ALL_DESIGNS_SUMMARY KEY_53 KEY_53_FOREIGN_KEY US_DESIGNS DESIGN_53 KEY_53
この出力には、次の値依存性が表示されています。
order_id_foreign_key値依存性は、oe.orders表のorder_id列とoe.order_items表のorder_id列の間の依存性を示します。
key_53_foreign_key値依存性は、us_designs.all_designs_summary表のkey_53列とus_designs.design_53表のkey_53列の間の依存性を示します。
データベース内のオブジェクト依存性を表示するには、次の問合せを実行します。
COLUMN OBJECT_OWNER HEADING 'Object Owner' FORMAT A15
COLUMN OBJECT_NAME HEADING 'Object Name' FORMAT A15
COLUMN PARENT_OBJECT_OWNER HEADING 'Parent Object Owner' FORMAT A20
COLUMN PARENT_OBJECT_NAME HEADING 'Parent Object Name' FORMAT A20
SELECT OBJECT_OWNER,
OBJECT_NAME,
PARENT_OBJECT_OWNER,
PARENT_OBJECT_NAME
FROM DBA_APPLY_OBJECT_DEPENDENCIES;
出力は次のようになります。
Object Owner Object Name Parent Object Owner Parent Object Name --------------- --------------- -------------------- -------------------- ORD CUSTOMERS ORD SHIP_ORDERS ORD ORDERS ORD SHIP_ORDERS ORD ORDER_ITEMS ORD SHIP_ORDERS
この出力には、ord.ship_orders表が次に示す子表の親表であるオブジェクト依存性が表示されています。
ord.customers
ord.orders
ord.order_items
DBMS_APPLY_ADMパッケージのCOMPARE_OLD_VALUESプロシージャを使用すると、非キー列の競合検出を停止できます。このプロシージャを使用すると、接続先データベースのすべての適用プロセスについて、指定した列の競合検出が停止されます。競合検出が停止された各列を表示するには、次の問合せを実行します。
COLUMN OBJECT_OWNER HEADING 'Table Owner' FORMAT A15
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A20
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A20
COLUMN COMPARE_OLD_ON_DELETE HEADING 'Compare|Old On|Delete' FORMAT A7
COLUMN COMPARE_OLD_ON_UPDATE HEADING 'Compare|Old On|Update' FORMAT A7
SELECT OBJECT_OWNER,
OBJECT_NAME,
COLUMN_NAME,
COMPARE_OLD_ON_DELETE,
COMPARE_OLD_ON_UPDATE
FROM DBA_APPLY_TABLE_COLUMNS
WHERE APPLY_DATABASE_LINK IS NULL;
出力は次のようになります。
Compare Compare
Old On Old On
Table Owner Table Name Column Name Delete Update
--------------- -------------------- -------------------- ------- -------
HR EMPLOYEES COMMISSION_PCT NO NO
HR EMPLOYEES EMAIL NO NO
HR EMPLOYEES FIRST_NAME NO NO
HR EMPLOYEES HIRE_DATE NO NO
HR EMPLOYEES JOB_ID NO NO
HR EMPLOYEES LAST_NAME NO NO
HR EMPLOYEES PHONE_NUMBER NO NO
HR EMPLOYEES SALARY NO NO
|
注意: Oracle以外のリモート・データベースに適用される変更についての競合検出を停止することもできます。この問合せでは、この種の指定は表示されません。これは、指定が表示されるのは、APPLY_DATABASE_LINK列がNULLの場合のみであるためです。 |
DBMS_APPLY_ADMパッケージのSET_UPDATE_CONFLICT_HANDLERプロシージャを使用して更新の競合ハンドラを指定した場合は、関連する競合が発生すると、そのハンドラがデータベース内のすべての適用プロセスに対して実行されます。
この項で説明する問合せを実行すると、ビルトインの更新の競合ハンドラを使用して競合解消が指定されている列がすべて表示されます。つまり、データベース内で指定されているすべての列リストの列が表示されます。また、この問合せでは、指定されているビルトインの競合ハンドラの型と、列リストに指定されている解消列も表示されます。
データベース内のすべての更新の競合ハンドラに関する情報を表示するには、次の問合せを実行します。
COLUMN OBJECT_OWNER HEADING 'Table|Owner' FORMAT A5
COLUMN OBJECT_NAME HEADING 'Table Name' FORMAT A12
COLUMN METHOD_NAME HEADING 'Method' FORMAT A12
COLUMN RESOLUTION_COLUMN HEADING 'Resolution|Column' FORMAT A13
COLUMN COLUMN_NAME HEADING 'Column Name' FORMAT A30
SELECT OBJECT_OWNER,
OBJECT_NAME,
METHOD_NAME,
RESOLUTION_COLUMN,
COLUMN_NAME
FROM DBA_APPLY_CONFLICT_COLUMNS
ORDER BY OBJECT_OWNER, OBJECT_NAME, RESOLUTION_COLUMN;
出力は次のようになります。
Table Resolution Owner Table Name Method Column Column Name ----- ------------ ------------ ------------- ------------------------------ HR COUNTRIES MAXIMUM TIME COUNTRY_NAME HR COUNTRIES MAXIMUM TIME REGION_ID HR COUNTRIES MAXIMUM TIME TIME HR DEPARTMENTS MAXIMUM TIME DEPARTMENT_NAME HR DEPARTMENTS MAXIMUM TIME LOCATION_ID HR DEPARTMENTS MAXIMUM TIME MANAGER_ID HR DEPARTMENTS MAXIMUM TIME TIME
ここでは、現行セッション用のOracle Streamsタグと各適用プロセス用のデフォルト・タグを表示するために実行できる問合せについて説明します。
|
参照:
|
次のようにDUALビューを問い合せると、現行セッションについてすべてのREDOエントリ内で生成されたタグ値を表示できます。
SELECT DBMS_STREAMS.GET_TAG FROM DUAL;
出力は次のようになります。
GET_TAG -------------------------------------------------------------------------------- 1D
また、DBMS_STREAMS.GET_TAGファンクションをコールすると、セッション用のタグを判断できます。
DBA_APPLYデータ・ディクショナリ・ビューでAPPLY_TAGの値を問い合せると、各適用プロセスによって生成されるすべてのREDOエントリのデフォルト・タグを取得できます。たとえば、各適用プロセスによってREDOエントリ内で生成されるデフォルト・タグの16進値を取得するには、次の問合せを実行します。
COLUMN APPLY_NAME HEADING 'Apply Process Name' FORMAT A30 COLUMN APPLY_TAG HEADING 'Tag Value' FORMAT A30 SELECT APPLY_NAME, APPLY_TAG FROM DBA_APPLY;
出力は次のようになります。
Apply Process Name Tag Value ------------------------------ ------------------------------ APPLY_FROM_MULT2 00 APPLY_FROM_MULT3 00
適用プロセスに関連付けられているハンドラまたはカスタム・ルールベースの変換ファンクションでは、DBMS_STREAMS.GET_TAGファンクションをコールしてタグを取得できます。
ここでは、ソース・データベースでインスタンス化のために準備済であるデータベース・オブジェクト、および接続先データベースでのデータベース・オブジェクトのインスタンス化SCNを判断するために実行できる問合せについて説明します。
データベース・オブジェクトをインスタンス化のために準備するには、DBMS_CAPTURE_ADMパッケージの次のいずれかのプロシージャまたはファンクションを使用します。
PREPARE_TABLE_INSTANTIATIONプロシージャでは、表に対する変更が取得プロセスによって取得される場合、1つの表がインスタンス化のために準備されます。
PREPARE_SYNC_INSTANTIATIONファンクションでは、表に対する変更が同期取得によって取得される場合、1つの表または複数の表がインスタンス化のために準備されます。
PREPARE_SCHEMA_INSTANTIATIONプロシージャでは、スキーマ内のすべてのデータベース・オブジェクトおよび将来そのスキーマに追加されるすべてのデータベース・オブジェクトがインスタンス化のために準備されます。このプロシージャは、取得プロセスによって変更が取得される場合にのみ使用する必要があります。
PREPARE_GLOBAL_INSTANTIATIONプロシージャでは、データベース内のすべてのデータベース・オブジェクトおよび将来そのデータベースに追加されるすべてのデータベース・オブジェクトがインスタンス化のために準備されます。このプロシージャは、取得プロセスによって変更が取得される場合にのみ使用する必要があります。
どのデータベース・オブジェクトのインスタンス化の準備が完了しているかを判断するには、対応する次のデータ・ディクショナリ・ビューを問い合せます。
DBA_CAPTURE_PREPARED_TABLES
DBA_SYNC_CAPTURE_PREPARED_TABS
DBA_CAPTURE_PREPARED_SCHEMAS
DBA_CAPTURE_PREPARED_DATABASE
たとえば、PREPARE_TABLE_INSTANTIATIONプロシージャでインスタンス化の準備が完了しているすべての表、各表が準備された時刻およびそのSCNを表示するには、次の問合せを実行します。
COLUMN TABLE_OWNER HEADING 'Table Owner' FORMAT A15
COLUMN TABLE_NAME HEADING 'Table Name' FORMAT A15
COLUMN SCN HEADING 'Prepare SCN' FORMAT 99999999999
COLUMN TIMESTAMP HEADING 'Time Ready for|Instantiation'
SELECT TABLE_OWNER,
TABLE_NAME,
SCN,
TO_CHAR(TIMESTAMP, 'HH24:MI:SS MM/DD/YY') TIMESTAMP
FROM DBA_CAPTURE_PREPARED_TABLES;
出力は次のようになります。
Time Ready for
Table Owner Table Name Prepare SCN Instantiation
--------------- --------------- ----------------- -----------------
HR COUNTRIES 196655 12:59:30 02/28/02
HR DEPARTMENTS 196658 12:59:30 02/28/02
HR EMPLOYEES 196659 12:59:30 02/28/02
HR JOBS 196660 12:59:30 02/28/02
HR JOB_HISTORY 196661 12:59:30 02/28/02
HR LOCATIONS 196662 12:59:30 02/28/02
HR REGIONS 196664 12:59:30 02/28/02
インスタンス化SCNは、接続先データベースで設定されます。このSCNによって、データベース・オブジェクト対して、適用プロセスで無視される取得LCRおよび適用される取得LCRが制御されます。ソース・データベースからの表に関するLCRのコミットSCNが、接続先データベースでその表のインスタンス化SCN以下であれば、接続先データベースの適用プロセスではLCRが廃棄されます。それ以外の場合は、適用プロセスによってLCRが適用されます。LCRは、取得プロセスまたは同期取得で取得できます。
インスタンス化SCNは、DBMS_APPLY_ADMパッケージの次のいずれかのプロシージャを使用して設定できます。
SET_TABLE_INSTANTIATION_SCN: 1つの表のインスタンス化SCNを設定します。
SET_SCHEMA_INSTANTIATION_SCN: 1つのスキーマ（オプションで、スキーマ内のすべてのデータベース・オブジェクト）のインスタンス化SCNを設定します。
SET_GLOBAL_INSTANTIATION_SCN: 1つのデータベース（オプションで、データベース内のすべてのデータベース・オブジェクト）のインスタンス化SCNを設定します。
どのデータベース・オブジェクトのインスタンス化SCNが設定されているかを判断するには、対応する次のデータ・ディクショナリ・ビューを問い合せます。
DBA_APPLY_INSTANTIATED_OBJECTS
DBA_APPLY_INSTANTIATED_SCHEMAS
DBA_APPLY_INSTANTIATED_GLOBAL
次の問合せを実行すると、接続先データベースでインスタンス化SCNが設定されている各表と、それぞれの表のインスタンス化SCNが表示されます。
COLUMN SOURCE_DATABASE HEADING 'Source Database' FORMAT A15
COLUMN SOURCE_OBJECT_OWNER HEADING 'Object Owner' FORMAT A15
COLUMN SOURCE_OBJECT_NAME HEADING 'Object Name' FORMAT A15
COLUMN INSTANTIATION_SCN HEADING 'Instantiation SCN' FORMAT 99999999999
SELECT SOURCE_DATABASE,
SOURCE_OBJECT_OWNER,
SOURCE_OBJECT_NAME,
INSTANTIATION_SCN
FROM DBA_APPLY_INSTANTIATED_OBJECTS
WHERE APPLY_DATABASE_LINK IS NULL;
出力は次のようになります。
Source Database Object Owner Object Name Instantiation SCN --------------- --------------- --------------- ----------------- DBS1.NET HR REGIONS 196660 DBS1.NET HR COUNTRIES 196660 DBS1.NET HR LOCATIONS 196660
|
注意: Oracle以外のリモート・データベースに適用される変更についてのインスタンス化SCNを表示することができます。この問合せでは、この種のインスタンス化SCNは表示されません。これは、インスタンス化SCNが表示されるのは、APPLY_DATABASE_LINK列がNULLの場合のみであるためです。 |
ストリームでの論理変更レコード（LCR）の流れは通常、次のようになります。
データベースの変更が取得され、LCRにフォーマットされてエンキューされます。取得プロセスまたは同期取得では、データベースの変更を暗黙的に取得できます。アプリケーションまたはユーザーは、LCRを構成およびエンキューして、データベースの変更を明示的に取得できます。
1つ以上の伝播によって、LCRがOracle Streams環境内の他のデータベースに送信されます。
1つ以上の適用プロセスによって、LCRがデキューおよび処理されます。
DBMS_STREAMS_ADMパッケージのSET_MESSAGE_TRACKINGプロシージャを使用して、ストリームでのLCRの流れを追跡できます。このプロシージャを使用すると、現行セッションで生成される各LCRの一部として追跡ラベルを指定できます。この追跡ラベルを使用してV$STREAMS_MESSAGE_TRACKINGビューを問い合せると、ストリームでLCRを追跡し、LCRが各Oracle Streamsクライアントによって処理された状況を確認できます。
LCRの追跡は、1つ以上の適用プロセスでLCRが正しく適用されていない場合に役立ちます。この場合、LCRを追跡することによって、ストリーム内のLCRの停止場所を判断し、その場所で発生している問題に対応できます。
取得プロセスまたは同期取得でLCRを取得する場合、取得されるデータベースの変更を行ったセッションに対して追跡ラベルが設定されていると、LCRに自動的に追跡ラベルが含まれます。ユーザーまたはアプリケーションがLCRを構成する場合、LCRを構成するセッションに対して追跡ラベルが設定されていると、LCRに自動的に追跡ラベルが含まれます。
ストリームでLCRを追跡するには、次の手順を実行します。
SQL*Plusで、セッションを開始します。取得プロセスまたは同期取得によって取得されるデータベースの変更に対して追跡ラベルを使用する場合は、取得プロセスまたは同期取得のソース・データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
メッセージの追跡を開始します。
BEGIN
DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
tracking_label => 'TRACK_LCRS',
actions => DBMS_STREAMS_ADM.ACTION_MEMORY);
END;
/
LCRの追跡には、任意のラベルを使用できます。この例では、TRACK_LCRSというラベルを使用しています。
また、この例では、actionsパラメータにDBMS_STREAMS_ADM.ACTION_MEMORYを指定しています。この値を指定すると、LCRに関する情報がメモリーで追跡され、V$STREAMS_MESSAGE_TRACKING動的パフォーマンス・ビューにLCRに関する情報が移入されます。現在、actionsパラメータに指定可能な値は、ACTION_MEMORYのみです。
セッションでメッセージの追跡が設定されていることを確認するには、追跡ラベルを取得します（オプション）。
SET SERVEROUTPUT ON SIZE 4000
DECLARE
tracking_label VARCHAR2(4000);
BEGIN
tracking_label := DBMS_STREAMS_ADM.GET_MESSAGE_TRACKING();
DBMS_OUTPUT.PUT_LINE('Tracking Label: ' || tracking_label);
END;
/
手順2で指定した追跡ラベルが、GET_MESSAGE_TRACKINGファンクションによって戻されます。
取得プロセスまたは同期取得によって取得される変更をソース・データベースに対して行い、取得プロセスまたは同期取得でストリームを開始するか、または追跡するLCRを構成およびエンキューします。通常、これらのLCRはテスト用としてのみ使用します。たとえば、表に多数の仮行を挿入した後で、それらの行を変更できます。テストが完了したら、これらの行は削除できます。
Oracle Streams環境全体を監視してLCRを追跡します。これを行うには、LCRを処理する各データベースでV$STREAMS_MESSAGE_TRACKINGビューを問い合せます。
たとえば、手順2で指定したTRACK_LCRSラベルを持つLCRを追跡するには、各データベースで次の問合せを実行します。
COLUMN COMPONENT_NAME HEADING 'Component|Name' FORMAT A10
COLUMN COMPONENT_TYPE HEADING 'Component|Type' FORMAT A12
COLUMN ACTION HEADING 'Action' FORMAT A11
COLUMN SOURCE_DATABASE_NAME HEADING 'Source|Database' FORMAT A10
COLUMN OBJECT_OWNER HEADING 'Object|Owner' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COMMAND_TYPE HEADING 'Command|Type' FORMAT A7
SELECT COMPONENT_NAME,
COMPONENT_TYPE,
ACTION,
SOURCE_DATABASE_NAME,
OBJECT_OWNER,
OBJECT_NAME,
COMMAND_TYPE
FROM V$STREAMS_MESSAGE_TRACKING
WHERE TRACKING_LABEL='TRACK_LCRS';
この問合せによって、各データベースでのLCRの処理状況が表示されます。LCRが接続先データベースに適用されていない場合は、ストリーム内のLCRの停止場所が表示されます。
たとえば、同期取得によるソース・データベースでの出力は、次のようになります。
Component Component Source Object Object Command
Name Type Action Database Owner Name Type
---------- ------------ ----------- ---------- ------ ---------- -------
CAPTURE SYNCHRONOUS Create HUB.NET HR EMPLOYEES UPDATE
CAPTURE
CAPTURE SYNCHRONOUS Rule evalua HUB.NET HR EMPLOYEES UPDATE
CAPTURE tion
CAPTURE SYNCHRONOUS Enqueue HUB.NET HR EMPLOYEES UPDATE
CAPTURE
適用プロセスによる接続先データベースでの出力は、次のようになります。
Component Component Source Object Object Command Name Type Action Database Owner Name Type ---------- ------------ ----------- ---------- ------ ---------- ------- APPLY_SYNC APPLY READER Dequeue HUB.NET HR EMPLOYEES UPDATE _CAP APPLY_SYNC APPLY READER Dequeue HUB.NET HR EMPLOYEES UPDATE _CAP APPLY_SYNC APPLY READER Dequeue HUB.NET HR EMPLOYEES UPDATE _CAP
V$STREAMS_MESSAGE_TRACKINGビューで追加の列を問い合せると、詳細情報を表示できます。たとえば、ACTION_DETAILS列では各アクションに関する詳細情報が提供されます。
現行セッションでメッセージの追跡を停止するには、SET_MESSAGE_TRACKINGプロシージャでtracking_labelパラメータをNULLに設定します。
BEGIN
DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
tracking_label => NULL,
actions => DBMS_STREAMS_ADM.ACTION_MEMORY);
END;
/
|
注意: message_tracking_frequency取得プロセス・パラメータを使用すると、LCRを自動的に追跡できます。 |
|
参照: message_tracking_frequency取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。 |
Oracle Flashback Queryを使用すると、履歴データを表示および修正できます。特定の時刻またはシステム変更番号（SCN）におけるデータベースに問合せを実行できます。単一ソースのOracle Streamsレプリケーション環境では、レプリケートされたデータベース・オブジェクトが同じであると予測する過去の時点のソース・データベースと接続先データベースでフラッシュバック問合せを使用できます。
ソース・データベースと接続先データベースで対応するSCNに対して問合せを実行すると、ソース・データベースで実行されたレプリケート・オブジェクトへのすべての変更が、接続先データベースに適用されているかどうかを判断できます。接続先データベースに適用エラーが発生している場合、フラッシュバック問合せによって、エラー発生時のレプリケート・オブジェクトの状態が表示されます。この情報は、エラーの原因と、エラーの最適な訂正方法を判断するために役立ちます。
各データベースでフラッシュバック問合せを実行すると、表の対応するSCNに特定の行が存在するかどうかを確認することもできます。対応するSCNの表データが一致しない場合、レプリケーション環境に問題があります。
問合せを実行するには、Oracle Streamsレプリケーション環境が次の条件を満たしている必要があります。
レプリケーション環境は単一ソース環境であり、レプリケート・オブジェクトへの変更が1つのデータベースのみで取得される。
Streamsのレプリケート・オブジェクトに対して変更が行われていない（変換、サブセット・ルール（行の移行）、または適用ハンドラによって、レプリケート・オブジェクトのLCRが変更されていない）。
接続先データベースのレプリケート・オブジェクトに対して、DMLまたはDDLの変更が行われていない。
ソース・データベースと接続先データベースの両方がOracle Flashbackを使用するように構成されており、両方のデータベースのOracle Streams管理者がDBMS_FLASHBACKパッケージのサブプログラムを実行する権限を持っている。
UNDO表領域に、各データベースで問合せを実行するために十分な情報が含まれている。Oracle Flashbackの機能では、自動UNDO管理システムを使用して、トランザクションの履歴データとメタデータが取得されます。各データベースのUNDO_RETENTION初期化パラメータは、フラッシュバック問合せを実行するために十分大きい値に設定されている必要があります。
Oracle Streamsレプリケーションは非同期であるため、フラッシュバック問合せで過去の時間を使用することはできません。ただし、DBMS_STREAMS_ADMパッケージのGET_SCN_MAPPINGプロシージャを使用することによって、ソース・データベースのSCNに対応する接続先データベースのSCNを判断することができます。
次の手順では、ソース・データベースでのフラッシュバック問合せのSCNがわかっていると想定しています。このSCNを使用して、接続先データベースでのフラッシュバック問合せの対応するSCNを判断できます。この問合せを実行するには、次の手順を実行します。
接続先データベースで、フラッシュバック問合せ対象のおおまかな時間のアーカイブREDOログ・ファイルがデータベースで使用可能であることを確認します。GET_SCN_MAPPINGプロシージャを実行する場合、このREDOログ・ファイルが使用可能である必要があります。
SQL*Plusで、Oracle Streams管理者として接続先データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
GET_SCN_MAPPINGプロシージャを実行します。この例では、ソース・データベースのSCNが52073983であり、ソース・データベースからの変更を適用する適用プロセスの名前がstrm01_applyであると想定しています。
SET SERVEROUTPUT ON
DECLARE
dest_scn NUMBER;
start_scn NUMBER;
dest_skip DBMS_UTILITY.NAME_ARRAY;
BEGIN
DBMS_STREAMS_ADM.GET_SCN_MAPPING(
apply_name => 'strm01_apply',
src_pit_scn => '52073983',
dest_instantiation_scn => dest_scn,
dest_start_scn => start_scn,
dest_skip_txn_ids => dest_skip);
IF dest_skip.count = 0 THEN
DBMS_OUTPUT.PUT_LINE('No Skipped Transactions');
DBMS_OUTPUT.PUT_LINE('Destination SCN: ' || dest_scn);
ELSE
DBMS_OUTPUT.PUT_LINE('Destination SCN invalid for Flashback Query.');
DBMS_OUTPUT.PUT_LINE('At least one transaction was skipped.');
END IF;
END;
/
有効な接続先SCNが戻されたら、手順4に進みます。
適用プロセスで1つ以上のトランザクションがスキップされたために、接続先SCNがフラッシュバック問合せで有効ではない場合は、適用プロセス・パラメータcommit_serializationがnoneに設定され、非依存トランザクションが順不同で適用されています。戻されたdest_instantiation_scnの後に接続先データベースでコミットされたsrc_pit_scnより小さいソース・コミットSCNを持つトランザクションが1つ以上存在しています。したがって、指定したソースSCNのソース・データベースと接続先データベースの表は異なる可能性があります。別のソースSCNを選択して、手順1から再度実行できます。
ソースSCNを使用して、ソース・データベースでフラッシュバック問合せを実行します。
手順3で戻されたSCNを使用して、接続先データベースでフラッシュバック問合せを実行します。
|
参照:
|
