作者归档：Lunar

固定执行计划-使用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 | 标签为 | 留下评论

Leap Second(润秒）跟Oracle相关产品的提示

发表于 2015 年 6 月 30 日 由 Lunar

今天好多朋友都在讨论Leap Second(润秒）的问题（不少集成商和客户都收到Oracle的通告了）： Oracle官方的解释也很清晰： Oracle所有产品线关于润秒的说明： Information Center: Leap Second Information for All Products – Database – Exadata – Middleware – Exalogic – Linux – Sun – Fusion – EBS – JDE – Siebel – Peoplesoft (Doc ID 2019397.2) . MySQL也会有相应的影响，比如 NOW() … 继续阅读 →

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

使用DUL和ODU抽取Exadata上的oracle数据库（抽取磁盘上的数据文件）

发表于 2015 年 6 月 23 日 由 Lunar

之前研究过dul和odu，发现不能识别磁盘，当时犯了一个错误，因为普通环境（非exadata环境），都是在主机上运行扫描磁盘的工作，因此我之前也在exadata的主机上扫描磁盘，发现不行，具体参见： 在Exadata上，为什么 DUL 和 ODU不能读取ASM数据库的数据，但是Kfed却可以？ 今天在exadata的存储节点（cell节点）上配置了一下，发现dul和odu都可以直接扫描磁盘，以后有exadata上oracle数据库损坏时，请联系我，O(∩_∩)O哈哈 具体测试如下： 这里我使用control+C终止了，因为磁盘太大了，扫描时间太久，上面的信息已经可以证明，至少可以扫描 至于normal external等其他问题，以后再说。 扫描文件具体如下： 这里 IDX_DATA1.dat 就是dul扫描出来的一些信息，之后使用命令抽成文件就依据这些。 再看看ODU： 这里报错是因为cell上磁盘空间很小，稍微一折腾就满了（存放ODU抽取文件的是根，100%了）： 先别急删除，进去看看数据; 可以看到，odu也抽出了数据， 并且，可以看到，已经抽取了几个dbf的数据文件。

发表在 ASM, backup&recovery, DUL ODU, Exadata | 标签为 , , , | 留下评论

ASM NORMAL REDUNDANCY情况下，谁完成了数据的镜像IO？

发表于 2015 年 6 月 16 日 由 Lunar

前几天，一些朋友讨论ASM中，如果是NORMAL redundancy磁盘组，数据的镜像是由oracle rdbms进程完成，还是由ASM的进程完成镜像的工作。 我们知道，ASM NORMAL REDUNDANCY磁盘组类似于RAID 10的操作，也就是镜像+条带划。 . 在传统架构中，oracle只负责写入一份数据，数据保护（镜像）是由存储或者RAID卡来完成的，那么在ASM中是否也是DB完成一次写入，ASM进行同步呢？ 根据下面的测试，结论是： DB的进程完成数据库中所有应用数据的IO操作，包括镜像数据的IO。而ASM进程只负责元数据（metadata extent）的维护和IO。 . 具体测试如下： 首先，我们创建一个normal redundancy的磁盘组，用来放数据库的redo，比如 +REDODG： 这个两个磁盘的failure group的信息如下： 然后，我们使用REDODG创建了9组redo log group（这套10204的RAC的redo都放在上面了）: 这个数据库实例的LGWR进程号为 11159： 现在我们使用strace跟踪一下这个进程在数据库切换日志时的动作，如果lgwr进程只写了一个设备，比如/dev/mapper/redolun1或者/dev/mapper/redolun2，那么可以再跟踪一下ASMB进程。 . 如果LGWR进程写了两个设备，即/dev/mapper/redolun2和/dev/mapper/redolun1都写入了相应的IO，那么我们可以认为，数据库的LGWR自己完成了primary extent和mirror extent的全部操作。 这也是Oracle 文档中一直说明的一点“ASM负责ASM实例的metadata的IO，而DB完成应用实际数据的IO”。 具体跟踪文件如下： 上面的跟踪文件可以很清晰的看到，LGWR进程连续写了2分相同的数据到fd为16和17的设备上。 那么16和17是什么呢： 这里看到，16和17就是redodg所使用的两个磁盘。也就是说，LGWR自己完成了primary extent和mirror extent的IO操作。 至此已经很清楚了，那么可以我们可以推断，DBWR等数据库操作也是有DB自己的进程完成了，而ASM只负责元数据的IO操作和维护。 具体的测试，有兴趣的可以自己跟踪。 上面的跟踪信息还可以看到，实际上oracle使用AIO的方式（使用io_submit，io_getevents等），定期同步控制文件的信息，仍然是写16和17两个设备。 … 继续阅读 →

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

收集ASM信息的脚本

发表于 2015 年 5 月 17 日 由 Lunar

当ASM中某些磁盘状态异常，比如应该是“MEMBER”的，却是“CANDIDATE”或者其他等各种盘头异常，或者ASM实例异常，可以使用下面脚本收集ASM信息（来源于MOS）

发表在 ASM, Scripts | 标签为 , | 留下评论

使用dd备份和恢复ASM中的数据文件头

发表于 2015 年 5 月 17 日 由 Lunar

今天看了飞总微博上的备份ASM中数据文件头（http://www.xifenfei.com/5888.html），觉得有意思 佩服飞总专业的钻研精神，那么多X$的internal视图……O(∩_∩)O哈哈~ 这里用大家随处可见的（除了extent分布的x$kffxp需要百度和google外），其余都是文档中有详细记载的常用ASM视图来实现同样功能：

发表在 ASM | 标签为 , | 一条评论