• 締切済み

仕事のミス:本番データの削除→ロールバック

こ、こんばんわ 私は客先でオブジェクトブラウザ(OB)を使って仕事している 新米SEです。 今日OBを使って本番データを操作していたところ、 あやまって一テーブルのデータを全件削除してしまいました。 すぐに気づいて青くなり、気を落ち着けて慎重にロールバックボタンを押したところ、 全データ復活しました。 消えている間そのテーブルに関するバッチプログラムも動いていません。 なので、特に報告もしなかったのですが、 今日のこのミスは報告しなくてもよかったんだろうか といまさら悩んでいます、、。 いったんデリートしたという事実はアーカイブログかなんかで わかるんですよね? ウツです。。

みんなの回答

  • uresiiwa
  • ベストアンサー率45% (49/107)
回答No.5

>いったんデリートしたという事実はアーカイブログかなんかで わかるんですよね? アーカイブログでも分かりますが、SQL監査(audit)を有効にしていると、詳細に記録が残ります。本番DBということであれば恐らくある程度の監査をかけているのでは?と思います。 (ロールバックしても記録が残ります) 仕事での出来事はちゃんと報告をしましょう。 隠しても何もよいことはありません。きちんと報告をして次への対策を上司を練ってください。そうすれば、ミスを責められることよりも、むしろ信頼を得る結果になると思います。 逆に、黙っていて監査ログを確認されたら・・・、非常によろしくありません。 本番環境でのデータ更新作業は、 ・事前バックアップを取る ・作業のログを取る ・作業内容の手順書やスクリプトを事前に作成し、関係者でレビューする ということをぜひ行ってください。 いまこういうことが行われていないなら、ぜひ提案しましょう。 「急いでいるから」というのは、スピード違反で事故を起こすようなことになるので、大事件が起こる前に改めましょう。 本番での作業準備や作業に十分な時間を与えられないなら、上司に必要性を強く訴えましょう。

全文を見る
すると、全ての回答が全文表示されます。
  • 3rd_001
  • ベストアンサー率66% (115/174)
回答No.4

アーカイブログ上には記載されているので、ログマイナで調査すれば分かります。 あとは、監視ツールを入れているとSQLを監査されてしまうかもしれません。以前、PISOを使ってマスタテーブルに対するSQL監査を仕掛けていて、無断でUpdate文を流したのを検知されて怒られたケースは見たことがあります。 http://www.insight-tec.com/products/service_piso.html あと意見としては、復旧できる準備がない作業は行わないのが基本です。 作業前にはバックアップをとりましょう。 厳しいシステムでは本番機を触る場合、以下が基本でした。 ・データの変更はテスト機でスクリプトとして開発する。 ・本番機では上記のスクリプトを実行する。 ・スクリプト実行も手順書化しておき確認された方法でしか本番機を触らない。 ・手順書を実行する時は複数人でチェックを行う。 ・本番データを触る場合はバックアップを取る。 報告云々ですが、次に起こった際に復旧できない可能性を考えると 再発防止策はたてるためにも報告はしたほうがよいと思います。 まあ、報告の仕方にもよりますが作業に不安をかかえておりミス時のリカバリー方法を検討してもらうようにはした方がよいと思います。

全文を見る
すると、全ての回答が全文表示されます。
  • pon2pon2
  • ベストアンサー率42% (107/250)
回答No.3

ま、とりあえず報告だけして、ごめんなさいして、 後は上司に責任(リカバリー)を取ってもらいましょう。 それが上司の仕事なので。 ま、オブジェクトブラウザーで、発生した問題は、 Oracle社非サポートなんですけど、 とりあえず、やった内容を正確(どんなSQLを実行したかとか。)に 上司につたえれば、上司なら対応考えてくれるはずです。 顔が青ざめるような失敗はDBAなら誰でも経験することです。 逆に失敗を経験していないDBAの方が怖いです。 なので、一つ成長し、良い経験をしたと思って その場を乗り切りましょう。 1年もすれば、やってしまった失敗なんて、 そんなこともあったな程度の内容になるので、 そんなに落ち込むことはないです。 大丈夫。頑張れ!!

全文を見る
すると、全ての回答が全文表示されます。
  • Myuu4
  • ベストアンサー率34% (36/103)
回答No.2

まずは技術的な面を。 ORACLEは、通常COMMIT(かROLLBACK)するまで、他セッションからは更新前のデータしか参照できません。 ※そのテーブルに関するバッチプログラムも動いていません に関して。 が、それはあくまで通常の話です。 ObjectBrowserは便利なツールです。下の画面に表示されているデータを修正した場合、カーソルを他行へ移すと、確か自動的にCOMMITがかかったと思います。 新米SEであれば、ObjectBrowserでデータを更新するような作業はやめておいた方が良いと思います。 基本は、SQL*PlusでSQL実行です。

