This may be a silly question, but I don't seem to know where to find the answer.

We saw some SQL errors in our log today (SQL0404N A string in the UPDATE or INSERT statement is too long for column ""), but we didn't know what SQL was being executed to cause them. Is there a way to see what SQL has been issued recently against a db2 database (ver 8.2 - unix) ? In oracle, we can query v$sql to see what SQL is still in the statement cache... is there anything similar in DB2?

Thanks!
Jodie

There is a way to see it, but only if it is a valid statement and added to package cache. You can see the statements in package cache with a "get snapshot for dynamic sql" or db2pd command. See the Command Reference manual for details on both of these commands.

If it's a valid statement (which I believe it was), would it automatically be added to the package cache?

Yes, although in certain circumstances it could be bumped out by other subsequent statements.

If the error was a runtime error, then the statement probably would be in package cache, but if the error was detected during SQL statement compilation, then it would not be in package cache.

Thanks...
I tried the "db2 get snapshot for dynamic sql", and saw all of the SQL. Unfortunately, all of the variables were "?", indicating bind variables (which is a good thing), but is there any way to see what the variables have been for recent executions?

Not with a snaphsot. You may be able to see the actual statements with DB2 Query Patroller, which I believe is priced as a separate license.

Figures... Thanks for the information.

As far as I know, Query Patroller doesn't capture bind variable values anyway.