初めまして。これから開発の不具合あるあるを紹介していきます。UPDATE時のWHERE句の重要性

SQL

初めまして。

このブログでは、今まで数多く経験した不具合やトラブルその対応などを紹介していければと思っています。

自警の意味合いと、少しでも私の経験から皆様が同じ過ちを繰り返さないための礎となれれば、、と大層ことを言ってみる。

おそらく皆様に共感していただけるのではないかなー、、、、、なんて思っています。

応援よろしお願いします。

 

まずは自己紹介をちょろっと、

大学卒業後からITの開発の仕事を14年ほどやっています。いわゆるSEをしています。

最初の3年は組込み系でPGとして派遣されてました。

その後は受託開発の会社でWEBを8年ほど。ここでPG⇨SEになりました。あるあるですね。

その後に、サービス系のWEBを3年ほどやっております。

これ以上は身ばれしちゃうので、、悪しからず。

 

では記念となる第一回目の不具合を紹介します。

 

私が開発経験4年目の頃の登録制のWEBサイトでの話です。

あるお客様と外出先で打合せ後に、ついでにメンバーのデータの修正をお願いされました。

わかりました〜。と一声で承り、自社に帰って、変更内容をメールを確認。

ふむふむ、ユーザーIDを3名変更すれば良いのだな。

ちょろいちょろいと、お客様のサーバに入り、まずは1人目の update文を作成し

おらよっと。タン、タン、タターン。でSQLをコンソール上で実行。

あれ、なんか反応遅いな、、なかなか返ってこない。

うーん、

ん、

ん、

あれ?

あ、

あ、

あ、

where句抜けてる、、、

あーーーーーー、

ctrl + C でキャンセル。これの反応も遅い、、、

これって、、、、

もしかして、、、、、

全員のユーザーID変更したんじゃ、、、

焦りながらも、SQLで調べると、

やはり、ほぼすべて、同じIDに変わっている、、、、、、、、、、、

ひとまず落ち着いて。

うん、オワターーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

社内の上司(営業さん)に報告。

とは言っても、1人1人が独立してやっている会社なので、営業も他の開発も助けてくれるわけでもなく。。。

お客様(結構大企業)に事情を説明。

激怒するというよりは、冷静に、復旧手段を考えてくれとのことで

必死に考えました。(この時点で夜10時)

ひとまずサイトはこの時点で停止されました。

 

まずは昨日時点の、バックアップDBがあることをお客様に確認。

トン、トン、トン、よし!と一休さん並に思いつきました!!!

復旧手順1:バックアップDBがある分はユーザーIDをメールアドレスの一致で普及し

復旧手順2:バックアップDB後に登録されたユーザーは、登録時の履歴メールから普及することでなんとか普及できる!(履歴メールがDBで残っていてよかった)

まずは電話でお伝えする。⇨社内で検討するので資料を作ってくれとのこと。

結構相手は、偉い人も含め数名が残っています。さすが大企業。(こちらは私1人)

復旧手順の資料を作る。 ⇨ 提出。 ⇨ 30分後くらいにOKが出ました。

次は復旧後に、復旧が正しく行われたことをどう確認するかの資料を作ってとのこと。なるほど、さすが大企業。

なので、復旧手順1で復旧されるべき数、復旧手順2で復旧されるべき数を調査し、

復旧後にその数が一致することを確認できる手順を記載した資料を提出。

そして、ようやくお客様から資料の確認が取れ、OKが出ました(この時点で深夜2時)

社内には私一人しかいません。

皆大丈夫?とは気遣ってくれるものの、手伝えるような社内の組織体系ではないので、残念ながら、一人で対応するしかない。

そそくさと、復旧手順1と復旧手順2の復旧プログラムを作成

そして復旧後の確認プログラムも作成。

プログラムをお客様に提出。(この時点で深夜4時)

よくわからないだろうけど、一応確認してくれたみたいで、OK実行してくれとの許可がおりました。(この時点で深夜5時)

ここからスムーズにいきました。復旧プログラムを実行し、確認プログラムを実行。

そして数値を確認すると、、、

奇跡的にしかるべき数値になっていました。1つの差分もないい。。

そのまま報告し、OKをもらい、

その後お客様の方でサイトの停止から再稼働。(午前7時、もうギリギリっすわ)

その後、お客様からは、深夜稼働分の請求はきました。。

 

でもとにかく復旧できてよかった。

本日の教訓

 

ひとーつ:UPDATE文(DELETE文も)には、WHERE句は絶対必要!!!

はぁ?と思うかもしれませんが、非常に大切なことです。

WHEREによるUPDATEや、DELETEを許していないフレームワークもあります。

UPDATE、DELETEはデータを取得し、プライマリーキーを指定することでしか実行できないようになっていたりします。

 

ひとーつ:障害復旧には復旧したことの証明が必要!!

実はこれ結構重要で、これがあると、お客様は納得してくれます。

中身はシステムよりになるので、意味はわからないのでしょが、

ここの数値が合えば、うまくいった証拠になります。

というのが伝われば、納得してくれます。

この技はその後も社内での復旧作業時も含め、何度か使用しました。

 

いかがでしたでしょうか。皆様もこのような大トラブルの1つや2つは経験していると思います。

それを今後にどう活かすかですよね!!(超ポジティブシンキング)

 

ということで、今後もアップしていきますので、ご愛読の方よろしくお願いします。

にほんブログ村 IT技術ブログへ
にほんブログ村


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です