Oracle固定SQL的执行计划(二)---SPM

之前写了一篇博客介绍的是用SQL Profile来调整、稳定目标SQL的执行计划,即使无法修改目标SQL的SQL文本。但SQL Profile实际上只是一种亡羊补牢、被动的技术手段,应用在那些执行计划已经发生了不好的变更的SQL上,即当我们发现这些SQL的执行计划已经出了问题时通过创建SQL Profile来纠正、稳定这些SQL的执行计划。即便通过创建SQL Profile解决了目标SQL执行计划变更的问题,依然不能保证系统后续执行的SQL的执行计划就不再发生不好的变更。这种不确定性会给Oracle数据库大版本升级(比如从Oracle 10g升级到Oracle 11g)带来一系列的麻烦,因为不清楚升级之后原先系统中哪些SQL的执行计划会发生不好的变更。

为了解决上述问题,Oracle在11g中推出了SPM(SQL Plan Management)。SPM是一种主动的稳定执行计划的手段,能够保证只有被验证过的执行计划才会被启用,当由于种种原因(如统计信息的变更)而导致目标SQL产生了新的执行计划后,这个新的执行计划并不会被马上启用,直到它已经被我们验证过其执行效率会比原先执行计划高才会被启用。

随着Oracle数据库版本的不段推进,其CBO的算法、功能也在一直不断进化和增加,所以同样的SQL有可能在新版本的Oralce数据库中执行效率更高,如果我们使用了SQL Profile(特别是使用了Manual类型的SQL Profile)来稳定目标SQL的执行计划,那就意味着可能失去了继续优化上述SQL的执行效率的机会。而SPM的推出可以说彻底解决了执行计划稳定性的问题,它既能主动地稳定执行计划,又保留了继续使用新的执行效率可能更高的执行计划的机会。

当启用了SPM后,每一个SQL都会存在对应的SQL Plan Baseline,这个SQL Plan Baseline里存储的就是该SQL的执行计划,如果一个SQL有多个执行计划,那么该SQL就可能会有多个SQL Plan Baseline,可以从DBA_SQL_PLAN_BASELINES中查看目标SQL所有的SQL Plan Baseline。

DBA_SQL_PLAN_BASELINES中的列ENABLED和ACCEPTED用来描述一个SQL Plan Baseline所对应的执行计划是否能被Oracle启用,只有ENABLED和ACCEPTED的值均为“YES”的SQL Plan Baseline所对应的执行计划才会被Oracle启用,如果一具SQL有超过1个以上的SQL Plan Baseline的ENABLED和ACCEPTED的值均为YES,则Oracle会从中选择成本值最小的一个所对应的执行坟墓来作为该SQL的执行计划。

在Oracle 11g及其以上的版本中,有如下两种方法可以产生目标SQL的SQL Plan Baseline。

  • 自动捕获

  • 手工生成/批量导入(批量导入尤其适用于Oracle数据库大版本的升级,它可以确保升级后原有系统所胡SQL的执行计划不会发生变化)

下面分别介绍如何自动捕获和手工的方式来产生SQL Plan Baseline。

1 自动捕获SQL Plan Baseline

参数OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES用于控制是否开启自动捕获SQL Plan Baseline,其默认值为FALSE,表示在默认情况下,Oracle并不会自动捕获SQL Plan Baseline。这个参数可以在session或系统级别动态修改。当修改为TRUE后,则Oracle会对上述参数影响范围内所有重复执行的SQL自动捕获其SQL Plan Baseline,并且针对目标SQL第一次捕获的SQL Plan Baseline的ENABLED和ACCEPTED的值均为“YES”。随后如果该SQL的执行计划发生了变更,则再次捕获到的SQL Plan Baseline的ENABLED的值依然为YES,但ACCEPTED的值变为了NO,这表示后续变更的执行计划虽然被捕获了,但Oracle不会将其作为该SQL的执行计划来执行,即此时Oracle会永远沿用该SQL第一次被捕获的SQL Plan Baseline所对应的执行计划(除非后续做了手工调整)。

