oracle 12c 数据库上编写SQL语句时卡顿的问题解决

简介: 开发环境的一个用户数据测试库,是12.1.0.2的数据库。 使用pl/sql developer连接后,编写sql语句,例如: Select a.Id, a.门诊号 From 病人挂号记录 A Where NO = 'Q0000453' 输入字段时,输完a,再输点之后,大约要5秒才弹出字段选择,选择了字段之后,按回车,大约需要8秒才能继续进行输入。
开发环境的一个用户数据测试库,是12.1.0.2的数据库。
使用pl/sql developer连接后,编写sql语句,例如:
Select a.Id, a.门诊号 From 病人挂号记录 A Where NO = 'Q0000453'

输入字段时,输完a,再输点之后,大约要5秒才弹出字段选择,选择了字段之后,按回车,大约需要8秒才能继续进行输入。
这么慢的速度,严重影响了开发人员的调试和编码。

并且,执行任何单表查询,无论数据多少,也是需要卡一下( 约2秒左右)才返回结果。

初步判断,可能pl/sql developer的操作过程中涉及到一些系统表的查询,可能数据字典和系统固定对象的统计信息没有收集,导致有些内部视图的访问太慢。
于是收集 数据字典和系统固定对象的统计信息
14:02:25 SQL> exec dbms_stats.gather_dictionary_stats;
PL/SQL 过程已成功完成。
已用时间:  00: 02: 34.50
15:23:01 SQL> exec dbms_stats.gather_fixed_objects_stats
PL/SQL 过程已成功完成。
已用时间:  00: 03: 56.13

完成之后,清空共享池:alter system flush shared_pool;

验证之前慢的操作,仍然还是慢,于是做了一个sql trace,根据跟踪文件,发现以下类似的sql在编写sql语句期间被自动执行了:
原来是进行了动态采样,这些采样语句的IO都比较高,所以会这么卡。

SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring 
  optimizer_features_enable(default) no_parallel result_cache(snapshot=3600) 
  */ C1, C2, C3 
FROM
 (SELECT /*+ qb_name("innerQuery") NO_INDEX_FFS( "O2")  */ 4294967295 AS C1, 
  COUNT(*) AS C2, SUM(CASE WHEN ("O2"."TYPE#"=88) THEN 1 ELSE 0 END) AS C3  
  FROM SYS."OBJ$" SAMPLE BLOCK(44.1745, 8) SEED(1)  "O2" WHERE ("O2"."TYPE#"=
  88)) innerQuery




call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       12      0.00       0.00          0          0          0           0
Execute     12      0.00       0.00          0          0          0           0
Fetch       12      0.14       0.08          0       9564          0          12
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       36      0.14       0.08          0       9564          0          12


Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 310     (recursive depth: 2)


Rows     Row Source Operation
-------  ---------------------------------------------------
      1  VIEW  (cr=797 pr=0 pw=0 time=5509 us cost=219 size=31 card=1)
      1   SORT AGGREGATE (cr=797 pr=0 pw=0 time=5506 us)
      0    TABLE ACCESS SAMPLE OBJ$ (cr=797 pr=0 pw=0 time=5497 us cost=219 size=16 card=1)


********************************************************************************


SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring 
  optimizer_features_enable(default) no_parallel result_cache(snapshot=3600) 
  */ C1, C2, C3 
FROM
 (SELECT /*+ qb_name("innerQuery") NO_INDEX_FFS( "DO")  */ 4294967295 AS C1, 
  COUNT(*) AS C2, SUM(CASE WHEN ("DO"."TYPE#"=92) THEN 1 ELSE 0 END) AS C3  
  FROM SYS."OBJ$" SAMPLE BLOCK(44.1745, 8) SEED(1)  "DO" WHERE ("DO"."TYPE#"=
  92)) innerQuery




call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        8      0.00       0.00          0          0          0           0
Execute      8      0.00       0.00          0          0          0           0
Fetch        8      0.04       0.04          0       6376          0           8
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       24      0.04       0.04          0       6376          0           8


Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 310     (recursive depth: 2)


Rows     Row Source Operation
-------  ---------------------------------------------------
      1  VIEW  (cr=797 pr=0 pw=0 time=5716 us cost=219 size=31 card=1)
      1   SORT AGGREGATE (cr=797 pr=0 pw=0 time=5711 us)
      0    TABLE ACCESS SAMPLE OBJ$ (cr=797 pr=0 pw=0 time=5704 us cost=219 size=16 card=1)


查了一下动态采样的参数,其值居然是3,修改参数值为0,关闭动态采样:
alter system set optimizer_dynamic_sampling=0 scope=both;

执行后大部分操作有一定的性能改善,但没有完全解决,于是又重启了数据库,再进行相应的操作,就不再卡了。

-------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
开了个公众号:医信系统性能优化,主要写一些日常工作中性能优化方面的各种案例,包括SQL优化,数据结构设计优化,Oracle系统性能优化。
主要面向编写SQL及相关脚本的开发人员和技术支持人员,分享一些性能优化的经验。
对性能优化的技术学习感兴趣的同学,欢迎订阅,共同学习,相互交流。


目录
相关文章
|
17天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
64 11
|
1月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
23天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
4天前
|
存储 Oracle 关系型数据库
数据库传奇:MySQL创世之父的两千金My、Maria
《数据库传奇:MySQL创世之父的两千金My、Maria》介绍了MySQL的发展历程及其分支MariaDB。MySQL由Michael Widenius等人于1994年创建,现归Oracle所有,广泛应用于阿里巴巴、腾讯等企业。2009年,Widenius因担心Oracle收购影响MySQL的开源性,创建了MariaDB,提供额外功能和改进。维基百科、Google等已逐步替换为MariaDB,以确保更好的性能和社区支持。掌握MariaDB作为备用方案,对未来发展至关重要。
18 3
|
4天前
|
安全 关系型数据库 MySQL
MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!
《MySQL崩溃保险箱:探秘Redo/Undo日志确保数据库安全无忧!》介绍了MySQL中的三种关键日志:二进制日志(Binary Log)、重做日志(Redo Log)和撤销日志(Undo Log)。这些日志确保了数据库的ACID特性,即原子性、一致性、隔离性和持久性。Redo Log记录数据页的物理修改,保证事务持久性;Undo Log记录事务的逆操作,支持回滚和多版本并发控制(MVCC)。文章还详细对比了InnoDB和MyISAM存储引擎在事务支持、锁定机制、并发性等方面的差异,强调了InnoDB在高并发和事务处理中的优势。通过这些机制,MySQL能够在事务执行、崩溃和恢复过程中保持
22 3
|
4天前
|
SQL 关系型数据库 MySQL
数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog
《数据库灾难应对:MySQL误删除数据的救赎之道,技巧get起来!之binlog》介绍了如何利用MySQL的二进制日志(Binlog)恢复误删除的数据。主要内容包括: 1. **启用二进制日志**:在`my.cnf`中配置`log-bin`并重启MySQL服务。 2. **查看二进制日志文件**:使用`SHOW VARIABLES LIKE 'log_%';`和`SHOW MASTER STATUS;`命令获取当前日志文件及位置。 3. **创建数据备份**:确保在恢复前已有备份,以防意外。 4. **导出二进制日志为SQL语句**:使用`mysqlbinlog`
28 2
|
18天前
|
关系型数据库 MySQL 数据库
Python处理数据库:MySQL与SQLite详解 | python小知识
本文详细介绍了如何使用Python操作MySQL和SQLite数据库,包括安装必要的库、连接数据库、执行增删改查等基本操作,适合初学者快速上手。
129 15
|
11天前
|
SQL 关系型数据库 MySQL
数据库数据恢复—Mysql数据库表记录丢失的数据恢复方案
Mysql数据库故障: Mysql数据库表记录丢失。 Mysql数据库故障表现: 1、Mysql数据库表中无任何数据或只有部分数据。 2、客户端无法查询到完整的信息。
|
18天前
|
关系型数据库 MySQL 数据库
数据库数据恢复—MYSQL数据库文件损坏的数据恢复案例
mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现:1、数据库无法进行查询等操作;2、使用mysqlcheck和myisamchk无法修复数据库。

推荐镜像

更多