Maclean’s Oracle Database Tech Blog Archives

MySQLサーバのMyISAMテーブルをこわれた原因はなんでしょうか？   適用範囲: MySQLサーバー – バージョン：4.0〜5.5 – リリース：5.5 MySQLサーバ – バージョン：4.0 – リリース：4.0 MySQLサーバー – バージョン：4.0〜5.5 – リリース：4.0〜5.5 すべてのプラットフォーム 目標 MyISAMテーブルがこわれた具体的な原因を説明する。   解決策 MyISAM ストレージエンジンは非常に頼りになる。もしMyISAMテーブルがよく壊れることがあれば、それについての原因を考えてください。データを検索するときに、以下のエラが現れたとはテーブルがこわれたと意味する： Error 1034 Incorrect key file for table: ‘…’. Try to repair it あるいは以下のエラ番号を含んだ情報： Error 126 = Index file is crashed Error 127 = Record-file is crashed Error 134 = Record…

If you cannot start the Oracle database,you do not have valid backups to restore,lost system tablespace data files,data files corrupted !Is there a way to recover your data !   Yes,Still you have an option to extract your data using an Oracle tool Data Unloading (DUL). Oracle DUL Data Unloader data recovery tool information summary…

What tools exist for DUL? As mentioned before, there are very few utilities available for unloading Oracle data files. If you should run into a situation where you need this type of utility or service, I’ve compiled a comprehensive list below: Bernard’s Data UnLoader Oracle’s official DUL utility was initially written by Bernard van Duijnen…

配置 SQL 跟踪工具以收集会话统计信息 使用 TRCSESS 实用程序合并 SQL 跟踪文件 使用 tkprof 实用程序设置跟踪文件的格式 解释 tkprof 命令的输出 端到端应用程序跟踪面临的挑战 我要检索 CRM 服务的踪迹。 我要检索客户机 C4 的踪迹。 我要检索会话 6 的踪迹。 启用跟踪机制后，Oracle DB 通过为每个服务器进程生成跟踪文件来实施跟踪。 在专用服务器模型中，跟踪特定客户机通常不是问题，因为将由一个专用进程在会话生存期内负责会话跟踪。可以从属于负责会话跟踪的专用服务器的跟踪文件中查看该会话的所有跟踪信息。但是，在共享服务器配置中，通常由不同的进程交替为客户机提供服务。与用户会话有关的跟踪信息分散在属于不同进程的不同跟踪文件中，因此很难完整地了解会话在生存期内的踪迹。 而且，有时出于性能或调试目的需要合并特定服务的跟踪信息，又该怎么办呢？因为同时有几个客户机使用同一服务，而每个生成的跟踪文件都属于提供该服务的服务器进程，所以这也很困难。     端到端应用程序跟踪 通过将应用程序工作量通知给以下项，可以简化在多层环境中诊断性能问题的过程： –服务 –模块 –操作 –会话 –客户机 端到端应用程序跟踪工具： –Oracle Enterprise Manager –DBMS_APPICATION_INFO、DBMS_SERVICE、DBMS_MONITOR、DBMS_SESSION –SQL 跟踪和 TRCSESS 实用程序 –tkprof 端到端应用程序跟踪简化了在多层环境中诊断性能问题的过程。在多层环境中，来自最终客户机的请求通过中间层路由到不同的数据库会话，这使得跨不同数据库会话跟踪客户机变得较困难。端到端应用程序跟踪使用客户机标识符，经由所有层直到数据库服务器，唯一地跟踪一个特定最终客户机。 可以使用端到端应用程序跟踪确定超常工作量的来源，例如某条高负荷的 SQL 语句。并且，您还可以确定用户的会话在数据库级别所执行的活动，以解决用户性能问题。 端到端应用程序跟踪通过跟踪某项服务中的特定模块和操作，还简化了应用程序工作量的管理工作。端到端应用程序跟踪可以识别下列项的工作量问题： 客户机标识符：基于登录 ID…

