FC2ブログ

社内SEの徒然なる日記

データベース(Oracle)のメンテナンス!

■ 監視業務

月に1度、決まったタイミングでデータベースの状態をチェックしています。

具体的には、ストレージの容量、Oracleが使用してている容量をストレージのスライス毎に算出。テーブルスペース、データファイルの容量を取得。これを毎月保存しておいて、一ヶ月間のデータ増加量(の平均値)、ストレージの空き容量などを確認しています。

さて、私が管理しているシステムでは月のデータ増加量は2〜3GBって所だったのですが、いきなり増加量が10GBまで膨らんでしまいました。

・・・何かあったかな?

■ 調査&対応

詳細は省きますが、色々と調べて行くと、旧システムから現在のシステムにデータ移行するために作ったインデックスに根本的な原因があるようです。

そのインデックス自体は使っていないのは知っていたのですが、私がシステム管理を引き継いだ時には既にあったものなので、消してしまう勇気が出なくて残していたのです。

でも、こうなると消さないとダメですね。

って事で、とある日曜日にシステムを停止してメンテナンスを行いました。インデックスを削除して、念のために統計情報を取り直して・・・

うん、何だか久しぶりにエンジニアらしい仕事をした気がします。

■ 後書き

この類の仕事って、相応に知識と技術が必要な上に手間暇かかるし、上手くいっても目に見える変化がないので誰も褒めてくれないし、逆に失敗すると責められるので、やりたがる人は少ないと思います。

ただ、それでも私は結構好きだったりします。何というか、ゴミ掃除を終えてスッキリ!みたいな。

ここ数年は、自らプログラムを書くことも少なくなり、管理的な仕事が増えてきました。そういう仕事も嫌いじゃないし、むしろ得意ではあるのですが、やっぱり私はエンジニアっぽい仕事の方が好きなようです。

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

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

PageTop

改元対応の再調査完了!

■ 新元号の発表

新元号の発表日が正式に開示されました。事前の予想通り2019年4月1日だそうです。

・・・遅い!

確かに、大抵のシステムはパラメータを直すだけですが、一ヶ月前じゃ手間が増えるのです。

例えば、事前に2019年5月1日以降だった場合も「平成」と表示するようにプログラムを直し、新元号が発表されたら「平成」とした箇所を新元号に置き換えるとか。

言葉にすると簡単ですが、最近のシステム改修って色々と手続きとかあるし、他の案件との調整とかもあるので面倒なんですがね。

■ 再調査

それはそうと、改元に対する影響の調査自体は前年の内に終わらせていました(改元の対応が思ったよりも辛い(ListCreator))。

なのですが、そこで横から「全部、西暦にしよう」とかいう衝撃の発言が・・・

いや、パラメータを変えるだけで終わる機能(画面、帳票)については放置の予定だったんですが。そこを含めると影響範囲が増えるんですが。根回しもなく、いきなり宣言するのやめて!

ってことで、再調査ですよ。やれやれです。

■ 後書き

実のところ、もう手を付けないと間に合いそうに無いのですが、他に大きな案件があって調整が大変です。改元対応と、別の案件で機能が被っていたりするので、それをどうするのかって話もありまして。この様子だと、6月くらいまで引きずりそうです。

そうそう、基本的には和暦は廃止する予定なのですが、一部は和暦のままにします。例えば、手形とか。

もう西暦で良い気がするのですが、そもそも手形にプレ印刷されているし、勝手に西暦にしても受け付けてくれないだろうし、そうなると和暦で出力せざる得ません。

これ、手形の印刷もそうですが、合わせて手形に関係する画面や帳票も和暦で表示した方が一貫性があって使う方としては便利なんですよね。

あと、官公庁に関係するシステムも同じことが言えます。

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

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

PageTop

改元の対応が思ったよりも辛い(ListCreator)

■ 改元の対応試算

2019年5月1日に改元が行われるようです。システム屋としては、これに対応しなければなりません。そろそろ年も変わりそうなので、影響範囲を調べて見ました。

今のシステムは10年くらい前に作ったものなので、元号の変更対応は出来ているはず。手形の関係とか、一部の機能で和暦を使っていますが、データ自体は西暦だし、西暦と和暦の変換は共通処理になっているので、そこを修正するだけで対応完了・・・の筈だったのですが、実際に調べて見ると誤算がありました。

■ ListCreator(帳票)

まず、帳票に直接「平成」と書かれているものがありました。何かの冗談かと思ったのですが、本当に元号を直打ちしています。

・・・誰だ、こんな帳票作ったのは!

さらなる誤算がListCreatorの和暦表示。ListCreatorというソフトで帳票を作っているのですが、かなりの本数で和暦表示をしていました。

まともに対応すると、1ヶ月以上かかりそうだったのですが、ソフトウェアの変換であれば、何かの設定ファイルの変更とかパッチとかで対応できる気がします。

そう思って調べたのですが、ListCreatorには「和暦のカスタマイズ指定」が可能らしいという情報を見つけました。これで行けるかと思って、自分が使っているパソコン上で設定を弄って見たのですが、ListCreatorデザイナのプレビュー機能では確かに新元号への対応が出来ました。

これで行けるかと思ったのですが、ここに罠が・・・

実際にAPサーバの設定を修正して試して見たのですが、「和暦のカスタマイズ指定」が機能しません。どうしてだろうと思ったのですが、マニュアルを読むとCOBOLからの出力には対応していないとか。

だったら、Javaからだったらどうかと思ったのですが、こちらもダメです。

んで、こちらの理由はListCreatorのバージョン。「和暦のカスタマイズ指定」ってV10.4からの対応だったらしく、APサーバのバージョンはV10.0。

・・・結局、地道に対応するしかなさそうです。

■ 後書き

しかしこれ、富士通(ListCreatorの製造元)はどう考えてるんですかね。せめて修正パッチを提供するのが当然の対応だと思うのですが。対応しているバージョンにアップデートしろと言われても、Solaris(APサーバのOSはSolaris)に対応したバージョンってV10.0までだった気がします。

うーん、プログラムで和暦変換するって手もありますが、それよりも和暦表示を止める方が良い気がします。とりあえず、その前提で見積もりますかね?

ちなみに、Oracleの機能を使用した和暦変換も1機能だけ使っていたのですが、それはプログラムを書き換えることにしました(Javaで作った共通処理で和暦変換する)。Oracleの設定で対応することも可能みたいですが、たった1機能しか使っていないのであれば、プログラムを直した方が早いです。

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

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

PageTop

年度変わりの組織変更と業務組織の機能集約の影響

■ 問い合わせ

私は社内SEなので、現場の人間から色々と相談を受けて、基幹システムを修正したり、業務の自動化を行ってきました。もう20年近く会社にいるので、私が作ったツールが多数社内に存在しています。

普段は意識していないのですが、この時期(4月、5月)になると、それに対する問い合わせが頻繁に発生するようになります。

何でかというと、年度変わりで組織変更したり、人事異動をしたりするので、担当者が変わるのです。その時に前任者から引き継ぎは行われるのですが、伝言ゲームのごとく情報に漏れが発生して、結局はこちらに問い合わせがくることになります。

・・・そんな、何年も前に作ったものなんて覚えていないよ。

■ 業務組織

さて、勤め先では、今年は管理系の部門で大きめの組織変更が行われました。

その中で、これまでは営業部門の中にいた業務サポートの人員を、一つの業務部を作って集中させることになりました。ですが、まともに機能していないようです。

基本的には営業をサポートする部署ではあるのですが、明確に部署が別れると仕事って頼みにくいんですよね。その結果、誰にも頼めずに自分で抱えることになってしまいます。

前述の問い合わせですが、取引先から送信される納品データを変換して基幹システムに取り込むというツールに対するものだったのですが、私の記憶では業務サポートの人が処理を行っていたはずです。

なのですが、実際の問い合わせは営業の課長クラス。一体どうしたのかと思ったら、これまで頼んでいた人が人事異動で全員いなくなり、部署も分けられてしまって頼めなくなったので、自分でやっているとのこと。

・・・何だかね。

■ 後書き

各部署に散っていた業務サポートの人員を集めて部署を作るって発想そのものは、理論としては間違っていないのでしょうが、現実的にはなかなか機能しないものです。

勤め先でも、管理系の部門の人間の主導で時々行うのですが、数年後には営業から仕事が廻らないとクレームがついて、元どおりに各部署に人を配置するようになるという流れを何度も繰り返しています。

構想としては、各部署から仕事を請け負う組織としたかったのでしょうが、部署が別れた段階で、仕事を頼むのが大変になるので、結局は自分で抱えてしまうんですよね。

さて、今回作った組織は何年持つかな?

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

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

PageTop

絵に描いたようなシステム導入失敗の進み方

■ 失敗事例?

ここ数年、会社に銀行出身の人たちがやってきて、新部署を設立して何やらやっています。勝手にやっていれば良いと思うのですが、火の粉が我が身に降りかかってきたので、人ごとではなくなりました。

奴らは、何やらシステムを導入して業務を効率化するとか言っています。

それが悪いとは言いませんが、現状分析も何もせず、ベンダーや商品の選定もせず、これまで付き合いのなかった会社からシステムを購入して話を進めようとします。

口が上手いのか、経営陣にはうけが良いらしく誰も反対せずに導入決定。なのですが、そこからの進め方が・・・

導入するシステムを使うのは営業系の部門なのですが、その打ち合わせには管理部門の人間しか参加していません。

我々システム部門の人間には、一切相談なくベンダーやシステム構成まで決めてしまって決裁まで進めてから、「基幹システムから連携しろ」とかって上から目線言っています。

・・・何か、システム導入が失敗する典型的な進め方だなぁと思う、今日この頃です。

■ 後書き

他所から来た人間は、短期間に何らかの成果を求めるようで、そのために分かりやすいのがシステム導入による業務の効率化です。

だからこそ、システム導入のノウハウを持つシステム部門の承諾もなく話を進めているのでしょうが、さて、どうなるでしょうかね。

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

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

PageTop