構築ブロック > ソリューション固有の構築ブロック > オペレーション KPI 構築ブロック > データベース可用性の損失とその影響
データベース可用性の損失とその影響
DPM ソリューションでは、ソリューションが最初にデプロイされるときに作成される DPM データベースと ThingWorx データベースの、2 つのデータベースを使用します。データベースは、通常のデータベースメンテナンス、ネットワーク接続の喪失、ディスク障害など、さまざまな理由で使用できなくなる可能性があります。どちらか一方のデータベースが使用できなくなった場合、データオートメーションからのデータが損失しているか、このデータが重複している可能性があります。
• 損失したデータまたは重複したデータにジョブオーダー、材料マスター、またはターゲット数量のイベントが含まれている場合、後続のイベントおよび数は、正しくないジョブオーダーまたは材料に対して記録される可能性があります。
• 損失したデータまたは重複したデータに生産数またはスクラップ数のイベントが含まれている場合、生産およびスクラップのカウンタの値が不正確になる可能性があります。ロールオーバーカウンタの場合、これにはマイナスの波及効果があります。ロールオーバーカウンタの詳細については、データオートメーションの設定を参照してください。
DPM と ThingWorx の両方には、データベースが使用できなくなったときのほとんどのシナリオで、データ損失やデータの重複を回避するための次のようなプロセスが用意されています。
• バッチ処理中の任意の時点で DPM データベースが使用できなくなった場合、バッチ処理はその時点で終了します。PTCLastProcessedEventTimestamp プロパティは、最後に正常に処理されたイベントのタイムスタンプに設定されます。オートメーションイベントタイマーが次回にトリガーされるときに、未処理イベントデータに対して値ストリームがクエリーされます。現在の PTCLastProcessedEventTimestamp プロパティ値より後に発生するタイムスタンプを持つ、すべてのイベントが処理されます。これには、バッチ処理が以前に終了したときにまだ処理されていなかったイベントも含まれます。
• ThingWorx データベースが使用できなくなった場合、イベントデータが値ストリームキューに書き込まれます。ThingWorx には、データベースへの接続を再確立するための再試行メカニズムがあります。データベースが使用できるようになると、値ストリームキューからのエントリが値ストリームに追加されます。
このトピックでは、データベースが使用できなくなることでデータ損失やデータの重複が発生する可能性がある通常ではないシナリオについて説明し、これらのシナリオがいつ発生したかを特定するために何ができるか、および結果となるデータの問題に対処する方法について説明します。
データオートメーションフロー
これらのシナリオを理解するには、データオートメーションからイベントデータを処理するための高レベルなフローを理解しておくと便利です。データオートメーションのために設定されているすべての先導作業ユニットは、次のフローに従います。
1. データオートメーションによってイベントデータが受信されます。値ストリームキューに良質なデータが書き込まれます。値ストリームにキューからのエントリが追加されます。
2. オートメーションイベントタイマーがトリガーされ、バッチ処理が始まります。
a. 未処理イベントに対して値ストリームがクエリーされます。未処理イベントとは、PTCLastProcessedEventTimestamp プロパティの現在の値より後に発生するタイムスタンプを持つイベントのことです。
b. タイムスタンプごとに、クエリーされたイベントが順番に処理されます。
c. 各カウンタのグループに数を統合するために、生産数とスクラップ数がバッファリングされます。
d. DPM データベースにグループ化された数が挿入されます。
3. PTCLastProcessedEventTimestamp プロパティは、各イベントが正常に処理された後に更新されます。生産数とスクラップ数の場合、グループ化されたすべての数がデータベースに挿入されるまで、PTCLastProcessedEventTimestamp プロパティは更新されません。バッファリングされたすべてのグループからの最新のタイムスタンプが、PTCLastProcessedEventTimestamp プロパティ値として設定されます。
シナリオ
次のテーブルでは、データの損失や重複が発生する可能性がある通常ではないシナリオについて説明します。データオートメーションフローは、データオートメーションのために設定されているすべての先導作業ユニットで行われることに注意してください。シナリオが発生するタイミングに応じて、一部の先導作業ユニットに影響を与え、他には影響を与えないことがあります。
シナリオ
説明
結果
すべて同じタイムスタンプを持つ複数のイベントを処理している間、DPM データベースが使用できなくなる。
データオートメーションによって受信されたすべてのイベントにはタイムスタンプがあります。まれに、複数のイベントに同じタイムスタンプが指定されている可能性があります。これが発生すると、同じタイムスタンプを持つイベントは、ジョブオーダー、材料マスター、ターゲット数量、可用性、生産数とスクラップ数の順序で処理されます。
同じタイムスタンプを持つイベントが複数ある場合、そのタイムスタンプを持つ最初のイベントが処理された後に、PTCLastProcessedEventTimestamp プロパティが更新されます。
同じタイムスタンプを持つイベントがすべて正常に処理される前に、DPM データベースが使用できなくなった場合、そのタイムスタンプを持つ未処理イベントはすべて失われます。これには、そのタイムスタンプを持つ生産数とスクラップ数のイベントも含まれます。これは、オートメーションイベントタイマーが次回にトリガーされたときに、現在の PTCLastProcessedEventTimestamp プロパティ値より後に発生するタイムスタンプを持つイベントが、バッチ処理によってクエリーされるためです。
PTCLastProcessedEventTimestamp プロパティと同じタイムスタンプを持つ未処理イベントはすべて失われます。これには、生産数とスクラップ数のイベントが含まれます。
ThingWorx データベースが使用できなくなり、値ストリームキューがいっぱいになる。
ThingWorx データベースが使用できなくなると、データオートメーションから生じているイベントは、そのキューサイズに達するまで、値ストリームキューに追加され続けます。データベースが再び使用できるようになると、値ストリームキューが処理されて、値ストリームにエントリが追加されます。そこでは、オートメーションイベントタイマーが次回にトリガーされると、バッチ処理中にそれらがクエリーされます。
値ストリームキューがいっぱいになると、データオートメーションから生じている新しいイベントはすべて却下されます。
却下されたイベントは失われます。
ThingWorx データベースが使用できなくなり、ThingWorx サーバーが再起動される。
ThingWorx サーバーが再起動されると、値ストリームキューと永続キュー内のコンテンツはすべて失われます。値ストリームに追加されていたがまだ処理されていないエントリは保持されます。
値ストリームキューと永続キュー内のデータはすべて失われます。
ThingWorx データベースが使用できなくなり、接続再試行数は使い果たされ、ThingWorx がシャットダウンされる。
ThingWorx データベースの再試行メカニズムに設定されている再試行数が使い果たされると、ThingWorx サーバーはシャットダウンされます。ThingWorx 再試行メカニズムの詳細については、ThingWorx ヘルプセンターの ThingWorx でのデータの保管を参照してください。
値ストリームキューと永続キュー内のデータはすべて失われます。
ThingWorx のシャットダウン中に、データオートメーションから生じている新しいイベントはすべて失われます。
永続キューが処理されて PTCLastProcessedEventTimestamp プロパティが更新される前に ThingWorx データベースが使用できなくなり、ThingWorx サーバーが再起動される。
永続キューが処理されて PTCLastProcessedEventTimestamp プロパティが更新される前に ThingWorx データベースが使用できなくなり、ThingWorx サーバーが再起動されると、永続キューのコンテンツは失われます。PTCLastProcessedEventTimestamp プロパティ値は以前の値のまま残ります。つまり、すでに処理されており、DPM データベースに追加されている PTCLastProcessedEventTimestamp プロパティ値より後に発生するタイムスタンプを持つイベントは、再処理され、データベースに再び追加されます。
再処理されたイベントは重複データを作成します。
データベース可用性インシデントの識別
データベース可用性イベントによって、データ損失またはデータ重複が引き起こされるタイミングは、次の 2 つの方法で識別できます。
• 生産中に生産ダッシュボードを監視します。自動化された先導作業ユニットのオペレータは、現在の生産ブロックと展開されたイベントログの両方で、正しくないデータが表示されているタイミングを識別できます。
• 特に、データベースの可用性に影響を与える可能性があるデータベースメンテナンスなどのアクションが実行されていることがわかっている場合は、ThingWorx ログでデータベースの使用不可のエラーをレビューします。影響を受けた先導作業ユニットを識別し、生産ダッシュボードでデータをチェックして、欠落しているデータや重複したデータがあるかどうかを確認します。
データ問題への対処
このようなまれなシナリオを回避する確実なストラテジーは存在しませんが、実際に遭遇した場合の対処法を以下に列挙します。
• 個々の先導作業ユニットごとに、不正確な生産カウンタとスクラップカウンタをリセットします。
1. Kepware サーバーを停止します。
2. ThingWorx Composer で、先導作業ユニット Thing に移動します。
3. 「プロパティ」で、リセットするカウンタごとに、次の情報を含むように、行を PTCLastAutomationProcessedValues プロパティインフォテーブルに追加します。
▪ propertyName - 生産カウンタの場合は、PTCPoductionCount を入力します。スクラップカウンタの場合は、スクラッププロパティの名前を入力します。
▪ value - カウンタをリセットする値です。
▪ jobOrderUid - このフィールドは DPM によって無視されます。
4. Kepware サーバーを起動します。
生産カウンタとスクラップカウンタの詳細については、データオートメーションの設定を参照してください。
• 生産ダッシュボードを使用して、個々の先導作業ユニットごとに、欠落しているデータを手動で入力します。過去 24 時間以内の生産の場合、過去 24 時間中に発生した損失イベント、生産数、およびスクラップ数は、先導作業ユニットごとに手動で入力できます。さらに、最大 1 週間のスクラップイベントの履歴を追加できます。
• 生産ダッシュボードを使用して、個々の先導作業ユニットごとに、重複した生産数を手動で除去します。現在の生産ブロックについては、生産ダッシュボードの「生産エントリ」枠から、生産数を除去できます。過去 24 時間から生産数を除去するには、「時間損失の説明」ウィンドウを使用できます。
これは役に立ちましたか?