質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.53%

  • データベース

    821questions

    データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

  • Oracle Database 10g

    33questions

    Oracle DatabaseはRDBMSの商品です。具体的な発売商品として知られているのが、 Oracle9i、Oracle10g、Oracle 11gとOracle 12cです。

DBからレコードを削除したときのエビデンスの残し方

解決済

回答 4

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 2,143

mnsc10

score 25

DBから200万件のレコードを削除しなくてはいけません。
削除対象が日々変わっているため事前調査もあまり意味がない状態です。
どのようにエビデンスを残せばよいのでしょうか。

今までは100件程度だったので以下の手順で確認及びエビデンスを残していました。

①エクセルに関数で左右のレコードが同じならTRUEを返すシートを作成しておく。

②事前調査で対象のデータを抽出

③エクセルに貼り付け

削除当日
④テーブルの総レコード数を取得

⑤削除前に対象のデータを抽出

⑥エクセルに貼り付け

⑦TRUEなら用意していたDELETE文を使い削除
(100件なら100本のDELETE文を用意し、全て正常終了することを確認)

⑧テーブルの総レコード数を確認
(④で取得した件数より100件少ない事を確認)

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • Panzer_vor

    2016/08/04 21:10

    ワークテーブル等の作成は不可能なのでしょうか?
    例えば削除対象のレコードを蓄えるワークテーブルの追加がOKであるなら削除作業はもう少し楽が出来るように思います。

    キャンセル

回答 4

+5

Excelが出てくる時点でおかしいです⋯

DELETE文にはRETURNING句があり、削除した行をコレクション変数に受け取れますからそれを印字するなり何なりして「実際に削除されたレコードのリスト」というのを確実に作ることができます。

https://docs.oracle.com/cd/E16338_01/appdev.112/b56260/tuning.htm#BCGHDEJH

対象データを抽出し、そのあとで削除という手順も大丈夫なのでしょうか。抽出作業と削除作業の間に新しく削除すべきデータが出現する可能性があります。抽出というのがWHERE句で記述可能なのなら、それをDELETE文に渡すことでタイムラグに何かが紛れ込む心配がなくなります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/08/04 23:32

    質問者じゃないですが、RETURNING句というのがあったんですね…。DBでは一番Oracleにお世話になってるのに全く知らなかったです^^;

    キャンセル

checkベストアンサー

+3

正直な所、エビデンスとしてどこまで担保する必要があるのかに依存しますよね…。

それに日々対象が変わるというお話から、更新が多く発生するテーブルの匂いもしますし…。

削除条件に当てはまった時点で問答無用にDELETEかけても良いのかという点にも懸念がありますし…。

エビデンスとしてどこまで要求されるのものなのでしょうか?

例えばエビデンスとして以下を担保しなければならない場合

  • 事前に削除対象をリストすること(削除時に思わぬデータが消されたという自体への対策としてはあり得る)
  • 削除対象が間違いなく消されたことを確認できること(削除漏れがないことの確認)
  • 削除対象として上げたもののみが削除されたことの確からしさを担保すること

想定される一番厳しいレベルで考えると上記3点を満たす必要が出てくるのではと思ってます(そこまで要るかって話もありますが)。

上記レベルのエビデンスを求められると削除結果からのリストではエビデンス不足と言われる恐れあります。(削除結果からのエビデンスではNGとか言うのも変な話かもですが)

後は想定外のものが削除された場合はどう対応するのか?
トランザクション内で削除データをロールバックするのか?
トランザクション内でリカバリできないならフラッシュバックテーブルで戻すのか?
それ以前に想定外に削除され過ぎないよう予防策を張るのかetc…

削除され過ぎないことが優先なら

想定外の削除を防ぐことが必須であれば、事前(前日までなど)に削除対象をリスト化が必須なので、
この場合はワークテーブルを作って良いならば削除対象レコードを蓄えるものを作っちゃいましょう。

そのワークテーブルを利用して削除を実施すれば、削除対象として上げたもののの削除漏れは高確率で防げるでしょう。
心配でしたら、

  1. 本テーブルとワークのINTERSECTにより取得した結果が0件であることを確認
  2. 削除前の本テーブルの件数と削除後の本テーブルの件数差異がワークの件数に一致することを確認

ここまでやれば誰も文句は言わないでしょう。
多分ここまで求められることはないでしょうが。

削除漏れを起こさないことが優先なら

今のやり方自体が削除漏れを起こすやり方となってるので、
WHERE条件で書けるならWHERE句にまとめて一括削除しましょう。

他の回答者さんを参考に、
削除結果をリスト化する仕組みを作れば、リスト作成の手間も省けて万々歳です。

要求が厳しくないならこちらで十分でしょう。

ただし想定外に消されちゃったのでリカバリしたいとなったら一度リカバリしてから、想定外分を除いて削除する手間は発生します。

最後に

長くなりましたが、
結局はエビデンスとしてどの程度まで担保するかで戦略は変わるので、
それに応じて対応方法を検討すると良いでしょう。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/08/05 00:17

    確かに。
    Oracleを19年くらい使っているけど、DELETEしたデータをエビデンスに残す案件って経験ないですね。エビデンスを作る時間や費用をもっと建設的な方向に使った方がよさそうな。

    キャンセル

  • 2016/08/05 00:33

    ISMS外部監査とかが伴う運用業務とかだと、
    ユーザ同意を取るため削除データを事前にリスト化して云々は考えられますがね。
    証跡とかユーザ同意得てないとか指摘くらいかねないので。

    ただその場合でもある程度自動化を図って効率化していかないとやってられなくなりますがね^^;

    キャンセル

  • 2016/08/05 01:08

    情報セキュリティ監査の重要性
    http://www.atmarkit.co.jp/ait/articles/0302/28/news035.html
    正社員じゃなくて社外からの助っ人でやっているので、直接セキュリティ方面の作業をすることはありません。トリガーであるテーブルへの更新情報を履歴テーブルに取ったり、ファイングレイン監査を使ったり、などの要求は珍しくありませんが、DELETE情報だけExcelに、、、って今時、自動小銃が普通に使われている現代に火縄銃で対抗しているような違和感がぬぐえません。

    キャンセル

  • 2016/08/05 01:45 編集

    削除データのエビデンス単体で見ると僕もナンセンスかと思います。

    ただデータ整理などの業務で、ユーザに確認してもらうという意味で、
    削除対象をリスト化するということはあり得るのかなと。

    その場合でもそのリスト以外にユーザ承認もらってやってますとかその辺りの手続きがエビデンスとして別途必要となるのですが。

    でも多分今回の質問は、そういった意味は含んでいない気はしてます

    キャンセル

+2

ExcelにDELETEするデータを記録するのも手間なので、DELETE時トリガーで別テーブルに履歴を取っては?
CREATE TRIGGER

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

「削除対象が日々変わっている」ってのがよくわかりませんが、
200万件の削除とはごっつい作業ですなあ。
REDOログがあふれて止まっちゃいそう。(^_^;

さて、削除するからにはなんらかの削除条件がありますよね。
それをプログラミング的に削除SQLを生成するとして、
そのプログラムの正しさを担保するのが分かりやすいかなあ。
できれば、ある程度小分けにして削除できるなら
そうした方がリスクは減らせると思います。
で、どういう資料を残せばいいかというと…
どうしたもんですかね?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

同じタグがついた質問を見る

  • データベース

    821questions

    データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

  • Oracle Database 10g

    33questions

    Oracle DatabaseはRDBMSの商品です。具体的な発売商品として知られているのが、 Oracle9i、Oracle10g、Oracle 11gとOracle 12cです。