Maclean’s Oracle Database Tech Blog Archives

本文固定链接：https://www.askmac.cn/archives/hadoop-permissions-guide.html 本文是官方文档的翻译，原文地址是： http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html     1.概述   HDFS为文件和目录实现了一个权限模块，一大部分共享是POSIX模式。每个文件和目录关联到一个用户和一个组。文件和目录以用户所有者来权限划分，其他的用户可以是一个组的成员，也可以是所有其他的用户。对于文件来说，r 权限是读文件的权限，w 权限是写或者追加到文件的权限。对于目录来说，r权限是列出目录内容的权限，w权限是删除和创建文件或目录的权限，x权限是访问子目录的权限。 于POSIX模式对比，文件没有setuid或setgid位，因为没有可执行文件的概念。同样地，对于目录也没有setuid和setgid位。粘贴位可以被设置在目录上，可以防止除了超级用户之外，目录所有者或文件所有者在这个目录中删除或移动文件。在文件上设置粘贴位没有作用。总的来说，一个文件或目录的权限是它们的模式。一般来说，Unix用户的表现模式将被使用，包括这个表述上的8进制方法。当文件或目录被创建，它们的所有者是客户端进程的标识，它们的组时父目录的组（BSD规则）。 HDFS也提供了POSIX ACLs（访问控制列表）支持，来增加对特定命名用户或命名组的更细粒度规则的文件权限。ACLs在后面有更详细的讨论（www.askmac.cn）。 每个客户端进程访问HDFS拥有2部分标识：用户名和组列表。当文件和目录被一个客户端进程访问时，HDFS必须进行权限检查。 如果用户名匹配所有者，那么所有者权限是通过的。 如果组权限匹配组列表中任何一个成员，那么组权限是通过的。 否则，其他权限是通过的。 如果权限检查失败，客户端操作就失败。

本文地址：https://www.askmac.cn/archives/mysql-partition-type.html   9.2 分区类型 RANGE分区：基于列值所处在的给定范围来对行进行分区。 LIST分区：和RANGE分区类似，不过区别是基于一组离散值集合中的值匹配来进行分区。 HASH分区：分区的选择基于要插入行的列值进行用户定义功能函数计算后的返回值。其功能函数可以包括任意MySQL有效表达式并返回一个非负的整数值。 KEY分区：和Hash分区类似，不过区别是使用MySQL自有的哈希功能来对一列或多列进行哈希计算，其中的列值也可以包含除整数值之外的值，而MySQL并不关心列值的具体数据类型，在哈希计算后，都会返回一个整数值。   通常使用数据库分区时会按日期时间来都对数据进行分割。一些数据库系统支持显式时间日期分区语法，不过MySQL不支持。不过在MySQL中，想要基于DATE，TIME，或DATETIME列来建立分区，或基于使用这些列进行计算的表达式来进行分区都并不困难。   当通过KEY或LINEAR KEY建立分区时，你可以在不对DATE，TIME或DATETIME列进行任何值修改的情况下，直接使用它们来进行分区。例如，以下表分区语句在MySQL中是可行的： CREATE TABLE members ( firstname VARCHAR(25) NOT NULL, lastname VARCHAR(25) NOT NULL, username VARCHAR(16) NOT NULL, email VARCHAR(35), joined DATE NOT NULL ) PARTITION BY KEY(joined) PARTITIONS 6;

