Month: January 2016

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏     IT系统安全性，特别是数据库系统安全性，成了当下IT行业一个热门话题。本人曾听一位销售同事曾说：“在XX集团计划部，现在只要说申报与安全性相关的项目，准保一路绿灯。” 但也如另外一位同行所说：“安全性是说起来重要，做起来次要，忙起来不要。”无论重要也罢，次要、不要也罢。安全性特别是数据库安全性的确是值得深入探讨的话题，更具有广泛、全面实施空间的领域。 本章就将从数据库安全性需求及现状说起，再对Oracle数据库安全性解决方案进行一番介绍，然后结合某银行客户的安全性需求，制定安全性解决方案策略，最后系统描述了针对该银行的某关键业务系统的安全性评估情况。 数据库安全性需求及现状 IT 系统发展的一大趋势就是业务和数据的大集中。大集中之后的IT系统在系统的高可用性、高性能、可管理性、扩展性、安全性等方面，都将面临更严峻的挑战。具体在数据库安全性方面，在身份鉴别、数据存储层面、访问控制、安全审计和日志管理等诸多方面，IT系统都应得到进一步加强和加固，从而满足不断增长的数据安全管理和合规性需求。 目前，各类IT 系统安全事故的频发，例如客户资料流失等，不仅给各企业带来巨大损失，而且也造成非常不良的社会影响。于是，各行业领导都更高度重视数据库安全性。 安全性是涉及硬件、网络、操作系统、数据库软件、中间件软件、应用软件等各层面的系统工程。但是，据本人的了解，很多行业的安全性解决方案主要在服务器、网络等层面展开实施，例如某通信行业的4A认证体系。而在数据库层面，特别是Oracle数据库中，安全性实施的力度和强度并不充分。在大部分Oracle系统中，我们发现基本只采用了一些传统的安全性技术。例如： 防范非法用户访问的身份认证，如操作系统层、数据库层的口令管理。 基于数据库对象的防范非授权数据访问的权限控制。包括系统权限（system privileges）以及对象权限（object privileges）的设计，以及便于安全管理的角色（role）设计等。 为实现记录级的安全控制，采用了视图（View）方式。 关闭操作系统级不必要服务。如telnet、FTP服务等。 这种传统技术的安全保护强度是远远不够的，满足不了日益增长的安全性和合规性需求，导致数据库系统的各种安全风险暴露在外。例如，国内Oracle数据库几乎没有采取加密技术，特别是关键和敏感的客户资料全部是明文存储在数据库中；DBA权限过高，能访问所有应用数据；对重要操作行为缺乏审计等。 为什么在客户最为关注的Oracle数据库领域，客户反而没有充分实施安全解决方案呢？因为商务方面因素？的确Oracle大部分安全产品都需要单独购买。因为技术因素？的确Oracle大部分安全产品在实施方面还是有一定工作量和技术难度的，而且多数技术人员缺乏这方面实施经验。因为体制问题？的确很多行业明确规定安全性技术不能采用国外技术，只能采用国内自有技术体系。 但本人一次与一个国内重要客户DBA有关安全性的沟通内容，则耐人寻味，也有点啼笑皆非。 我问：“为什么你们的系统只在操作系统和网络层面实施安全性，而不在Oracle数据库内部加强安全性呢？”   DBA回答：“你们Oracle数据库现在就那么多Bug，就象个大马蜂窝，我们哪敢还去实施那么多安全性产品，去捅这个马蜂窝啊？你们Oracle更像个核反应堆，我们宁可在外面构筑铜墙铁壁，也不轻易碰你们这个核反应堆。” 我说：“再坚固的钢筋水泥也抵挡不住内部的核泄露啊，就象日本福岛核电站爆炸事故一样。” DBA无语，但也未必赞同我的解释。 Oracle数据库安全性解决方案 从源头说起 在IT系统日益面临各种内外安全攻击和挑战的严峻环境下，为满足IT系统不断增长的安全需求，为符合各种安全性和合规性要求，Oracle数据库安全性技术和产品也在不断推陈出新，以下就是Oracle在不同版本下安全性技术不断发展的示意图：     其实追根溯源从Oracle数据库诞生之日起，Oracle就非常重视数据库安全性。值得一提的是上图第一行所谓政府客户（Government Customer），实际上就是美国军方。Oracle数据库其实就是来源于当年的RSI公司（Oracle公司前身）为美国中央情报局设计开发的一套专用信息处理系统，因为该项目名称叫Oracle，所以RSI公司更名为寓意更深远、发音也更响亮的Oracle公司，并从此扬名天下。而在数据库安全领域，由于来源于政府和军方的缘故，Oracle具有先天优势，诸多产品如Oracle Label Security等也带有浓郁的美国政府特别是军方色彩。 从总体上而言，Oracle数据库是业界安全性方面最完备的数据库产品。在数据库安全性的国际标准中，Oracle通过了14项标准的测试，是所有数据库产品中通过安全性标准最多、最全面的产品。Oracle在C2级的操作系统上(如商用UNIX、VMS操作系统)，不仅满足NCSC C2级安全标准，而且已经正式通过了NCSC C2标准的测试。在B1级的操作系统上不仅满足NCSC B1级安全标准，而且已经通过了NCSC B1级标准的测试。   数据库安全性全面解决方案 以下示意图从一个角度代表了Oracle数据库安全性全面解决方案：     还记得前面一个DBA的话语吗？他把数据库安全性比喻成一个核反应堆。上图不就是非常形象的Oracle数据库安全性的核反应堆吗？ 即在核反应堆的最外层，Oracle通过数据库防火墙（Database Firewall）产品构筑了一层坚固的钢筋水泥保护墙，用于阻断（Blocking）和记录（Logging）对数据库的恶意攻击。例如，监视数据库活动，防止未授权的数据库访问、SQL 注入、权限或角色升级、对敏感数据的非法访问等。 而在数据库内部，除传统的数据库用户、口令、角色、权限、审计等功能之外，在安全监控层、访问控制层和数据存储层面，均推出了功能更强、更符合安全性需求的产品和技术，使得Oracle数据库安全性得到全面加强。下图更清晰地展现了各层面的相关技术和产品：  …

  关于数据库碎片管理   各行各业的数据库容量急剧增长是目前IT系统一个普遍的现象，除去正常业务增长因素，大量碎片的存在是导致这种现象的重要因素。其实，大多数DBA们都深知碎片的存在和带来的危害，但大家却很少进行计划性、系统化的碎片整理。为什么呢？通常的原因是：不了解如何评估碎片的严重性；不知道Oracle提供了哪些技术手段；业务系统高可用性太高，也不敢以在线方式进行碎片的整理… … 本章就将围绕碎片管理这个话题展开专题讨论，包括在表空间、表、索引等不同级别和对象方面进行碎片指标的介绍，以及Oracle公司提供的多种碎片整理技术，最后将结合一个案例，介绍碎片管理的实施过程。 希望本章能为大家在数据库空间管理方面起到一个抛砖引玉的作用，更希望各行各业有更多的客户能将碎片管理作为数据库运维中一项制度化、常态化的工作。   数据库空间碎片问题   10GB被压缩到1GB!     若干年前作为Oracle技术顾问，本人非常有幸参与了国家某基础数据库的建设工作。当2012年再次拜访该客户时，我向客户DBA询问了该库的最新容量，他告诉我已经增长到十几个TB了，而且说已经在考虑如何对数据库进行历史数据迁移等瘦身计划。凭借经验，我认为除了正常的业务高速增长因素之外，数据库一定存在大量碎片。于是，我让客户先查查碎片情况，别着急马上实施工程庞大的数据库瘦身计划。 果不其然，几天之后，突然接到客户DBA电话： “罗老师，我们按你推荐的方法对系统进行了一次碎片分析，并对一张10GB的大表通过重建方式，进行了碎片整理，结果被压缩到1GB！”。 “哈哈，按照这个压缩比例，你们的库可能被压到几个TB，甚至1个TB”。我在电话里也不无得意道。 是的，根据个人对国内多个行业Oracle数据库系统的观察，大多数核心数据库空间在急剧膨胀。例如，以下就是某银行一个关键业务系统数据库空间增长情况和趋势分析：       排除正常业务增长因素，大量碎片的存在是空间急剧膨胀的重要根源。而现状是大多数DBA们很少进行系统的碎片分析，更没有计划性、周期性、常态化地进行空间碎片整理了。于是，我们听到的更多是空间不断增长和性能下降的抱怨，还有每年不断增加的存储采购。 何谓碎片 客户经常会遇到这种问题：明明 dba_free_space等视图显示数据库有足够的空闲空间，但却遇到ora-1547、ora-1562、ora-1653等表示无法分配空间或空间不足的错误。通常而言，这就是遇到空间碎片问题了。 Oracle在表空间、表、索引等不同层面和对象方面都可能存在碎片。在表空间级，如果频繁进行创建、删除表和索引等DDL操作，会导致大量碎片。表空间级碎片通常有两种：一种是不连续的空闲空间，导致Oracle无法分配一个完整的extent，Oracle也无法对这种不连续的空闲空间进行合并（coalesce）操作。另一种是空闲空间相邻，Oracle SMON进程会定期进行合并（coalesce）操作，在一定程度上可以缓解碎片问题。   在表级，大量DML操作会导致大量碎片，特别是进行大量Delete操作之后，又进行大量Insert 操作，很容易产生碎片，这是因为Oracle的Delayed block cleanout特性所导致。所谓Delayed block cleanout特性，是指当对表进行DML操作之后，Oracle只会先将相应的数据块标识为修改状态，而不会立即真正在磁盘上执行这些操作，除非马上访问（Select）这些数据块。这样，当表的记录被Delete，空间可能还没有被真正释放，马上进行Insert操作，Oracle将不会将新记录插入到刚被Delete记录所占的空间，而是插入到新的extent之中，这样将导致表的空间急剧增长。   同样地，大量DML操作也会导致索引产生大量碎片，而且在原理上索引更容易产生碎片。例如，由于无法指定索引的PCTUSED属性，这样当一条记录被删除后，Oracle并不会重用该记录所对应的索引空间。而且针对update操作，Oracle在索引上实际是进行Delete和Insert和操作，非常容易产生碎片。   空间碎片带来的问题和风险 空间浪费 首先，碎片带来的问题是空间的无谓浪费，导致客户在存储设备方面进行了很多不必要的扩容和投入。例如，根据我们的初步估算，如果技术方案和实施手段得当，上述银行系统至少能节省出1/3以上的空间。 访问效率的低下 无论是联机交易应用，还是批处理应用，大量碎片的存在，都将导致访问效率低下，甚至极度恶化。如果是联机交易应用，由于索引碎片较多，将导致索引访问效率下降，极大影响以索引访问为主的联机交易应用性能。如果是后台批处理应用，由于表的碎片较多，特别是碎片表的高水位标志（HWM）较高，而实际记录数并不多，将导致以全表扫描、全分区扫描为显著特征的批处理应用效率低下，并且浪费大量内存和I/O资源。大量碎片的存在，也将导致RMAN备份和逻辑备份、统计信息采集等后台作业效率低下。   空间管理需求分析 如何有效加强各系统的空间管理，特别是合理运用Oracle相关技术有效解决碎片问题，将不仅是数据库系统目前急待解决的问题，而且也是客户运维团队一项长期、艰巨的工作任务。 以下是我们在日常工作中与客户运维团队的沟通中，了解到客户针对空间管理，特别是在碎片管理方面提出的需求： 合理评估空间问题 首先，希望Oracle服务团队在表空间、表、索引等不同层面和不同数据对象方面，提供评估空间问题，特别是碎片问题的合理方法、指标和评估标准。 合理选择技术方案 其次，客户希望Oracle服务团队在Oracle众多空间管理，特别是碎片管理方面的技术手段中，结合实际系统特点，在技术有效性、对生产系统影响、技术成熟性等方面进行综合平衡，提出针对表空间、表、索引等不同层面和不同数据对象的碎片管理技术方案。 合理的实施计划 在上述技术方案基础上，根据客户系统特点，制定合理的的实施计划，以适当的资源投入，达到既合理解决空间问题，同时又能将对生产系统的影响降至最小等目的。 实施效果评估分析 在上述实施计划基础上，选择典型系统实施之后，希望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 for column buffer size (number)   故障原因和解决方法 有病不可怕，就怕病人说不清自己的症状，也怕没有相关的检查报告和指标。同样地，数据库出故障也不可怕，只要有错误信息，就可追根溯源了。以下就是Oracle关于IMP-00020错误的原因分析和解决方法：   IMP-00020: long column too large for column buffer size (number) Cause: The column buffer is too small. This usually occurs when importing LONG data. Action: Increase…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 我们经常会遇到应用软件在开发测试环境和生产环境性能不一致的问题，以及升级之后应用性能衰减等问题。除去管理、实施、沟通、协调等因素，一个重要原因就在于不同环境绝对隔离，相互之间缺乏有效的关联技术。例如开发测试环境和生产环境是相互独立的，升级前后的系统也是相互独立的。 11g新的性能管理工具SPM就是这种不同环境之间的关联技术。通过SPM，我们可以将开发测试环境和生产环境，以及升级前后的系统有效地关联起来，使得不同环境之间的应用软件性能不会出现衰减。 本章先从一些典型场景和问题着手，然后全面介绍SPM原理和运用过程，以及SPM的管理等技术点，最后将介绍有关SPM的更多参考资料。   一些典型场景 典型场景１ “系统性能这么差，肯定是应用软件问题，这帮开发人员可能就没有好好测试，就直接投到生产系统了。”—- 负责运维的DBA经常这么抱怨道。 “我们的应用在开发和测试环境都跑得好好的，肯定是这帮DBA瞎改什么配置，搞得应用出了问题，特别是把语句执行计划搞得变了。”—- 应用开发团队一方面觉得委屈，另一方面又觉得问题可能是出在生产系统环境。 在很多大型企业，特别是国企，应用软件设计开发和系统运行维护分属两个相对独立的部门或团队，管理上的过于职责分明和缺乏有效沟通更加剧了这种分歧和对立。 典型场景2 日益发展的IT技术既给现有IT系统提供了更先进的平台和更广泛的技术，但系统升级、变更可能带来的风险，又让决策者们彷徨犹豫。终于升级到11g了，但是新系统却出现了性能衰减。于是，各方抱怨又纷至沓来： “我们原来在10g跑得好好的，怎么一跑到11g就出现这么多问题，你们11g到底行不行啊？” —- 应用开发、运维等各方客户齐声抱怨道。 “我们不敢奢望11g比10g跑得快，但你们Oracle能不能保证我们的应用在11g下起码别比10g跑得慢啊？” —- 客户几乎是在哀求了。 “… …” 针对上述一些典型场景和客户需求，除了需要在项目管理、沟通协调等方面加强工作之外，Oracle在技术方面有什么招数吗？有！Oracle 11g的SPM（SQL Plan Management）就是解决上述问题的典型技术。   SPM原理 传统技术手段 众所周知，SQL语句执行性能好坏主要取决于语句执行计划，而Oracle优化器特别是基于成本优化器（CBO），主要依靠所访问表和其它对象的统计信息、优化器版本、优化器参数、系统硬件配置和参数设置、SQL Profile等信息，来综合分析并确定语句最佳执行计划。保证语句执行计划最优和稳定的一种重要手段就是统计信息的准确性和实时性，大部分DBA和开发人员也深知及时采集和更新统计信息的重要性。但确定执行计划的因素的确太多，例如上述的优化器版本、参数等信息，因此仅仅依靠统计信息还不能确保语句执行计划的最优化和稳定性。 Oracle传统上有哪些保证语句执行计划稳定性的技术呢？第一种就是在语句中增加提示（HINT），强制Oracle优化器采用某种固定的执行计划。另一种就是使用存储大纲（Stored Outline）技术，即将优化的执行计划提示信息存储在Oracle内部一组表格中，强制相关SQL语句使用这些存储大纲。这两种技术一个共同特点就是将相关SQL语句的执行计划固定下来，而不考虑未来环境变化，例如数据库版本升级之后是否会带来新的更优化的执行路径。 SQL Profile则是Oracle从10g开始提供的另一种确保语句执行计划最优化的技术。相比表和索引有统计信息，SQL Profile就是一条SQL语句的统计信息。例如，当我们遇到一个复杂且资源消耗非常大SQL语句时，Oracle可采用一些取样数据，或者可以执行该语句一个片段，以及分析该语句的历史执行情况，这些信息就是语句的SQL Profile。Oracle通过预先采集SQL Profile信息，来评估整体执行计划是否最优化。即当Oracle正式执行该SQL语句时，优化器不仅利用该语句所访问对象的统计信息，而且利用已产生的该语句SQL Profile信息，来产生整体上更优的执行计划。 11g SQL执行计划管理技术：SPM 在上述传统性能管理技术基础上，Oracle 11g推出了更先进的SQL执行计划管理技术：SPM，全称为SQL Plan Management技术。 SPM在原理上通过维护一个SQL执行计划的基线（Baseline），来自动控制SQL语句执行计划的演化过程。当启用SPM技术之后，优化器新产生的执行计划只有证明不会导致性能衰减时，才能加入到执行计划基线中。也就是说，只有基线中的执行计划才能被真正执行。如后所述，Oracle可以自动产生SQL语句的执行计划基线，也可以通过SQL Tuning Sets等手工方式产生。 SPM的最大好处就在于维持SQL语句的性能稳定性，避免性能衰减，同时也能有效减轻DBA工作负担，使得DBA们不用花费大量精力去识别、分析性能衰减问题并加以解决。 以下就是SPM原理图：  …

  作者为:  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 Cache原理 基本原理 11g出了个SQL Query Result Cache的新特性，简称Result Cache技术吧。其基本原理就是将SQL语句查询结果数据直接存储在内存中，这样后续相同查询语句就直接从该内存中读取了，这将极大地提高该类语句重复查询性能。 为此，Oracle在SGA的Shared Pool内存中专辟了一个Result Cache内存，如下图所示：                     以下就是Result Cache的工作原理图：       即： 当第一个会话进行第一次查询时，将首先从硬盘读取数据 。 第一个会话同时将该数据存储在SQL Query Result Cache区域 。 第二个会话进行相同语句查询时，Oracle直接从SQL Query…

  作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏   以下是各种表压缩算法特性的进一步描述：   IT系统数据量与日俱增，对IT系统设计、开发、运维各方面人员都带来了巨大挑战。除在硬件层面不断进行投入和加强之外，在软件层面一个重要的应对策略就是数据压缩技术。但是，以本人的经历，国内Oracle数据库却很少采用数据压缩技术，这是为什么呢？Oracle 11g在数据压缩领域有什么新的发展？各种压缩算法的压缩比如何？压缩对性能到底有什么影响？如何合理运用11g压缩技术和管理压缩数据？ 本章就将针对上述问题进行分析和叙述，特别是介绍相关案例和实施细节。   为什么Oracle压缩技术运用不普及？ 海量数据的增长和挑战 IT系统数据量与日俱增，甚至呈几何级数增长。以下就是国外相关机构在2010年对VLDB数据库数据量变化的统计和预测：     可见，在以往年代最大的数据库为Teradata，而从2003年之后则是Oracle独占鳌头了。该机构并预测在2008年就将出现PB级数据库，可能现在早就有了，至少本人在2004年就见识过国内380TB规模的数据库了。 导致数据量剧增的原因可能包括如下几方面： 数据和应用大集中 数据和应用大集中已成为各行各业IT 系统发展的一大趋势。这种趋势给IT系统带来的挑战是全方位的，首先就是数据规模和访问量的急剧增长，面对海量数据的访问性能、安全性、可管理性、高可用性等需求更是IT系统架构设计、应用开发、运行维护等多方人士共同面对的严峻挑战。 安全审计的需要 面对日益增长的安全性和合规性需求，特别是面对各种行业组织和国家有关部门的安全审计需求，例如国外的萨班斯-奥克斯利法案（Sarbanes-Oxley Act），越来越多企业的IT系统被要求保留交易明细，甚至需要构建专门的安全审计系统。本人2012年下半年就为某国有大型银行的安全审计系统提供一定的技术服务，该系统一年数据量就达到200TB，将成为该行有史以来最大的数据库。 互联网应用的高速增长 互联网应用持续高速增长，不仅导致传统交易数据量的增长，而且由于Web 2.0应用和各种多媒体应用的推广，使得各种内容管理数据也呈蓬勃发展之势。   为什么不采用Oracle压缩技术？ 面对这种海量数据增长所带来的挑战，除了采用更先进服务器和存储设备技术之外，在数据库设计方面应该考虑的一个重要技术就是数据压缩技术，就象我们都经常在自己机器上通过 Winzip、rar等工具对大文件进行压缩一样。但是，我们发现国内基于Oracle的数据库很少使用到Oracle压缩技术，为什么会出现这种局面呢？本人分析的原因如下： Oracle压缩技术的局限性 首先，Oracle在11g之前的压缩技术的确存在一定的局限性。Oracle 11g之前只有在批量加载数据，并采用direct path load等技术情况下，才能进行数据压缩，也就是说在数据仓库的ETL等典型场景中才可能使用到压缩技术，而在普通OLTP应用中，Oracle没有提供数据压缩技术。这就大大限制了压缩技术的使用范围。 担心性能开销 采用了压缩技术，客户担心在数据写入时需要压缩，在查询数据时又要解压缩，都可能增加额外的CPU开销。这也是导致压缩技术没有普遍使用的重要原因之一。 现在早就是11g时代了，Oracle 11g已经在数据压缩技术方面有了突飞猛进的发展。下面我们就在这个新的平台上与大家共同讨论相关技术和应用前景吧。 11g压缩技术概述 Oracle压缩技术特点和好处 总体而言，Oracle压缩技术具有如下特点和好处： 节省大量存储空间 就象我们自己压缩文件所期待的一样，Oracle数据库压缩技术带来的好处，首先就是节省大量存储空间。以下就是Oracle公司内部ERP系统的各个应用系统，在压缩前后的存储空间变化情况：   即平均达到3倍的压缩比。大大节省的存储空间带来的效益是全方位的，不仅是存储设备投入的节省，而且对生产、容灾、测试、开发等环境需求都大大降低。   性能不降反升 通常地，一旦采用压缩算法，数据写入时需要压缩，在查询数据时又要解压缩，都可能增加额外的CPU开销，这也是广大客户所担忧的。但压缩之后，将带来I/O访问量的大幅度下降，同时也降低了Oracle缓存（Buffer Cache）的开销。这样一正一负，很多测试表明性能是不降反升了。特别是对需要进行大规模数据处理的应用更是收效显著，例如逻辑和物理备份、统计信息采集等。 另外，后面详细描述的11g新OLTP压缩算法并不是在每个DML语句运行时都进行压缩计算，而是采取一种延迟的批处理方式压缩，这也有效保障了DML操作性能不受影响。 Oracle可在表空间、表、分区级进行压缩…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文地址：https://www.askmac.cn/archives/oracle-acs%E8%B5%84%E6%B7%B1%E9%A1%BE%E9%97%AE%E7%BD%97%E6%95%8F-%E8%80%81%E7%BD%97%E6%8A%80%E6%9C%AF%E6%A0%B8%E5%BF%83%E6%84%9F%E6%82%9F%EF%BC%9A11g%E6%96%B0%E6%8A%80%E6%9C%AF%E6%96%B0%E5%8A%9F.html     本章首先将以自己一个与11g相关的尴尬经历开始，然后对11g新技术和新特性进行一番总体介绍，再围绕一个具体技术话题，讲述11g新技术使用策略的重要性，最后针对11g新技术/新功能的总体使用策略提供自己的具体建议，希望这些内容对广大读者在11g平台的设计、开发和运维等方面工作有所裨意。   5.1 我被客户“打懵”了 故做镇定 2012年2月的某一天，应某国有大型银行的要求，来到了该银行的南方开发基地，为其正在进行的11g升级项目提供技术支持和咨询服务工作。那天上午一踏入会议室，与该行一群新老朋友简短地寒暄之后，便很快进入了正题： “罗工，你先帮我们梳理一下这张表格，11g这些新特性到底用还是不用？” 我快速扫描了一下大屏幕上投影的表格，以下是片断内容： 维护项 11g对应的功能点 是否使用 使用说明 数据库及补丁安装 联机热补丁 待确认 1、HOT PATCH是否只能联机安装，2、联机安装时对数据库的影响，3、通过OPATCH命令查询补丁是否为HOT PATCH，4、目前同业中HOT PATCH的使用情况 Time Stamp With Time Zone数据的自动补丁安装* 待确认 确认该新特性功能 零停机时间的Clusterware补丁安装* 推荐使用 工程师确认联机安装对RAC的影响 故障管理 自动诊断信息库框架 必须使用 日常维护中要熟悉文件存放结构 命令行故障管理工具adrci 推荐使用 日志信息诊断扩展功能 支持工作台 不使用 由于需要配置外网连接，故部分功能不可用 健康监控工具Health Monitor 待确认 手动启用或者在严重错误时自动触发，在严重故障时运行该功能对数据库的影响需评估，AB类关闭，CD类开启， 意外事件打包服务IPS 推荐使用 相关日志打包提供给ORACLE技术支持 数据恢复向导Data…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址：https://www.askmac.cn/?p=16572   本人的第一本书《品悟性能优化》，“洋洋洒洒”近500页，按Oracle性能优化方法论从上往下，即从应用设计开发，到系统层面逐步展开叙述。性能优化的确是IT系统各方人士长期面临的艰难挑战，也是大家百谈不厌的话题。本书虽然没有对性能优化再浓墨重彩，但很多章节内容其实也是围绕性能优化而展开的。 本章我们先对《品悟性能优化》一些重要观点进行回顾，然后再通过若干案例，对这些观点进行总结。同时，由于受篇幅等因素限制，针对《品悟性能优化》书所没有包括的一些优化技术，例如适合于数据仓库的Bitmap索引、Bitmap Join索引等进行介绍。 众所周知，应用性能问题对系统整体性能影响最大，所以本章案例更多地侧重于应用性能问题的解剖。同时，性能问题也涉及IT系统的方方面面，本章最后一个案例就是分析数据库备份恢复中的性能问题。   重温《品悟性能优化》一些重要观点 回顾性能优化方法论 Oracle性能优化方法论主要分为如下两种： 自顶向下（Top-Bottom） 该方法论可以如下图表示：   即在项目设计、开发、上线的全程都展开性能优化工作，而且优化工作开始地越早，其效益也越高，同时付出的成本也最小。而优化工作开始地越晚，其效益也越低，并且付出的成本也最大。 之所以叫自顶向下，是因为一方面从软件生命周期角度而言，从头开始就关注性能优化工作。另一方面，最初我们在业务逻辑、架构设计等层面关注性能问题，然后再逐步深入到应用设计、开发和测试层面考虑优化，最后才到数据库系统、操作系统、硬件等层面考虑参数设置、存储配置等优化，即从IT系统架构层面而言，也是自顶向下的。 总之，自顶向下更适合于一个新项目的建设。 自底向上（Bottom -Top） 如果针对一个已经投产的系统发生的性能问题，则我们需要采用自底向上方法论了。以下就是自底向上方法论示意图：   即我们先从系统层面开始，了解硬件配置，检查系统的CPU、I/O利用率等，然后再逐步了解到数据库的各种等待事件，从而基本确定性能瓶颈所在，最后再重点分析应用问题。即从IT系统架构层面而言，是自底向上的。 另外，从上线后发现性能问题，到逐步分析出某个SQL语句、某个应用问题，最终可能回溯到数据库设计、数据库架构，甚至业务流程设计的问题，因此这种问题分析和解决方式从IT系统时间轴上分析，也是自底向上，自后往前的。   性能优化中的20/80规则 数据库体系结构设计和应用设计对系统性能的影响能占到80%，而硬件配置、参数调整、系统软件Bug等系统方面因素，只占到20%。 80%的性能问题是由20%的应用导致的。如少量大表的全表扫描导致的性能瓶颈。并不是应用一有问题，就一定要对现有数据库结构大卸八块，应用推倒重来。 80%的性能问题可以由20%的优化技术所解决。如简单的索引策略，执行路径分析等，能解决绝大部分性能问题。 应用开发指导思想 建议应用系统设计和开发人员在开发过程中，在开发指导思想上进行如下方面的加强： 不仅关注SQL语句功能，而且要关注性能。即用量化手段，进行SQL语句质量控制 开发队伍能有层次性和专业分工。不仅按照业务模块分工，而且有专门的质量控制，尤其是SQL质量控制人员 加强软件开发的规范管理 注重知识共享和传递，减少低级错误的重复性 强调实际测试的重要性。切忌想当然的主观推断，一切以实际应用在尽可能真实数据和环境下的测试数据为准 针对OLTP和OLAP系统，合理运用不同技术 IT系统总体上可以分为OLTP和OLAP系统，数据库系统优化的目标与应用系统的类型是紧密相关的。这两类系统无论在业务特征还是适用的技术方面都迥然不同。例如，针对生产系统，应以系统的响应速度作为首要的优化目标。而对查询统计系统而言，则应该以系统整体吞吐量作为优化目标。 以下是我们总结的两类系统在业务操作特征，以及技术运用方面的主要区别： 比较项目 联机业务 批处理业务 业务特征 操作特点 日常业务操作，尤其是包含大量前台操作 后台操作，例如统计报表、大批量数据加载 响应速度 优先级最高，要求反应速度非常高 要求速度高、吞吐量大 吞吐量 小 大…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址：https://www.askmac.cn/?p=16572         请允许我重复在《品悟性能优化》中关于分区技术的一段叙述：“Oracle公司历史上第一位华裔高级副总裁（SVP）曾说：随着分区技术的出现，标志着Oracle公司真正成为了名符其实的企业级数据库软件供应商，Oracle数据库也真的具有海量数据处理能力了。” 正因为Oracle分区技术在满足海量数据处理的高性能、扩展性、数据可管理性、数据生命周期管理、数据备份恢复、高可用性等综合需求中，扮演着太重要的作用，分区技术又是那么地丰富多彩。因此，我们还是结合上一章某银行大集中项目，在本章对分区技术进行专题叙述。包括该系统现有分区方案的评估、大集中系统的分区方案，以及全局分区索引、11g分区新技术等专题技术的介绍。本章最后通过一个最新案例，介绍分区技术方案的实施过程和感悟。 现有系统分区方案分析 以下就是该银行系统现有的分区方案情况，以及我们项目组给出的相关评估分析： 现有系统分区状况 目前，现有系统进行了一定的分区工作，具体情况大致如下： 表分区 表分区情况如下：   PARTITI SUBPART   COUNT(*) ——- ——- ———- HASH    NONE            62 RANGE   NONE            46 RANGE   HASH             6   即共有62个表进行了HASH分区，46个表进行了RANGE分区，6个表进行了RANGE-HASH复合分区。 HASH分区主要按ACC（帐号）、（PAPER_TYPE,PAPER_NO）等字段进行了HASH分区，分区数为16、32个等。 RANGE分区主要按TRAN_DATE等时间字段，按月进行分区。 RANGE-HASH复合分区基本按TRAN_DATE等时间字段进行第一维分区，按ACC等字段进行HASH第二维分区。 RANGE分区和RANGE-HASH分区部署在BIG_DT1、BIG_DT2等表空间。 HASH分区均匀部署在HASH_DT01 … HASH_DT10等表空间。 索引分区 全部为Local分区索引。包括Local Prefixed Index和Local non-Prefixed Index。 分区索引部署在BIG_IDX1、BIG_IDX2，HASH_IDX01 … HASH_IDX10等表空间。 现有分区状况评估 现有系统分区状况，在如下方面值得进一步商榷和改进： TRAN_DATE等时间字段由于采取数字表示，分区方案的可读性和维护性不是非常好。…

