• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 764
  • Last Modified:

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.
0
bhagatali
Asked:
bhagatali
  • 3
  • 2
1 Solution
 
Dave FordSoftware Developer / Database AdministratorCommented:

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
0
 
tliottaCommented:
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
0
 
Dave FordSoftware Developer / Database AdministratorCommented:

Tom, that's really cool. I never knew that about the file level identifier. That information will definitely come in handy. Thanks!

-- DaveSlash
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
bhagataliAuthor Commented:
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_timestamp) >= '2010-10-01'                
and table_type = 'T'                                                    

I am now trying to determine how reliable this information is. Any thoughts on this?

Regards
Ali
0
 
tliottaCommented:
Good choice for ALTER_DATE from PRODSCHEMA/systables. It might depend on what version your OS is. I suspect that almost anything in version 5 or later should make it reliable, especially if the DB2 group PTF level is reasonably current.

I would run DSPFD to an outfile, selecting a wide subset of physical files. I would include both DDS PFs and SQL tables. Then I would input that file into a simple program that passed each file through the Retrieve Database File Description (QDBRTVFD) API. The file identifier level is right in the header at offset 69 as a CHAR(13) field. I would have the program convert the file ID to a timestamp, and the file name, library and timestamp would all be written into a new table.

That should be easy enough to create. It gives you a good set of test data to start from.

Then I'd run a SQL statement that compared that timestamp for each file against the timestamp from SYSTABLES.

If they all match, then I'd be satisfied with reliability on that system. If they didn't match, I'd attempt to reconcile any mismatches and make my decision based on results.

I haven't had to do the same thing you're doing, so I don't have anything available. But the API will be simple because you won't need to drill into any of its data structures. You only need to retrieve 82 bytes or so for each file you test.

As long as reliability is acceptable, I'd go with ALTER_DATE from the system database catalog. There have been times when DDS PF details weren't recorded the same in the SQL database catalog as SQL tables. I'd just run a basic test to be comfortable. Most recent releases have been pretty good at it.

Tom
0
 
tliottaCommented:
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
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now