社内SEの徒然なる日記

今度の開発案件は在庫の発注サポートシステム No1 構想

■ 状況

勤め先では、在庫品の管理は各部署単位で行っています。管理系の部門としては在庫の集中管理をしたいのですが、同じ商品でも部署が違うと原価が異なるため、現場が在庫統合を嫌がるのです。

それに、在庫の発注担当からすると、自分が管理する在庫を使うのは自分の所属部署(つまり、立ち上がって見渡せる範囲にいる人達)だけなので、管理が楽というのもあります。

なのですが、時代が徐々に変わって行って、部署管理から集中管理に方式が変わりつつあります。

■ 在庫管理

さて、そうなると在庫品の荷動きの予想が難しくなるという問題が発生します。受注時に出荷する日付が決まっているのなら話は早いのですが、在庫を使うのは決まっているが出荷日は未定ということが良くあります。

現状の在庫システムでは、現在の在庫数、引当済み数、未引当数は把握できます。出荷日が未定の場合、未引当数にカウントされるのですが、これがいつ頃に出荷されるのか見当がつかないので、在庫品を発注するタイミングが分かりにくくなったそうです。

ってことで、この問題をなんとかする在庫品の発注サポート機能を作ることになりました。

■ 後書き

単純に考えれば、在庫に下限数を設定しておいて、それを下回ったらアラートを上げるという仕組みで良いのでしょうが、これだと問題が解決しない気がします。

色々と知恵を絞っているのですが、過去の入出荷の実績、在庫回転率、出荷数量の標準偏差、発注から入荷までの平均日数、伝票起票から出荷日が決定するまでの平均日数あたりから、適正在庫数を算出できないかと考えています。

理想としては、在庫管理の経験が少ない人でも困らないようなものにしたいところです。さて、上手く作れるかな?

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

基幹システムの移行!(2017)移行と後始末

■ 基幹システム移行

去年(2016年)からずっと取り組んでいた基幹システムの移行(基幹システムの移行!(2017)基幹システムの移行!(2017)の徹夜でダウン(風邪)DBサーバのディスクをSSDにしたら高速移行が出来た)ですが、ようやく完了しました。

しかし、本稼働後に少し問題は出ました。

Oracleのバージョンが11から12に変わったのですが、その影響か一部の処理(というか、SQL)が異様に遅くなりました。DBサーバの膨大なメモリとSSDの力で何とか業務が止まらない程度の速度は出ているのですが、ちと問題です。

統計情報に問題があるのかとも思ったのですが、取得し直しても結果は変わらず。色々と対応方法は思いつくのですが、素直にヒント句を追加して性能の安定を図りました。

他にもパラパラと出てしまいましたが、大きな目線で問題になることはなかったので一安心です。

■ ラックの移設

本稼動から数週間。今度はラックの移設を行いました。

新しいサーバー(などの機器)は、一時的に借りたラックに置いていたのですが、月を跨ぐと費用が発生してしまいます。今更切り戻しってこともあり得ないので、古い機器を撤去して、その場所に移設することにしました。

言葉にすると簡単ですが、IDCの機器って普段は電源入れっぱなしってのが多いので、移設に合わせて電源の入れ直しをするのは実は結構なリスクがあったりします。

電源の入れる順番を間違えると起動しないとか普通にあるし、電源を入れた後でさらに別のサービスを起動しないと行けなかったりと、きちんとシステム構成を把握していないと大問題に発展します。

ってことで、電源の停止&起動の順番を考えて、稼動後の確認手順を作成して、私がいなくても問題なく作業できるように関係者に周知して、そうそう、移設作業中はシステムが使用できないので現場に連絡して、うん、意外とやることありますね。

・・・・・・・・・・・・いや、基幹システム自体の持分は私ですが、ラックの移設って別の人の担当だったような気が。まぁ、別に良いんですけどね。

■ 後書き

遅くなったSQLを見ると、片方はWITHで作った内部テーブルを抽出条件として使用するSELECT文を UNION ALL でくっ付けています。実行計画を見ると、何故かWITHの結果を見ないで妙な条件で再抽出するような奇妙な動作をしています。もう片方はSQLを引っこ抜いて実行計画を見ると特に変な感じはしません。

前者は結構知恵を絞りました。使用するインデックスの指定だけではダメで、テーブルの結合順番まで細かく指定して、ようやく望みの実行計画になってくれました。Oracleのオプティマイザって徐々に良い感じに動くようになっているとは思いますが、逆に言うと妙な動作をするようになったのなら、チューニングも手間が掛かるようになったとも言えるかも知れません。

問題は後者の方です。Enterprise Managerで実行時のSQLを見るとマスタ系のテーブルをフルテーブルスキャンしたり、明らかに参照していない項目を使ったインデックスを使っていたりと、奇妙な実行計画になっています。

しかし、そのSQLを引っこ抜いてSQL Developerで実行計画を取って見ると、良い感じに実行計画を作っています。こういった特定の条件下で発生する遅延って厄介です。

まぁ、実は原因は想像がついていて、おそらくCOBOLから実行しているのが良くないと思われます。COBOLからOracleを使うには、ソースをPro*COBOLプリコンパイラなるものを通して変換する必要があるのですが、その変換に何やら問題がありそうなのです。

こうなった時の対策は、ヒント句を突っ込むのが手っ取り早いです。