即至农历春节前，Oracle终于完成其在中国最后一站 — 上海站的SPARC M7新产品宣讲。 作为一个坚定的Oracle粉，身居上海的我们自然也受到了会议邀请~。不过，和广大技术同胞不同的是，我们是以媒体人的身份来参加的，因此分支会议上会有些小小的不同:） 主题为《安“芯”防卫，智胜云端》的Oracle大会一如既往的座无虚席，虽然是产品介绍会，但是除了媒体之外，还是有非常多的IT技术人员到场听讲的。 也许是由于开场的时间稍有延后的关系，在Oracle中国区事业部的詹飞浪总经理做了简短的开幕致辞后，潘榆奇总监便开始了对Oracle SPARC M7的主题演讲。 此次Oracle力推的SPARC M7产品确实是一款Oracle的实力之作，诚如潘榆奇先生所言，Oracle的发展思路明确，”速度” -> “安全” -> “云”。 从软件到硬件的整合能力，到对一体机的长期投入研发，Oracle在其技术领域中一直处于标杆地位。现在Oracle更需要乘着云的东风，希望在硬件领域有更多突破。

本文地址：https://www.askmac.cn/archives/mysql-partition.html   第9章 分区(Partition)   章节概述 本章介绍在MySQL中分区的管理。你会了解： 理解分区概念 使用SHOW VARIABLES来确定服务端的分区支持 如何建立一张分区表 描述分区类型   9.1 分区概述 SQL标准中并不提供很多关于数据物理存储方面的指导。而SQL语句本身趋向于独立于数据结构或这些模式（schema/database），表，行或列下对应的介质进行运行。但是，大多数高级的数据库管理系统都会有一些方法来判断具体被用于存储的文件系统或硬件下的数据片的物理位置。在MySQL中，InnoDB存储引擎还支持表空间概念。在MySQL服务端，介绍分区之前，你可以配置不同的空物理目录来存储不同的数据库。 Tips：分区是从MySQL 5.1.14-Beta版本开始被引入的功能。   分区在此基础上更近一步，允许你在将单个表的各个部分分布在整个文件系统中（只要所设分区文件的大小遵守系统的规则）。实时上，一张表的不同部分可以如各个分割的表存储在不同位置。数据通过用户选择的规则进行的分割（我们称为分区功能），如按量值进行分区，或简单匹配一个值列范围进行分区，或使用内部哈希函数或一个线性函数进行分区等。如何分区由用户按分区类别来确定，其所用的功能匹配可以接受用户提供的表达式值作为参数，表达式可以是一个整型列值，或在对一个或多个列进行处理后来得出的一个整数来作为返回。表达式的值被传给分区功能函数，此函数会返回一个整数值代表了对应数据行应该被存放在哪个分区的分区号。此功能函数必须是非静态值和非随机值。它不能包含任何查询，但可以“虚拟的“使用在MySQL中有效的任意表达式（只要表达式返回的正整数小于最大可能的正整数值MAXVALUE即可）。   我们在这里所介绍的分区在概念上指水平分区（horizontal partitioning）– 即，表中的不同行可以在不同的物理分区中。MySQL不支持垂直分区（vertical partitioning），即表中的不同列被分派到不同的物理分区中。到现在为止，MySQL还未有任何计划来引入垂直分区功能。   9.1.1 查看分区功能启用状态 在MySQL 5.6版本之前，你可以通过使用以下语句来查看MySQL的分区功能是否已经启用： mysql> SHOW VARIABLES LIKE ‘%partition%’; +——————-+——-+ | Variable_name | Value | +——————-+——-+ | have_partitioning | YES | +——————-+——-+ 1 row in set (0.00 sec) 不过从MySQL…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 尝鲜Oracle 12c 就在本书写作期间的2013年秋天，Oracle公司终于正式推出了令广大IT人士翘首以盼的12c数据库，c就是云（Cloud），意味着Oracle将12c定位为数据库云平台整体解决方案。 12c到底有哪些新特性和新技术？特别是在云计算方面有什么特色技术？在12c尚未正式推出的2013年春天，本人参加了一次公司内部的12c技术培训，发现12c林林总总的新特性真不少，但培训教材的前几章则在全面介绍两大技术领域：CDB/PDB架构和信息生命周期管理，可见这两大技术领域在数据库云平台和云计算方面的重要性。于是，本章也只涉足这两大技术领域，以及相关的实施案例。   新特性培训课的趣事 本人从2001年加入Oracle公司算起到2013年的12年间，Oracle数据库版本从9i一直发展到了12c，个人知识和能力也是伴随着Oracle技术的不断发展而共同进步。以下就是Oracle公司描述的最新几个版本的技术创新示意图：   在这12年间，本人也有幸参加了各个版本的新特性培训。记得在2001年参加9i新特性培训时，还是在国贸二座的Oracle大学一间大教室，公司内外听课者有数十人之众。而在2004年参加10g新特性培训时，人数就只有10余人了。再到2007年在上海Oracle大学参加11g新特性培训时,则只有区区3个人，其中包括本人在内的2位是Oracle内部员工，真正的客户就1位。而在2013年参加12c新特性培训时，也只有可怜的4个人，而且可能是因为12c尚未正式发布的缘故，4个人全部都是Oracle公司内部员工。 记得2007年在参加11g培训时，当老师按照教材一上来就介绍有关ASM新特性时，那位唯一的客户一听就傻眼了：“老师，什么叫ASM啊？”。原来他们的系统还运行在9i平台，尚未接触过10g，更未听说过什么ASM，呵呵。感慨：以后听这种新特性的课程，一定不能跨版本。IT技术发展太快了。 在本次连续5天的12c培训过程中，因工作等各种原因，包括本人在内的4位听课者或多或少缺席了一些课程。到培训的最后一天，其他同学因故都缺席了,老师就只对我一个人滔滔不绝了，但老师依然是非常职业地抑扬顿挫，搞得我都不好意思了：“老师，就我一个人了，您不用那么大声音了。”呵呵。但我一直坚持到最后做完课程的所有练习。 IT技术的确发展太快，搞得客户都有点跟不上这种高速发展的步伐了。但作为原厂技术服务人员，紧跟IT技术发展潮流，并及时抢占技术制高点其实是我们的基本职业诉求。 虽然说总体感觉12c相比以前版本而言，并未发生很多革命性的根本变化。例如像10g一样，新增加ASM、clusterware等架构性技术。但5天的培训课程，感觉12c还是推出了大量新特性。限于篇幅，也根据自身理解，将只介绍几个12c最重要的新特性，包括在架构方面的新变化和新技术：Container DB和Pluggable DB，以及在信息生命周期方面的新技术。   12c架构方面最大变化 Oracle传统架构 Oracle数据库主版本从8i开始均带有一个字母：8i、9i、10g、11g、12c。根据Oracle公司官方解释：i代表Internet、Intellegence等，g则代表Grid Computing（网格计算），而c则是Cloud Computing（云计算）了。 Oracle宣称12c版本为云计算平台，并非赶时髦，而的确是在架构层面大动干戈了！传统的Oracle架构中实例和数据库关系只有1对1关系和N对1关系。下图就是实例和数据库1对1关系的单机架构：     同时，Oracle还支持多个实例共享一个数据库的N对1关系，即如下图所示的RAC集群架构：   在12c之前的传统Oracle架构中，是不支持一个实例管理多套数据库的1对N关系的架构，即如下图所示：   但是为适应云计算发展的需要，Oracle在12c中也支持这种架构了，也就是后面要详细描述的Container DB和Pluggable DB概念了。这就是本人觉得12c在架构方面最大的改变和新特性了。 Container DB和Pluggable DB基本概念 以下就是Container DB和Pluggable DB概念示意图：       首先，在这种架构下只有一个数据库实例，即所有数据库共享一组后台进程和一组内存，包括SGA、PGA等。 其次，该实例可以管理多个数据库，即多个Container数据库。上图表示一个名为root 的Container数据库，简称CDB。而且包括3个类型为Pluggable的Container数据库，简称PDB。其中一个为Seed PDB（种子PDB），另外两个为SALES PDB和HR PDB应用数据库，也就是说CBD和所有PDB是父子关系，并且CBD和PDB数据库在一个实例下运行和管理。 再者，在CDB层面像传统数据库结构一样，包括SYSTEM、SYSAUX、UNDO、TEMP等系统表空间和应用表空间，以及控制文件和日志文件等。但在PDB层面则只有专属PDB的SYSTEM、SYSAUX系统表空间和应用表空间，而没有UNDO表空间、控制文件和日志文件。也就是说CDB的UNDO表空间、控制文件和日志文件是整个CDB所共享的。 CBD的临时表空间和临时表空间组可以为各PDB所共享，但是每个PDB也可拥有自己独立的临时表空间和临时表空间组。 最后，CDB的归档模式决定了所有PDB的归档模式。即所有CDB和PDB同为归档或非归档模式。  …

本文固定链接：https://www.askmac.cn/archives/hadoop-concepts.html     Hadoop概念   应用程序经常需求，超过廉价（商品）机器上可用的更多资源。许多组织发现自己的业务流程不再适合在单一的、具有成本效益的计算机上进行。一个简单却昂贵的解决方案是购买耗费大量内存，并具有多个CPU的专门机器 。该解决方案可最快扩展至机器所支持的程度，但是唯一的限制因素通常是你的预算。另一种解决方案是建立一个高可用性集群，它通常试图看起来像一个单台机器，并且通常需要非常专业化的安装和管理服务。许多高可用性集群都是有版权并且昂贵的。   获取必要的计算资源的一种更经济的解决方案是云计算。一种常用模式是：那些需要被转换的批量数据，其中每个数据项的处理基本上独立于其他数据项;也就是说，通过使用单指令，多数据（SIMD ）方案。Hadoop提供一个云计算的开源框架，以及一个分布式文件系统。 本书的设计意图是作为使用Hadoop，一个由Apache软件基金会主办的项目，来开发和运行软件的实用指南。本章将为你介绍Hadoop的核心概念。目的是为下一章的内容做准备，下一章中你将了解Hadoop的安装和运行（www.askmac.cn）。   Hadoop介绍   Hadoop是以发表于2004年的有关MapReduce的Google文章为基础，其发展始于2005年。当时，Hadoop的开发是为了支持一个叫做Nutch的开源网络搜索引擎项目。最终，Hadoop从Nutch中分离出来，成为Apache基金会下自己的一个项目。 今天Hadoop是市场上最知名的MapReduce框架。目前，有几家围绕Hadoop的公司已经发展到提供Hadoop软件的支持、咨询和培训服务。 Hadoop的核心是一个基于Java的MapReduce框架。然而，由于Hadoop平台的迅速普及，支持非Java用户群体很有必要。Hadoop已经发展到拥有以下改进，和支持该群体的子项目，并将其范围扩大到企业。

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 数据库私有云技术 云计算是当下IT行业最为热门的技术领域之一。无论是IT行业各厂商，还是IT从业人员，如果不念念有词云计算，不知道什么叫IaaS、PassS、SaaS，似乎就Out了。不仅广大IT人士被各厂商的云计算概念弄得云山雾罩，而且也有很多调侃云计算的段子。例如，美国某记者在街头随机采访一老太太，询问“什么叫云计算？”。老太太一本正经：“就是在飞机上访问Internet吧？”，呵呵。 云计算到底是什么？作为IT公司大佬的Oracle是如何定义和诠释云计算，特别是数据库云计算的？Oracle数据库云计算中有哪些关键技术？数据库云计算有哪些成功案例？本章将就这些话题展开讨论。   20.1 云计算概述 云计算定义 云计算实际上是网格计算、分布式计算，以及并行计算、网络存储、虚拟化、负载均衡等传统计算机技术和网络技术发展融合的产物。虽然各IT软硬件供应商都在研究和发展自己的云计算产品和技术，对云计算的定义和解释也不尽相同。但美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）的如下定义，基本为IT行业所普遍接受： “云计算是一种新的计算模式。在该模式下，用户可便捷、按需地通过网络访问一组包括网络、服务器、存储、应用和服务在内的计算资源池，并且服务供应商可以极少的管理成本，对计算资源提供快速供应和释放能力。” 以下是云计算架构示意图：   云计算基本特征 根据上述定义，云计算具有如下基本特征： 按需的自助服务能力 资源共享池 快速灵活的伸缩性 可度量的服务 高速网络访问能力 云计算服务模式 云计算可以认为包括以下几个层次的服务： IaaS：基础设施即服务 IaaS(Infrastructure-as-a-Service)：基础设施即服务。消费者通过Internet可以从完善的计算机基础设施获得的服务。 PaaS：平台即服务 PaaS(Platform-as-a-Service)：平台即服务。PaaS实际上是指将软件研发的平台作为一种服务提交给用户。 SaaS：软件即服务 SaaS(Software-as-a-Service)：软件即服务。它是一种通过Internet提供软件的模式，用户无需购买软件，而是向提供商租用基于Web的软件，来管理企业经营活动。   云计算的实施模式 从实施角度而言，云计算具有如下4种模式： 公有云 公共云是在公共网络上搭建的计算平台，比如亚马逊等网站提供的云服务。 私有云 私有云就是企业内部搭建的计算资源平台。比如Oracle公司在企业内部就拥有并使用很多私有云平台，供广大研发和技术支持人员使用。 社区云 社区云是公有云和私有云的变种，实际上是若干个企业共享一个云计算平台，介于公有云和私有云之间，主要特征是使用权和所属权的分离。 混合云 混合云是将私有云和公有云结合起来的计算资源。比如很多银行和保险公司在月底做报表的时候需要大量的计算资源，如果按照这个峰值配置硬件设备又很浪费，80%的时间内有80%的机器是闲置的。因此，可以将企业内部的机器和亚马逊这类的云服务供应商相连接，需要的时候通过云计算服务租取机器。     云计算的益处 云计算的核心思想即为客户提供一组资源共享池。通过云计算理念构造的IT系统，将为客户带来如下图所示的四方面的效益：     降低IT系统成本 在云计算架构下，各IT系统不再拥有独立的计算资源，而是共享计算资源，因此，IT系统建设和运行维护成本都将显著下降。例如在建设方面，服务器、存储等硬件资源将大幅度减少，对应的软件许可证（License）和资源投入也将大幅度减少。…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 话说升级 长期以来，Oracle数据库系统升级是让IT系统决策者和管理者陷入两难境地的重要话题。一方面，IT系统高速发展所提供的大量新技术和新特性，对IT人员充满诱惑，也的确能解决现有IT系统中的大量问题。另一方面，面对各行业正在运行的、非常重要的生产系统，缺乏全面评估和验证的数据库系统升级操作，不仅可能会导致业务中断时间过长，更严重的是可能导致应用软件的不稳定性，甚至性能衰减。因此，犹豫和彷徨之中，IT系统决策者们一次次错失了升级的良好契机，所谓“一步赶不上，步步赶不上”。日积月累之下，不仅数据库技术老化，而且也妨碍了硬件、网络、中间件等其它层次新产品和新技术的运用，最终导致现有IT系统难堪重负。更有甚者，索性推翻原有IT系统，另起炉灶。这不仅导致大量重复建设，更使得现有系统的软硬件资源和数据资源难以继承，即导致整个IT系统的投入产出比(ROI)的下降。 关于Oracle数据库升级，业界到底有多少顾虑？为什么要升级？升级项目应该包括哪些实施内容？升级技术方案到底有哪些？如何防范升级之后应用软件性能不衰减？升级项目如何组织实施？如何防范风险？本章试图围绕这些话题一一道来，希望给大家在计划和组织升级项目实施时，起到抛砖引玉的作用。 关于数据库升级的疑虑 关于升级的矛盾和纠结 关于升级，IT行业不同层面和角色人员到底有哪些纠结、矛盾和疑虑？以下这张图大概能表白大家的很多共同心声：   上述“为什么要升级？”和“升级能带来什么益处？”，其实更多地是有关升级的必要性问题。而“升级如何保证停机时间”、“万一升级失败，怎么办？”、“新版本对应用是否兼容”、“升级后是否会导致性能下降”等类问题，则是有关升级的可行性问题了。最后，“如何使用新特性？”、“需要对系统运维工作进行哪些调整？”等问题，就不仅仅是将升级看成是一种被动而为的事情，特别是为了满足Oracle产品服务期限的需求，也不是一种新瓶装旧酒的保守思维方式，而是以更积极的心态，主动接受和拥抱新平台、新技术，将升级看成是一次升华的过程了。 本章和本书更多章节内容，都是在试图解答大家的这些共同的疑虑，从而帮助大家面对升级工作，树立起既积极乐观、又严谨缜密的思维模式和工作方法。   关于升级两种绝对观点 在多年与国内多个行业的众多客户探讨数据库升级时，我们经常听到如下两类截然相反的观点： “升级是很简单的事情” 此观点更具体的叙述是：“升级哪有你们Oracle公司说的那么复杂，不就是建个11g新库，然后把9i、10g数据倒一遍吗？你们Oracle就想忽悠我们买你们更多服务吧？” 以本人经验，持这类观点的用户也是有所根据的：通常他们的系统数据量可能不大，例如最多只有几十GB。更重要的是，这类系统高可用性可能并不高，停几个小时、甚至停个周末进行升级都无所谓，几十GB数据慢慢倒几天呗。还有，这类系统的应用软件也比较简单，基本采用最基础、最经典的SQL语句，也几乎不可能在新平台运行时出现应用不兼容、性能衰减的问题。 不过，尽管这类客户的数据库升级风险不是很大，但麻雀虽小、五脏具全，同样也应考虑作为一个升级项目的方方面面的工作，例如升级技术方案的确定、性能稳定性保障、11g新特性运用、数据库是否需要整合等工作内容。 “升级太复杂了，风险太大了” 持这类观点的人当然是银行、电信、政府、制造等关键行业的客户了。这些行业的数据库系统不仅数据量动辄达到TB、甚至几十TB以上，而且几乎全部是7*24小时的关键业务系统。为了升级这种多年难遇的事情，也最多向主管部门申请数个小时的停机时间窗口，如何保证在这么短的时间窗口内，完成这么浩大的升级工作？ 再则，这类关键系统的应用通常都非常复杂，不仅表、索引、分区、存储过程、函数等数据对象经常达到万个以上，而且国内应用开发高手们，经常写出数百行的单个SQL语句，这些SQL语句在新平台的兼容性，特别是性能稳定性如何保证？的确是困扰各层面人士的难题。 于是，就出现了上述犹豫和彷徨之中，一次次错失了升级的良好契机，所谓“一步赶不上，步步赶不上”的局面。 数年前，某电信公司将核心营业系统的Siebel应用软件进行升级，同时将数据库也升级到11g R2版本。尽管专门组织了由客户、集成商、Oracle原厂商等组成的团队，更进行了长时间的精心准备和测试，但依然在正式升级之后，出现了数据库宕机，并长时间停止对外服务的重大故障，甚至被媒体曝光。究其原因是多方面的，例如Oracle 11g进程内存消耗过大问题；测试期间模拟并发数不够，而投产之后更大并发数导致内存耗尽等问题。此次严重故障也让客户各层面人士，特别是高层承受了巨大压力，甚至导致客户得出了这样的结论：“以后我们再不为你们Oracle版本单独升级了，除非我们在你们新平台重新建设一套新系统。” 其实，深究其原因，还是在升级项目组织、工作内容、工作流程方面等方面出现了重大偏差，如果我们好好总结经验教训，还是完全可以借鉴并避免这些问题发生的。   关于升级的正确观点 关于升级的正确观点是什么呢？总体而言应该用“战略上藐视，战术上重视”来描述。首先以事实为依据，在笔者所在的Oracle高级服务团队（ACS）自从2007年开始在全国提供全面、系统的数据库升级服务以来，我们团队在国内各行业的数百个系统实施了升级到10g和11g的项目，尽管经历了大大小小的各种坎坷，但没有一个系统没有升级成功！因此，对于升级，我们完全可以持“战略上藐视”的态度。 但是，在我们经历的升级项目中，也的确出现过上述电信公司尽管没有回退,但充满坎坷的项目，更经历过第一周升级不成功而不得不回退，在及时总结经验教训之后，第二周成功升级的典型案例，这也恰恰说明升级工作的复杂性和风险性，也就是说“战术上重视”的重要性。 更具体而言，针对数据库升级工作，我们应持如下的观点和相应的工作方法： Oracle数据库系统升级是一项机遇和风险并存的系统工程。 对现有系统的全面了解和评估，升级需求的分析，合理的升级技术方案设计是升级项目的基础。 性能问题是升级过程中需要特别关注的问题。 科学的升级方法论指导和项目有计划的实施是升级的重要保障。 下面章节，我们就将围绕这些观点，以某银行现状和升级需求为背景，展开更进一步的讨论。   为什么要升级？ 为什么要升级？其实主要原因只有两个：首先就是Oracle产品支持周期问题，其次就是充分运用新版本的新技术和新特性，有效解决现有版本无法解决的一些问题。有关11g新特性话题，我们已经在本书前面若干章节进行了讲述。本节只叙述Oracle产品支持周期问题。 Oracle产品均有自己的生命周期，下图就是Oracle9i、10g、11g数据库产品和服务的生命周期政策：     其中: Permier Support（PS）表示Oracle标准支持服务期 Extended Support（ES）表示Oracle延长支持服务期，Extended Support需在标准服务费的基础上增加额外的延长支持服务费用，且要求客户的数据库需要升级到当前版本的最后一个补丁集，如9i R2的2.0.8，10g R2的10.2.0.5等。 Sustaining Support（SS）表示Oracle扩展支持服务期，相比Extended…

  开源的数据库平台mongoDB今天（美国时间2015-06-02）在纽约举行的其公司举行的MongoDB World发布会上，发表了一些升级内容。其中，就包含了Tableau等数据可视化工具的整合。 负责MongoDB发展方向的VP Kelly Stirman说：MongoDB与一直以来的RDB不同，有着可以处理非典型数据的自由性，所以如今很多企业的应用中都在利用。这也是大家使用MongoDB的重要原因之一，但至此，所使用的数据可视化工具处理非典型数据都非常困难。 他还说，大家都说这些应用很先进，是因为这些应用使用了以往的行(row)与列(column)的数据库无法处理的丰富的数据结构。 因此，为了处理这些愈发先进的MongoDB所带来的无法预测的结果，其公司就发表了可以连接BI(business intelligence)以及数据可视化工具的连接，同时介绍了公司的合作伙伴Tableau，并说明了，其他工具也能同样地这样连接。   Tableau虽然是本公司的合作伙伴，但连接是IBM的Cognos以及SAP的BusinessObjects、Microsoft Excel等等，也有与其他工具之间的互换性，所以几乎可以处理所有情况。   Stirman然后还说，几百万的用户每天都在使用这些应用，但至此都是MongoDB没有接触到的领域。因此，今天发布的新连接，就会成为两个世界的桥梁。   他还说：“至此，要用现有的数据可视化工具处理MongoDB以及数据，需要在编程上耗费大量心力，因此时间与资金的成本都很庞大。但是，只要使用连接的话，现有的可视化工具，就不需要其中的layer了，于是就可以访问MongoDB的数据了。“   同样地发布会还在Salesforce.com上举行过，但那次与这次的案例相反，是通过Salesforce的可视化工具wave将外部数据与Salesforce的数据同时进行可视化的连接 与MongoDB的情况相同，至此如果在编程上煞费苦心的话，就可以用wave观察外部数据。并且，Salesforce这次也与MongoDB相同，终于领悟了。要实现与外部顺利连接还是要靠Bender自身这一点。两个公司同时制成的连接，就可以使得数据库与可视化工具之间的数据迁移以及数据访问更加方便。 MongoDB3.2中，除了连接还有REST相应的密码化以及为了数据库管理员，会导入GUI。这方面的内容预计会在今年的第四季度公开。 MongoDB至此引起了风投们极大的注意，大约收集到了3亿美元左右的资金。就是最近一段时间，仅仅是今年一月就获得8000万美元。    

  作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 Oracle集群数据库RAC（Real Application Cluster）自Oracle公司在2001年 9i版本推出以来，经过10g、11g和最新的12c等多个版本的发展，产品已经得到不断发展和稳定，尤其在国内银行、电信、政府、制造等诸多行业得到了广泛、深入的应用。 但是，作为保障数据库系统高可用性的重要产品，却时常出现宕机、挂起等故障。究其原因，与RAC自身版本和补丁、主机和操作系统环境、网络环境，以及与应用等多方面都有关系。 如何遵循Oracle公司RAC实施方法论和最佳实践经验，合理组织RAC的实施，确保RAC运行的稳定性，同时充分发挥RAC在性能、扩展性等方面的作用，是本章的宗旨。 本章将结合一些具体案例来叙述RAC实施方法论和最佳实践经验，并在RAC高可用性、RAC运维管理等领域展开一些深入介绍，希望能给大家在RAC实施过程中起到抛砖引玉的作用。   客户哑口了 某典型故障 某日，我接到某移动公司DBA发过来的邮件，描述了其RAC数据库两次出现宕机的情况。邮件要点如下： 系统环境 某关键业务系统运行在 IBM AIX 5.3，数据库为两节点10.2.0.4.12 RAC环境，存储技术采用裸设备，即采用IBM HACMP软件。 故障现象及初步原因分析 在5月8日和6月20日由CRS发起了主机重启，从数据库的日志来看， vote disk心跳超时导致重启的，但是从主机上看，当时系统并未发现异常。由于本次重启，在主机侧未发现任何异常，IBM主机工程师认为是当时主机繁忙，在短时间内未响应，导致数据库误认为主机已经异常或者HANG住了。 IBM工程师进一步分析由于HACMP和Oracle Clusterware心跳检测参数设置不匹配，是导致宕机的一个重要因素。其中HACMP心跳检测参数为600秒，而CRS缺省为30秒。 即IBM工程师认为是Clusterware检测参数设置过小，导致Clusterware过于敏感了，应用软件压力大点，Clusterware在30秒中未检测到对方心跳，就以为对方宕机或 HANG住了。 初步解决方案 为了避免此问题，IBM公司的ORACLE数据库工程师建议将misscount的值改动到大于HACMP的心跳超时的值。这样的话，一旦主机有问题将由HACMP进 行重启，不会由数据库来发动重启，而且在他们实施的案例中，修改过这个参数之后，这个问题就避免了。 客户提出的问题 如果修改这个参数的值 为600秒，会导致数据库出现什么问题，从经验来看，该值一般设置为多大合适？ Oracle官方建议 仅分析上述邮件内容，就感觉该问题涉及的层面比较多，既可能与应用压力过大相关，也与HACMP和Clusterware底层参数设置相关，更与整个系统架构相关。为此，我首先在Metalink中查询了好几篇关于CSS参数设置相关的文档，特别是《CSS Timeout Computation in Oracle Clusterware [ID 294430.1]》。在此文档中，Oracle总体建议是谨慎调整MISSCOUNT参数。例如，在该文档的“CONSIDERATIONS WHEN CHANGING MISSCOUNT FROM THE DEFAULT VALUE”一节中，特别指出：  …