列出使用绑定变量的优点 使用绑定扫视 使用自适应游标共享 Cursor Sharing 游标共享和不同的文字值   如果在您使用的 SQL 语句中，为 WHERE 子句条件提供了不同的文字值，则会在库高速缓存中存储许多版本的几乎完全相同的 SQL 语句。因为每条 SQL 语句是使用不同值提交的，不能在库高速缓存中找到此语句，因此您必须执行所有步骤来处理新的 SQL 语句。这样不仅常常会导致不必要的语句分析，还会导致库高速缓存很快被填满，因为所有不同的语句都存储在其中。 在以此方式进行编码时，您没有利用游标共享。 但是，根据提供的文字值，优化程序可能会生成不同的执行计划。例如，可能存在大量 JOBS，其中 MIN_SALARY 大于 12000。另一方面，可能只有很少的 JOBS，其中 MIN_SALARY 大于 18000。数据分布上的差异可能表明需要添加一个索引，以便可以根据查询中提供的值使用不同的计划。本幻灯片展示了这样的情况。正如您所看到的，第一个查询和第三个查询使用相同的执行计划，但第二个查询使用了另一个执行计划。 从性能角度看，有独立游标时性能较好。但是，这不是很经济，因为您可以为本例中的第一个查询和最后一个查询实现共享游标。 注：在幻灯片示例中，第一个查询和第三个查询的 V$SQL.PLAN_HASH_VALUE 是 相同的。       Curosr Sharing 游标共享和绑定变量     如果使用绑定变量，而不是针对不同文字值发出不同语句，则可避免额外的分析活动（在理论上）。这是因为优化程序会认识到该语句已经过分析，因此决定重用相同的执行计划，即便在下次重新执行相同的语句时您指定了不同的绑定值，也是如此。 在幻灯片的示例中，绑定变量名为 min_sal。它将与 JOBS 表的 MIN_SALARY 列进行比较。不必发出三条不同的语句，发出使用绑定变量的一条语句即可。在执行时，会使用相同的执行计划，用特定值替换变量。 但是，从性能角度看，这不是最佳方案，因为在三次执行中，只有两次您获得了最佳性能。从另一方面看，这样做非常经济，因为您只需要在库高速缓存中存储一个共享游标便可执行全部三条语句。   SQL*Plus 中的绑定变量     SQL>…

收集优化程序统计信息 收集系统统计信息 设置统计信息首选项 使用动态采样 处理优化程序统计信息   SQL CBO 优化器/优化程序 统计信息   优化程序统计信息描述有关数据库及其中对象的详细资料。查询优化程序使用这些统计信息，为每个 SQL 语句选择最佳的执行计划。 由于数据库中的对象经常发生更改，所以必须定期更新统计信息，以使它们能够准确地描述这些数据库对象。统计信息由 Oracle DB 自动进行维护，您也可以使用 DBMS_STATS 程序包手动维护优化程序统计信息。 描述数据库以及数据库中的对象 查询优化程序使用以下信息进行评估： –谓词的选择性 –每个执行计划的成本 –访问方法、联接顺序和联接方法 –CPU 和输入/输出 (I/O) 成本 与收集优化程序统计信息相比，对过时的统计信息进行刷新同样重要。 –由系统自动收集 –用户使用 DBMS_STATS 手动收集   优化程序统计信息的类型 表统计信息： –行数 –块数 –平均行长度 索引统计信息： –B* 树级别 –唯一键 –叶块数量 –聚簇因子 系统统计信息： –I/O 性能及利用率 –CPU 性能及利用率 列统计信息： –基本统计信息：相异值数量、空值数量、平均长度、最小值、最大值 –直方图（列数据有偏差时的数据分布） –扩展的统计信息…

Oracle 用户组汇聚了最活跃的 Oracle 忠实用户。为了更紧密和 Oracle 用户组合作，Oracle 认证团队将支持 Oracle 用户组年轻专家项目。 Oracle 用户组年轻专家项目旨在鼓励用户组成员学习和分享 Oracle 技术，并成为 Oracle 认证的技术专家。为此，Oracle 认证团队将在中国发放数量有限的免费考试券给符合条件的用户组候选人。这些考试券将可以用于 Oracle 认证考试包括 Beta 考试。 了解更多关于 Oracle 认证的信息，请参考 Oracle 认证网站 。 本次活动面向 ACOUG 和 SHOUG 的用户组成员开放。有意参加者请联系 ACOUG 的仇实 ([email protected]) 和 SHOUG 的胡章扬 ([email protected])。 如何获取免费优惠券   用户组成员参与本项目并获取免费考试券必须满足以下条件： 1. 是 ACOUG 或 SHOUG 的活跃会员 2. 符合下列条件之一： 发布博客或撰写关于 Oracle 数据库技术的文章（需要提供文章主题和链接）。 在社交媒体发布的有关 Oracle 公司数据库技术的信息，被甲骨文中国的新浪微博或微信引用或转发（需要提供截图或链接）。…

