Month: February 2016

本文永久链接地址：https://www.askmac.cn/archives/oracle-11g-ocm-spa.html 5 SQL性能分析   5.1 目标 在完成这个课程后，你应该能够完成下列事情： 确定使用SQL 性能分析器的好处 描述SQL性能分析器工作流程 使用SQL 性能分区器在数据库变更后确定性能   5.2 性能变化时DBA面临的挑战   通过改变硬件或软件的配置来维护服务级别协议（SLA） 提供生产级别的工作负载环境来达到测试的目的 有效的预测和分析SQL性能的影响 大的关键业务应用是复杂的，并且具有高度变化的负载和使用模式。在同一时刻，这些业务系统被希望提供确定的服务，保障响应时间，吞吐量，正常运行时间和可用性。任何系统的改变（例如数据库升级或者修改了配置），在这些更改之前，经常需要进行广泛的测试和验证，以使其成为生产系统。为了有信心移动到生产，数据库管理员（DBA）必须以生产环境中的经验，公开测试系统工作负荷的工作量。它也拥有利于DBA以一个更有效的方式来分析SQL性能对整体系统水平变化的影响，这样在生产之前可以进行任何所需的调整更改。  

本文固定链接：https://www.askmac.cn/archives/getting-started-with-the-hadoop-framework.html Hadoop框架入门   前几章讨论了大数据的动机，接着深入介绍市场上最重要的大数据框架-Hadoop。本章你将实际使用Hadoop，指导你完成设置Hadoop开发环境的过程，并提供一些操作系统上安装Hadoop的操作指南。然后写一个Hadoop程序，并引导你了解Hadoop架构下更深层次的概念。   安装类型 虽然安装Hadoop往往是有经验的系统管理员的任务，并且Hadoop的安装细节可在Apache 网站找到，但对于在各种平台上安装Hadoop有2点需要知道： 要启用Hadoop程序的单元测试，Hadoop需要以独立模式安装。该过程对Linux系统来说相对简单，但对于Windows系统来说更复杂。 为了能够在一个真实集群中启用Hadoop程序模拟，Hadoop提供了一个伪分布式集群的操作模式（www.askmac.cn）。   本章涵盖了使用Hadoop的多种模式。Hadoop开发环境是虚拟机的背景下讨论的。我们以独立模式在Windows和Linux上展示Hadoop安装（还讨论了Linux的伪集群安装）。 Hadoop是一个不断发展的软件，它的安装过程非常复杂。 附录A介绍了Windows和Linux平台的安装步骤。这些步骤须视为一套通用的安装指南。具体情况可能会有所不同。如本章中所述，Hadoop 2.x平台的开发，建议使用VM方法来安装开发环境。

 本文永久链接地址：https://www.askmac.cn/archives/oracle-11g-ocm-rac-install.html   16 RAC数据库安装   16.1 目标   在完成这个课程后，你应该可以： 安装数据库软件 创建一个集群数据库 执行创建数据库后的任务  

本文永久链接地址：https://www.askmac.cn/archives/oracle-11g-ocm-manage-clusterware.html     15 管理Oracle 集群   15.1 目标 在完成这个课程后，你应该可以： 熟练的描述集群管理 演示OCR备份和恢复技术   15.2 管理Oracle 集群 命令行工具 –crsctl管理集群相关的操作： -启动和关闭Oracle集群 -启用和禁用Oracle集群后台进程 -注册集群资源 -srvctl 管理Oracle 资源相关操作 -启动和关闭数据库实例和服务 在Oracle Grid安装的home路径下的命令行工具crsctl和srvctl用来管理Oracle集群。使用crsctl可以监控和管理任何集群节点的集群组件和资源。srvctl工具提供了类似的功能，来监控和管理Oracle相关的资源，例如数据库实例和数据库服务。crsctl命令只能是集群管理者来运行，srvctl命令可以是其他用户，例如数据库管理员来使用。

  作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文地址：https://www.askmac.cn/?p=16600   为满足重大故障的紧急救援需求，SSC提供了如下的专业化、制度化的救援流程：     即一旦客户IT系统出现1级或升级2级严重问题，客户DBA可第一时间拨打Oracle公司专门为SSC客户提供的7*24小时的值班电话，当SSC值班工程师接到救援电话之后，会马上听取客户的情况介绍，并判断问题的严重程度和影响范围。根据客户需求和问题情况，SSC可确定是否可以通过电话或VPN登录方式，进行远程解决 。同时，客户也可拨通服务实施经理（SDM）电话。SDM可与SSC工程师沟通故障情况，并根据客户需求确定是否需要安排工程师去现场。如果的确问题非常严重、难以远程解决， SDM会果断决定派出客户当地城市或最近城市的工程师，同时深圳的SSC团队也会考虑派出工程师赶赴现场。当工程师到达客户现场后，会立即与客户运维团队、应用开发商、 硬件等其它厂商进行会商，并根据问题症状分析出问题原因所在，最终提供问题解决方案并加以实施。在故障彻底解决并验证之后，将提交故障处理分析报告。 以下就是Oracle最近在某移动公司出现重大故障时的响应速度：     时间点 操作内容 … … … … 10月30日 21:58 在节点2出现ORA-600 [qertbFetchByRowID]告警，紧接着节点1也出现ORA-600 [kclchkblk_3]告警 10月30日 22:00 业务方面反映20多张表不能插入 10月30日 23:04 重启数据库后，数据库还是出现ORA-600 [kdsgrp1]告警 10月31日 2:10 SSC值班接到保障电话，开始对问题进行分析 10月31日 3:00 SSC工程师远程登陆数据库，对有问题的表的索引进行分析及重建，发现相关索引在重启后恢复正常。 10月31日 6:00 发现大部分表恢复正常访问，业务基本恢复，但后台持续有报错。 10月31日 6:06 容灾库尝试启动但报错ora-01172无法启动 10月31日 6：45 华东区工程师从杭州出发赶往现场支持 10月31日 7：00 SSC工程师从深圳出发赶往现场支持， 10月31日20:00…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址为：https://www.askmac.cn/?p=16596   某天与一位新来的销售同事一同去拜访客户，当我们在调研客户数据库系统版本和补丁情况时，销售同事迷惑了。于是，我不得不私下向他简要介绍Oracle数据库版本和补丁的命名规则。他一边听我介绍，一边发出感慨：Oracle版本和补丁也太复杂了！ 是啊，像我的销售同事一样，国内很多客户也不了解Oracle复杂的版本和补丁概念，更没有积极主动地进行补丁评估和实施。这也是导致国内很多Oracle数据库系统运行状况不佳的重要原因。 本章就将从Oracle版本和补丁的基本概念讲起，并重点讲述Oracle公司建议的积极、主动地实施补丁计划的策略和方法论，以及相关的最佳实践经验。   16.1 关于Bug和补丁的一个典型故事 2011年在走访某省网通公司时，对其网管部门的一个重要生产系统进行了一番调研。以下就是该系统在上午业务高峰时期最消耗时间的部分语句列表： Elapsed Time (s) CPU Time (s) Executions Elap per Exec (s) % Total DB Time SQL Id SQL Module SQL Text 4,517 597 22 205.33 5.72 57h0pvsntqc2p   SELECT related_mscserver, subc… 4,505 557 24 187.70 5.71 8fk8d1qshkkd9   SELECT related_mscserver, subc……

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址：https://www.askmac.cn/?p=16586   针对主机故障、网络故障、系统软件故障、存储介质故障、人为操作失误等各类故障，Oracle公司都提供了相应的技术方案。例如RAC、RMAN、Data Guard等，其中防范人为操作失误的最好技术就是10g之后的FLASHBACK技术。 可惜，在本人与国内众多行业的广大客户接触中，发现大部分客户DBA和开发人员都缺乏对FLASHBACK技术的深入、系统的研究和应用。问其原因，得到的回答往往是：“FLASHBACK技术很消耗资源，不敢打开”。其实，客户说的是Flashback Database技术，该技术需要打开Flashback Log，的确消耗一定资源。而实际上，FLASHBACK技术不是一个单一技术，而是一个技术簇：Flashback Database、Flashback Drop、Flashback Table、Flashback Query等，而上述很多技术是缺省就打开，我们可以直接使用的，并不额外消耗资源。 本章就将先从案例开始，然后系统介绍FLASHBACK技术家族，以及在测试、安全审计、容灾，以及与其它数据保护技术结合等方面的应用。 人为错误的防范 当年天塌下来一样的重大事故 本人在《品悟》一书的第一章，曾经描述过某大型银行一个重大事故：在2007年初该行一位工作人员在分析和测试一个性能问题时，错误地将生产环境当成测试环境，一个Delete操作将生产系统中一张核心业务表的大部分数据删除掉，导致业务被迫中断。后来通过传统的Imp工具，从前一天的逻辑备份数据中进行了恢复，同时通过业务人员几乎通宵达旦的的数据补录，才将当天数据全部恢复，确保了第二天业务的正常运行。当年该事故引起了该银行高层的高度重视，Oracle公司各服务部门也投入了大量技术力量。 如今回想起来，该银行不仅需要在操作流程规范和访问环境方面进行深入总结，而且在技术方面更是感慨良多。当年该系统还是9i版本，只能采取上述传统的逻辑恢复和数据补录方式，不仅导致恢复时间长，而且还不能保证数据完全被恢复。如果是10g以上版本，上述故障则可以通过如下类似命令进行恢复了： /*+ 回退到5分钟之前 */ flashback table <表名> to timestamp(sysdate-1/288); 上述语句不仅简单，而且非常快速，并且能保证数据得到完整恢复。 这就是技术进步！这就是本章要讲解的主题：Flashback。 人为错误是最大单一因素 根据国内外IT行业的统计，在导致系统不可用的因素中，人为错误其实是最大的单一因素，占到40%以上，如下图所示。人为错误概率其实远远高于服务器硬件故障、网络故障、系统软件故障、存储介质故障等。 常见的人工操作失误包括： 错误地删除（Drop）了某张业务表 错误地清除（Truncate）了某张业务表的全部记录 错误地修改（Update）、插入（Insert）、删除（Delete）了某张业务表的记录 错误地运行了批处理程序，例如重复运行了批处理程序，导致业务数据紊乱 … … 如何快速、稳妥地对人工操作失误导致的数据损失进行恢复，是涉及数据库系统数据安全性设计、日常运行维护等方面工作的重要挑战。 传统技术手段 为对人工操作失误导致的数据损失进行恢复，Oracle的传统技术示意图如下：   exp/imp或Data Pump技术 通过Oracle传统的数据卸载（Exp）或10g Data Pump（Expd）技术，定期进行数据逻辑备份。在发生数据误错误时，通过数据装载（Imp）或10g Data Pump（Expd）技术，在表（table）、模式（schema）、数据库（database）等不同级别进行数据恢复。 RMAN不完全恢复技术 如果发生大规模数据误操作，通过RMAN不完全恢复可将数据库恢复到指定的过去某个时间点、SCN号或日志序列号，达到在数据库级进行数据恢复的目的。 表空间按时间点恢复技术（Tablespace Point-in-Time…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏     本文永久地址：https://www.askmac.cn/?p=16585     如同我们每年都要进行健康检查，防患于未然一样，数据库系统也一直处于动态变化之中，也应该定期进行健康检查。 数据库健康检查应该包括哪些内容？其宗旨和策略是什么？客户、Oracle自身技术人员对数据库健康检查如何看待？Oracle有哪些健康检查新工具？这些就是本章将要展开的话题。 什么是数据库健康检查？ 数据库健康检查 = 常规体检 生活在现代社会尤其生活在大都市快节奏下的人们，越来越关爱自己的身体，不太令人放心的食品安全，更有严重恶化的环境等因素，都对我们的身体带来负面影响。于是，每年的例行常规体检成了很多人生活中的一个重要内容。尽管每年的体检报告内容大同小异，但大家仍然还是不敢掉以轻心，尽可能地防患于未然。 数据库系统也运行在一个不断变化的世界里，硬件方面可能出现各种服务器、存储、网络故障，数据量、访问量也在不断变化，应用更是在不断地推陈出新，以满足业务不断发展的需求。数据库系统的生存环境、运行状况到底如何？是否有问题和隐患？这是广大客户，特别是DBA们非常关注和担忧的事情。 于是与常规体检类似，定期进行数据库健康检查（Database Health Check），成了保障IT系统平稳运行的一个重要任务，也成了Oracle服务的一项常规内容。 “数据库健康检查就是Ctrl+C、Ctrl+V”？ 数年前与一位当时在Oracle服务部门从事实施工作的女同事聊天。在谈到数据库健康检查时，她一脸的无奈：“数据库健康检查就是Ctrl+C、Ctrl+V，一天检查好几个系统，烦死了”。的确，Oracle服务部门已经将数据库健康检查服务做得非常规范化、程式化了，通过RDA、AWR等工具抓取相关系统大量信息之后，然后就是在检查报告模版里开始拷贝、粘贴的工作。 由于该工作成了例行工作，客户也由最初的新鲜感到产生一定的审美疲劳了，于是要求Oracle公司一天检查好几套，甚至上十套系统，工程师真成了整天都在Ctrl+C、Ctrl+V了，甚至难免会出现张冠李戴的情况。“我们银行业务系统的检查报告怎么出现了电信计费系统？”“你们工程师能不能更敬业点？”这是我亲耳听到的客户抱怨。 虽然的确有少数工程师不够职业，但也不能完全责备工程师。客户一天要求我们检查10几套库，我们只能拷贝、粘贴了，哪有时间和精力去做更深层次、更个性化的分析工作？更无暇与架构设计、应用开发等更多人员进行沟通，出点错也在所难免。关键是客户自己也将该工作视为例行公事了，一个季度检查一次，客户往往将报告束之高阁，只数报告数量，并不仔细阅读。检查报告本身也被工程师做成了党八股，数据库健康检查工作真成了弃之可惜、食之无味的鸡肋了，呵呵。   13.2 多年前一次健康检查 基于Oracle工具的数据库健康检查 针对数据库常规健康检查工作，Oracle公司早就提出了规范化的检查项目，甚至嵌入到了相关产品中。例如，当年在9i OEM里面就有一个菜单项“Health Check”，通过该工具可进行规范化的常规检查，包括数据库配置和运行状况检查，并能生成图文并茂的HTML报告，甚至支持中文。以下就是该报告的目录：   目录 例程 数据库和例程信息 数据库选项 SGA 信息 初始化参数 方案 方案对象概要 (非 SYS 和 SYSTEM) 无效对象 过程对象错误 索引尚未分析的已分析表 主关键字被禁用的表 SYSTEM 表空间中的用户对象 安全性 一般用户帐户信息 用户角色…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址：https://www.askmac.cn/?p=16580 一天在公司与几位负责紧急救援电话支持服务的同事聊天，当我询问客户主要有哪些求救电话时，他们告诉我最多的求救电话是两类：一类是数据库宕机或挂起，特别是RAC 数据库出现宕机，另外一类则是数据库坏块问题。前者在我意料之中，而后者则有点出乎我的意料。但仔细一想，事实的确可能如此。大家千万别小看数据坏块的处理，从危害程度而言，几个小小数据坏块的确可能导致客户核心数据不可访问，甚至丢失。而从技术角度而言，数据坏块处理涉及的内部机制和处理方法是非常复杂的。为此，Oracle有若干专题文章是讲述数据坏块处理的。 本章我们先从若干案例介绍起，先让大家从不同层面感触一下数据库坏块处理的多样性和复杂性，然后将详细介绍坏块的处理流程，坏块的定位和相关解决方案，例如使用DBMS_REPAIR包或设置10231事件、ROWID扫描方法等。 可怕的数据库坏块 案例1：逻辑坏块导致的坏块 第一个案例来自于国税某系统，笔者在《品悟性能优化》的第十七章曾经“绘声绘色”地叙述过。本书再次摘要该案例主要内容如下： 故障现象和原因 首先，了解到共有18个数据坏块，三个表核心业务表分别有一个数据坏块，其他15个坏块为索引。 其次，了解硬件特别是存储并没有报错，说明很可能是逻辑坏块。 再其次，了解到前一天的RMAN备份顺利完成，意味着RMAN备份集已经包含了数据逻辑坏块。 处理方案和结果 针对上述具体情况，分别制定了不同的处理方案。 首先不能直接通过RMAN进行恢复，因为备份集很可能已经包含了逻辑坏块，如果恢复只能同样恢复成坏块。 针对索引，采取重建索引到新的数据文件的方案，并获得了成功。 针对三个核心业务表，先采取了设置event=”10231 trace name context forever, level 10”，或者通过SKIP_CORRUPTION_BLOCKS方法，试图将坏块之外的数据读出来，但都没有成功。 与应用开发人员进一步沟通，发现其中一张表为汇总统计表，于是采取了重新运行汇总程序的办法，重新生成了该表并移到一个新的物理位置。 为减少数据损失，对剩余2张表采取了ROWID Range Scan技术。其中一个表获得了成功，但1000多万的表丢失了4条记录。而另外一个表却没有成功。 针对最后一张表，只好采用了最后一个不得已的招术：Oracle的内部技术DUL。最终也基本获得了成功，400多万的表丢失了10多条记录。 案例2：CPU损坏导致的坏块 故障现象和原因 该案例来自于某省移动BOSS系统。具体故障现象表现为：数据库实例宕机，数据库也异常关闭。在客户请求Oracle紧急现场救援服务，Oracle工程师赶到现场之后，经过分析alert.log日志发现：Online Redo Log出现坏块，Oracle在发现Redo Log校验失败之后，为保护数据，Oracle主动关闭数据库实例和数据库。 在硬件公司的积极配合下，后来发现导致该故障的最终原因是数据库服务器的CPU损坏，导致Oracle的Online Redo Log被写坏。 处理方案和结果 Oracle工程师在现场评估了问题原因和影响范围之后，最终确定通过RMAN进行数据库的不完全恢复，即只恢复到出现坏块的Online Redo Log的前一个。该数据库已经达到TB级，为此花费了20多个小时才完成了该核心系统的不完全恢复。由于恢复期间，数据库处于Mount状态，意味着业务不得不停顿了20多个小时。更严重的是，由于是不完全恢复，导致丢失了一个多小时的业务数据。 事后，本人在与承担具体抢救任务的同事聊天时，他坦言：其实他当时是恢复到出现坏块的Online Redo Log的前两个，而不是前一个。原因是他担心前一个也有坏块，而Oracle可能没有及时检查出来。如果出现这种不幸，那Oracle数据库还是无法打开，可能要再次进行恢复。他说宁可客户数据多丢一点，也要保证数据库尽快顺利地打开，及时恢复正常业务。他当时还很神秘地告诉我：千万别告诉客户哦，客户还以为只丢了一个日志文件的数据呢。抱歉，哥儿们，今天在这儿泄露你的秘密了。呵呵。 案例3：Oracle Bug导致的坏块 故障现象 2011年3月21日5：10分左右，某银行系统出现异常，具体情况如下： 数据库在预分配空间时出现异常，报空间分配失败 账务流水表出现数据块逻辑读写错误，不可读写，进而中断交易。 smon后台进程不断尝试恢复损坏的数据块，恢复后将实例2自动关闭。…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址：https://www.askmac.cn/archives/luomin-fix-oracle-error.html   虽然Oracle数据库的故障千奇百怪，甚至让客户有种防不胜防的感觉，但还是有很多故障是比较常见的，这些问题也是我们Oracle服务部门在客户现场经常遇见，也经常处理的问题。 事实上，针对这些常见问题，Oracle公司不仅提供了诊断和解决问题的思路和方式，甚至针对具体问题，提供了专门的官方处理文档。如果我们能在平日的运行维护工作中，提前预读这些文档，甚至自己编写相应的故障处理手册，一旦这些常见故障真正发生时，我们就不会那么手足无措，即便不一定完全胸有成竹，也至少可以做到一定的心中有数了，就像打仗一定要有作战预案、一定要打有准备之战一样。 本章就将介绍这些常见故障的诊断和处理过程。例如ORA-00600、内存不够、数据库空间不够、snapshot too old、UNDO表空间无法扩展等。   ORA-00600：内部错误 什么是ORA-00600错误? ORA-00600是常见的一类错误，以下是Oracle 11g中关于该错误的官方描述：     ORA-00600: internal error code, arguments: [string], [string], [string], [string], [string], [string], [string], [string], [string], [string], [string], [string] Cause: This is the generic internal error number for Oracle program exceptions. It indicates that a process has encountered…