tomasefing
質問者

お礼

御回答ありがとうございます。 僕のような不注意でスキルの低い奴が、 OBで本番データをさわることじたいほんとどうかと思うんですが、 どうすれば人為ミスを回避できるのか、もししてしまった場合は・・? ということから逃げてはいけないですよね。 SQL*Plusについて、もちろん知ってはいるのですが それを使って作業することはあまりありません。 ミス回避につながるということなので、これから勉強しようと思います。

全文を見る
すると、全ての回答が全文表示されます。
  • takapiii
  • ベストアンサー率55% (944/1707)
回答No.1

20年のDB技術者です。 その気になって調べれば分かりますが、まぁ殆ど分からないですよ。 ただ、報告しないのはアウトです。貴方は元に戻ったと思っていても、本当に戻っていると確信できるのでしょうか。 どのような設計になっているかは不明ですが、その時点で報告すれば完全に復活できたものを、見逃してしまった可能性は0ではありません。 それとテーブルを全て消してしまうという事は、delete文のwhere句に不備があったのだと思いますが、ObjectBrowser上でSQL文を書いて実行するのは私のチームではご法度です。あれはあくまでも管理用ツールなので、データを扱う時は、必ずsql用ファイルを作成し、検証後に実行しましょう。

tomasefing
質問者

お礼

御解答ありがとうございました。 >ただ、報告しないのはアウトです。貴方は元に戻ったと思っていても、本当に戻っていると確信できるのでしょうか。 >どのような設計になっているかは不明ですが、その時点で報告すれば完全に復活できたものを、見逃してしまった可能性は0ではありません。 ですよね。 もう本当ごめんなさい!と心の中で思うしか僕には・・・ >それとテーブルを全て消してしまうという事は、delete文のwhere句に不備があったのだと思いますが、ObjectBrowser上でSQL文を書いて実行するのは私のチームではご法度です。 >あれはあくまでも管理用ツールなので、データを扱う時は、必ずsql用ファイルを作成し、検証後に実行しましょう。 未然防止は意識しているところなのですが、 期限が迫っていると利便性を優先している自分がいます。 私のチームではあくまでも個人の注意力に任されてまして、、、。 取り返しの付かないミスを想像するとそれだけで、 不安でいっぱいになっていまいます。 仲間が平然とデータを扱っているのに対し、 どこか抜けている私は常に今日のような不安につつまれている状態です。。 そしてちょっと気が抜けたとき、今日のようなミスを・・・あぁ・・・ 実は皆さんもそうなんでしょうか?

全文を見る
すると、全ての回答が全文表示されます。

