  |
はてなキーワード: アーカイブログとは
以前在籍していた会社で企業向けパッケージソフトの開発をしていた。
お客様にそのソフトだけを売ることもあるが、サーバーへの導入など非IT企業には難しいので、維持管理も含めて契約していた。
私はアプリ側の担当者だった。パッケージソフト本体を作っていた。
導入、サービス管理、お客様のアプリが入っているサーバー（Linux）の保全などは維持チームが担当している。
お客様の要求に合わせたスペックにあわせた構成にするのも維持チームが担当するということになっている。
しかし、この維持チームはコマンドをコピペでしかできないわけだ。
なにか障害等が発生したときは当然アプリ側もバグの調査などでログを確認したりするが、サーバー側の不具合かどうかも我々が確認していた。
ミドルウェアの脆弱性が発覚したときもその対応方法の調査、手順の作成もした。
アプリ導入方法もミドルウェアの導入方法も我々がかいたものだ。
そのアプリがDBがもともと有償のあるDBしか対応していなかったんだが、PostgreSQLにも対応できるように機能改善した。
その時は差分バックアップの方法、リストアのやり方、ディスクが故障しても大丈夫なアーカイブログの保存法などの説明して、バックアップ設計までした。
なにせ、リカバリをする場合はリストアコマンド一つでできるもんではなく、ロールフォワードでどの時点まで戻すかという判断が必要になってくる。
ある時点で重要なデータを消したというのであればその時点より前までに戻さなければならないので、リストアのやり方の選択肢も状況により変わる。
あとPostgresは他のDBに比べてファイルをコピーしたりテキストを書いたりすることが多い。
Linuxのディストリが新しいバージョンが出たとき、アプリの動作検証も行ったあと、そのLinuxの導入手順書もつくったな
Apacheの導入手順も書いたな。
ミドルウェアやLinuxの使い方教えるのアプリ実装担当の範囲外じゃね？
でも維持チームにやれる人がいなかったのよ。
維持チームはつまり手順書というコマンドで動くシェルのようなもんだ。
Linuxの上にBashというシェルがあるが、その上に維持チームというシェルがあって、我々プログラマがその維持チームにコマンドを送っていた。
維持チームシェルの良いところはお客様の窓口になってくれたのでメールや電話はやってくれた。
全体、傾向変わりすぎ。午後ⅡはDBより業務を読み取るテストのような気がした。
----
午前Ⅱ
…1-15=DB、16-25=他（分散/BigData：4、Sec：3、他:3）DBでも新規が多くて面白かった。SQLがたくさん出た。19のAWES鍵長はアが正解。直前でイ→アにしてしまった。悔しい。
----
午後1
■問1：アフターサービス業務（イオだけ空白で43min。あとで戻って回答。）…傾向変わりすぎ！記載省略の網掛け部分が増えて難易度高い。
設問1
・SLP→SLPWeb問合せ ・問合せ--Web問合せ、通話（排他的サブタイプ）
・Web問合せ→発信通話 ・通話--発信通話（包含的サブタイプ） ・CC要員→通話
(2)
ア：媒体区分、問合せ年月日時刻、問合せ者氏名、電話番号 …「お名前」はさすがに属性名を変更した。
イ：問合せ内容 …ここが何もなかったのでやむを得ずアから問合せ内容を移動。エの「通話音声」と対応していると考えた。
ウ：SLP-BP(外)
エ：通話成立区分、社員番号(外)、通話時間、受発区分、通話音声
オ：Web問合せ番号(外) …3(6)「入ったWeb問合せに対して～電話をかける」より。
設問2
(1) (a) あ：製品シリーズ い：点検修理項目 う：案件
・ユニット→要点検修理FAQ ・要機能管理部品→(b)故障 ・FAQ→(c) ・FAQ→(e)
(2)（ついでにabcdefの関係名も記載）…連関祭り。それぞれの主キー＋αだけ。
キ：a=製品シリーズ：製品シリーズコード(主)、ユニットコード(主)
ク：b=故障：ユニットコード(主)、機能部品番号(主)、故障年月日 …ここの故障年月日は本文に無いが寂しくて追加した。
コ：d=案件適用FAQ：FAQコード(主)、案件番号(主)、可能性順位
サ：e=関連FAQ：FAQコード(主)、関連FAQコード(主)、関連度ランク
シ：f=FAQ点検修理項目関連：FAQコード(主)、MTコード(主)
設問1
(2) TBL名：見積依頼明細、見積回答明細 制約：商品(商品コード)への参照制約 …制約定義名もないので明確な制約だとするとこれだろう。
(3) (c)商品コード (d)適用開始日 (e)FOR (f)FOR (g)OLD2 (h)NEW2 …efミスった。トリガ構文が出るとは。e=AFTER,g=BEFOREが正解か。
(4) (i)2022-08-31 (j)2022-09-01 (k)NULL
(5) 商品の更新：3,5,6 商品履歴への挿入：1,2,4
設問2…ここは簡単な気がする。
(1) (ア)アーカイブログ (イ)5 (ウ)1800 (エ)864000 (オ)1728
(3)複製先でログをディスクに出力する前にフェイルオーバーした場合
----
午後2
■問2：フェリー乗船予約システム（120minギリギリ。これも傾向変わりすぎ。）
設問1
追加リレーション↓
・宿泊区画→船型別宿泊区画 ・運航スケジュール→運航スケジュール明細
・運航スケジュール明細→等級別在庫 ・航路明細→運航スケジュール明細
・航路明細→(ア)販売区間 ・航路明細→(ア)販売区間（2本目）
(2)イ：顧客登録無し予約客 ウ：顧客予約客 エ：顧客乗船客 オ：顧客登録無し乗船客
追加リレーション↓ …線少ない！書くところが無い！
・予約-乗船（1:1）
(3)カ：航路番号(主)、乗船港コード(主)、降船港コード(主)、販売区間名
設問2
(1) (a)TBL名：等級別在庫 列名：利用可能個室残数、利用可ベッド残数
列値：（以下3行。全て' 'で挟んだ。） …ミスった。C港じゃなく003とかのコードだった。
01、2022-3-14、C港、DX
01、2022-3-14、D港、DX
01、2022-3-15、E港、DX
変更列名：利用可能個室残数 …わからない。1名だし個室かなとしたがベッドでもよさそう。
変更内容：１だけ減算する。
(2) (a)積載可能車両残長の最小値 (b)挿入する行の車両全長 以上
(3)往路予定日の６日前以降であるが、復路予定日まではまだ７日以上ある場合
設問3 …なんとなくスルスル解けたが見直す時間が無かった。
(1)
(2)
(3)
(a)キャンセル待ち、仮予約、本予約、の状態を判別する …予約TBLに予約ステータス区分 を追加するとして。
(b)
(4)
TBL名：船内売上 追加列名：航路番号(外)、出発年月日(外)、乗船客番号(外)
(5)
まとめ精算番号（航路番号(主)、出発年月日(主)、まとめ精算番号(主)、乗船客番号(外)、精算合計金額）
----
ぶっちゃけタルいのがすげー嫌。
Oracle DBの使い方を習得するのに、一番最初に用意すべきなのはパソコンでもサーバでもない。
その教科書で、まずはスキーマやインスタンスやアーカイブログやREDOログといった、Oracle DBの仕組みや概念を学習する。
次にそれが実際のサーバ上でどんな風に見えていて、どうオペレーションするか…というアプローチを取らないと、絶対に動かないようにできている。
あーもうすげーめんどくせー。
なんでこんなにもったいぶっていて、無駄に固いんだか。覚えにくいことこの上ない。
それに比べると、PostgreSQLはフリーソフトなのに本当によくできている。
無駄な前置きは一切なしで、実際にいじりながら覚えていけるのでハードルが超低い。
てか、こういうのでいいんだよこういうので。
そもそもOracleのような「教科書と授業」みたいな形式で覚えてくのって、ストレージやアプライアンスを扱うのも仕事のうちという構築や運用の人間ならともかく、プログラマにとっては全く水が合わない。
だってCOBOLやFortranが主流だった大昔ならいざしらず、開発の世界じゃそういうのはC言語が出た時点で時代遅れになってるから。
まじで勘弁してほしい。