いや、正確には動的SQLにしてやればPro*COBOLによる変換を回避できるようなので、そっちにするって手もあるのですが、埋め込みSQLを動的SQLに書き換えるのは少し手間だし、ヒント句の追加に比べてリスクが高くなるので避けたいところです。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

DBサーバのディスクをSSDにしたら高速移行が出来た

■ システム移行

少し前に書いていましたが、ゴールデンウィーク中に基幹システムの移行を行います(基幹システムの移行!(2017))。

作業を要約すると、Oracleのエクスポート&インポートという方式なのですが、やはりデータ量が多いので、それなりに時間が掛かります。

今から6年ほど前にも同じように移行をしたのですが、その時はエクスポートして、インポートして、アナライズを実行して・・・とか夜通し実行を続けて、丸々2日掛かりました。

■ SSDの力

今回も同様の方式で移行したのですが、これが恐ろしく早いです。インポートが3時間、アナライズも1時間程度。Oracle以外にも移行するファイルは存在したのですが、そっちの方が時間がかかったくらいです。

何故こんなに早かったかというと、ぶっちゃけるとDBサーバーのディスクをSSDに変えたから。やはり非接触式のディスクは性能が違います。ちと高くはなりましたが、これだけ早くなるなら投資した価値があるというものです。

■ 後書き

そういう訳でして、日が暮れる前に移行が終了しました。終了といっても、移行計画としては翌日の作業もあるので完全に終わりって訳ではありませんが、主要な作業は終わったので終わったようなものです。

事件が起こるとしたら、ゴールデンウィーク明けにユーザーが使い始めてからですね。

さて、軽く祝杯でもあげようかな?

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

プロジェクトリーダー(自称)だが、メンバーが・・・

■ プロジェクト計画

少し大きめのプロジェクトが動いてい、私が実質的なプロジェクトリーダーとしてプロジェクト計画を立案して進めていました。

ここで指標とするのが、以前学んだプロジェクトマネジメント。まぁ、資格試験の結果は残念なものでしたが(プロジェクトマネージャ、ダメでした・・・)、学んだ知識は無駄ではありません。

ってことで進めているのですが、計画立案において困ったのが人員の割り振りです。

■ 人が振れない、動かない

勤め先の部署は、いわゆる情シスなのですが、10年近く前の基幹システムを再構築しています。それまでのホスト系から、WEBアプリに乗せ替えたわけです。

その結果、それまでホスト系で育ってきた人員のスキルが途絶え、当時若手だった私だけが技術面の担当となりました。

そう、そうなると今のシステムの技術面に関する事に関して振れる人間がいない。若い人間がいれば、将来の成長を見越して出来なくても担当してもらうのですが、見回すと50を過ぎ、60に迫るオッサンばかりで、流石に振れない。

この時点で、私がプロジェクトリーダーと実務担当を兼任することが確定。それでも、運用面や技術に関係ない件に関しては割り振ったのですが、動かなかったり、進捗管理表に入力しなかったり、エビデンスがいい加減だったり、勝手に作業を追加したり・・・

■ 後書き

まぁ、部署自体が良くある(と思う)属人化が進んだ部署なので、計画に従って仕事を進めるという事に不慣れ&勝手にやりたいって人間ばかりなので、こうなるのは分かってはいました。

なので、プロジェクト計画もそれを前提として緩く作りましたし、公式な進捗管理はかなりザックリしたものにして、私自身がメンバーに口頭で話しかけて実体の把握に務めるようにしていたので、プロジェクト自体としては上手く廻ってはいるのですが、もうちょっと計画的に仕事を進められる組織にしていきたいものです。

しっかし、メンバー全員が私よりも年長なのに、プロジェクトリーダーが私と言うのは、ちょっとやりにくいですね。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

基幹システムの移行!(2017)の徹夜でダウン(風邪)

■ バックアップ

勤め先の基幹システムは、夜間バッチが動くタイプのシステムです。日次処理、月次処理とあって、年次処理もあります。

さて、基幹システムの移行に伴って夜間バッチのテストもしているのですが、今は4月上旬で、ちょうど年次処理を実行するタイミング。これ幸いと、年次処理直前のバックアップを移行して、新システムでテストすることにしました。

さて、問題は年次処理直前のバックアップです。Oracleのエクスポートを実行したいのですが、日々の運用では夜間バッチ前のデータは抜いていません。ってことで、私がジョブスケジュールを調整して手動でバックアップを取得することにしました。

■ 徹夜

夜間バッチと言うだけあって、処理が夜間に実行されます。なので、その日は遅い時間に出社させてもらいました。シフト勤務ってやつです。

んで、バックアップを取得して、夜間バッチを手動実行して・・・と一連の作業を続けて、全てが終わったのは朝の6時頃。当初の予定では帰宅して少し休んでから出社するつもりだったのですが、色々と会議とか検討事項とかがあって帰れない・・・

結局、24時間を超える勤務になりました。そして、帰宅後はシャワー&ベットに直行。

・・・翌日、喉が痛い。

・・・・・・さらに翌日、体が気だるい。

風邪ですね。

■ 後書き

たった1日の徹夜で風邪を引くとは、私も年を取ったものです。筋トレとかに精を出しているので、単純な体力だけなら若い頃よりもあるはずなのですが、寄る年波には勝てないと言うことでしょうか。

ま、深刻な状態ではないので、このまま安静にしていたら仕事に影響はなさそうです。

それにしても、私が後を託せる人間が早く欲しいものです。そうすれば、もうちょっと楽になるのですが。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop