Author: mac

作者为:  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…

本文永久链接地址：https://www.askmac.cn/archives/oracle-11g-install-grid.html   Grid 安装 14.1 目标   在这个课程之后，你应该能够： 完成grid 预安装任务 安装grid 验证安装 配置ASM磁盘组   14.2  grid预安装任务   1.共享存储 这里有3种方式来存储grid文件： -一个支持的集群文件系统（CFS） -一个验证的网络文件系统（NFS） -自动存储管理（ASM）   存储选项 Voting/OCR oracle 软件 ASM yes no ASM集群文件系统（ACFS） no yes oracle 集群文件（OCFS2） yes yes NFS(仅仅验证) yes yes 共享磁盘片（块或裸设备） no no   使用DBCA或者OUI不能最新安装到块或者裸设备上 当更新一个现存的RAC数据库，你可以使用现有的裸设备和块设备分区和执行安装的滚动升级。

本文地址：https://www.askmac.cn/archives/mysql-maintenance-type.html   第10章 表的维护   章节概述 本章介绍如何在MySQL中进行表的维护管理。你会了解： 分辨表维护操作类型 执行表维护SQL语句 使用客户端及工具程序来进行表维护 修理InnoDB表 启用对MyISAM表的自动修复   10.1 表维护操作类型 一些表维护操作对于判定并修正数据库中的问题（例如，当一张表由于服务器奔溃而导致损坏后）或帮助MySQL优化表查询时非常有用。MySQL（根据存储引擎）可允许你执行几种类型的维护操作: 存储引擎名 MyISAM InnoDB CHECK TABLE 完整检查更新索引统计信息 完成检查 REPAIR TABLE 修理讹误表 N/A ANALYZE TABLE 更新索引统计信息 更新索引统计信息 OPTIMIZE TABLE 回收被浪费的空间表碎片整理索引页排序 更新索引统计信息 表重建（MySQL 5.7.4以后部分使用了online DDL的机制避免了表拷贝）

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址：https://www.askmac.cn/?p=16572 IT系统不仅需要存储和处理大量的传统结构化数据，而且对各类半结构化，例如XML文档、Word文档等，以及非结构化的图片、图像、视频等信息的处理需求也日益增长。Oracle自8i开始就推出了大对象（LOB）技术，用于存储半结构化和非结构化的数据。 本章将首先介绍传统LOB技术的运用，并总结传统LOB技术的不足，然后将介绍Oracle 11g新一代的大对象处理技术：SecureFiles，以及将传统LOB向SecureFiles进行迁移的相关技术，最后介绍相关案例和进一步的参考资料。 传统LOB技术的运用 LOB字段分为存储二进制的BLOB字段、存储字符类型的CLOB、存储国家字符集的NCLOB，以及存储外部文件的BFILE等类型。LOB字段的设计和使用并不复杂，例如，以下就是创建一个包含LOB字段表的语句：     CREATE TABLE print_media ( product_id NUMBER(6) , ad_id NUMBER(6) , ad_composite BLOB , ad_sourcetext CLOB , ad_finaltext CLOB , ad_fltextn NCLOB , ad_textdocs_ntab textdoc_tab , ad_photo BLOB , ad_graphic BFILE); LOB表物理设计基本原则 LOB字段在物理设计和应用开发中，都具有独特的技术特征。以下是Oracle顾问根据国内外不同项目实施LOB字段的经验，提出的LOB表物理设计基本原则。这些原则的贯彻，将有效提高LOB字段的可管理型和性能：   LOB表空间设计 为方便管理和处理的高性能，建议所有LOB字段单独建立表空间，并为每个LOB数据段单独命名。LOB表空间和数据段命名规则如下： 类型 命名 LOB表空间 TS_<基表名>_<LOB字段名> LOB数据段 SEG_<基表名>_<LOB字段名> 如果在LOB字段建立索引，Oracle将LOB索引与LOB数据共同存储在LOB表空间。因此不需要建立LOB索引表空间。…

动态统计信息（Dynamic Statistics）是一个新的概念。在11g的数据库，我们知道的动态采样（dynamic sampling）是在优化sql语句之前收集最基本的对象的统计信息。 12c优化器会判断当前有效的统计信息是否足够，否则使用动态统计信息。动态统计信息是一个持久的统计信息，会存储在统计仓储中，因此可能会被其他的查询语句使用。在12c中， 优化器会判断是否动态统计信息是有用的，是否动态采样是正确的方法，并能自动决定动态采样的级别。   动态统计信息 ： During the compilation of a SQL statement, the optimizer decides whether to use dynamic statistics by considering whether the available statistics are sufficient to generate a good execution plan. If the available statistics are not enough, then dynamic statistics are used. Dynamic statistics are persistent and may…

SCOPE This Document concerns itself with highly desirable patches and related fixes in 12.1.0.2 that are not included in PSU updates, either because they contain optimizer layer fixes or because the PSU that will contain them has not yet been released.   TIP: If a patch is not available for your specific version and OS,…