参数OPTIMIZER_USE_SQL_PLAN_BASELINES用于控制是否启用SQL Plan Baseline,其默认值为TRUE,表示在默认情况下,Oracle在生成执行计划时就会启用SPM,使用已有的SQL Plan Baseline,这个参数也可以在session或系统级别动态修改。

下面看一下实例:

查看上述两个参数的默认值

zx@MYDB>showparametersql_plan

NAMETYPEVALUE
---------------------------------------------------------------------------------------------------
optimizer_capture_sql_plan_baselinesbooleanFALSE
optimizer_use_sql_plan_baselinesbooleanTRUE

在当前session中禁掉SPM并同时开启自动捕获SQL Plan Baseline:

zx@MYDB>altersessionsetoptimizer_use_sql_plan_baselines=FALSE;

Sessionaltered.

zx@MYDB>altersessionsetoptimizer_capture_sql_plan_baselines=TRUE;

Sessionaltered.

创建测试表T2

zx@MYDB>createtablet2asselect*fromdba_objects;

Tablecreated.

zx@MYDB>createindexidx_t2ont2(object_id);

Indexcreated.

zx@MYDB>execdbms_stats.gather_table_stats(ownname=>USER,tabname=>'T2',estimate_percent=>100,cascade=>true);

PL/SQLproceduresuccessfullycompleted.

zx@MYDB>selectobject_id,object_namefromt2whereobject_idbetween103and108;

OBJECT_IDOBJECT_NAME
----------------------------------------
103MIGRATE$
104DEPENDENCY$
105ACCESS$
106I_DEPENDENCY1
107I_DEPENDENCY2
108I_ACCESS1

6rowsselected.

wKioL1i1djrRH9N_AAA32GVLpeo751.png

从执行计划上看,走的是索引IDX_T2上的索引范围扫描,因为SQL只执行了一次,所以Oracle不会自动捕获SQL Plan Baseline,DBA_SQL_PLAN_BASELINES中没有记录

zx@MYDB>colsql_handlefora30
zx@MYDB>colplan_namefora30
zx@MYDB>coloriginfora20
zx@MYDB>colsql_textfora70
zx@MYDB>selectsql_handle,plan_name,origin,enabled,accepted,sql_textfromdba_sql_plan_baselines;

norowsselected

再次执行上述SQL,因为重复执行该SQL,Oracle自动捕获了这个SQL的SQL Plan Baseline

zx@MYDB>selectobject_id,object_namefromt2whereobject_idbetween103and108;

OBJECT_IDOBJECT_NAME
----------------------------------------
103MIGRATE$
104DEPENDENCY$
105ACCESS$
106I_DEPENDENCY1
107I_DEPENDENCY2
108I_ACCESS1

6rowsselected.

zx@MYDB>selectsql_handle,sql_textfromdba_sql_plan_baselines;

SQL_HANDLEPLAN_NAMEORIGINENABLEDACCEPTEDSQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------
SYS_SQL_ac526b1e4be74880SQL_PLAN_asnmb3t5yfk4024c6dbb6AUTO-CAPTUREYESYESselectobject_id,object_namefromt2whereobject_idbetween103and108

