我之前也碰到过类似的Objects Copy跳过表的坑，给你几个接地气的排查方向：

• 先确认源表有没有符合条件的数据
  别着急找软件的问题，先在源库DATABASEA里手动跑这条SQL验证：

  SELECT COUNT(*) FROM "Table X" WHERE PROCESS_DATE = TO_DATE('2017-12-31', 'YYYY-MM-DD');
  

  如果返回0，那SQL Dev跳过是正常的——没数据可复制嘛。另外注意日期格式，有的库DATE字段的默认显示格式是DD-MON-YYYY，直接写字符串可能会因为隐式转换匹配失败，用TO_DATE指定格式更稳妥。

• 核对目标表的权限和结构细节
  你说结构完全一致，但还是要抠细节：

  • 目标库DATABASEB的Table X字段顺序、数据类型（比如DATE/VARCHAR、精度长度）是不是和源表完全对齐？哪怕一个字段类型差一点，都可能导致复制被跳过。
  • 检查连接目标库的用户有没有Table X的INSERT权限！有时候SQL Dev的日志不会明确写权限不足，直接就跳过表了，这点很容易忽略。

• 重新检查Objects Copy的配置项
  再走一遍复制流程，别放过任何细节：

  • 在「Select Objects」步骤，确认Table X是被勾选状态，有没有不小心漏选或者被过滤掉？
  • 「Data Copy Options」里，是不是只勾选了Copy Data（没选Copy DDL），并且打开了Append Data选项？不同版本的SQL Dev界面布局可能有点变，仔细核对一遍。
  • 看看「Filter」标签页，有没有加过表名的排除规则，比如误加了Table X的排除条件？

• 重置SQL Developer的缓存配置
  换了新电脑后，软件的缓存配置有时候会抽风。试试：

  1. 关闭SQL Developer
  2. 找到配置目录：Windows是C:\Users\<你的用户名>\AppData\Roaming\SQL Developer，Mac是~/Library/Application Support/SQL Developer
  3. 删除里面以system开头的文件夹（比如system4.3.0）
  4. 重新打开软件，重新配置数据库连接后再试复制操作

• 换个方式绕开Objects Copy
  如果以上都不行，不如换个更直接的方法：

  • 建立两个库之间的DBLINK，直接在目标库执行INSERT：

    INSERT INTO "Table X"
    SELECT * FROM "Table X"@DATABASEA_LINK
    WHERE PROCESS_DATE = TO_DATE('2017-12-31', 'YYYY-MM-DD');
    

  • 或者用SQL Dev的「Export Data」把符合条件的数据导出成CSV，再用「Import Data」导入到目标表，这种方式步骤更透明，出错也更容易排查。

内容的提问来源于stack exchange，提问作者jlb122