澄清
您能否澄清以下内容
- sqlplus客户端是否在您的数据库管理系统所在的同一物理机(或虚拟机)上(更具体地说,是您的
oraand datafiles)?
- 您可以通过使用减小结果集的大小来测试您的查询
fetch first n rows吗?
时间复杂度和细节
为什么你认为瓶颈是假脱机?在对性能不佳的原因做出任何结论之前,您可能需要尝试收集一些有关查询的计时统计信息。我会修改您的查询以仅返回行的子集
SELECT * FROM scott.dept FETCH FIRST 10000 rows
优化查询很大程度上取决于数据的结构和例程的运行方式,因此为了优化,您需要能够对性能变化进行基准测试。
然后,您将需要检查以下两个参数
SHOW PARAMETER statistics_level
SHOW PARAMETER timed_statistics
您还需要为查询计时
SET TIMING ON
请记住,所有这些只是为了对性能进行基准测试,您需要在生产中恢复这些设置。
请记住,由于池/缓冲/缓存等,多次运行相同的查询会导致性能指标不一致。您应该查询v$statistics_level并调查
- 已处理的行
- 排序(内存)
- 排序(磁盘)
- 物理读取
- 一致得到
我会SHUTDOWN IMMEDIATELY; STARTUP MOUNT;然后你多次解释你的查询。
EXPLAIN PLAN FOR SELECT * FROM SCOTT.DEPT;
检查解释计划是否在您随后的电话中发生变化。
此外,在某些情况下,您可以通过运行强制缓存表
SELECT * FROM SCOTT.DEPT CACHE;
然后将其与性能指标进行比较
SELECT * FROM SCOTT.DEPT NOCACHE;
您可能还希望将表无限期地保留在内存中
ALTER TABLE *scott.dept* STORAGE (buffer_pool keep)
如果您没有看到任何明显的东西,请运行 explain plan for您的查询。连续多次运行解释,看看是否有任何变化。
除此之外,您还应该记住,在不刷新缓冲区/清除缓存的情况下多次运行查询会给您带来不可靠的读数。如果您不确定假脱机是瓶颈,我还建议您运行explain plan for your查询
还有一些技巧可以随着时间的推移提高性能(假设定期运行此例程)。如果您使用alter table *table_name* cache,运行查询而不使用假脱机到文件,然后再次alter table *table_name* nocache使用假脱机运行,您可能会获得更高的性能,但如果这完全可行,则再次完全取决于您的用例。
设置
虽然我怀疑您的问题是否可以通过任何设置组合来解决,但以下是一些可能会提供边际收益的方法
set trimspool on
删除 spool 文件中的空格以填充 linesize 2. 设置 echo off 这可能毫无意义,具体取决于您的例程是完全自动化还是交互式 3.set verify off
这将从您的 spool 中删除替换变量,但可以大大加快您的进程...再次,取决于您的数据 4.set autoprint off
这是另一个变量设置。关闭是默认设置,但您可以保证我会明确地将其设置为 5。set serveroutput off
6.SET TRIMOUT ON
删除在输出文件 7 上填充 linesize 的空格。 set arraysize N
您肯定会修改这个。N 是一次获取的行数。这个的大小取决于你的表的结构
虽然这些设置可能会提高您的例程速度,但性能通常取决于您的架构和数据集。