现在将索引IDX_T2的聚簇因子修改为2400万,目的是为了能让SQL的执行计划变为对表T2的全表扫描(为何修改聚簇因子,参考http://www.jb51.cc/article/p-brzveamg-xe.html)。修改完后再执行上述SQL,并查看执行计划:

zx@MYDB>execdbms_stats.set_index_stats(ownname=>USER,indname=>'IDX_T2',clstfct=>24000000,no_invalidate=>false);

PL/SQLproceduresuccessfullycompleted.

zx@MYDB>selectindex_name,clustering_factorfromdba_indexeswhereindex_name='IDX_T2';

INDEX_NAMECLUSTERING_FACTOR
-----------------------------------------------------------------------------------------------------------
IDX_T224000000

zx@MYDB>selectobject_id,object_namefromt2whereobject_idbetween103and108;

OBJECT_IDOBJECT_NAME
----------------------------------------
103MIGRATE$
104DEPENDENCY$
105ACCESS$
106I_DEPENDENCY1
107I_DEPENDENCY2
108I_ACCESS1

6rowsselected.

wKioL1i1e3_CKEWzAAAvWrViOHQ942.png

从执行计划中可以看出该SQL的执行计划已经变为全表扫描。因为目标SQL已经重复执行且同时又产生了一个新的执行计划,所以现在Oracle就会自动捕获并创建这个新的执行计划所对应的SQL Plan Baseline了。从如下查询可以看出Oracle对新的执行计划产生了一个新的SQL Plan Baseline,其ENABLED的值依然为YES,但ACCEPTED的值变为了NO:

wKiom1i1fKawm8HlAAA-8lMjR2w622.png

现在我们对当前Session关闭自动捕获SQL Plan Baseline并同时开启SPM,现在索引IDX_T2的聚簇因子依然为2400万,再次执行目标SQL,并查看执行计划:

zx@MYDB>altersessionsetoptimizer_use_sql_plan_baselines=TRUE;

Sessionaltered.

zx@MYDB>altersessionsetoptimizer_capture_sql_plan_baselines=FALSE;

Sessionaltered.


zx@MYDB>selectindex_name,object_namefromt2whereobject_idbetween103and108;

OBJECT_IDOBJECT_NAME
----------------------------------------
103MIGRATE$
104DEPENDENCY$
105ACCESS$
106I_DEPENDENCY1
107I_DEPENDENCY2
108I_ACCESS1

6rowsselected.

wKiom1i1fbyDv_8uAAA50HboFX4394.png

wKioL1i1fbyBQ8hfAAAOoTRrHrs335.png

从上面的显示内容可以看出,现在目标SQL的执行又从全表扫描恢复为了索引范围扫描,并且执行计划中的Note部分有“SQL plan baseline SQL_PLAN_asnmb3t5yfk4024c6dbb6 used for this statement”内容,说明SPM开启的情况下,即便目标SQL产生了新的执行计划,Oracle依然只会应用该SQL的ENABLED和ACCEPTED的值均为YES的SQL Plan Baselline。

如果想启用目标SQL新的执行计划(即全表扫描),应该如何做呢?

针对不同的Oracle版本,会有不同的处理方法。比如这里想启用目标SQL的新的执行计划,如果是11gR1的环境,则只需要将目标SQL所采用的名为SQL_PLAN_asnmb3t5yfk4024c6dbb6的SQL Plan Baseline(即索引范围扫描)的ACCEPTED的值设为NO就可以了。但对于11gR2环境,上述方法会报错,因为在11gR2中,所有已经被ACCEPTED的SQL Plan Baseline的ACCEPTED的值将不再能够被设为NO:

zx@MYDB>vartempvarchar2(1000);
zx@MYDB>exec:temp:=dbms_spm.alter_sql_plan_baseline(sql_handle=>'SYS_SQL_ac526b1e4be74880',plan_name=>'SQL_PLAN_asnmb3t5yfk4024c6dbb6',attribute_name=>'accepted',attribute_value=>'NO');
BEGIN:temp:=dbms_spm.alter_sql_plan_baseline(sql_handle=>'SYS_SQL_ac526b1e4be74880',attribute_value=>'NO');END;

*
ERRORatline1:
ORA-38136:invalidattributenameACCEPTEDspecified
ORA-06512:at"SYS.DBMS_SPM",line2469
ORA-06512:atline1

在11gR2中,我们可以联合使用DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE和DBMS_SPM.ALTER_SQL_PLAN_BASELINE达到启用目标SQL新的执行计划的目的。

先用DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE将新的执行计划(全表扫描)所对应的SQL Plan Baseline的ACCEPTED值设为“YES”:

zx@MYDB>exec:temp:=dbms_spm.evolve_sql_plan_baseline(sql_handle=>'SYS_SQL_ac526b1e4be74880',plan_name=>'SQL_PLAN_asnmb3t5yfk40b860bcf2',verify=>'NO',commit=>'YES');

PL/SQLproceduresuccessfullycompleted.

wKioL1i2VxqjOvvpAABM2ewZX24436.png

从上面显示的内容看到如下信息:“Plan: SQL_PLAN_asnmb3t5yfk40b860bcf2----Plan was changed to an accepted plan.”,这表明已经将新的执行计划(全表扫描)所对应的SQL Plan Baseline的ACCEPTED值设为YES

从下面的查询结果也可以证明:

zx@MYDB>selectsql_handle,sql_textfromdba_sql_plan_baselineswheresql_textlike'selectobject_id%';

SQL_HANDLE		PLAN_NAME		ORIGIN		ENABLEDACCEPTEDSQL_TEXT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SYS_SQL_ac526b1e4be74880SQL_PLAN_asnmb3t5yfk4024c6dbb6AUTO-CAPTURE	YES	YESselectobject_id,object_namefromt2whereobject_idbetween103and108


SYS_SQL_ac526b1e4be74880SQL_PLAN_asnmb3t5yfk40b860bcf2AUTO-CAPTURE	YES	YESselectobject_id,object_namefromt2whereobject_idbetween103and108

然后再使用DBMS_SPM.ALTER_SQL_PLAN_BASELINE将原先的执行计划(索引范围扫描)对应的SQL Plan Baseline的ENABLED的值设为NO:

zx@MYDB>exec:temp:=dbms_spm.alter_sql_plan_baseline(sql_handle=>'SYS_SQL_ac526b1e4be74880',attribute_name=>'enabled',attribute_value=>'NO');

PL/SQLproceduresuccessfullycompleted.

zx@MYDB>selectsql_handle,sql_textfromdba_sql_plan_baselineswheresql_textlike'selectobject_id%';

SQL_HANDLE		PLAN_NAME		ORIGIN		ENABLEDACCEPTEDSQL_TEXT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SYS_SQL_ac526b1e4be74880SQL_PLAN_asnmb3t5yfk4024c6dbb6AUTO-CAPTURE	NO	YESselectobject_id,object_namefromt2whereobject_idbetween103and108

再次执行目标SQL

zx@MYDB>selectobject_id,object_namefromt2whereobject_idbetween103and108;

OBJECT_IDOBJECT_NAME
----------------------------------------
103MIGRATE$
104DEPENDENCY$
105ACCESS$
106I_DEPENDENCY1
107I_DEPENDENCY2
108I_ACCESS1

6rowsselected.

wKiom1i2Vv2iwub_AAAvSnV71kE481.png

wKioL1i2Vv7hc8GWAAAPcRB3DjE878.png

从上述显示可以看出,现在SQL的执行计划已经变为了全表扫描,我们要启用新的执行计划(全表扫描)的目的已经实现,Note部分也有了提示。

从上述测试结果可以看出,实际上我们可以轻易地在目标SQL的多个执行计划中切换,所以SPM确实是既能够主动地稳定执行计划,又保留了继续使用新的执行计划的机会,并且我们很容易就能启用新的执行计划。

下面介绍手工生成SQL Plan Baseline:

手工生成目标SQL的SQL Plan Baseline其实非常简单,其核心就是调用DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE。这里只讨论针对单个SQL的SQL Plan Baseline的手工生成。

之前介绍过用Manual类型的SQL Profile可以在不改变目标SQL的SQL文本的情况下调整其执行计划。实际上,用手工生成SQL Plan Baseline的方式也完全可以实现同样的目的,甚至会比使用Manual类型的SQL Profile更加简洁。

手工生成目标SQL的SQL Plan Baseline的具体步骤为:

1)针对目标SQL使用DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE手工生成其初始执行计划所对应的SQL Plan Baseline。此时,使用DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE传入的参数如下所示:

