ロックテーブルのオーバーフロー - CIO目指すITコンサルタントの備忘録

こんばんは、カズヤんです。

結構、業務を振り返ると対応してきたインシデントってあるもので、今日はその中の1つを紹介します。

といわけで、「ロックテーブルのオーバーフロー」について説明します。

これに関しては、SAPのNoteが正式にリリースされているので、SAP Basis管理者の方でしたら、そちらを見ていただいた方が確実に早いのですが、今回は、新人の私の理解を助けるためにも書かせていただきます。

そもそも、ロックテーブルについてですが、

ロックテーブルは、エンキューテーブルとも言いますが、何かプログラムを実行する際に、システムに事前に定義されたテーブルをロックします。システムによってまちまちですが、大量の処理を実行するプログラムの場合には、大量のロックテーブルを取得することがあります。

ロックテーブルのオーバーフローとは、

大量のロックを取得するプログラムを実行した際に、システムで事前に定義していたロック数以上のロックを取得することになり、ロックテーブルが飽和する状態を指します。つまり、取得要求ロック数 > 定義済みロック数となるとオーバーフローが発生します。

ロックテーブルのオーバーフローが起こった際には、

対策としては、特になく、大量処理が終わるのを待つのみですwww

ただし、オーバーフローが起こる前の対策として、以下の2つの対応が可能です。

１、SAPパラメータenque/table_sizeの拡張を事前に実施する。

パラメータenque/table_sizeはSAPシステムにおいて、取得可能なロック数を定義するパラメータです。このパラメータの数値はシステム上で変更することが可能なため、事前に大きめの値に設定しておくことで、大量ロック取得に耐えることが可能になります。

２、ロック大量取得プログラムを実行しない

何らかの理由で、enque/table_sizeを拡張できない場合には、ロックを大量に取得するプログラムをそもそも実行しないことで回避できます。プログラムを改修して、分割することなどなども1つの手段かと思います。

Trcd:SM12を利用して、どのロックテーブルでどれだけロックを取得していて、どのトランザクションが該当するかも記載があるため、確認が可能です。

本情報はSAP Note746138、もしくは、下記リンクから確認いただけます。

SAPにおいては、大変メジャーなインシデントだということですが、

実際これが起こるとかなりビビります。

私が、このインシデントを知ったのは、週次MTG途中に別チームの方が部屋に来られて、

〜システムのジョブが全部落ちてます！！と連絡が来ました

というわけです.....

この時は、アサインされて3日の出来事だったので、正直くそ焦りました。

先輩とPMがたまたま居合わせたので、彼らが秒速で稼動確認を実施し、SM21のシスログ確認してNoteが該当したので、ことなきを得ましたが、本当に無力で怖かったですね。今もし、障害出たらビビるとは思いますが、自分で対応できそうな自信はあります。

一応、私の知識整理のために今回の記事を書かせていただきましたが、経験者の方で詳しい方いらっしゃいましたら、積極的なコメントをおまちしております。

それでは、今日はここまでにします。