月归档：2016 年一月

Linux7（CentOS,RHEL,OEL）和Oracle RAC环境系列–1-简介

发表于 2016 年 1 月 18 日 由 Lunar

去年开始测试Linux7.1的相关功能，包括CentOS Linux7的安装和OEL的安装 在Linux7.1(8月份已经release的是Linux7.2）上安装Oracle 11.2.0.4 RAC, Oracle 12.1 RAC,Oracle 12.2 beta Standalone等等大量测试。 由于Linux7在架构上改变较Linux6有很大改变，包括系统服务的架构，管理命令集等等 感觉上是几乎是重新学习了一下Linux的一些常用管理方法，就如同Oracle 10.2 RAC到11.2 Grid Infrastructure 的改变一样。 由于比较懒，之前没有总结，一段时间不玩，发现很多生疏了，记忆力不好是硬伤……因此，开始打算逐步总结一下，免得以后用的时候忘记了 ：） . Linux7总体感觉启动很快，这个可能跟Linux7采用systemd的管理方式有关系 之前的Linux版本中，使用SysVinit一次一个的串行地启动服务。 系统启动按照/etc/inittab中定义的脚本顺序启动，这种启动服务的方式靠脚本控制，考虑服务之间的依赖关系，因此是顺序执行的 从Linux7开始，采用Systemd并行地启动系统服务进程，系统启动时并行启动多个预先配置的Unit 不同Unit之间的依赖关系使用缓冲的方法，将有依赖关系的服务请求放入队列 待被依赖的服务启动后，该服务继续获取执行，因此可以做到并行执行服务来快速启动。 而且Systemd最初仅启动确实被依赖的那些服务，极大地减少了系统引导的时间。 可以用下面的命令看到系统引导用时： 这里看到，开机时间是31秒左右，可见开机速度之快（关机也同样快）！ . systemd命令非常丰富，通过查看help就可以看出来。 比如列出所有正在运行的单元: . 作为一个DBA，从安装开始熟悉一个新成品，然后通过逐步测试官方文档中的各种功能来熟悉产品已经成为习惯。 这就从安装RAC开始说起。 首先是OS的安装，因为考虑后面是为了跑Oracle，因此我选择OEL Linux7. 安装时如果后面不考虑静默安装RAC或者静默安装数据库，那么需要选择“带图形的服务器”（Server with … 继续阅读 →

发表在 Installation and Deinstall, Linux, ORACLE 12C, RAC | 标签为 , , , | 一条评论

固定执行计划-使用SPM（Sql Plan Management）固定执行计划

发表于 2016 年 1 月 13 日 由 Lunar

测试目的： 使用SPM（Sql Plan Management）固定执行计划和hint中指定no index，谁的优先级高？ . 固定执行计划-使用SQL Tuning Advisor 固定执行计划-手工指定PLAN OUTLINE 固定执行计划-手工指定索引名称的方式 固定执行计划-使用coe_xfr_sql_profile固定执行计划 固定执行计划-使用SPM（Sql Plan Management）固定执行计划 . 在Oracle 11g前，我们可以借助存储大纲(Stored Outline)和SQL Profile来帮助我们固定某个SQL语句的执行计划。 11g中，Oracle 提供了SPM（Sql Plan Management）。 通过这个特性，可以考虑让Oracle自动去判断某个SQL的新的执行计划是否更加合理（成本更低），只有在新的执行计划比原来的执行计划更好才会被使用，从而保护了执行计划的稳定性和SQL语句的执行效率。 可以考虑手工捕获和自动捕获两种方式，这里我们采用手工捕获（11.2的缺省设置是非自动捕获）。 首先查看当前为禁止自动捕获的状态： 当前SPM中没有内容： 手工加载一个SQL到SPM中： 由于上一个测试，我们已经有了正确的执行计划，即： 下面，我们装载指定的执行计划： 确认该执行计划的OUTLINE： 这里看到是我们需要的走索引的outline，详细的OUTLINE信息如下: 现在我们删除profile以前用coe绑定的sql profile： 再次验证SPM的执行计划： 执行SQL，发现SPM可以固定执行计划，使用了我们期待的： 这里看到已经使用了SPM中的SQL Profile：SQL_PLAN_0k9pqn7v9yvuw02b73393 … 继续阅读 →

发表在 Performence Tuning | 标签为 , | 留下评论

固定执行计划-使用coe_xfr_sql_profile(BASELINE)固定执行计划

发表于 2016 年 1 月 13 日 由 Lunar

测试目的： 使用coe_xfr_sql_profile的方式固定执行计划和hint中指定no index，谁的优先级高？ 在SQLT工具中包含了几个轻巧方便的coe脚本，用来固定执行计划，其中coe_xfr_sql_profile是我常用的。 . 固定执行计划-使用SQL Tuning Advisor 固定执行计划-手工指定PLAN OUTLINE 固定执行计划-手工指定索引名称的方式 固定执行计划-使用coe_xfr_sql_profile固定执行计划 固定执行计划-使用SPM（Sql Plan Management）固定执行计划 . 查看当前的SQL Profile： 使用coe_xfr_sql_profile脚本自动识别和指定执行计划: 因为删除了SQL Profile，对应的执行计划也会被删除，因此当前只有一个全表扫描的执行计划（上次测试留下的），以前的执行计划都不在了。 上面的执行过程中已经告诉我们，这个执行计划会使用全表扫描(q'[FULL(@”SEL$1″ “LUNARTEST1″@”SEL$1”)]’)： 我们查看一下这个SQL Profile的主要内容： 现在我们产生一个正确的执行计划，让该sql执行时使用到索引： 找出sqlid 找出正确的outline: 这里我们看到已经使用了索引。 使用coe_xfr_sql_profile固定执行计划： 现在，测试一下，使用SYS用户绑定是否会影响其他用户使用执行计划： 再次执行查询： 这里我们看到该SQL还是忽略了hint而使用了索引。 结论： 1，使用SYS用户绑定执行计划不会影响其他用户使用该SQL Profile及执行效果 2，这里已经使用了我们的SQL PROFILE(coe_bjgduva68mbqm_3241900148)，sql使用了索引，说明coe_xfr_sql_profile绑定执行计划的方式比hint的优先级高

发表在 Performence Tuning | 标签为 | 留下评论

固定执行计划-手工指定索引名称的方式

发表于 2016 年 1 月 13 日 由 Lunar

测试目的：手工指定索引的方式绑定的执行计划和hint中指定no index，谁的优先级高？ . 固定执行计划-使用SQL Tuning Advisor 固定执行计划-手工指定PLAN OUTLINE 固定执行计划-手工指定索引名称的方式 固定执行计划-使用coe_xfr_sql_profile固定执行计划 固定执行计划-使用SPM（Sql Plan Management）固定执行计划 . 由于上一个测试中，已经绑定了SQL Profile。 这里我们需要先删除该SQL Profile，再手工指定索引的方式绑定执行计划试试看。 确认下SQL PROFILE的内容： 删除这个sql profile 通过sqlprof_attr来实现手工指定索引的方式绑定执行计划，执行计划起名为“Lunar_bjgduva68mbqm_profile”： 查看这个Lunar_bjgduva68mbqm_profile的一些参数，确认是我们指定的索引： 再次执行SQL，看看这个Lunar_bjgduva68mbqm_profile是否生效： 结论： 这里看到已经使用了Lunar_bjgduva68mbqm_profile，但是SQL并没有按照Lunar_bjgduva68mbqm_profile中指定的索引名称使用索引。 这里已经使用了我们的SQL PROFILE，但是仍然走全表扫描 说明hint覆盖了手工指定索引的方式绑定的执行计划，说明手工指定索引名称的方式比hint的优先级低。

发表在 Performence Tuning | 标签为 | 留下评论

固定执行计划-手工指定PLAN OUTLINE

发表于 2016 年 1 月 13 日 由 Lunar

测试目的： hint和手工指定OUTLINE参数的方式来帮顶执行计划，谁的优先级高？ . 固定执行计划-使用SQL Tuning Advisor 固定执行计划-手工指定PLAN OUTLINE 固定执行计划-手工指定索引名称的方式 固定执行计划-使用coe_xfr_sql_profile固定执行计划 固定执行计划-使用SPM（Sql Plan Management）固定执行计划 . 由于上一个测试中，已经绑定了sql使用SQL Tuning Advisor中的执行计划，从而使SQL走索引了（覆盖了hint）。这里我们需要先删除该SQL Profile，再手工绑定试试。 确认下SQL PROFILE的内容： 这里我们看到该SQP Profile中提供了详细的表和列的统计信息 并且有“IGNORE_OPTIM_EMBEDDED_HINTS”，也就是忽略嵌入到SQL中的hint 确认一下，当前SQL语句使用了该SQL Profile： 这里我们看到，当前执行确实使用了SQL profile SYS_SQLPROF_015236655fb80000，因此hint no_index失效了 （优先级低于SYS_SQLPROF_015236655fb80000，具体参见固定执行计划-使用SQL Tuning Advisor） 查看SYS_SQLPROF_015236655fb80000的OUTLINE信息： 这里我们看到该SQP Profile中提供了详细的表和列的统计信息 并且有“IGNORE_OPTIM_EMBEDDED_HINTS”，也就是忽略嵌入到SQL中的hint 现在，我们删除这个SQL Profile，稍后使用上面的OUTLINE手工绑定执行计划： 此时，应该正常按照hint走了全表扫描： 手工指定sqlprofile参数的方式绑定执行计划： … 继续阅读 →

发表在 Performence Tuning | 标签为 | 留下评论

固定执行计划-使用SQL Tuning Advisor

发表于 2016 年 1 月 13 日 由 Lunar

测试目的，当有hint时，并且hint跟需要绑定的执行计划有冲突，谁的优先级高。 . 固定执行计划-使用SQL Tuning Advisor 固定执行计划-手工指定PLAN OUTLINE 固定执行计划-手工指定索引名称的方式 固定执行计划-使用coe_xfr_sql_profile固定执行计划 固定执行计划-使用SPM（Sql Plan Management）固定执行计划 . 这里是第一个测试，使用SQL Tuning Advisor来测试： 创建测试用例： 执行查询，我们看到sql按照hint的方式没有使用索引，而是全表扫描，这是我们预期的结果： 下面我们运行SQL Tuning Advisor来生成建议报告： 查看生成的报告内容： 这里我们看到SQL Tuning Advisor提示了两个建议： 1，收集统计信息： 并且给出了这个执行计划和原始执行计划的对比，可以看到 执行效率提高了89%以上，逻辑读从23降低为2，减少了91.3%。 . 下面我们按照建议执行。 首先收集统计信息： 然后我们接受建议中的执行计划： 现在，再次查询看看效果： 这里我们看到，这个执行计划中已经使用了索引，并且逻辑读从49降低为14, 但是这里还有物理读，因此，我们再次执行看看： 逻辑读从14降低为3，这个执行计划已经是我们需要的。 现在我们查看一下这个SQL Profile的OUTLINE： 这里我们看到该SQP Profile中提供了详细的表和列的统计信息 … 继续阅读 →

发表在 Performence Tuning | 标签为 | 留下评论