dbms_spm.load_plans_from_cursor_cache(sql_id=>'原目标SQL的SQL_ID',plan_hash_value=>原目标SQL的PLAN HASH VALUE)

2)改写原目标SQL的SQL文本,在其中加入合适的Hint,直到加入Hint后的所改写的SQL能走出我们想要的执行计划,然后对改写后的SQL使用DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE手工生成新的执行计划所对应的SQL Plan Baseline。此时传入的参数如下所示:

dbms_spm.load_plans_from_cursor_cache(sql_id=>'加入合适Hint后改写SQL的SQL_ID',plan_hash_value=>加入合适Hint后改写SQL的PLAN HASH VALUE,sql_handle=>'原目标SQL在步骤(1)中所产生的SQL Plan Baseline的sql_handle')

3)使用DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE删除步骤(1)中手工生成的原目标SQL的初始执行计划所对应的SQL Plan Baseline。此时传入的参数如下所示:

dbms_spm.drop_sql_plan_baseline(sql_handle=>'原目标SQL在步骤(1)中所产生的SQL Plan Baseline的sql_handle',plan_name=>'原目标SQL在步骤(1)中所产生的SQL Plan Baseline的plan_name')

下面使用一个实例演示:

zx@MYDB>select/*+no_index(t2idx_t2)*/object_name,object_idfromt2whereobject_id=4;

