このセクションでは、Oracle DDLのレプリケーションがアクティブなときに発生する多くの一般的な問題と解決策について説明します。SharePlex DDLのサポートの詳細については、「DDLのレプリケーションの設定ページを参照してください。
発生している問題がこのドキュメントに記載されていない場合は、SharePlexのナレッジベースを検索してください
ナレッジベースには、フィルタリングオプションや、SharePlexの使用とトラブルシューティングに役立つその他のリソースへのリンクが含まれます。
デフォルトでは、一部のOracle DDLのみが有効になっています。その他のDDLのサポートは、パラメーター設定で明示的に有効にする必要があります。
SP_OPO_STOP_ON_DDL_ERRパラメーターは、DDLの適用時にエラーが発生した場合にデフォルトでPostプロセスを停止させ、データベースの同期を維持するために問題を修正できるようにします。このパラメーターは1（オン）に設定する必要があります。有効にすると、以下のようなメッセージでDDLがスキップされたことが通知されます。
Skipping generic 9i DDL operation, schema (bob) could not be set.（汎用9i DDL操作をスキップしたため、スキーマ（bob）を設定できませんでした。）
FAILED DDL Replication for "create user bob."（「create user bob」のDDLレプリケーションに失敗しました。）
解決方法: 以下のパラメーターが適切に設定されていることを確認してください。これらのパラメーターを使用してDDLレプリケーションを設定する方法の詳細については、「Oracle DDLレプリケーションの制御ページを参照してください。
SharePlexは複製されたDDLをイベントログに出力しますが、2,000文字を超えるステートメントは切り捨てられます。ログに記録されるのは最初の2,000文字のみです。
解決策: 必要なし。
このトピックは、 SharePlexキューに関連するレプリケーションの問題を解決するのに役立ちます。
発生している問題がこのドキュメントに記載されていない場合は、SharePlexのナレッジベースを検索してください
ナレッジベースには、フィルタリングオプションや、SharePlexの使用とトラブルシューティングに役立つその他のリソースへのリンクが含まれます。
キューにデータが蓄積されると、 SharePlexのディスク容量が不足する可能性があります。以下に、考えられる原因とソリューションを示します。
| 問題点 | 説明 | ソリューション |
|---|---|---|
| レプリケーションプロセスの停止 |
レプリケーションプロセスが停止すると、データがキューに蓄積されます。 |
プロセスがユーザによって停止された場合は、その理由を突き止め、できるだけ早くプロセスを開始してSharePlexが蓄積されたデータを処理できるようにします。エラーが原因でプロセスが停止した場合は、show logコマンドを使用してイベントログを表示し、何が起きたかを調べます。その後、問題を解決することで、処理を続行し、キューのバックログを減らすことができます。 |
| 大規模な操作 |
まだCOMMITされていない大きなトランザクションを格納すると、postキューが大きくなることがあります。ロールバックとデータ復旧を可能にするため、 SharePlexはCOMMITを受信するまでpostキューにデータを保持します。 |
qstatusコマンドを使用してpostキューを表示します。Backlog (messages) フィールドの値が一定のまま、または縮小している一方で、Number of messagesフィールドの値が増加している場合、PostはCOMMITを受信するまでデータの開放を保留しています。 show post detailコマンドを使用して、Postがトランザクションを正常に処理していることを確認します。可能であれば、アプリケーションのCOMMITポイントを500に設定して、SharePlexが処理するSQLステートメントのサイズを小さくします。また、名前付きpostキューを使用する設定を作成することも検討してください。これにより、長時間のトランザクションが知られているテーブルを分離できます。詳細については、名前付きpostキューの設定を参照してください。 postキュー内のメッセージの蓄積がディスク容量の問題を引き起こす恐れがある場合は、Postが他のトランザクションからの処理の一部をクリアできるまでImportを停止することができます。詳細については、ディスク容量不足を解消する方法を参照してください。 |
| (Oracle）Captureがアーカイブログを処理している |
Captureがアーカイブログを処理している場合、アーカイブされたレコードが処理されている間、captureキューはディスクスペースを消費します。 |
ログ内のCaptureの位置がデータベースのそれよりもはるかに遅れている場合、ソースデータとターゲットデータ間のレイテンシが大きすぎて、ターゲットユーザを許容できない可能性があります。変数データディレクトリにディスク容量を追加するよりも、ora_cleanspを実行して、レプリケーション環境とキューをクリーンアップし、データを再同期して、設定を再アクティベーションする方が現実的な場合があります。 Captureがアーカイブログを処理しているために、SharePlexのディスク容量が不足し続ける場合、SharePlexサポートチームがCaptureのパフォーマンスをチューニングし、REDO設定を調整するサポートをいたします。 |
| ソース・トランザクション・アクティビティの計画外の増加 |
ソースシステム上のアクティビティが計画外に増加すると、データがpostキューに蓄積され、割り当てられたディスク容量の最大値に達する原因となります。 |
|
イベントログに以下のような一連のメッセージが表示される場合は、sp_copを停止してから開始します。
1 08-06-12 13:20:17.089485 2384 1 sp_ordr(rim) (for o.user queue o.user) Error opening output queue rv=9 que_open(-,writeuser+ X,0x0a02d364+PR+o.user+sp_ordr+o.user)
Notice 08-06-12 13:20:17.089485 2384 1 sp_ordr (for o.user queue o.user) data route to a02d364.48.7e failed err=100
Error 08-06-12 13:20:17.089485 2384 1 sp_ordr (for o.user queue o.user) 11004 - sp_ordr failure writing to queue(s)
Notice 08-06-12 13:20:17.089485 2384 1 sp_ordr (for o.user queue o.user) Exit sp_ordr to retry rim-write.
Info 08-06-12 13:20:17.089485 2384 1 Process exited sp_ordr (for o.user queue o.user) [pid = 8183] - exit(1)
SharePlexをホストしているシステムに障害が発生した場合、1つ以上のSharePlexキューが破損して、キューからの読み込みや書き込みにエラーが発生する可能性があります。この場合、purge configコマンドとabort configコマンドは使用できません。これらのコマンドは、キューに依存して動作するからです。
ソリューション: SharePlexサポートに連絡して、キュー破損の問題を解決してください。
postキューのサイズがそこに含まれるメッセージの数に比べて大きすぎるように見えても、それは珍しいことではありません。SharePlexpostキューは、実際には複数のサブキューから構成されており、それぞれがソースシステム上のユーザセッションにほぼ対応しています。サブキューには1つ以上のファイルを関連付けることができ、それぞれのデフォルトサイズは8 MBです。8 MBのサイズ全体が使用されない場合、データがポストされ、読み取りリリースされた後でも、ファイルはシステム上に残ります。
ソリューション: ステータス表示のpostキューのサイズは、すべてのキューファイルによって使用される実際のディスク容量です。SharePlex qviewユーティリティのtrimコマンドを使用すると、読み取りリリースされた古いファイルを削除できます。このコマンドは、まだターゲットデータベースにポストおよびコミットされていないデータを含むファイルは削除しません。qviewユーティリティの詳細については、『SharePlexリファレンスガイド』を参照してください。
このセクションでは、一般的な同期の問題の原因とソリューションについて説明します。これらのソリューションを試しても問題が解決しない場合は、 Questサポートにお問い合わせください。
発生している問題がこのドキュメントに記載されていない場合は、SharePlexのナレッジベースを検索してください
ナレッジベースには、フィルタリングオプションや、SharePlexの使用とトラブルシューティングに役立つその他のリソースへのリンクが含まれます。
トランスフォーメーションに関連するものを除くすべてのオブジェクトについて、SharePlexはレプリケートされたデータをターゲットにポストする前に、所定の操作におけるソースとターゲットのデータが同期していることを検証します。SharePlexは、トランスフォーメーションが使用されている場合は、同期を検証しません。これは以下の理由によります。
SharePlexはソースデータとターゲットデータが異なると判断した場合、エラー状態を生成しますが、postキューから他のデータのポストを続行します。Postが非同期状態を検出したときに完全に処理を停止させるには、SP_OPO_OUT_OF_SYNC_SUSPEND（Oracle）またはSP_OPX_OUT_OF_SYNC_SUSPEND（Open Target）パラメータを変更します。『SharePlexリファレンスガイド』のPostパラメータのドキュメントを参照してください。
非同期状態が発生すると、Postプロセスはステータスデータベースにメッセージを記録し、イベントログにも記録します。sp_ctrlでこれらのファイルを表示するには:
これらのコマンドを頻繁に使用して非同期エラーを監視します。
以下に、SharePlexが非同期状態をどのように報告するかの例を示します。
sp_ctrl (irvspxu14:8567)> show sync
Out Of Sync Status Database irvspxu14
Count Details
----- --------------------
3 Table "SCOTT"."TG_TEST1" out of sync for queue irvspxu14 since 16-Jun-
08 17:06:33
3 Table "SCOTT"."TG_TEST2" out of sync for queue irvspxu14 since 17-Jun-
08 15:47:58
1 Table "SCOTT"."TG_TEST3" out of sync for queue irvspxu14 since 17-Jun-
08 15:52:03
データが非同期になると、SharePlexは失敗したSQLステートメントを、 SharePlex変数データディレクトリのdataサブディレクトリにあるdatabase_ID_errlog.sqlファイルに記録します。
重要: ステータスデータベースとイベントログに非同期メッセージが表示されているのに、database_ID_errlog.sqlファイルにそのトランザクションのレコードがない場合、このメッセージを無視しないでください。ROLLBACKに関連している可能性があります。トランザクションがロールバックされるかどうかにかかわらず、SharePlexはソース行とターゲット行のプリイメージを比較します。両者が異なっている場合、データが同期していないことを意味します。トランザクションがソースでコミットされたが、ターゲットでは失敗した場合のみ、SharePlexは、database_ID_errlog.sqlファイルに記録して、問題解決のためのツールとして、および手動でステートメントを適用するためのツールとして（適切な場合）、適用されるはずだったステートメントの記録を提供します。ロールバックされたステートメントはキャンセルされた操作であるため、ターゲットには記録されません。
時々、非同期メッセージが誤りであり、データが非同期ではない場合があります。compareコマンドを使用してソースとターゲットのデータを比較することもできますし、手動で以下のcompareを実行することもできます。
compareコマンドで比較するには:
『SharePlexリファレンスガイド』のcompareコマンドを参照してください。
データが非同期であることを確認するには:
注意: テーブルに一意な列がない場合、Compareが誤った結果を表示する可能性があります。
以下に、データが同期しなくなる一般的な原因を示します。ほとんどの場合、SharePlexは非同期状態を検出し、エラーメッセージを返しますが、状況によっては非同期状態が隠され、SharePlexがエラーを返さない場合があります。
| 非同期状態 | 説明 | ソリューション |
|---|---|---|
|
間違ったクリーンアップ手順 |
database_cleanspクリーンアップユーティリティの1つが、アクティブな設定に関連付けられたシステムの一部（すべてではない）で実行された場合、SharePlexは非同期状態を認識します。 |
イベントログを表示して、すべてのシステムでクリーンアップユーティリティが実行されたかどうかを確認します。ログには、各システムで実行されたかどうか、またいつ実行されたかが記録されています。設定がアクティブになったかどうかや、いつアクティブになったかも確認できます。これらのイベントの時間を比較することで、何が起こったかを判断することができます。 この設定のすべてのレプリケーションシステムでクリーンアップが完了していない場合は、すべてのシステムでクリーンアップユーティリティを実行します。クリーンアップによってレプリケーションキューとプロセスが削除され、設定が非アクティブになるため、初期同期を再度実行する必要があります。 |
| DDLの変更 |
DDLに関連する非同期状態の原因には、以下のようなものがあります。
|
サポートされているDDLのリストについては、『SharePlexリリースノート』を参照してください。 手動およびSharePlexで行った重複するDDLの変更を元に戻すには、以下の手順に従います。
|
| ターゲットに対して直接行われたDMLの変更 | アプリケーションまたはユーザがターゲット上のテーブルにDMLの変更を加えた場合、その変更結果が隠れた非同期状態を作り出しますが、Postが影響を受ける行にレプリケートされた変更を適用しようとするまで認識されません。変更が適用されると、SharePlexは非同期エラーを返します。 |
レプリケーション中のターゲットテーブルへのすべてのDMLアクセスを禁止します。 compareコマンドとrepair コマンドを使用して、非同期行のテーブルを比較し、それらの行を修復することができます。詳細については、『SharePlexリファレンスガイド』のコマンドのドキュメントを参照してください。 |
| ターゲットオブジェクトへのトリガ |
ターゲットオブジェクトでトリガを無効にする必要があります。トリガはソースシステム上で起動し、SharePlexがその効果をターゲットにレプリケートします。 |
ターゲットシステムでトリガが起動した場合、トリガによって変更されたオブジェクトは同期がとれていないため、再同期する必要があります。詳細については、ソーステーブルとターゲットテーブルを再同期する方法を参照してください。 データが再同期された後、ターゲットOracleオブジェクトに対するトリガの効果を無効にするには、以下のいずれかを実行します。
|
| 不必要な制約 |
一方向レプリケーション設定でターゲットテーブルに必要な制約は、プライマリキー制約と一意キー制約だけです。CHECK制約は、ソース上で満たされるのでターゲット上では必要ありません。FOREIGN KEY制約とON DELETE CASCADE制約もソース上で満たされ、SharePlexはターゲット上の正しいテーブルに子の操作をレプリケートします。 Oracleターゲットの場合、SharePlexがON DELETE CASCADE制約を無視するように設定されている場合は、この制約を有効にしたままにしておくことができます。 |
レプリケートされたオブジェクトの制約を処理する方法については、「レプリケーションのためのOracleデータベースオブジェクトの設定レプリケーションのためのOracleデータベースオブジェクトの設定 |
| 設定ファイル内のエントリが重複している | ソース、ターゲット、およびルーティングマップが同一である重複エントリは、ターゲットへの二重ポストの原因となります。 |
設定ファイルを新しいファイルにコピーします。 新しいファイル内で重複を見つけて削除します。 再同期と再アクティベーションを実行します。詳細については、ソーステーブルとターゲットテーブルを再同期する方法を参照してください。 |
| ディスク容量不足 |
SharePlexにユーザトランザクションをキューに収容する十分な容量がないときに、ユーザトランザクションが続行されると、データが同期されなくなります。これは次のような場合に発生する可能性があります。
|
詳細については、ディスク容量不足を解消する方法を参照してください。 |
|
水平分割レプリケーションにおける列条件の変更 |
水平分割レプリケーションを使用すると、次のような場合に非同期状態が発生する可能性があります。
|
パーティションシフトが発生しないように、列条件を作成します。詳細については、水平分割レプリケーションの設定を参照してください。 |
| 設定変更後に再アクティベーションしない |
テーブルを設定に追加した後に設定が再アクティベーションされなかった場合、そのテーブルに対する操作はレプリケートされません。 注意: Oracleソーステーブルの場合、自動追加機能はデフォルトで有効になっており、名前が設定ファイル内のワイルドカードを満たす新しいテーブルはすべて、レプリケーションに自動的に追加されます。詳細については、Oracle DDLレプリケーションの制御を参照してください。 |
影響を受けるテーブルを再同期し、SharePlexがオブジェクトキャッシュを更新できるように設定を再アクティベーションします。詳細については、ソーステーブルとターゲットテーブルを再同期する方法を参照してください。 |
| キューの破損 |
システム障害などでSharePlexのキューが破損すると、キュー内のデータが失われる可能性があります。この場合、再同期が必要です。 |
詳細については、ソーステーブルとターゲットテーブルを再同期する方法を参照してください。 (Oracle）システム障害時のキューの破損を避けるために、パラメータSP_QUE_SYNCを使用することができます。『SharePlexリファレンスガイド』のキューパラメータのドキュメントを参照してください。 |
以下に、特にOracleデータベース間のレプリケーションに関連する一般的な同期の問題を示します。ほとんどの場合、SharePlexは非同期状態を検出し、エラーメッセージを返しますが、状況によっては非同期状態が隠され、SharePlexがエラーを返さない場合があります。
| 非同期状態 | 説明 | ソリューション |
|---|---|---|
| DDLの変更 |
DDLに関連する非同期状態の原因には、以下のようなものがあります。
|
サポートされているDDLのリストについては、『SharePlexリリースノート』を参照してください。 手動およびSharePlexで行った重複するDDLの変更を元に戻すには、以下の手順に従います。
|
| コンフリクト解決ルーチンが不十分、または存在しない |
コンフリクト解決手順は、ピアツーピア（アクティブ-アクティブ）設定で必要です。SharePlexはコンフリクト解決手順を使用して、異なるシステムから同じデータ変更を受信した場合に、どちらの操作をポストするかを決定します。 |
コンフリクト解決手順を修正してテストした後、データを再同期します。詳細については、ソーステーブルとターゲットテーブルを再同期する方法を参照してください。 |
| ログラップ |
Captureが必要なデータを処理する前にREDOログがラップした場合、アーカイブロギングが有効になっていないか、Captureが必要とするアーカイブログが削除されていると、データの同期が失われる可能性があります（通常、Captureはアーカイブログにアクセスし、レプリケーションを続行します）。 |
|
| LONG列 |
テーブルにプライマリキーまたは一意キーがない場合、SharePlexは、LONG列およびLOB列を除くすべての列に基づいてシミュレートされたキーを構築します。ターゲット行のLONG列が一意の値を含む唯一の列である場合、複数の行がシミュレートされたキーの条件を満たす可能性があります。SharePlexは、エラーを検出せずに間違った行にUPDATEまたはDELETEを適用し、エラーメッセージを表示することなくテーブルの同期が失われる可能性があります。 |
ターゲットテーブルの一意性が保証される列からキーを作成できれば、この種の非同期状態を避けることができます。キーを作成したら、それらのオブジェクトを再同期して再アクティベーションし、SharePlexがオブジェクトキャッシュを更新できるようにします。 プライマリキーや一意キーを追加できない場合（パッケージアプリケーションが使用されている場合など）、ターゲットシステム上の行の一意性は保証できません。 |
| キーの変更 |
テーブルが自動生成された数値シーケンスをキーとして使用している場合に、キーの値が変更されると、ターゲットシステム上で重複が発生する可能性があります。新しい値がターゲットシステム上の別の行のキーとして既に存在する場合、 SharePlexは一意キー制約違反と非同期エラーを返します。これは、x +n（n は増分）式を使用して値を更新するときに発生する可能性があります。x +n値のいずれかが既存の値と等しくなる可能性があります。 |
ターゲットシステム上で更新によるキーの重複が発生しないようにシーケンスを作成します。 |
| ソースシステムおよび/またはターゲットシステムで実行されているDBMS_SCHEDULERプロシージャ | レプリケーション外でオブジェクトが作成、操作、削除されるなど、これらのプロシージャの影響はレプリケーションは認識できない、またはサポートされていない可能性があり、その結果、データ変更が発生し、非同期状態を引き起こします。 | ソースオブジェクトとターゲットオブジェクトをジョブから除外します。 |
| 仮想プライベートデータベース | 仮想プライベートデータベースとして設定されているデータをレプリケートする場合、SharePlexデータベースユーザにデータをキャプチャするアクセス権がない可能性があります。そのデータへの変更は、ターゲットに反映されません。 |
そのデータをターゲットにレプリケートする必要がない場合は、分割レプリケーションを使用して、 SharePlex設定からデータを除外することができます。 データをレプリケートしたい場合は、SharePlexユーザに適切なアクセス権を割り当ててください。 |
| PK/UKロギングが有効になっていない | 特定のレプリケーションの問題は、キー値をロギングすることで防止できます。SharePlexは行IDに基づいてキー値を取得します。行IDを変更する操作（ALTER TABLE...MOVEなど）を行うと、その後のDML操作で間違ったキー値が使用される可能性があります。 | SharePlexでは、プライマリキーと一意キーの両方のサプリメンタルログを設定するか、レプリケーションのすべてのテーブルに一意の列のサプリメンタルロググループを定義することお勧めします。 |
データが同期されていない場合は、再同期する前に以下の作業を行ってください。
詳細については、ソーステーブルとターゲットテーブルを再同期する方法を参照してください。
compareコマンドまたはrepairコマンドで問題が発生した場合は、以下を参照してください。
発生している問題がこのドキュメントに記載されていない場合は、SharePlexのナレッジベースを検索してください
ナレッジベースには、フィルタリングオプションや、SharePlexの使用とトラブルシューティングに役立つその他のリソースへのリンクが含まれます。
| 問題点 | 説明 | ソリューション |
|---|---|---|
| Oracleエラー904 |
Error 904 calling oexec in de_select_prepare_to_fetch.（de_select_prepare_to_fetchでのoexec呼び出しエラー904。） compare対象のソーステーブルとターゲットテーブルの構造が異なるため、compareに失敗しました。compareコマンドとrepairコマンドは、同期していないDDL操作や構造的に同一でないテーブルに起因する非同期状態を検出してrepairすることはできません。 |
両方のテーブルに対してDESCRIBEを実行します。おそらくテーブルの列数が等しくないか、データ型が異なることが示されます。DDLの問題を修正した後、repairを実行して行の値を再同期することができます。 |
| 「ユーザ数が多すぎる」エラー |
Can not add DataEquator queue reader que_TOOMANYUSERS: User table is full.（DataEquatorキューリーダーque_TOOMANYUSERSを追加できません: テーブルがいっぱいです。） SharePlexのキューとの間で読み取り/書き込みをするプロセスの最大数を超えました。レプリケーションプロセスとcompareおよびrepairプロセスなど、20を超えるプロセスでpostキューに対し同時に読み書きすることはできません。repairでは、修復なしのcompareの場合よりもはるかに長い時間キューにアクセスするため、repairオプションが使用されたときにエラーが発生する可能性が最も高くなります。 |
回避策や制限を調整する方法はなく、制限を超えずに同時に実行できるcompareプロセスの数を決定する方法もありません。 ヒント: プロセスの制限を受けずに複数のテーブルを同時にcompareするには、compare usingコマンドを使用します。compareするテーブルを限定するには、compareするテーブルのみを含む新しい設定を作成し、その設定をcompareに使用します。（この設定は有効にしない）。すべてのテーブルが、プロセスを使用した1つのcompareで比較されます。 |
| クライアントプロセスが終了しない |
sp_desvrサーバプロセスが終了すると、通常は関連するsp_declt クライアントプロセスも終了します。プロセスが終了しない場合は、そのプロセスを強制終了することができます。 |
詳細については、compareプロセスの強制終了を参照してください。 |
| サーバのプロセスが終了しない | sp_declt クライアントプロセスを強制終了した場合、またはクライアントプロセスが終了した場合、あるいはsp_desvr サーバプロセスがクライアントと通信していない場合、sp_desvr サーバプロセスは、通常はSP_DEQ_TIMEOUTパラメーターによって制御される一定時間後に終了します。 | 詳細については、compareプロセスの強制終了を参照してください。 |
クライアントプロセスを強制終了するには:
sp_decltクライアントプロセスを強制終了する必要があるときに複数のcompareが実行されている場合は、以下のいずれかの方法で強制終了するプロセスを決定できます。
イベントログの表示により – イベントログには、各sp_decltクライアントプロセスの起動とそのPIDが記録されます。ログ内の後続のエントリは、プロセスが書き込んでいるcompareログファイルを記録します。そのエントリのcompareログファイル名の中にサーバプロセスのPIDがあります。例えば、以下のサンプルエントリでは、sp_decltプロセスPIDは2450です。このプロセスは、compareログ../o734v32a_declt- 1228-01.logに書き込みます。1228はサーバプロセスのPIDです。
05/04/01 17:01 Process launched: sp_declt (for o.o734v32a-o.o734v32a- 87056 queue all) [pid = 2450]
05/04/01 17:01 Notice: sp_declt(deq) (for o.o734v32a-o.o734v32a-87056 queue all) Opened DataEquator session log file /u10/julia30014/var7/ log/o734v32a_declt-1228-01.log
終了したサーバプロセスのログファイル名を検索し、そのログファイルに関連付けられているクライアントプロセスを探して、強制終了する正しいPIDを決定することができます。
サーバプロセスを強制終了するには:
sp_decltクライアントプロセスが終了したときにsp_desvrサーバプロセスを強制終了する必要がある場合は、イベントログでsp_decltクライアントプロセスが書き込んでいたログを調べます。イベントログは、各クライアントプロセスの起動とそのPIDを記録します。ログ内の後続のエントリは、プロセスが書き込んでいるcompareログファイルを記録します。そのエントリのcompareログファイル名の中にサーバプロセスのPIDがあります。例えば、以下のサンプルエントリでは、sp_decltプロセスPIDは2450です。このプロセスは、ログ../o734v32a_declt-1228-01.logに書き込みます。1228はサーバプロセスのPIDで、強制終了するプロセスです。
05/04/01 17:01 Process launched: sp_declt (for o.o734v32a-o.o734v32a- 87056 queue all) [pid = 2450]
05/04/01 17:01 Notice: sp_declt(deq) (for o.o734v32a-o.o734v32a-87056 queue all) Opened DataEquator session log file /u10/julia30014/var7/ log/o734v32a_declt-1228-01.log
© ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center