関連するQ&A

  • データ削除、追加によるロールバックセグメントについて

    環境:Oracle9i サーバ:Win2003 言語:VB6 テスト環境であるテーブルの200万件の削除、100万件の追加を行った後にVBアプリがすごく遅くなりました。 1.ロールバックセグメント(UNDOセグメント?)にデータがたまって遅くなったのでしょうか?  またはテンポラリにデータがたまったのでしょうか? 2.削除や追加が行われた場合はどのオブジェクトにデータがたまったりするのでしょうか? 対応としてDBサーバのOSの再起動を行ったのですがまだ遅く、再起動後にDBの再起動を行ったらなぜか遅かったのが改善されました。 そもそも原因がデータの削除、追加で体感レベルで遅くなったりするのかも疑問です。 基礎知識が足りなくて申し訳ありませんが、アドバイスお願いいたします。

  • データ削除の方法

    オラクルのデータベース容量を減らす為に、SQL PLUSにてDELETE文を実行(テーブル別に)しました (テーブルの中身、全件削除ではなく条件に一致した不要なデータのみ削除) 条件に該当するデータは消えましたが、オラクルデータベース自体の容量が逆に増えていました 正しいデータの削除方法を教えて頂きたいのですが。宜しくお願いいたします データベース:ORACLE 9I DATABASE

  • SQLクエリ1年前のデータを削除できない

    現在このクエリを作成したのですがデータが削除されなくて、データ全件が抽出されてしまいます。 以下の構文で試したのですが・・・・もし、ご指摘、アドバイス等ございましたらよろしくお願いします。 select * from テーブル名 delete from テーブル名 where 日付 < = (select DATEADD(year,(-1),(日付))) ちなみに、日付はDATETIMEです   バージョン:SQL management studio 10.50.25.000

  • データ削除とSQL*Loaderでのインポート

    SQL*Loaderを使ってデータをインポートするのですが、既存データが存在するテーブルにインポートするため、実行前に、条件に一致する一部のデータを削除します。 ですが、SQL*Loaderでインポートが失敗した際には、元に戻したいと思っています。 そういう場合に、SQL*PlusからDELETEのSQL文を実行してから、SQL*Loaderを起動してインポートするとなると、SQL*Plusから抜けた時点でCOMMITされてしまいますよね?そのためSQL*LoaderでインポートがエラーになってROLLBACKされても、削除されたデータは元に戻らないですよね・・・。 全件削除なら、CTLファイル内でREPLACEを指定してインポートするのですが・・・ データの一部削除とSQL*Loaderでのインポートを一連の処理として、エラーの際にはROLLBACKさせられる方法はありますでしょうか? よろしくお願いします。

  • エラーを起こす方法

    初心者です。バッチプログラムの単体テストで、異常ケースでエラーを起こさせたいのですが、どのように実行したらいいのかわからず困っています。プログラムの内容は、Aテーブルのデータを全件、同じ構造をしたBテーブルに登録するというものです。ユニークキーのデータを追加して一意制約エラーをおこすにも、そもそもAテーブルにユニークキーのデータを追加して登録することができないと思うのですが、どのようにやるのですか?

  • ACCESSのファイル容量

    おせわになります ACCESSにInTouchよりデータをINSERTしているのですが のデータ容量が テーブルのレコードを削除しても 減りません そういうものなのでしょうか 毎日全件DELETEしてINSERTするのですが 大体1日のデータ量で収まるのかと思っていたのですが どんどん大きくなっていって ACCESSファイルが異常に大きくなってしまっています ファイル容量をある程度で肥大しないようにする方法はありますでしょうか

  • バッチプログラムでSQLSever2008を操作

    教えてください。 (1) SQLSever2008内にあるデータベース1のテーブルAのデータを削除 (2) 同じインスタンス内にあるデータベース2のテーブルAのデータを、DB1のテーブルAにコピー (3) (2)の処理が失敗したらロールバック 上記のことを、バッチプログラムで行いたいと思っております。 単にコマンドプロンプトで入力するというのであれば(1)も(2)もできるのですが、 バッチプログラムで行うとなると、どうやっていいのか見当もつきません。 さらに(3)は、(2)でSQLを実行した戻り値も見なければならないと思います。 データベース1のテーブルAとデータベース2のテーブルAはまったく同じ構成です。 自分なりに色々調べてはいるのですがどうしてもわかりません。 もしどなたかご存知の方がいらっしゃったらぜひ教えてください。 どうぞよろしくお願いいたします。

  • データベースのタイミングについて

    PHPでとあるデータベースに接続したいのですが、 本番のサーバーのため、 処理を慎重に行いたいと思います。 データベースの処理の流れがよくわかっていないのですが、 処理としては データーベースを接続する Beginする テーブルを作成 大丈夫だったら  コミットする 大丈夫じゃなかったら  ロールバックする Endする データベースを切断する という処理でいいのでしょうか?? また、データベース上に同じテーブル名などがある場合は CREATを実行したときにエラーを返してくれるのでしょうか??

    • ベストアンサー
    • PHP
  • 検索の効率に付いて

    フロントエンドをAccessのADPにて作成しようとしています。 少しスッキリしないので確認をさせて下さい。 AccessのVBAやフォームのソースに書くSELECTですが SELECTであれば全てサーバー側で絞り込んで結果だけが帰って来るのか from句で指定したテーブル全件が送られて来てクライアント側で 絞り込みされるのかどちらでしょうか? 回線スピードが遅いのでネットワークに流れるデータ量を抑えたいと 考えています。 私の頭の中では・・・ FROM [テーブル名] の場合はクライアント側 FROM dbo.[テーブル名] の場合はサバー側 要はAccessの「テーブル」と「クエリ」に表示されているオブジェクトを 指定するとクライアント側(全件→クライアントで絞り込み=データ量多)、 「dbo.」を付けるとサーバー側(絞り込み後のデータ→クライアント=データ量少) と考えています。

  • Access2003 VBAのDELETEについて

    AccessでOracleとODBC接続してデータを操作するアプリを作成しています。 処理をする際に毎回ワークテーブルを全件削除し、取り込んで本テーブルにインサートする という処理にて、ワークテーブルのデリート文でなぜか10件しかレコードが削除されません。 固有レコードの問題を解消するためにDB側ではID列をPKとして一意に決まるように振っています。 ODBCのリンクテーブルという形で登録しています。 テーブル:TEST_WORK カラム:ID(PK)、コード、名称 CurrentDb.Execute "DELETE FROM TEST_WORK" 上記記述にてなぜか全削除されません。 感じとしては一回目のdeleteでIDが1~9までが削除され、次にdeleteした際は10~99までが削除され・・・というように桁数で変化している気がします。 全て消すにはどのようにすればよいでしょうか?