OBJECT_NAME			OBJECT_ID
----------------------------------------
TAB$					4

zx@MYDB>select*fromtable(dbms_xplan.display_cursor(null,null,'advanced'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID	0n5z3wmf8qpgn,childnumber0
-------------------------------------
select/*+no_index(t2idx_t2)*/object_name,object_idfromt2where
object_id=4

Planhashvalue:1513984157

--------------------------------------------------------------------------
|Id|Operation	|Name|Rows|Bytes|Cost(%CPU)|Time	|
--------------------------------------------------------------------------
|0|SELECTSTATEMENT|	|	|	|287(100)|	|
|*1|TABLEACCESSFULL|T2	|1|30|287(1)|00:00:04|
--------------------------------------------------------------------------

QueryBlockName/ObjectAlias(identifiedbyoperationid):
-------------------------------------------------------------

1-SEL$1/T2@SEL$1

OutlineData
-------------

/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.1')
DB_VERSION('11.2.0.1')
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
FULL(@"SEL$1""T2"@"SEL$1")
END_OUTLINE_DATA
*/

PredicateInformation(identifiedbyoperationid):
---------------------------------------------------

1-filter("OBJECT_ID"=4)

ColumnProjectionInformation(identifiedbyoperationid):
-----------------------------------------------------------

1-"OBJECT_NAME"[VARCHAR2,128],"OBJECT_ID"[NUMBER,22]


43rowsselected.

zx@MYDB>selectsql_handle,sql_textfromdba_sql_plan_baselineswheresql_textlike'select/*+no_index(t2idx_t2)%';

norowsselected

zx@MYDB>vartempnumber
zx@MYDB>exec:temp:=dbms_spm.load_plans_from_cursor_cache(sql_id=>'0n5z3wmf8qpgn',plan_hash_value=>1513984157);

PL/SQLproceduresuccessfullycompleted.

zx@MYDB>selectsql_handle,sql_textfromdba_sql_plan_baselineswheresql_textlike'select/*+no_index(t2idx_t2)%';

SQL_HANDLE		PLAN_NAME		ORIGIN		ENABLEDACCEPTEDSQL_TEXT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SYS_SQL_75b06ae056223f5fSQL_PLAN_7bc3aw1b24guzb860bcf2MANUAL-LOAD	YES	YESselect/*+no_index(t2idx_t2)*/object_name,object_idfromt2whereobject_i
												d=4

从上述显示目标SQL初始执行计划为全表扫描,sql_id和plan hash value可以从执行计划中找到,由于没有启用自动捕获SQL Plan Baseline,一开始没有查到目标SQL对应的SQL Plan Baseline,手工生成后,可以查到全表扫描对应的SQL Plan Baseline。

改写原目标SQL,加入Hint后重新执行:

zx@MYDB>select/*+index(t2idx_t2)*/object_name,'advanced'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID	60txg87j30pvw,childnumber0
-------------------------------------
select/*+index(t2idx_t2)*/object_name,object_idfromt2where
object_id=4

Planhashvalue:2008370210

--------------------------------------------------------------------------------------
|Id|Operation		|Name|Rows|Bytes|Cost(%CPU)|Time|
--------------------------------------------------------------------------------------
|0|SELECTSTATEMENT	|	|	|	|	335(100)|	|
|1|TABLEACCESSBYINDEXROWID|T2|	1|	30|	335(0)|00:00:05|
|*2|INDEXRANGESCAN	|IDX_T2|	1|	|	1(0)|00:00:01|
--------------------------------------------------------------------------------------

QueryBlockName/ObjectAlias(identifiedbyoperationid):
-------------------------------------------------------------

1-SEL$1/T2@SEL$1
2-SEL$1/T2@SEL$1

OutlineData
-------------

/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.1')
DB_VERSION('11.2.0.1')
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX_RS_ASC(@"SEL$1""T2"@"SEL$1"("T2"."OBJECT_ID"))
END_OUTLINE_DATA
*/

PredicateInformation(identifiedbyoperationid):
---------------------------------------------------

2-access("OBJECT_ID"=4)

ColumnProjectionInformation(identifiedbyoperationid):
-----------------------------------------------------------

1-"OBJECT_NAME"[VARCHAR2,22]
2-"T2".ROWID[ROWID,10],22]


46rowsselected.

zx@MYDB>exec:temp:=dbms_spm.load_plans_from_cursor_cache(sql_id=>'60txg87j30pvw',plan_hash_value=>2008370210,sql_handle=>'SYS_SQL_75b06ae056223f5f');

PL/SQLproceduresuccessfullycompleted.

zx@MYDB>selectsql_handle,sql_textfromdba_sql_plan_baselineswheresql_textlike'select/*+no_index(t2idx_t2)%';

SQL_HANDLE		PLAN_NAME		ORIGIN		ENABLEDACCEPTEDSQL_TEXT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SYS_SQL_75b06ae056223f5fSQL_PLAN_7bc3aw1b24guz24c6dbb6MANUAL-LOAD	YES	YESselect/*+no_index(t2idx_t2)*/object_name,object_idfromt2whereobject_i
												d=4

SYS_SQL_75b06ae056223f5fSQL_PLAN_7bc3aw1b24guzb860bcf2MANUAL-LOAD	YES	YESselect/*+no_index(t2idx_t2)*/object_name,object_idfromt2whereobject_i
												d=4

从上述输出可以看出把改写过的SQL的新的执行计划所对应的SQL Plan Baseline已经成功生成,而且所有手工生成的SQL Plan Baseline的ENABLED和ACCEPTED的值均为YES,这是和自动捕获的SQL Plan Baseline不一样的地方。

Drop掉原执行计划(全表扫描)所对应的SQL Plan Baseline:

zx@MYDB>exec:temp:=dbms_spm.drop_sql_plan_baseline(sql_handle=>'SYS_SQL_75b06ae056223f5f',plan_name=>'SQL_PLAN_7bc3aw1b24guzb860bcf2');

PL/SQLproceduresuccessfullycompleted.

zx@MYDB>selectsql_handle,object_idfromt2whereobject_i
												d=4

再次执行原目标SQL,并查看执行计划

zx@MYDB>select/*+no_index(t2idx_t2)*/object_name,childnumber2
-------------------------------------
select/*+no_index(t2idx_t2)*/object_name,22]

