我在 Windows Server 2019 上新安装 Oracle 12c 时遇到“问题”(至少是一种奇怪/缓慢的行为),此查询至少需要 5 分钟才能完成:
SELECT COUNT(*) FROM SYS.ALL_VIEWS;
为什么要花这么多时间?我错过了什么?
Oracle 12c 在 SSD 上的 Win2019(在 VMWare VM 中)上运行。VM 有 5 GB 内存。对于“真正的”数据库来说,这可能还不够,但我的数据库包含一个默认的通用数据库(没有用户数据),因为我只需要为客户进行快速测试。
谢谢你。
不是一个简单的查询。
ALL_VIEWS
是一个非常复杂的视图,它有许多连接需要特殊的逻辑来确定调用用户实际上可以看到什么。您可以使用
all_views
查看背后的逻辑all_views
,这就是它在 19c 上的样子。够简单吗?好吧,
int$dba_views
实际上是一个视图本身,所以让我们更深入一点,这个视图定义为猜猜看,
sys."_CURRENT_EDITION_OBJ"
也是一个具有复杂过滤器的视图。我不会继续粘贴,因为您可以在自己的 12c 安装上跟踪跟踪(并且可能会略有不同)。但是这里要注意的重要一点是,
ALL_VIEWS
当您按名称查找视图时,实际使用速度很快,计算您可能能够使用的每个视图并不快(这是合理的,因为它不是您永远需要匆忙做)。如果您想
ALL_VIEWS
在某种基准测试中使用,那么您可以将其具体化为一个表格并计算它。在我公司的一个大小为 1 TB 的 Oracle 实例上运行相同的查询,执行时间不到一秒。
作为 SYS AS SYSDBA 执行
结果是:
正如其他答案所指出的,它可能与您查询的视图的复杂性有关,但我不会把所有的钱都押在这上面。
其他需要考虑的事情
查询可能与您拥有的权限相关。您是否尝试将查询运行为
SYS as SYSDBA
?然后,拥有一个只有 5 GB 的 Oracle 数据库实例和一个 10 GB 大小的数据库可能会影响性能。想一想:数据还没有在缓存中。
另一个问题与 Oracle 实例的内存配置有关。您是在配置和参数的地方运行自动内存管理(AMM),还是在配置
MEMORY_MAX_TARGET
和MEMORY_TARGET
参数的地方运行自动共享内存管理(ASMM) ?您是否将这些值设置为高于 1 GB,以便 Oracle 数据库实例可以受益于将一些数据库对象(数据)缓存到 RAM 的能力?sga_target
sga_max_size
如果第二次运行查询会发生什么?你有同样糟糕的表现吗?思考:数据库(数据)缓存。
如果您的本地系统正在运行其他虚拟机,请关闭它们并重试。它跑得更快吗?
您是否在同一台桌面/服务器上运行任何其他内存或 CPU 密集型应用程序?关闭它们。
防毒软件?如果关闭或按照 Oracle 的建议从扫描中排除某些文件/目录,请关闭。
如果您遵循其中的一些建议,那么您应该在查询简单视图时观察到性能的提高。
哦,顺便说一下,我的 Oracle 实例大小为 1 TB,并且
SGA_TARGET
设置为84 GB
. 内存对于数据库性能至关重要。以 SYSTEM 身份运行查询
以非特权用户身份运行查询
我创建了一个非特权用户
UNPRIV_USER
,除此之外没有任何特权GRANT CONNECT ...
,GRANT CREATE SESSION ...
然后对巨大的 1TB Oracle 数据库实例重新运行相同的语句,结果如下:因此,虽然非特权用户无权访问某些 VIEWS,但这不会影响查询执行的持续时间。
结论
权限/特权可能会对简单查询的执行时间产生影响,但在我的环境中,它似乎没有那么大的影响。(+/- 1 秒)
我将开始查看您的虚拟化和/或特定于实例的配置设置。
例如,我的实例在专用硬件上运行(16 核 @ 2.8 GHz,768 GB RAM,84 GB SGA 用于上述实例)。
桌面操作系统与服务器操作系统
桌面操作系统和服务器操作系统的优先级不同。桌面操作系统将优先考虑前台应用程序,而服务器操作系统通常会配置为优先考虑后台应用程序(服务)。
在 Windows 系统上,请按照以下快速步骤配置系统以优先处理后台应用程序:
这应该会为 Windows 操作系统上的 Oracle 服务带来更好的性能。