2

我正在使用 Oracle 数据库的两个实例，分别调用它们one和two. two运行在比 更好的硬件（硬盘、内存、CPU）上one，并且在 Oracle 版本（都是 11g）方面two落后一个小版本。one两者都具有完全相同的表table_name，并且定义了完全相同的索引。table_name我在两个实例上加载了 500,000 行相同的行。然后我在两个实例上运行：

delete from table_name;

此命令需要 30 秒才能完成，需要one40 分钟才能完成two。对两个表执行 INSERT 和 UPDATE 具有相似的性能差异。有没有人对什么会对两个数据库之间的性能产生如此巨大的影响有任何建议？

4

4 回答 4

3

我首先比较实例配置 - SELECT NAME, VALUE from V$PARAMETER ORDER BY NAME 并将结果后台打印到两个实例的文本文件中，并使用一些文件比较工具来突出差异。除了由于数据库名称和文件位置的差异之外的任何其他内容都应进行调查。一个极端的情况可能是一个数据库上没有归档日志记录，而另一个数据库上定义了 5 个归档目标。

如果您无权访问数据库主机上的文件系统，请找到可以访问的人并让他们从您开始会话时获取跟踪文件和 tkprof 结果，ALTER SESSION SET sql_trace=true，然后进行删除。由于表上的触发器（您可能不拥有）、审计等，这将暴露任何递归 SQL。

于 2010-04-19T22:25:59.393 回答
2

如果您可以监视 v$session 中的 wait_class 和 event 列以查找删除会话，您将获得有关延迟原因的线索。一般来说，我希望一个完整的表 DELETE 是磁盘绑定的（等待类指示 I/O 或配置）。它必须从表中读取数据（因此它知道要删除什么），更新数据块和索引块以删除为UNDO表空间和重做日志生成大量条目的条目。

在生产环境中，底层文件可能分布在多个磁盘（甚至 SSD）上。开发/测试环境可能会将它们全部卡在一台设备上，并且磁盘上有很多磁头移动会减慢速度。我可以看到跳跃 SQL 可能是十倍。你的情况比这更糟。

如果表 [wait_class of 'Concurrency'] 上有并发活动（例如其他会话插入），您可能会遇到锁定争用或会话都试图敲击索引。

于 2010-04-20T00:54:13.140 回答
1

请注意：我不是dba ...

我的办公室窗户上写着以下内容：

在紧急情况下，请随时待命的 dba：

  1. 检查计划
  2. 运行统计
  3. 刷新共享缓冲池

2 号和/或 3 号通常修复在一个数据库中工作但在另一个数据库中工作的查询，或者昨天工作但今天不工作的查询......

于 2010-04-19T22:49:36.413 回答
1

实例二显然有问题。我建议你看看这些 SO 问题及其答案：

尤其：

  • 您是否有未索引的外键引用（删除需要很长时间的原因＃1 - 请查看 AskTom 中的此脚本），
  • 你有任何 ON DELETE TRIGGER 吗？
  • 实例二是否有任何活动（如果此表不断更新，您可能会被其他会话阻止）
于 2010-04-20T07:59:42.133 回答