作者为:  SHOUG成员 – ORACLE ACS高级顾问罗敏 本文永久地址：https://www.askmac.cn/?p=16572   简而言之，数据库物理设计就是为满足海量数据的高性能、可扩展性、高可用性等处理需求，在数据库逻辑设计基础上，结合具体的数据库管理系统平台和硬件平台，特别是运用Oracle相关特色技术，进行的详细物理级设计工作。 事实上，Oracle物理设计的内涵非常丰富，外延也非常广泛。例如Oracle每个被存储的对象（普通表、索引、大对象LOB字段等）几乎都涉及到相关物理属性的设计；还包括数据库实例初始化参数设计、数据库块选择、数据库字符集选择、控制文件规划、日志文件设计等诸多方面；还有数据文件、表空间，特别是分区方案设计；如果采用ASM技术，还有ASM实例设计、ASM磁盘组设计、ASM 文件设计等；以及操作系统参数设计、存储系统配置设计等更多方面。 真是林林总总，目不暇接。本章将以一个银行案例为背景，介绍物理设计一些主要内容，本书后面章节还将涉及物理设计其它方面的相关内容，例如分区、大对象LOB等。 20多年前的物理设计 前面章节对自己20多年前刚工作时，在领导带领下开展的数据库逻辑设计和数据流程图设计工作，不无得意。实际上，在当年技术环境下，露怯的事情太多了。以下以物理设计为例，讲述当年的趣事。 20多年前我们几乎没有物理设计的概念，就知道如何在逻辑上写出建表语句而已，连表空间都不指定，更别提表的pctfree, pctused等一堆物理属性参数了。大家知道当年Oracle 5.1版在不指定表空间的缺省情况下，把表搁哪儿了吗？SYSTEM表空间！ 于是，在我们项目组历经半年的应用软件设计和开发之后，开始往数据库里灌数据时，不一会儿，数据库就报SYSTEM表空间满的错误（ORA-1652）了。此时，作为刚毕业的研究生，我被委以重任，研究如何解决该问题。在当年连Oracle联机文档都没有的情况下，抱着一本不知道是科海还是希望出版的，翻译得象天书一样的资料，苦苦研读，终于找到了如何扩表空间的命令。当年的Oracle 5.1版，居然要先通过一个Oracle提供的ccf工具，在操作系统创建一个文件，然后再通过“ alter tablespace <tablespace_name> add datafile <datafile name>”命令将该文件添加到指定表空间，从而完成表空间扩容工作。 就这样，我照猫画虎般地直接把SYSTEM表空间扩充了！也满足数据加载需求了。待任务完成之后，居然得到了领导的口头嘉奖。今天回忆起来，实在是汗颜。— 这就是我们20多年前的数据库物理设计水平。   一个项目的物理设计概貌 首先，我们瞥一下该银行大集中项目的物理设计部分章节内容，给大家一个总体感觉： 物理设计需求分析和设计原则 物理设计需求分析 物理设计基本原则 物理设计主要内容 数据库实例初始化参数设计 表设计基本建议 索引设计基本建议 数据库块选择 数据库字符集选择 控制文件规划 日志文件设计 表空间方案设计 10g/11g若干新特性使用建议 现有系统表空间设计思路分析 表空间设计基本思路 表空间详细设计建议 表空间设计总结 分区方案设计 Oracle分区表技术简介 Oracle 11g分区新特性简介 分区方案基本原则和方法 现有系统分区方案分析 分区方案与RAC实施 卡户及折户分区方案设计…