Results 1 to 4 of 4
  1. #1
    Join Date
    May 2016
    Posts
    1

    Unhappy Unanswered: Tracking of DB Update :eek:

    We are facing a situation in which it seems someone updated high number of row in one of the large table. Based on last update timestamp in table, it seems those updates happened three weeks back but user id columns is not updated.

    We want to know which user id was used for this update and also preferable to get IP address of system that submitted update statement.

    We are running DB2 UDB on AIX version 9.7

    Appreciate any help !!

  2. #2
    Join Date
    Jan 2003
    Posts
    4,286
    Provided Answers: 5
    Unless you had something monitoring the database at the time of the update, that logged the update, you are out of luck.

    How do you know the user ID column was not updated? Maybe it was set, but was the same value as the previous update.

    If you have the transaction logs from when the update happened, you might be able to IBM to analyze them to determine the user.

    Andy

  3. #3
    Join Date
    Jul 2013
    Location
    Moscow, Russia
    Posts
    666
    Provided Answers: 55
    You can get such an information from the transaction logs for the time when the changes were maid. But if you have "data capture changes" attribute was set for your table or you had db2_logging_detail registry variable set to AUTHID value.
    IP address is not recorded in the logs anyway unless you had some corresponding monitoring active at the time of changes.
    To dig into transaction logs you should use some SW using db2 read log API like IBM Recovery Expert, for example.
    Regards,
    Mark.

  4. #4
    Join Date
    Apr 2012
    Posts
    1,006
    Provided Answers: 16
    Comes down to this: how much money is it worth to pay to find out ?

    Got a Comprehensive database-enforced security model?
    Got comprehensive application logging, retained long enough to cover the period of the bulk update
    Got db2diag* for the period of the update?
    Got comprehensive scheduled-job records?

    You may find that a shared-ID was responsible for the update, meaning you might not be able to deduce which real end user triggered the updates (if there was one).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •