关于修改数据库参数的测试

简介: 在性能调优的时候,会发现很多类型的问题,有些问题可能通过使用隐含参数就能够解决,不过这种变更需要特别注意,因为做隐含参数的变更无形中会影响到其它的sql语句运行。

在性能调优的时候,会发现很多类型的问题,有些问题可能通过使用隐含参数就能够解决,不过这种变更需要特别注意,因为做隐含参数的变更无形中会影响到其它的sql语句运行。如果为了个别的问题而做了变更,导致了整个系统问题,那就得不偿失了,这中变更一定得经过测试,至少在测试环境中部署测试过,而且解决的问题可能是通用的,要不真是吃力不讨好。
个人建议有下面的步骤:
在测试环境部署。
测试前设定baselin,修改后,在同样的负载下对比性能情况,是否有明显的抖动。
分析收集的信息,进行评估,是否达到预期的目标。

现在生产环境中碰到了一个问题,发现了bind peek的问题,有些sql语句的结构都是一致的,但是传入的list变量值不同,结果导致系统的硬解析很高。
从系统中抓到的sql语句如下。可以看到变量值略有变化,但是sql_id每次都不一样。
7ww8mgvpgwnvb   SELECT xxxxx from xxxxx where PERIOD_KEY in(:3  , :4  , :5  , :6  , :7  , :8  , :9  , :10  , :11  , :12  , :13  , :14  , :15  , :16  , :17  , :18  , :19  ,
                :20  , :21  , :22  , :23  , :24  , :25  , :26  , :27  , :28  , :29  , :30  , :31  , :32  , :33  , :34  , :35  , :36  , :37  , :38  , :39  ,
                :40  , :41 ) xxxxxxx;

115hygxgm58ss   SELECT xxxxx from xxxxx where PERIOD_KEY in(:3  , :4  , :5  , :6  , :7  , :8  , :9  , :10  , :11  , :12  , :13  , :14  , :15  , :16  , :17  , :18  , :19  ,
                :20  , :21  , :22  , :23  , :24  , :25  , :26  , :27  , :28  , :29  , :30  , :31  , :32  , :33  , :34  , :35  , :36  , :37  , :38  , :39 ) xxxxxx

cq2pswgj3p9ru   SELECT xxxxx from xxxxx where PERIOD_KEY in(:3  , :4  , :5  , :6  , :7  , :8  , :9  , :10  , :11  , :12  , :13  , :14  , :15  , :16  , :17  , :18  , :19  ,
                :20  , :21  , :22  , :23  , :24  , :25  , :26  , :27  , :28  , :29  , :30  , :31  , :32  , :33  , :34 ) xxxxxx

0rp04bthp6whf   SELECT xxxxx from xxxxx where PERIOD_KEY in(:3  , :4  , :5  , :6  , :7  , :8  , :9  , :10  , :11  , :12  , :13  , :14  , :15  , :16  , :17  , :18  , :19  ,
                :20  , :21  , :22  , :23  , :24  , :25  , :26  , :27  , :28  , :29  , :30  , :31  , :32  , :33  , :34  , :35  , :36  , :37  , :38  , :39  ,
                :40 ) xxxxxx

从分析来看,有很明显的bin peek问题,有一个隐含参数和这个相关, _optim_peek_user_binds   这个特性可以关掉。
查看隐含参数的语句如下:            

SQL> set linesize 132
SQL> column name format a30
SQL> column value format a25
select
  x.ksppinm  name,
  y.ksppstvl  value,
  y.ksppstdf  isdefault,
  decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE')  ismod,
  decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE')  isadj
from
  sys.x$ksppi x,
  sys.x$ksppcv y
where
  x.inst_id = userenv('Instance') and
  y.inst_id = userenv('Instance') and
  x.indx = y.indx and
  x.ksppinm like '%_&par%'
order by
  translate(x.ksppinm, ' _', ' ')
SQL>  /
Enter value for par: bind_peek
old  14:   x.ksppinm like '%_&par%'
new  14:   x.ksppinm like '%_bind_peek%'
NAME                           VALUE                     ISDEFAULT ISMOD      ISADJ
------------------------------ ------------------------- --------- ---------- -----
_px_bind_peek_sharing          TRUE                      TRUE      FALSE      FALSE

关于这个特性,可以这么理解,比如表中有100万条数据,会按照分布的一个均值来统一显示执行计划,所以对于数据分布比较均匀,那就是一个很平衡的提高,如果数据分布不均匀,也是去均值,这样能够基本平衡。
当然了这个特性相当于对于问题的处理的一个很综合的处理,所以可以根据自己的情况来决定是否启用。
如果是分区表,比如有100个分区,那么对于统计信息而言就会取表级的统计信息而不是基于分区级的。

这种参数想要进行验证,是很困难的,你得很了解这个参数变更带来的边界,怎么去界定这个变更的范围。可能出现什么问题,需要得到什么样的预期效果。
对于这个参数的测试,可以使用一个Hint来灵活的启停(/*+opt_param('_optim_peek_user_binds', 'false')*/)。
来简单验证一下。
首先新建一个表,然后一通update,使得数据刻意的不均匀。然后通过动态的变量来查看启停hint得到的执行计划和统计信息。
SQL> set linesize 200
SQL> set pages 100
SQL> create table t (id varchar2(10),text varchar2(4000)) tablespace pool_data;

Table created.

SQL> insert into t select 1,object_name from dba_objects;

13576 rows created.

SQL>  commit;

Commit complete.

SQL> update t set id=2 where id=1 and rownum

1 row updated.

SQL> commit;

Commit complete.

SQL>  select id,count(*) from t group by id;  --可以看到数据的分布是极不均匀的。

ID           COUNT(*)
---------- ----------
1               13575
2                   1

SQL> create index t_idx on t(id);  --创建索引
Index created.

SQL> exec dbms_stats.gather_table_stats(user,'T',method_opt=>'for all indexed columns',cascade=>true);  --收集统计信息

PL/SQL procedure successfully completed.

SQL>
SQL> var fid varchar2;
SQL> exec :fid := '2';

PL/SQL procedure successfully completed.

SQL> alter system flush shared_pool;  --刷新shared pool

System altered.

SQL> alter system flush buffer_cache; --刷新buffer_cache

System altered.

SQL> select * from t where id=:fid;

ID
----------
TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2
SYS_LOB0000000920C00008$$


SQL> select * from table(dbms_xplan.display_cursor(null));  --查看执行计划,使用了索引扫描

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  fprdgayw5y5vq, child number 0
-------------------------------------
select * from t where id=:fid

Plan hash value: 470836197

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |    21 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"=:FID)


19 rows selected.

SQL> --alter system flush shared_pool; 
SQL> --alter system flush buffer_cache;
SQL> --set autot trace exp stat                --这个地方做标识,是因为个人的反复测试发现使用set autot trace 得到的执行计划不一样
SQL> --select * from t where id=:fid;
SQL> alter system flush shared_pool;

System altered.

SQL> alter system flush buffer_cache;

System altered.

SQL> alter session set "_optim_peek_user_binds"=false;  --修改了隐含参数。

Session altered.

SQL> select * from t where id=:fid;

ID
----------
TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2
SYS_LOB0000000920C00008$$


SQL> select * from table(dbms_xplan.display_cursor(null));  --可以看到启用特性之后,走了平均的统计信息。

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  fprdgayw5y5vq, child number 0
-------------------------------------
select * from t where id=:fid

Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |    16 (100)|          |
|*  1 |  TABLE ACCESS FULL| T    |  6788 |   139K|    16   (7)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("ID"=:FID)


18 rows selected.
--设置完后,为了突出变化,我们把隐含参数的设置去除,设置为原来的值。
SQL> alter session set "_optim_peek_user_binds"=true;

Session altered.
SQL> select * from t where id=:fid;

ID
----------
TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2
SYS_LOB0000000920C00008$$


SQL> select * from table(dbms_xplan.display_cursor(null));  --可以看到执行计划又开始走索引扫描了。

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  fprdgayw5y5vq, child number 1
-------------------------------------
select * from t where id=:fid

Plan hash value: 470836197

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |    21 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"=:FID)


19 rows selected.
SQL> select /*+opt_param('_optim_peek_user_binds', 'false')*/ id,text from t where id=:fid;  --我们加入Hint来看看全表扫描

ID
----------
TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2
SYS_LOB0000000920C00008$$


SQL>
SQL> select * from table(dbms_xplan.display_cursor(null));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  dpqhz5gjt26hh, child number 0
-------------------------------------
select /*+opt_param('_optim_peek_user_binds', 'false')*/ id,text from t
where id=:fid

Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |    16 (100)|          |
|*  1 |  TABLE ACCESS FULL| T    |  6788 |   139K|    16   (7)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("ID"=:FID)


19 rows selected.

SQL> select /*+opt_param('_optim_peek_user_binds', 'true')*/ id,text from t where id=:fid; 

ID
----------
TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2
SYS_LOB0000000920C00008$$


SQL> select * from table(dbms_xplan.display_cursor(null));   --查看去除bind peek之后的执行计划,执行计划又开始走索引

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  g80r4gd8sck2v, child number 0
-------------------------------------
select /*+opt_param('_optim_peek_user_binds', 'true')*/ id,text from t
where id=:fid

Plan hash value: 470836197

-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |       |       |     2 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |    21 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | T_IDX |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"=:FID)


20 rows selected.

通过上面的测试发现,执行计划都是取平均的统计信息,达到了预期的目标。

目录
相关文章
|
5月前
|
Java 测试技术 数据库
使用benchmarksql测试数据库处理能力
传统的OLTP业务,应用系统使用 java 开发,并且不建议使用存储过程,使用 benchmarksql 压测数据库最公平,既可以测试数据库性能,也可以测试JDBC驱动
387 88
|
6月前
|
数据库
【YashanDB知识库】YAC修改参数后关闭数据库夯住
【YashanDB知识库】YAC修改参数后关闭数据库夯住
|
6月前
|
数据库连接 PHP 数据库
【YashanDB知识库】PHP使用ODBC使用数据库绑定参数功能异常
【YashanDB知识库】PHP使用ODBC使用数据库绑定参数功能异常
|
6月前
|
数据可视化 JavaScript 前端开发
利用Postman和Apipost进行API测试的实践与优化-动态参数
在API测试中,Postman和Apipost是常用的工具。Postman内置变量功能有限,面对复杂场景时需编写JavaScript脚本,增加了维护成本。而Apipost提供丰富的内置变量、可视化动态值配置和低代码操作,支持生成真实随机数据,如邮箱、手机号等,显著提升测试效率和灵活性。对于复杂测试场景,Apipost是更好的选择,能有效降低开发与维护成本,提高测试工作的便捷性和可维护性。
|
6月前
|
数据可视化 JavaScript 前端开发
从Postman到Apipost:我的动态参数测试实战踩坑记
作为一名全栈开发工程师,在开发用户中心模块时,我遇到了复杂参数API测试的挑战。最初使用Postman时,发现其在生成动态参数(如邮箱、手机号和日期)时存在诸多问题,导致测试效率低下甚至出错。例如,随机生成的邮箱格式无效等 后来,CTO推荐了Apipost,它提供了更智能的参数生成方式:支持真实邮箱、符合规范的手机号以及合法日期范围,极大提升了测试效率和准确性。通过对比,Apipost在处理复杂动态参数方面明显优于Postman,减少了维护成本并提高了团队协作效率。现在,我们已全面切换到Apipost,并利用其「参数组合测试」功能发现了多个边界条件bug。
|
6月前
|
PHP 数据库
【YashanDB知识库】PHP使用OCI接口使用数据库绑定参数功能异常
【YashanDB知识库】PHP使用OCI接口使用数据库绑定参数功能异常
|
6月前
|
数据库
【YashanDB知识库】yac修改参数后关闭数据库hang住
【标题】YashanDB yac修改参数后关闭数据库hang住 【简介】修改yac参数后执行`shutdown immediate`时,数据库hang住。原因是Shutdown操作中线程卡在获取信号量,jobManagerStop()和checkRedoFreeSpace()接口导致死循环,且SHM_POOL_SIZE过小影响redo日志使用。需检查配置文件并调整SHM_POOL_SIZE参数。影响范围为23.1 - 23.1.1.200版本。 【关键词】YashanDB, yac, shutdown hang 【修复版本】待定
|
7月前
|
数据库
【YashanDB 知识库】误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降
**标题:误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降** **简介:** 数据库性能骤降至正常水平的百分之一,主要表现为大量 free buffer wait 等待事件。原因是系统级别 STATISTICS_LEVEL 被误设为 ALL。解决方法是将其恢复为默认值 TYPICAL,执行命令:`ALTER SYSTEM SET statistics_level='TYPICAL' SCOPE=BOTH;` 以恢复正常性能。
|
8月前
|
弹性计算 运维 Java
OS-Copilot参数功能全面测试报告
作为一名运维工程师,我主要负责云资源的运维和管理。通过使用OS Copilot的-t/-f/管道功能,我顺利解决了环境快速搭建的问题,例如Tomcat的快速部署。具体步骤包括购买ECS服务器、配置安全组、远程登录并安装OS Copilot。使用-f参数成功安装并启动Tomcat,自动配置JDK,并通过|管道功能验证了生成内容的正确性。整个过程非常流畅,极大提升了工作效率。
132 12
|
8月前
|
JavaScript NoSQL Java
基于SpringBoot+Vue实现的大学生体质测试管理系统设计与实现(系统源码+文档+数据库+部署)
面向大学生毕业选题、开题、任务书、程序设计开发、论文辅导提供一站式服务。主要服务:程序设计开发、代码修改、成品部署、支持定制、论文辅导,助力毕设!