Note
-----
-SQLplanbaselineSQL_PLAN_7bc3aw1b24guz24c6dbb6usedforthisstatement


50rowsselected.

从上述输出可以看出,原目标SQL已经走了新的执行计划(索引范围扫描),而且Note部分也有提示“SQL plan baseline SQL_PLAN_7bc3aw1b24guz24c6dbb6 used for this statement”说明走了SPM。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读773次,点赞6次,收藏9次。【代码】c# json字符串转Oracle的insert into的小程序。
文章浏览阅读8.7k次,点赞2次,收藏17次。此现象一般定位到远端的监听服务来找问题,在远端查看监听服务状态(具体看下面的解决方案会详细呈现),服务是否开启,另外查看监听端点概要是否存在host未指向到计算名的,如无直接进入监听配置文件listener.ora内添加指向即可。2、查看监听服务状态 lsnrctl status,右边为远端端点状态,未添加host指向到计算名;1、本地及远端安装好Oracle并配置好连接,Oracle服务和监听已启动;1、远程Oracle数据库:Oracle11g R2。或者进入下述服务手动重启。,再进行远程连接即可。_ora-12541:tns:无监听程序
文章浏览阅读2.8k次。mysql脚本转化为oracle脚本_mysql建表语句转oracle
文章浏览阅读2.2k次。cx_Oracle报错:cx_Oracle DatabaseError: DPI-1047: Cannot locate a 64-bit Oracle Client library_cx_oracle.databaseerror: dpi-1047: cannot locate a 64-bit oracle client libr
文章浏览阅读1.1k次,点赞38次,收藏35次。本文深入探讨了Oracle数据库的核心要素,包括体系结构、存储结构以及各类参数。通过解析Oracle数据库的体系结构,读者可以深入了解其内部组成和工作原理。存储结构部分介绍了数据在Oracle中的存储方式,从表空间到数据文件的层层逻辑。最后,我们深入探讨了Oracle数据库中各类参数的作用和配置方法,帮助读者更好地理解和优化数据库性能。本文旨在帮助读者全面理解Oracle数据库的运作机制,为其在实践中的应用提供基础和指导。
文章浏览阅读1.5k次。默认自动收集统计信息的时间为晚上10点(周一到周五,4个小时),早上6点(周六,周日,20个小时)由于平时默认每天只收集4小时,时间有点短了,改成每天可收集8小时。oracle 18c中默认是打开的。查看当前自动收集统计信息的时间。_oracle自动收集统计信息
文章浏览阅读929次,点赞18次,收藏20次。只有assm(Automatic Shared Memory Management)模式可以使用大页,需要关闭amm(Memory Manager Process)HugePages_Free: 306 (空闲306页,已使用306-306=0页)防止oracle使用的内存交换,所以设置的大小与oracle配置的sga、pga相关。HugePages_Rsvd: 0 (操作系统承诺给oracle预留的页数)HugePages_Total: 306 (总共306页)_oracle11g 大页
文章浏览阅读801次。例如:10046:0,1,4,8,12。默认redo日志有三个,大小为50M,循环覆盖使用。redo log再覆盖之前,会被归档,形成归档日志。答:不同事件,不同级别。trace的不同级别?_oracle 日志
文章浏览阅读4.2k次,点赞84次,收藏77次。主要讲解MySQL中SQL的DDL语句,其中包括对数据库和表的一系列操作。_sql ddl 新增字段 mysql
文章浏览阅读1.1k次。ON DEMAND:仅在该物化视图“需要”被刷新了,才进行刷新(REFRESH),即更新物化视图,以保证和基表数据的一致性;ON COMMIT:一旦基表有了COMMIT,即事务提交,则立刻刷新,立刻更新物化视图,使得数据和基表一致。Method =>'C',物化视图有三种刷新方式:COMPLETE、FAST和FORCE。物化视图会占用空间,一半可用于大量数据查询时,减缓主表的查询压力使用。例如创建一个物化视图,让对接单位查询。_oracle物化视图定时刷新
文章浏览阅读713次,点赞21次,收藏18次。1.背景介绍在当今的大数据时代,数据量越来越大,传统的关系型数据库已经无法满足业务需求。因此,NoSQL数据库技术迅速崛起,成为企业和开发者的首选。Oracle NoSQL Database是Oracle公司推出的一款分布式NoSQL数据库产品,具有高性能、高可用性和易于扩展等特点。在本文中,我们将深入了解Oracle NoSQL Database的集成与开发者工具,帮助您更好地掌握这款产品的...
文章浏览阅读2.5k次,点赞2次,收藏4次。今天遇见一个问题需要将字段中包含中文字符串的筛选出来。_oracle查询包含中文字符
文章浏览阅读802次。arcmap 在oracle删除表重新创建提示表名存在解决放啊
文章浏览阅读4.3k次,点赞2次,收藏4次。Oracle连接数据库提示 ORA-12638:身份证明检索失败_ora-12638
文章浏览阅读3.4k次,点赞6次,收藏25次。etc/profile是一个全局配置文件,所有用户登录都会使用该文件构建用户环境。与windows配置环境变量是一个道理。选择Linux系统,找到适合自己系统的安装包,我的是CentOS 8 x64。接下来需要登陆Oracle账户才能下载,无账户的可以自己注册一个。Linux中export 命令用于设置或显示环境变量。模式,利用上下键到文档最后,添加以下代码。出现如图所示版本号字样,则说明安装成功。点击下载,勾选1,点击2。记住完整路径用于后面配置。找到Java并点击进去。往下翻,找到Java8。_linux安装jdk1.8
文章浏览阅读2.4w次,点赞26次,收藏109次。JDK 是的简称,也就是 Java 开发工具包。JDK 是整个 Java 的核心,其中JDK包含了 Java 运行环境(Java Runtime Envirnment,简称 JRE),Java 工具(比如 javac、java、javap 等等),以及 Java 基础类库(比如 rt.jar)。最主流的 JDK 是Oracle公司发布的 JDK,除了 Oracle JDK(商业化,更稳定)之外,还有很多公司和组织开发了属于自己的 JDK,比较有名的有IBM JDK(更适合 IBM) 和OpenJDK。_jdk安装教程
文章浏览阅读7.5w次。出现 “java.sql.SQLNonTransientConnectionException:Could not create connection to database server” 的错误通常是由于无法连接到数据库服务器引起的。_java.sql.sqlnontransientconnectionexception: could not create connection to
文章浏览阅读849次,点赞7次,收藏10次。在ClickHouse中创建用户、数据库并进行权限分配是一个重要的管理任务,它涉及到安全性和访问控制。下面是一个基本的指南来帮助你完成这些操作:1. 创建数据库首先,需要创建一个数据库。使用以下命令:CREATE DATABASE IF NOT EXISTS your_database_name;将 your_database_name 替换为你想要的数据库名。2. 创建用户接下来,创建一个新用户。使用以下命令:CREATE USER your_username IDENTIFIED WIT_在clickhouse中如何创建用户 赋权
文章浏览阅读1.2k次,点赞53次,收藏39次。本文是一篇关于Oracle数据库安装和使用的博文摘要。作者以轻松幽默的笔调介绍了自己在实验中掌握的Oracle数据库基本操作,包括使用组件查看命令、配置数据库监听器等。作者也分享了在实验中遇到的一些有趣问题,如SQL语句缺少分号导致的意外错误。此外,作者还强调了登录sys用户和启动实例加载数据库的注意事项,并鼓励读者面对挑战时保持乐观,不断提升自己的能力。整体风格风趣严谨,引人入胜。
文章浏览阅读820次,点赞17次,收藏16次。KingbaseES、xml、dbms_xmlgen、SETSKIPROWS、人大金仓、KingbaseES兼容Oracle包dbms_xmlgen的功能是通过SQL查询将关系表中数据转化为XML文档。转化方式一共有两种:(1)通过查询字符串直接转化。(2)通过上下文句柄转化。对于通过查询字符串直接转化的方式,无法跳过若干行进行查询,只能直接将表格中的所有数据转化为XML文档。