我的一个表中的数据库（AS400- DB2）中存在一个问题，所有行都被删除了。我不知道它是用户执行的程序还是SQL。所有我知道它在早上凌晨3点左右。那时我确实检查过任何预定的工作。
我们设法从备份中恢复数据，但我想调查删除记录或用户的内容。
在物理表上是否存在任何日志，以检查SQL执行的内容以及何时在指定的表上？这将有助于我确定导致这种情况的原因。
我尝试检查I系统导航器但找不到任何日志...有没有办法使用i系统导航器或绿屏获取桌面上的跨国数据？如果我可以获得在时间线中执行的SQL。
任何帮助都将不胜感激。
答案 0 :(得分：1)
没有提及如何推断或确定时间，但由于缺乏日记，我建议一个好的方法是立即收集有关文件和成员的信息;用于* SERVICE和* FULL的DSPOBJD，用于* ALL，DMPOBJ的DSPFD，甚至可能是目录中TABLE的行的副本[包括SYSTABLES的ALTEREDTS列的LAST_ALTERED_TIMESTAMP或来自QADBXREF的基于字段的DBXATS ]。收集这些，几乎只有在任何其他活动之前完成[特别是在任何恢复活动之前]，可以帮助确定事件的时间，也许可以暗示事件是什么;大多数时间戳仅反映最近针对对象的活动[而不是历史日志]，因此任何恢复活动都可能导致丢失任何反映先前事件\活动的时间戳。
即使没有该文件的日志，也没有计划缓存中的任何内容，可能[虽然不太可能]是一个活动的SQL监视器。在iNav GUI中的某个位置也应该可以看到活动监视器。我不确定在之前的时间范围内可能已激活的监视器的可见性。
同样，尽管缺乏日记功能，但可能存在一些系统级对象或用户审核，其中事件被跟踪为命令字符串或作为file.member上的操作;结合推断的时间安排，可以审查所有审核记录，包括之前的审核记录。
虽然预定作业中可能没有任何内容，但是从那时起的历史记录日志（DSPLOG）可能会显示已结束的作业，或者[可能很快]之前的作业显示已开始的作业，这些作业更可能是负责。根据我的经验，工作的名称通常可能是指示性的;例如，作业的名称作为文件的名称，可能仅由于已从PDM提交的请求。可以检查任何假脱机的[或其他可用的]作业日志，以便可能参考文件和\或成员名称;也许是CLRPFM请求的完成消息。
如果操作可能来自程序，则该文件可能被记录为参考对象，使得DSPPGMREF的输出可能会显示带有引用的程序，并且任何作为SQL程序的[service]程序都可以嵌入它们用PRTSQLINF显示的SQL语句;最后用于这些程序可以审查可能的匹配。注意：也可以搜索模块和程序源，但是如果仅为了绑定而暂时创建它们，则无法知道它们被编译的名称或者它们可能被绑定的内容。
答案 1 :(得分：0)
使用System i Navigator，展开数据库。右键单击您的系统数据库。选择SQL Plan Cache-＆gt;显示语句。从这里，您可以根据各种标准进行过滤。
答案 2 :(得分：0)
这不太确定，但通常会节省我一些时间。使用System i Navigator，右键单击表并选择Index Advisor。如果您很幸运，建议使用一个或多个索引。如果是这样，按日期排序最后建议并右键单击具有最新日期的索引并选择显示语句...在该对话框中，按日期排序以帮助缩小范围或只是滚动查看语句以找到您的＆ ＃39;对此感兴趣。右键单击它并选择使用SQL语句，然后就可以了。