我的数据库(AS400-DB2)中有一个表出现问题，所有行都被删除了。我不知道用户执行的是程序还是SQL。我所知道的一切都发生在凌晨+-3点。当时我确实检查过任何预定的工作。
我们设法从备份中取回了数据，但我想调查是什么删除了记录或是什么用户。
在物理表上的die as400上是否有任何日志来检查在指定的表上执行了什么SQL以及何时执行？这将帮助我确定是什么原因造成的。
我试着检查我的系统导航器，但找不到任何日志。。。有没有一种方法可以使用i系统导航器或绿屏在表上获取跨国数据？如果我能得到在时间线上执行的SQL。
如有任何帮助，我们将不胜感激。
没有提到时间是如何推断/确定的，但由于缺乏日志记录，我建议一个好的方法是立即收集有关文件和成员的信息；DSPOBJD用于*SERVICE和*FULL，DSPFD用于*ALL，DMPOBJ，甚至可能是目录中TABLE的行的副本[以包括SYSTABLES的ALTEREDTS列的LAST_ALTERED_TIMESTAMP或基于QADBXREF中的字段DBXATS]。收集这些几乎只有在任何其他活动之前[特别是在任何恢复活动之前]才有价值的东西，可以帮助确定事件的时间，也许可以暗示事件是什么；大多数时间戳只反映对象的最近活动[而不是作为历史日志]，因此任何恢复活动都可能导致反映先前事件\活动的任何时间戳的丢失。
即使该文件没有日志，计划缓存中也没有任何内容，也可能存在活动的SQL监视器(尽管可能性不大)。在iNav GUI中的某个位置也应该可以看到活动监视器。我不确定在以前的时间段内可能处于活动状态的监视器的可见性。
类似地，尽管缺乏日志记录，但可能存在一些系统级对象或用户审计，事件被跟踪为命令字符串或文件.member上的操作；再加上推断的时间，可以对之前到之后的所有审计记录进行审查。
尽管计划的作业中可能没有任何内容，但从那时起的历史记录日志(DSPLOG)可能会显示结束的作业，或者在该时间之前[可能很快]显示开始的作业，这些作业更有可能是负责的。根据我的经验，通常工作的名字可能是指示性的；例如，作业的名称作为文件的名称，这可能只是因为PDM提交了请求。可以查看任何后台处理的[或仍然可用的]作业日志，以确定是否可能引用文件和/或成员名称；可能是CLRPFM请求的完成消息。
如果动作可能来自程序，则文件可以被记录为引用对象，使得DSPPGMREF的输出可以显示具有该引用的程序，并且作为SQL程序的任何[服务]程序都可以使用PRTSQLINF显示其嵌入的SQL语句；可以对用于这些程序的最后一个进行审查，以确定可能的匹配。注意：也可以搜索模块和程序源，但无法知道它们是以什么名称编译的，或者如果只是为了绑定而临时创建，则无法知道它们可能绑定到了什么。
使用System i Navigator展开数据库。右键单击系统数据库。选择"SQL计划缓存"->"显示语句"。从这里，您可以根据各种条件进行筛选。
这不一定很火，但通常会为我节省一些时间。使用System i Navigator，右键单击该表并选择Index Advisor。如果幸运的话，建议使用一个或多个索引。如果是，请按上次建议的日期排序，右键单击具有最新日期的索引，然后选择"显示语句…"。。。在该对话框中，可以按日期排序以帮助缩小范围，也可以滚动浏览语句以找到您感兴趣的语句。右键单击它，然后选择"使用SQL语句"，就可以了。