目的   本文件为用户提供了ORAchk（Oracle配置审计工具）运行和维护的信息。该工具的目的是在Oracle系统中的审计各种重要的配置设置。 注：在2.2.4版本中RACcheck已更名为ORAchk以反映其检查Oracle越来越多产品的健康的不断扩展的作用。请参考RACcheck配置审计工具的声明 –更名为ORAchk（文件编号1591208.1），了解更多详细信息。版本12.1.0.2.3将是raccheck脚本与ORAchk一起发行的最后一个版本。客户应该转化过来，使用任何自动化或环境配置中的orachk脚本。   在以下分类中工具审计配置的设置： OS内核参数 OS包 许多其他OS配置设置 CRS/Grid Infrastructure RDBMS ASM 数据库参数和配置设置 为目标版本2.0.3及以上升级准备评估   范围   ORAchk健康评估工具的范围是Oracle数据库服务器，Grid Infrastructure，Oracle数据库，硬件，操作系统和RAC软件。从ORAchk2.2.0开始，ORAchk功能扩展到Oracle单实例数据库，Oracle Restrat System以及RAC单节点配置   支持的平台   现在，该工具受以下UNIX平台支持： Intel Linux* (Oracle Linux/RedHat 5, 6, 7 and SuSE 9,10, 11, 12) Linux on System Z (RedHat 6, 7 and SuSE 12) Oracle Solaris SPARC (Solaris 10 and…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏     某日与Oracle同事一同在某移动公司进行技术交流，涵盖12c、云技术、数据库整合、容灾、OEM等多个专题领域。临近中午时分，一直喷到了Oracle最适合于人工错误恢复的FLASHBACK技术。正在唾沫四溅之际，突然接到客户DBA电话：“罗工，能不能暂停一下技术交流，我们正好有三张表刚被人意外删除了，能不能过来帮忙用你刚刚介绍的FLASHBACK技术把这三张表抢救回来？” 世界上怎么还有这么巧合的事情？已经由不得我有半分迟疑，特别是任何私心杂念了。诸如：“罗工，这不正好让你展现Oracle技术特点，给你次露脸机会了。”。“罗工，你不挺能吹的吗？看你能不能展示真才实学了”… …。于是，我端起笔记本电脑，直奔现场，一边下楼，一边赶紧看FLASHBACK相关资料。俗话说：临阵磨枪，不快也光。呵呵。 销售同事也看出了情形的紧迫和老罗的“窘”态，想尽一切可能在帮忙：帮我拆笔记本电源线，帮我提着矿泉水，更恨不得搀扶着正阅读文档，步履有点蹒跚的老罗同志一同下楼，哈哈！ 待我赶到机器旁边时，资料也已经看完了，心中也有底了。于是，在简单询问了问题现象之后，赶脚让第三方公司DBA输入如下命令： SELECT original_name, object_name, type, ts_name, droptime, related, space FROM user_recyclebin WHERE can_undrop = ‘YES’; 咦，怎么是空？再在sys用户下输入： Select * from dba_recyclebin; 还是空！怎么回事？难道删除这三张表的客户不是意外操作，而是诚心搞破坏，用了“drop table … purge”命令，或者清空了回收站（Recycle Bin），从而彻底删除了这三张表？与客户进一步确认：这三张表的确是误删除的，没有使用上述命令。 既然如此，为什么回收站没有这三表表的数据呢？稍一思忖，想起来了！Oracle还有个初始化参数（RECYCLEBIN），可控制是否使用FLASHBACK DROP。一检查，果然如此！原来DBA把RECYCLEBIN设置成OFF，从而关闭了FLASHBACK DROP功能。唉！遗憾啊，老罗同志失去了一次露脸的机会，Oracle更失去一次展现技术特点的机会！ 本来可以通过“flashback table <table_name> to before drop”一条简单命令，在数秒钟之内就能恢复被误删除表，结果害得客户从生产系统去重新抓取数据，同时恢复被删除的索引、Constraint等数据，整整折腾了一个多小时。客户庆幸的是：幸亏生产系统还有数据，否则叫天不应，喊地不灵。   待一切恢复正常了，我还是询问DBA了：“为什么要关闭FLASHBACK DROP功能呢？”回答是：“你们Oracle Flashback太消耗资源了，影响性能，我们不敢打开。” 哦，原来如此。这也是本文的主题：从技术上言，Flashback不是单一技术，而是一个技术家簇。以下就是各种Flashback技术的综合对比： Flashback技术 主要目的 级别 配置方式 技术原理…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏     现场直播救火过程 2014年8月初的某一天，突然接到东区服务销售经理电话：“老罗，你明天到上海出差，能否先到XX航空公司去一趟，他们一个重要系统宕机了。”据了解，该客户没有采购Oracle现场ACS服务，按Oracle公司先有鸡后有蛋的政策，我们是不能去现场做任何实质性的服务工作的。但从国情出发，更考虑客户感受和客户关系，作为ACS服务售前顾问去现场协助分析和解决问题，并进一步了解客户现状和需求，也是合情合理的，并不是趁火打劫哦，呵呵。于是，我决定调整行程，改签第二天头个航班，中午就飞到了上海。 在虹桥机场上了出租车之后，一个劲儿给师傅说抱歉的话，因为师傅可能等了几个小时，碰上我这个倒霉鬼，去机场附近的客户现场只需要起步价。师傅还是非常敬业，顶着中午火热的太阳，10分钟就把我拉到了该航空公司的信息中心大楼。 待我到达现场时，客户运维部门领导早已是翘首以待，把我热情引到会议室，更是把整个运维部门和开发单位的几十号人都召集到会议室，而且还有负责应用开发的印度专家。于是，在客户简短地介绍了系统概况和故障情况之后，就让我直接连入该系统，并把我电脑连接到大屏幕上，几十双眼睛开始齐刷刷地现场观摩Oracle顾问如何救火了，老罗同志又要开始一次臭显摆了，呵呵。   现场号脉 说实在的，尽管已经身经百战，但IT系统如此复杂，应用更是如此变化多端，IT新技术也是层出不穷，没有一个专家敢牛烘烘地说手到病除的。但是，分析诊断问题的思路和方式还是相通的，那就是先了解系统概况，然后再了解故障情况，特别是收集故障相关数据，再询问故障前是否有应用或环境的重大变更，再逐步分析和定位问题，并给出最终解决问题方式。以下就是与该系统和故障相关的上述几方面具体情况： 平台及架构情况 运行在2节点的SUN Solaris平台；数据库版本为11.2.0.4 RAC；数据库容量达到1.6TB。 故障现象分析 2014-08-01 14：14左右， 实例1重启；2014-08-01 14:28 实例2重启；2014-08-01 15:15:44 节点一被驱逐。故障发生之前，节点1的内存消耗非常高，达到了100%，并产生了大量SWAP操作。节点2的内存消耗也达到了90%。但客户没有安装OSWatcher，也就是没有采集到故障前后的操作系统数据。同时，RAC、GI的alert.log、crsd.log等日志文件也没有记录下明显的错误数据。 故障前变更情况 经客户介绍，该系统在8月1日之前应用软件安装了新补丁，即新部署了一些应用软件。通过对宕机之前的13：00 – 14：00 AWR报告分析，这些新应用软件中的3条SQL语句非常消耗资源。RAC重启之后，新部署的应用软件进行了回退，目前RAC系统运行平稳。 可见，新应用软件问题可能是导致RAC宕机的重要因素！ 应用深入分析 由于新应用很可能是导致RAC宕机的重要原因，而且负责该应用模块开发的印度专家也在现场，于是我们首先对其中一条SQL语句共同进行了深入分析。限于篇幅，我们只摘取如下的主要部分： 首先，该语句非常消耗资源，Buffer Gets和Disk Reads都非常之高，运行时间更是长达555秒。通过对该语句执行计划的分析，我们发现该语句对三个大表进行全表扫描。而导致全表扫描的直接原因是语句中如下部分的UPPER函数的使用： AND ((CUSDOCINF.DOCTYP = :2 AND UPPER(CUSDOCINF.DOCNUM) = UPPER(:3)) OR (CUSDOCINF.DOCTYP = :4 AND UPPER(CUSDOCINF.DOCNUM) = UPPER(:5))) 事实上，当我们去掉UPPER函数，或者将OR操作修改为in操作之后，Oracle执行计划非常合理，语句效率非常之高。 可是，待我仔细观察，发现开发人员其实已经设计了UPPER函数索引，而且也采集了统计信息，但为什么Oracle不走函数索引呢？正纳闷之际，印度工程师主动告诉我Oracle…