> 文章列表 / Page 27

作者为:  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行业所普遍接受： “云计算是一种新的计算模式。在该模式下，用户可便捷、按需地通过网络访问一组包括网络、服务器、存储、应用和服务在内的计算资源池，并且服务供应商可以极少的管理成本，对计算资源提供快速供应和释放能力。” 以下是云计算架构示意图：…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 话说升级 长期以来，Oracle数据库系统升级是让IT系统决策者和管理者陷入两难境地的重要话题。一方面，IT系统高速发展所提供的大量新技术和新特性，对IT人员充满诱惑，也的确能解决现有IT系统中的大量问题。另一方面，面对各行业正在运行的、非常重要的生产系统，缺乏全面评估和验证的数据库系统升级操作，不仅可能会导致业务中断时间过长，更严重的是可能导致应用软件的不稳定性，甚至性能衰减。因此，犹豫和彷徨之中，IT系统决策者们一次次错失了升级的良好契机，所谓“一步赶不上，步步赶不上”。日积月累之下，不仅数据库技术老化，而且也妨碍了硬件、网络、中间件等其它层次新产品和新技术的运用，最终导致现有IT系统难堪重负。更有甚者，索性推翻原有IT系统，另起炉灶。这不仅导致大量重复建设，更使得现有系统的软硬件资源和数据资源难以继承，即导致整个IT系统的投入产出比(ROI)的下降。 关于Oracle数据库升级，业界到底有多少顾虑？为什么要升级？升级项目应该包括哪些实施内容？升级技术方案到底有哪些？如何防范升级之后应用软件性能不衰减？升级项目如何组织实施？如何防范风险？本章试图围绕这些话题一一道来，希望给大家在计划和组织升级项目实施时，起到抛砖引玉的作用。 关于数据库升级的疑虑 关于升级的矛盾和纠结 关于升级，IT行业不同层面和角色人员到底有哪些纠结、矛盾和疑虑？以下这张图大概能表白大家的很多共同心声：   上述“为什么要升级？”和“升级能带来什么益处？”，其实更多地是有关升级的必要性问题。而“升级如何保证停机时间”、“万一升级失败，怎么办？”、“新版本对应用是否兼容”、“升级后是否会导致性能下降”等类问题，则是有关升级的可行性问题了。最后，“如何使用新特性？”、“需要对系统运维工作进行哪些调整？”等问题，就不仅仅是将升级看成是一种被动而为的事情，特别是为了满足Oracle产品服务期限的需求，也不是一种新瓶装旧酒的保守思维方式，而是以更积极的心态，主动接受和拥抱新平台、新技术，将升级看成是一次升华的过程了。 本章和本书更多章节内容，都是在试图解答大家的这些共同的疑虑，从而帮助大家面对升级工作，树立起既积极乐观、又严谨缜密的思维模式和工作方法。   关于升级两种绝对观点 在多年与国内多个行业的众多客户探讨数据库升级时，我们经常听到如下两类截然相反的观点： “升级是很简单的事情” 此观点更具体的叙述是：“升级哪有你们Oracle公司说的那么复杂，不就是建个11g新库，然后把9i、10g数据倒一遍吗？你们Oracle就想忽悠我们买你们更多服务吧？” 以本人经验，持这类观点的用户也是有所根据的：通常他们的系统数据量可能不大，例如最多只有几十GB。更重要的是，这类系统高可用性可能并不高，停几个小时、甚至停个周末进行升级都无所谓，几十GB数据慢慢倒几天呗。还有，这类系统的应用软件也比较简单，基本采用最基础、最经典的SQL语句，也几乎不可能在新平台运行时出现应用不兼容、性能衰减的问题。…

  开源的数据库平台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。这方面的内容预计会在今年的第四季度公开。…

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

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏     IT系统安全性，特别是数据库系统安全性，成了当下IT行业一个热门话题。本人曾听一位销售同事曾说：“在XX集团计划部，现在只要说申报与安全性相关的项目，准保一路绿灯。” 但也如另外一位同行所说：“安全性是说起来重要，做起来次要，忙起来不要。”无论重要也罢，次要、不要也罢。安全性特别是数据库安全性的确是值得深入探讨的话题，更具有广泛、全面实施空间的领域。 本章就将从数据库安全性需求及现状说起，再对Oracle数据库安全性解决方案进行一番介绍，然后结合某银行客户的安全性需求，制定安全性解决方案策略，最后系统描述了针对该银行的某关键业务系统的安全性评估情况。 数据库安全性需求及现状 IT 系统发展的一大趋势就是业务和数据的大集中。大集中之后的IT系统在系统的高可用性、高性能、可管理性、扩展性、安全性等方面，都将面临更严峻的挑战。具体在数据库安全性方面，在身份鉴别、数据存储层面、访问控制、安全审计和日志管理等诸多方面，IT系统都应得到进一步加强和加固，从而满足不断增长的数据安全管理和合规性需求。 目前，各类IT 系统安全事故的频发，例如客户资料流失等，不仅给各企业带来巨大损失，而且也造成非常不良的社会影响。于是，各行业领导都更高度重视数据库安全性。 安全性是涉及硬件、网络、操作系统、数据库软件、中间件软件、应用软件等各层面的系统工程。但是，据本人的了解，很多行业的安全性解决方案主要在服务器、网络等层面展开实施，例如某通信行业的4A认证体系。而在数据库层面，特别是Oracle数据库中，安全性实施的力度和强度并不充分。在大部分Oracle系统中，我们发现基本只采用了一些传统的安全性技术。例如： 防范非法用户访问的身份认证，如操作系统层、数据库层的口令管理。 基于数据库对象的防范非授权数据访问的权限控制。包括系统权限（system privileges）以及对象权限（object privileges）的设计，以及便于安全管理的角色（role）设计等。…

  关于数据库碎片管理   各行各业的数据库容量急剧增长是目前IT系统一个普遍的现象，除去正常业务增长因素，大量碎片的存在是导致这种现象的重要因素。其实，大多数DBA们都深知碎片的存在和带来的危害，但大家却很少进行计划性、系统化的碎片整理。为什么呢？通常的原因是：不了解如何评估碎片的严重性；不知道Oracle提供了哪些技术手段；业务系统高可用性太高，也不敢以在线方式进行碎片的整理… … 本章就将围绕碎片管理这个话题展开专题讨论，包括在表空间、表、索引等不同级别和对象方面进行碎片指标的介绍，以及Oracle公司提供的多种碎片整理技术，最后将结合一个案例，介绍碎片管理的实施过程。 希望本章能为大家在数据库空间管理方面起到一个抛砖引玉的作用，更希望各行各业有更多的客户能将碎片管理作为数据库运维中一项制度化、常态化的工作。   数据库空间碎片问题   10GB被压缩到1GB!     若干年前作为Oracle技术顾问，本人非常有幸参与了国家某基础数据库的建设工作。当2012年再次拜访该客户时，我向客户DBA询问了该库的最新容量，他告诉我已经增长到十几个TB了，而且说已经在考虑如何对数据库进行历史数据迁移等瘦身计划。凭借经验，我认为除了正常的业务高速增长因素之外，数据库一定存在大量碎片。于是，我让客户先查查碎片情况，别着急马上实施工程庞大的数据库瘦身计划。 果不其然，几天之后，突然接到客户DBA电话： “罗老师，我们按你推荐的方法对系统进行了一次碎片分析，并对一张10GB的大表通过重建方式，进行了碎片整理，结果被压缩到1GB！”。 “哈哈，按照这个压缩比例，你们的库可能被压到几个TB，甚至1个TB”。我在电话里也不无得意道。 是的，根据个人对国内多个行业Oracle数据库系统的观察，大多数核心数据库空间在急剧膨胀。例如，以下就是某银行一个关键业务系统数据库空间增长情况和趋势分析：    …

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 话说故障诊断 故障处理的确是一个涉及面既广又非常深入的领域。但Oracle数据库故障诊断就像世上其它领域的故障诊断一样，都遵循“获取故障现象和数据->故障原因分析->提供解决方案->解决方案测试->正式实施解决方案->故障处理后的评估分析”的通用思路。因此，只要心态平稳、方法得当，再复杂的故障都会找出问题端倪，并通过与各方协调，最终得到解决的。 本章首先将以若干故障诊断案例开始，介绍其中的经验和感悟。然后将介绍故障信息采集的重要性，特别是RDA、AWR、ADDM、DiagCollection.sql、RACCheck、Hanganalyze等数据库故障诊断基本工具的运用，最后又将回到案例，与各位共同分享故障诊断其中的苦与乐。   通过案例看故障诊断 其实，作为Oracle公司的解决方案顾问，我已经基本远离了故障诊断这样具体而富有挑战性的一线工作。但最近有幸为某客户的数据库升级和迁移提供现场技术支持服务，再次品味了现场故障诊断的那份紧张、刺激，甚至些许的成就感。下面通过该案例中几个具体故障的解决，与大家一块儿分享其中的经验、方法和规律，还有“痛并快乐着”的切身感受。 故障1：数据没装进去 故障现象 该系统投产前一天，应用开发商在进行正常的功能测试时，发现新系统中一张表的数据为空。由于该项目采取Exp/Imp方式进行升级和迁移，于是我让客户赶紧查一下Exp和Imp的日志文件。果然，在Imp日志文件中显示，该表在进行Imp操作时，出现如下一段错误信息，导致该表数据没有装进去。   IMP-00020: long column too large…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 我们经常会遇到应用软件在开发测试环境和生产环境性能不一致的问题，以及升级之后应用性能衰减等问题。除去管理、实施、沟通、协调等因素，一个重要原因就在于不同环境绝对隔离，相互之间缺乏有效的关联技术。例如开发测试环境和生产环境是相互独立的，升级前后的系统也是相互独立的。 11g新的性能管理工具SPM就是这种不同环境之间的关联技术。通过SPM，我们可以将开发测试环境和生产环境，以及升级前后的系统有效地关联起来，使得不同环境之间的应用软件性能不会出现衰减。 本章先从一些典型场景和问题着手，然后全面介绍SPM原理和运用过程，以及SPM的管理等技术点，最后将介绍有关SPM的更多参考资料。   一些典型场景 典型场景１ “系统性能这么差，肯定是应用软件问题，这帮开发人员可能就没有好好测试，就直接投到生产系统了。”—- 负责运维的DBA经常这么抱怨道。 “我们的应用在开发和测试环境都跑得好好的，肯定是这帮DBA瞎改什么配置，搞得应用出了问题，特别是把语句执行计划搞得变了。”—- 应用开发团队一方面觉得委屈，另一方面又觉得问题可能是出在生产系统环境。 在很多大型企业，特别是国企，应用软件设计开发和系统运行维护分属两个相对独立的部门或团队，管理上的过于职责分明和缺乏有效沟通更加剧了这种分歧和对立。 典型场景2 日益发展的IT技术既给现有IT系统提供了更先进的平台和更广泛的技术，但系统升级、变更可能带来的风险，又让决策者们彷徨犹豫。终于升级到11g了，但是新系统却出现了性能衰减。于是，各方抱怨又纷至沓来： “我们原来在10g跑得好好的，怎么一跑到11g就出现这么多问题，你们11g到底行不行啊？” —-…

  作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 第一次听说SQL Query Result Cache这个11g新技术，是在2007年11月的Oracle公司内部11g培训课程中。可能是因为11g新特性太多，而且那次连续几天的培训，被老师轰炸得审美疲劳了，对这个新技术并没有留下太深印象。当时只是感觉Oracle又多了个什么Cache，也没完全弄明白其原理，也不知道与传统Buffer Cache有什么区别，更不知道这个技术适合于什么场景。 待日后有精力再深入研究该技术，特别是结合客户相关实际问题，才猛然发现Oracle这个新技术太牛了！Oracle公司也太富有创新能力了，居然在几十年难得一动的SGA和Shared_Pool内存架构中增加了Result Cache结构，并提供了新的SQL Query Result Cache技术，解决了很多重复查询语句导致资源开销过大的典型问题。 Result Cache到底是什么新技术？如何使用？适合于什么应用场景？… …。希望本章的内容能回答这些问题，更希望您别像我当年一样，仅仅是走马观花地了解一下而已，而是能立马激动起来，并能运用到您的实际应用开发工作中去。呵呵。 Result…

  作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏   以下是各种表压缩算法特性的进一步描述：   IT系统数据量与日俱增，对IT系统设计、开发、运维各方面人员都带来了巨大挑战。除在硬件层面不断进行投入和加强之外，在软件层面一个重要的应对策略就是数据压缩技术。但是，以本人的经历，国内Oracle数据库却很少采用数据压缩技术，这是为什么呢？Oracle 11g在数据压缩领域有什么新的发展？各种压缩算法的压缩比如何？压缩对性能到底有什么影响？如何合理运用11g压缩技术和管理压缩数据？ 本章就将针对上述问题进行分析和叙述，特别是介绍相关案例和实施细节。   为什么Oracle压缩技术运用不普及？ 海量数据的增长和挑战 IT系统数据量与日俱增，甚至呈几何级数增长。以下就是国外相关机构在2010年对VLDB数据库数据量变化的统计和预测：     可见，在以往年代最大的数据库为Teradata，而从2003年之后则是Oracle独占鳌头了。该机构并预测在2008年就将出现PB级数据库，可能现在早就有了，至少本人在2004年就见识过国内380TB规模的数据库了。 导致数据量剧增的原因可能包括如下几方面：…