bhagatali
asked on
DB2 - Date table was last ALTERed
HI All,
Is there any way on AS400 that I can find out when a table in a schema was last ALTERed. Currently we don't have any mechanism to track table changes in production. ALTER commands are run manually during the implementation of every release. As part of an audit we have been asked to provide a list of all tables that have changed since 2010.
I tried doing a DSPOBJD of all objects in our production schema and then using the "Change Date" column to get the information i need. To my dismay I realized that "Change Date" gets updated every time I run an update on the table data.
Any ideas?
Regards
Ali.
Is there any way on AS400 that I can find out when a table in a schema was last ALTERed. Currently we don't have any mechanism to track table changes in production. ALTER commands are run manually during the implementation of every release. As part of an audit we have been asked to provide a list of all tables that have changed since 2010.
I tried doing a DSPOBJD of all objects in our production schema and then using the "Change Date" column to get the information i need. To my dismay I realized that "Change Date" gets updated every time I run an update on the table data.
Any ideas?
Regards
Ali.
You might review the "File level identifier" of the tables. This is a kind of timestamp value in the form CYYMMDDHHMMSS that attempts to record the current version level of the file object. Changes to data do not affect the file level, but recreation of the file or ALTER TABLE operations that change structural characteristics will generate new file level IDs.
Note that this value is not the same as a member level ID nor a format level ID.
I'm not sure if there's an easier way to check.
Tom
Note that this value is not the same as a member level ID nor a format level ID.
I'm not sure if there's an easier way to check.
Tom
Tom, that's really cool. I never knew that about the file level identifier. That information will definitely come in handy. Thanks!
-- DaveSlash
ASKER
Hi Tom,
I had been working all morning today to get that file level identifier extracted. You are right. That field is like a time stamp and gets affected only with an ALTER. Apparently the only easy way to extract that information is using an API. Do you know of any easier method?
There was someone else in my team who found that the the SYSTABLES contains a last modified information too.
select substr(table_name,1, 20) as TABLE, last_altered_timestamp
as ALTER_DATE from PRODSCHEMA/systables
where date(last_altered_timestam p) >= '2010-10-01'
and table_type = 'T'
I am now trying to determine how reliable this information is. Any thoughts on this?
Regards
Ali
I had been working all morning today to get that file level identifier extracted. You are right. That field is like a time stamp and gets affected only with an ALTER. Apparently the only easy way to extract that information is using an API. Do you know of any easier method?
There was someone else in my team who found that the the SYSTABLES contains a last modified information too.
select substr(table_name,1, 20) as TABLE, last_altered_timestamp
as ALTER_DATE from PRODSCHEMA/systables
where date(last_altered_timestam
and table_type = 'T'
I am now trying to determine how reliable this information is. Any thoughts on this?
Regards
Ali
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I never knew that about the file level identifier.
That's used by RSTOBJ when restoring *FILE objects to choose how the restore progresses. When you see things like old copies getting renamed to something like MYFILE0001, it's usually because file IDs don't match.
Unfortunately some times, file ID doesn't work like format ID, so restores don't care if the formats haven't actually changed. It can seem messy to clean up, but there is method behind most of it.
Member IDs can get involved for member restores.
Tom
That's used by RSTOBJ when restoring *FILE objects to choose how the restore progresses. When you see things like old copies getting renamed to something like MYFILE0001, it's usually because file IDs don't match.
Unfortunately some times, file ID doesn't work like format ID, so restores don't care if the formats haven't actually changed. It can seem messy to clean up, but there is method behind most of it.
Member IDs can get involved for member restores.
Tom
To my knowledge, the only way to tell if the table was ALTERed would be to look at the journals. An ALTER would record a journal entry of type CH and code F ... probably also an entry of type CG with a code of D.
As you discovered, the "last change date" in DSPFD includes the changes in data, not just structure. Therefore, I think the journals are the only way to detect changes in structure.
HTH,
DaveSlash