データベースMeetup(Vol.1)に参加!!
こんばんは、カズやんです。
本日は、振替により会社は休みです。
久しぶりに、ゆっくりできるので、ひたすらDBの勉強をしていましたが、
午後から渋谷でMeetupに参加してきましたw
大学が渋谷にあったので、道玄坂とかその辺には大変お世話になりましたが、渋谷にくるの自体は本当に何年ぶりとかそんな感じです。
今日お邪魔したのは、渋谷公演通り前ビル８FのTECH PLAY
エントランスがめっちゃいい雰囲気www
Theベンチャーって感じのラフな会場にスーツを着た大人が勢揃いでちょっと不気味でしたww
参加者は、大半が30歳以上で、平均年齢40歳くらいな感じです。
私と同年代は一緒に参加した会社の同期以外はおそらく1人もいない感じでしたw
AWSの方のデータベースのヒストリーとSAP Hanaの優位点についての説明。
最後に、アクセンチュアの花木さんのお話がこれまた技術だらけの話で超長いのですが、かなりためになる話でしたww
とりあえず、キーワードは
・インメモリデータベース
・カラム型
の2つは説明できれば今日のゴールは達成できたのではないかと思います。
最後の話が長すぎて私が一番聞きたかったパネルディスカッションは割愛され、懇親会になりました。懇親会はなかなか盛り上がらなくて笑いましたが、基本的に皆さん典型的なエンジニアで自分からは話しかけないですが、技術の話になるとクソほど止まらないという感じですwww
私が会話した方々は、ベンチャーでデータサイエンティストとして業務を行なっている方々が多く、皆さんビッグデータの分析基盤を担当するエンジニアの方々でした。正直、彼らの話している日本語はなかなか意味がわからなかったので、HANA DBも勉強です...
私が、当初目標としていた同年代の友人を作るという目標は果たせませんでしたが、HANA DBがOracleに代表される従来DBとどのように違うのかわかった気がします。
新ためての詳細は後日書かせていただきますが、今はとりあえずOracle MasterのDBAのところを頑張るのが私のタスクだと思うので精進したいと思います。
SAPプログラムバッファに関して
こんばんは、カズヤんです。
今日は、SAPプログラムバッファ(別名、SAP実行可能バッファ、ABAPバッファ、PXA、プログラム実行領域)について考えてみます。
前回の投稿で、SAPのインスタンスには、ディスパッチャ、ワークプロセス、プログラムパッファが含まれることを書きました。
そもそも、プログラムパッファについて、そんな簡単に頭入ってこないので、じっくり考えようと思います。
そもそも、プログラムバッファ領域は何かというと、ちと難しいですが、ABAPプログラムの実行可能な処理(ロード)を保管する機能を持つ領域のことです。
プログラムバッファの内容はテーブル D010L (ABAP ロード) 、D010T (テキスト) 、および D010Y(シンボルテーブル)に保管されます。
プログラムバッファ領域のパフォーマンスは、SAPGUI上にて Trcd:ST02にて、確認可能です。
ST02を実行すると、プログラムバッファヒット率と表示されています。
ここでいうヒット率は、プログラムを実行した際に、どれほどのロードをメインメモリのみで処理できるかを示す割合です。もし、メモリで処理できない場合には、OS上のディスクに保存されているデータを読み込む必要があるため、処理に時間がかかります。
基本情報試験とかだと、確か、必要データがキャッシュメモリとか、ディスクキャッシュに存在する確率のことをヒット率とか言ってますが、あれのことです。
ヒット率は、90%以上であることが望ましく、特に95%前後であることが1番良いです。
プログラムパッファ領域が大きいことが望ましいことは言うまでもありませんが、この指標をみて大きさを再度調整することも可能です。
もし、バッファヒット率が小さい場合には、ログオングループの設定を行うことで、メインメモリのリソースを軽減できるそうです。
ただ、基本情報の学習も兼ねて、メモリシステム構成に関して再度復習の必要性を感じています。机上で学んだ知識が実践で問われてもまだ繋がっていないです...
英単語帳では、意味がわかるけど会話に入れられないような感覚っすね...
ちと課題が見えたので、明日その辺学習してみようと思いまする...
では、今日はここにて失礼します
アプリケーションサーバー（インスタンス）とは？
こんばんは、カズヤんです。
最近、フリーランスの話を先輩にしてからというものの、先輩のモチベが120%まで上がり、SAP社によるADM100という研修に沿った内容のテキストを用いて、バッグエンドの学習を見てもらっています。今日は、本当に基礎の基礎のインスタンスやログオングループのところを教えてもらったので、自分の知識定着のためにも共有させてもらいます。
僕はインフラエンジニア向けの研修チームにいたのですが、サーバーについてはよく分かっていません。
開発演習でDNSサーバーを構築しましたが今は何も覚えていませんwww
(DNSはドメイン名とIPアドレスを対応させているということ以外忘れましたwww)
SAPにおいては、アプリケーションサーバーはインスタンスと呼ばれており、SAP独自の構成となっており一旦しっかり学習しないと仕組みを理解するのは容易ではないと思います。以下にて説明していきます。
通常、アプリを開発する際には、OS上にアプリを乗っけますが、
SAPでは、OS上にNet Weaver というミドルウェアがあり、Net Weaverの中にBasisというコンポーネントが含まれています。これは、以前の記事においても説明しましたね
Basisの中には、インスタンスが存在し、インスタンスには以下の3つの要素が含まれます。ディスパッチャー、ワークプロセス、メインメモリ領域です。
■ディスパッチャ
処理の順番待ちをしているワークプロセスを効率的に配分する役割を担います。ディスパッチャは各ワークプロセスに1つのみ存在します。SAPに限らずLINUXとかUNIXなら、ps -efで見れますよね。てことは、ディスパッチャもあるはず..
■ワークプロセス
SAP Basisでは、下記5つのワークプロセスが存在します。
(1) エンキューワークプロセス
SAPレベルでのロック処理はエンキューワークプロセスにて実行されます。
セントラルインスタンスに特有のワークプロセスです。
(2) バッググランドワークプロセス
ダイアログワークプロセスと異なり、非対話型のワークプロセスです。
夜間バッチ処理など、時間やイベントがジョブのトリガーとなっている際に実行されるワークプロセスです。
(3) ダイアログワークプロセス
バッググラウンドワークプロセスと異なり、対話型のワークプロセスです。
対話型のため、ユーザがジョブを実行すると即座にプロセスが起動しジョブが実行されます。
(4) 更新ワークプロセス
時間のかかる処理はバッググラウンドにて更新が実行されます。その際に、更新ワークプロセスが実行されます。
(5) スプールワークプロセス
スプールとは印刷を実行する際に、データを直接プリンタに送るのでなく、処理の順番が来るまで待機することです。スプールワークプロセスがこのような処理に実行されます。
■メインメモリ領域（プログラムバッファ）
どのインスタンスにも、メモリ領域が存在します。このプログラムバッファにより、同じプログラムをわざわざデータベースに読み込む必要なく迅速に処理が行えます。プログラムバッファが大きければ大きいほど、プログラムの処理速度が高速になります。
これらを図にすると、下記のような感じです。
このポリゴンみたいのが一個のインスタンスだと思ってもらえればいいっすww
この隙間部分がプログラムバッファ領域という感じですね。
ちなみに、このワークプロセス数は自由に変えられるそうです。
ダイアログワークプロセスやエンキューワークプロセスは必ず1つ以上は存在しなければならないそうですが、お客さんがシステムに要求するパフォーマンスやシステムが耐えられる負荷次第で変更できるということです(SAP Note 39412参照)。
ただ、ワークプロセス数は構築案件での話ですので、運用の場合はワークプロセスと機能だけを覚えておけば問題ないはずです。
ちなみにあるインスタンスのワークプロセスのステータスに関しては、
SAPにおけるTrcd: SM50にて確認ができます。
SAP Basisの仕組みは、OSの仕組みと似ていることが多いので、OSのコンピューティングの仕組みに精通された方なら飲み込みが早いと思います。転じて、SAP Basisの仕組みを学べば、OSのコンピューティングの仕組みも少し詳しくなると思います。
SAP Basis業務をやられている方の助けになれば幸いです。
Oracle試験とSAPコンサル試験引き続き頑張ります。
では、今日はここで失礼します。
ハードウェア障害
こんばんは、カズヤンです。
今日は、朝から強烈な体験したので書きます。
月曜は日曜からの憂鬱な気持ちをなんとかふっとばさないとやってられないので、
電車の中で綿密に計画を立てて、出社しました。
8:30 〜 〇〇案件の手順書修正する
8:45 〜 IT資産の棚卸計画作る
的な感じでシミュレーションして、自分のフロアのドアを開けたら、
いつも10:00に出社する私の上司がなんと8:30に会社にいるのですwww
なんか超絶、悪い予感しかしないなあ...
と思って、
私：(上司)さん、おはようございます....
と言ったら、
上司：昨日、〇〇案件のサーバ落ちたのよ...
私：へっ？？、まじすか？？..
上司：おん、んで昨日の夜中までやりとりしててあんま寝てねえよ..
私：おおっ、お疲れ様です...
日曜夕方に優雅にウォーキングしていた自分が恥ずかしい....WWW
本番機サーバは、主系(DBサーバ)・従系(APサーバ)のクラスタ構成をとっているため、うまい具合に従系(APサーバ)にフェールオーバし、業務影響はなかった模様...
どうやら、H/Wの一部が壊れていたとかいないとか、それをシステムが検知して止まったらしい。うちの責任範囲外ということで処理は終わり。H/Wベンダーもこれが休日で助かったなとなぜか自分も安心..
ただ、OSのプロセスが落ちて死活監視(Ping監視)引っかかることなんてなかなか見れるものじゃないので、個人の興味としてとてもありがたい経験だと思います。
あとは、こんなトラブルが起きた時も先輩SEが迅速に対応する感じがなかなかかっこよかったのでモチベ更に上がっています。
今のチームに入って5ヶ月が過ぎたわけですが、たくさんの障害に遭遇してきて今までで一番大物の障害に遭遇できたので、月曜から特別な気分です...
本障害の後処理に追われて自身の業務が全然進まなかったのですが、色々学べた月曜でした...
イベント当選!!
こんばんは、カズヤんです。
先週寄稿したブログにて、SAPイベントが今週開催されることを触れました。
さっきPC開いてページ開いたらイベント当選通知が届いてました!! まじきたっ!!
当初は、応募者が50名のイベントでしたが(私が応募した段階で49名/50名ww)、なんと数回の募集枠拡張で130名までのイベントになっておりましたwww
ちなみに、イベントはデータベース勉強会という体制をとっており、アクセンチュア、Amazon Web Services、SAPの3社共催のイベントです。
「守・破・離」と3本だてになっているため、極力全部出て全貌を掴みたいところ...
最初の「守」に参加できることにとりあえず安心しましたww
今後の日程としては、下記のテーマで開催されるそうです。
Vol.1（守）：12/21(木) 「DB進化論」
Vol.2（破）：来年2月頃 「OLTPとOLAPを一つのDBで実現（仮）」
Vol.3（離）：来年3月頃 「インメモリデータベースの今後。カラム単位管理のデファクト化と新領域への適用可能性（仮）」
とりあえず、初回はDBの変遷の歴史をたどっていく感じから始まるのでしょう。そのあとは、HANA DBに関するところに触れていく感じかな(?)。
私も今年からDB管理者として業務を行なっていますが、今後2025年以降SAPシステムは、Hana対応を迫られるので、インメモリの仕組みに関しては理解して置かないとやばいはず...
参加者一覧を見ると、20代後半〜40代半ば的なレンジですね。
おそらく、皆さんかなりのDBもしくはSAPプロフェッショナルだと思うので新人の私が相手してもらえるか全くわからないところではありますが、いろんな情報交換できたら嬉しいですね。
学生の時は、ソーシャルセクターのイベントのお手伝いとかしていたので、こういうイベントって結構あったのですが、自分が本当にプロとしてやっている分野のMeetupイベントってかなりワクワクします!!
よく社内でも先輩と会話しますが、私の会社の運用体制と他社の運用体制ってどれくらい違うのかとかって結構気になっています。会社によっては技術者が多く、マネジメントが弱い会社では、そもそも作業手順書の配備がしっかりなっていないなんてざらみたいな話ありますからねww
ということで、3名くらい同年代のSAP Basisコンサルタントの人と知り合いたいですね。シニアの人になると会社に何十人もいるのでぶっちゃけその辺は不要ですねwww
あとは、イベントが木曜なのでそれまでOracleDBについて沢山学習してキャッチアップでせねばまずいです。
これに関しては、木曜結果報告ということで記事を寄稿します!!
では、またよろしくお願いします!!
SEとして海外で働きたい（③ドイツ移住に関して）
こんばんは、カズヤんです。
忘年会続きで、3日ブログを更新できませんでしたが、また今日から書いていきます。
結構、ブログを3日書かないだけで自身をリフレクションの時間があってある意味充実していました。今日は、そんなリフレクションの中から生まれたアイデアなのですが、ドイツ移住ってできるのかなと思って書いてみようと思います。
目次：
１、ドイツの魅力
２、日本との違い
３、ビザに関して
４、終わりに
１、ドイツの魅力
そもそもSAPってドイツの会社ですから、そのシステムが作られる本場に足を踏み入れたいというのは自然の願望だと思います。ちなみに本社はドイツのヴァルドルフという都市に位置しています。多くの日本人が駐在するデュッセルドルフなら聞いたことありますが、私もここは知らなかったです。
SAP Office Locations | Headquarters, Labs, and Training Centers
起源は、ドイツIBM出身のエンジニア4名がIBMで培ったシステム構築の知識をERP開発に注ぎ、そこで誕生したのがSAPというERPパッケージだそうです。
ドイツは、日本に次いで世界第４位の経済大国であり、自動車などの製造業がとても盛んな国として有名です。ギリシャのデフォルト危機の際にもEU内で最も発言権を持っていたドイツの動向が注目されていたことからも、ドイツのヨーロッパにおけるプレゼンスは高いでしょう。
さらに、敗戦国として日本と似た歴史を持っていることから、いかに今までの地位を築いてきたのか、学ぶべき点があると思います。
もう１点面白いのが、首都であるベルリンは世界のスタートアップシーンでも活躍しています、下記世界スタートアップランキングにおいてもベルリンは順位を上げてきています。どのランキングサイトがデファクトスタンダードなのかわかりませんが、2017年11月度の下記ランキングによると、ベルリンは全体の2位と記載されており、まさかのサンフランシスコよりも上に来てるのには驚きましたww ↓↓
私は、Basisコンサルタントという立場ですが、DBエンジニアとしても携われる機会がないわけでもないと思ってるので、新しいものがどんどん生まれるクラスター内で仕事がしていたいです。やっぱ、自分と同じITのフィールドで活躍されている多くのエンジニアの方と交流したい気持ちがあります。なお、大変残念ですが、このランキングトップに日本の都市名はありません…
２、日本との違い
■仕事に対する意識の違い
ドイツの魅力をあげるとするならば(日本以外の先進国はそうなのかも知れませんが)、ドイツでは日本ほど仕事中心主義の、いわばワーカホリックは存在しません。彼らは終日たくさん働き、土日は徹底的に休み、ビールを飲むのです。
あとは、集団を重視する日本の組織と異なり、ドイツでは個を重視するなど、組織に対する帰属意識が低いのも特徴だそうです。私のドイツの友人は、
会社は彼の夢を実現するためのツールに過ぎない
とか普通に言っています。私もフローランスやりたい人なのでその風潮には同意です。
■わりと英語で業務ができること
とても意外ですが、ドイツの求人は割と英語話者であれば問題なく受け入れてもらえるという側面があります。特に、ITに関しては、技術発祥がアメリカのものはソースが英語でリリースされるため英語が話せないと逆にまずいということだそうです。
なお。SAPに関しても英語話者であれば問題ない旨、SAP社の求人サイトに掲載があります。
SAP Basis-Jobs - Dezember 2017 | Indeed.com
ただ、ドイツで生活する以上ドイツ語を日常会話に一切問題のないレベルまで対応できる語学力は必要かと思います。
３、ビザに関して
■ワーホリビザから就労ビザ
私も最近ドイツに住んでいる友人から聞いた話ですが、ドイツでは31歳以下まではワーホリビザにより２年間国内で就労できるそうです。オーストラリアなどでは、国が定めた農業などの職業につく必要がありますが、ドイツでは関係なさそうです。そのため、就労ビザを取得するまでの期間の2年間をワーホリビザ取得して対応できれば今後のドイツでの生活の可能性を考えながら業務に当たれると思います。
４、終わりに
私は、今の会社に入社する前からリタイアしたらスイスのアルプスの麓で素敵なじいちゃんになるという謎の欲望がありました(「夢」ほど難しくなく実現可能なものであるためあえて、「欲望」と言っています)。ちなみに、スイスではドイツ語、フランス語、イタリア語が話されているため、ドイツ語の学習をすでに始めています。
ドイツ語は一見するとむずかしく感じますが、英語と文法が類似していたり、単語も似ているため、英語が問題なく話せる場合はそこまで苦労せず習得が可能だと認識しています。
丸3日ブログを更新していなかったにもかかわらず、50〜100PV/日で推移しており、ニッチブログとしてはかなり好調で、いつも本ブログを閲覧してくださる皆様には大変感謝しております。
他にも気になっている国がいくつかあるので、私が直接訪れた訳ではなく２次情報で恐縮ですが日本にいる間にこの妄想記事をどんどん書いていきます。
大変恐縮では、ありますが今後ともどうぞよろしくお願いいたします。
エンジニア？テクノロジーコンサルタント？
こんばんは、カズやんです。
今日は、エンジニアというよりテクノロジーコンサルタントでよくね？っという点について綴っていきます。
というのも、最近自己紹介するときに、
エンジニアやっていますカズやんです！！
っていうと、プログラミングできるんですか？とか言われるますが、実際はコーディングそんなできるわけでもないので困ります。あとは、世間一般的にエンジニアは地味で陰険な人が多いので、少しネガティブなイメージを持たれてしまいます。
そこで、少し前からですが、
テクノロジーコンサルタントのカズやんです！！
というようにしています。
この方が、なんか活き活きしていてポジティブな印象を相手に与えられるのと、なんと言ってもかっこいいこれに尽きます(ただし、単にコンサルとは言いませんw)
この理由についてちょっと語らせてください。
ひとえにコンサルと言っても最近では、戦略コンサル、 ITコンサル、財務コンサル、人事コンサル、オペレーションコンサルとか色々あってわけわからんですよねww
おそらくコンサルと言ったら戦略コンサルのことをさすでしょうし、皆さんも戦略コンサルを連想するでしょう。
ただ、そもそもコンサルってなんでしょうかね？？
人・企業が抱える問題をソリューションで解決する人のことをコンサルティング
というわけで、エンジニアもコーダーでない限りは、お客さんの課題に対してロジックを駆使したり、技術を駆使して解決するわけです。そういう意味では、コンサルやろと思いました。
あとは、SAP Basisって日本よりも海外に技術者がいるのですが、彼らのプロフィールってそのほとんどがSAP Basis Consultantになっています。
実は、日本ではSIerなどで業務を行う技術者のことをエンジニアと呼びますが、海外ではテクノロジーコンサルタントと呼ぶ風習が少なからずあるそうです。よくLinkedinで海外の技術者と連絡をとるのですが、あるインドの技術者でBasisは10年経験ある32歳の人ですが、聞くところによると彼の周りのSAP Basis技術者はコンサルタントと名乗っているそうです。これは、上記の問題解決の理念によるものだそうです。
ちなみに、お客様に提出するサービス提案書でも「SAP Basisコンサルタント」と明記されます。
今回は、SAP Basisの話を例に出しましたが、エンジニアの方は今後はテクノロジーコンサルタントと名乗りましょう！！
その方が、依頼する側のお客さんも単なる友人でも印象変わります。
私も、本ブログでも自己紹介する時も、
テクノロジーコンサルタント
と言いまくります。
※今はブログを少しでも浸透させたいので、タイトルはまだ「テクノロジーコンサルタント」にはしません。
すごい勝手な話でしたね、では今日は失礼します！！
SAPにおける表領域(Table Space)
こんばんは、カズヤんです。
今日は、Oracleを学んでいることから、現在SAP Basisで私が管理することもある表領域に関して書いてみようと思います。
まずは、表領域についてですが、表領域には表(テーブル)データが格納されています。表データは、システム内で用いられるデータがSQLによって整列された形で格納されたデータのことです。
例えば、給与計算システムがあったら、社員番号と給与は必ず記載があって、あとは年齢、性別、勤務年数、役職、名前などが一つの表になって記載されているはずです。
SAPはERPなので、これら給与に関するものだけでなく、あらゆる社内データをデータベースにて管理しアプリケーションで呼び出す必要があるため、大量の表データが存在します。その表データは表領域に格納されています。
特に、メジャーな表領域が
・PSAP<スキーマID>
・PSAP<スキーマID><リリース>
・PSAP<スキーマID>USER
これら3つの表領域がメジャーっぽいです。
まず、PSAP<スキーマID>に関してですが、全SAPオブジェクト対象のテーブルが格納されます。なお、SAPシステムのテーブルの中でもこのテーブルが一番容量が大きい気がします。
補足ですが、さすがに表の種類はアプリ担当が知るべきところなのでカバー外ですが、よく出てくるのが、BSISテーブルです。これは、SAP FI関連の会計テーブルで、総勘定元帳：未決済明細データを格納するテーブルだそうです。これめっちゃ出ますし、容量も大きいですww
次の、PSAP<スキーマID><リリース>に関してですが、これはリリース依存のテーブルが格納されます。例えば、SAP Basis 700とかのリリースなら、PSAPSR3700みたいな感じの名前でよく出ます。リリース依存のため、量は少し小さくはなりますが、大切なところです(口では、そう言いますが、実際どんなデータが入っているか調べていませんwwリリース依存だから、そのバージョンのみ使用可能なAddonや修正パッチのことだと思います)。
最後に、PSAP<スキーマID>USERに関してですが、これは全カスタマオブジェクト対象の表領域です。カスタマオブジェクトとは、おそらくですが、ユーザーがカスタマインジングしたオブジェクトということだと思います。これ、調べてもあんま出てこないので濁しておきます。ただ、これも、ユーザ固有のものという意味では大切な表領域なので絶対知っておいた方がいいです。
今日は、SAPシステムにおけるメジャーな表領域について共有しました。SAP Basisコンサルタントの重要な業務であるDB管理の中でも表領域管理はとても重要です。中でも「表領域拡張作業」は覚える必要があると思います。これは、特別なBRツールにて行う作業で、SAPコンサルとかでもでるらしいです。
正規のOracle Masterとは逸れましたが今日はここまでで失礼します。
では、また!!
