Maclean’s Oracle Database Tech Blog Archives

今天一客户老总，对运维服务他想得很简单和完美，oracle培训他们的技术人员，然后他们搞定所有的事。所以只想买些培训。 我告诉他（1）是否买了培训，他的人就行了，能做他期望做的事？（2）人的培养需要时间，成长起来前他的系统考谁维护？ （3）人真的培养成专家了，他是否留得住？ 这几个问题把客户拉回到现实里. 管理者还是要想明白什么事让谁做，追求的是结果，把系统管好。这是管理，不是技术。

刚看到一个微博如下，不知道客户是谁，作者是谁，看了还是有不少感想。数据丟了还在找第三方小公司或所谓牛人做数据恢复？为何不找原厂？   微博原文如下： “ #数据安全警示录# 今早，我艰难的告诉一个用户，他们的数据无法完全恢复。客户在硬盘出现故障后插拔硬盘加载Raid同步，进而导致数据文件出现大量坏块，归档日志损坏错乱，虽然修复了SYSTEM表空间，打开了数据库，但是坏块严重损坏了一致性。这是一个灾难！建议大家遇到类似情况，避免草率的恢复尝试！” 我的感想   出故障时要请专家操作，否则处理不好，小错成大错，数据丢失了造成的损失相比服务费就贵多了，而且不同的人做服务，结果也会不一样。用户应该明白什么事该谁做，这是管理的艺术。 想起最近几个客户也有数据丢失的案例，（1）保护好现场立即联系我们的，我们几个小时内把库正常打开，数据无丢失 （2）现场没保护好的，自己处理搞不定才找我们的，我们尽可能回复到最大值，同时和客户应用业务部门协同工作，把数据补全。 相信这些客户在结案时应该觉得买原厂服务是正确的。

This note describes how to remotely boot an Exadata system from the rescue disk. SOLUTION 1. Find the rescue disk image on a still functioning node (or download from note) # locate diag.iso /opt/oracle.cellos/diag.iso Download it to your local machine. 2. Login to the gui ilom https://<hostname-of-ilom>/ or https://<ip-address-of-ilom>/ 3. Set Next Boot Device to CDROM…

I lost an entire VG in a similar way last week, this is how I recovered it. I called IBM support, their answer was to restore from tape backup (which I didn’t have), but they did point me to the readvgda command (see below). The LVM redbook vol. 2 did the rest. As always, *use…

ORACLEデータベースを正常にオープンできない場合やマウントできない場合、データベースが損傷した場合等にオラクルデータベースファイル(～.dbf)を直接読み込むことによって、ファイルから有効なデータを抽出するツールです。 Oracleデータベース救済-リカバリ-運用とメンテナンス-オプティマイザサビースは詩檀ソフトに訪ねてください。 にいる方は：+86  13764045638 Oracle DULはOracle社内部的なデータベースリカバリツールであり、オランダのOracle Support，Bernard van Duijnenによって、開發された。 DULはOracle会社の製品じゃない。 DULはOracle会社に支持されていない DULはOracle Supportアフタサービス部門の技術者にしか使えない。 DULは海外で使用するのがOracle会社の許可が必要、まずはOracleの基本的なサービスを購入してから許可が得られる。さもなければ、許可が得られないでしょう。 DULは厳密にコントロールされている原因はOracle一部のソースコードを採用したからである。 おおよそDUL 9から、Bernard van Duijnenは外の人がDULを使うことを避けたいという理由で、DULにソフトウェアタイムロックを追加した。つまり、彼は定期的に異なったプラットフォームのDULをプログラミングして、（DULはＣ言語に基づく）、そしてORACLE内部的なDUL workspaceにアップロードして(stbeehiveのスペースに基づく)、Oracle Supportは内部的なVPNによってダウンロードできる。例えば、bernard.van.duijnenは10月1日であるバーションをリリースした、時間ロックは30日なら、このバーションは11月1日に使えなくなった。DULは簡単なOSを読み取る時間じゃないから、OS時間を変更するのも役に立たない。Oracleのdatafileも現在の時間も記録したから、DULはdatafileの時間を読み取っているので、とても変更できない。   bernard.van.duijnenはHP-UXプラットフォームのDULを提供していないので、HP-UXプラットフォームに該当するバーションもない。 そして、ある古いバーションのOracle DULは10g、11g、12cでいま使えなくなったDULの使用はアメリカに限定されているが、中国ではそれほどじゃないが、一般的にDULを利用しているのはAdvanced Customer Servicesしかいないでしょう。それに現場サポートサビースを買うには大量な資金が必要としている。 この説明書の添付ファイルはOracle ACSが提供したDULサビースを紹介するフィルタである（現場技術サポートを買うのは高くて、そしてユーザーが毎年もPS基本的なサビースを買っている必要としているので、さもなければACSアドバンスサビースも買えなくなる。   DUL – DATA RECOVERY UNLOADER DataSheet https://www.askmac.cn/wp-content/uploads/2014/01/DUL.pdf DUL 10の取扱説明書英語バーション DUL User’s and Configuration Guide V10.2.4.27 https://www.askmac.cn/wp-content/uploads/2014/01/DUL-Users-and-Configuration-Guide-V10.2.4.27.pdf 以下はDUL 10のダウンロードリンクで、ロックされたから、ある時間をたつと使えなくなる。 DUL FOR LINUXプラットフォーム(PRM-DULにアップデートした) DUL FOR Windowsプラットフォーム (PRM-DULにアップデートした)  …

由于某种原因，现在大家都在谈去IOE,转发了两个典型客户（阿里和移动）的体会，上周也拜访了他们，交流中谈谈我自己的体会。这两个客户都有非常强的Oracle技术团队，对Oracle技术的适用性有很强的了解。阿里是互联网企业，从头到尾都自己来，因为他们有庞大的技术团队，和允许犯错的宽松环境（如某热门产品系统故障，上午半天不可用，技术负责人晚上依然出来朋友聚会，社会上也没啥反响，如果发生在移动或银行，社会反响和个人压力则无法想象），而浙江移动是企业客户，在成熟产品上发挥自己强项，在实践中创新，和厂商深度合作，将产品用到极致，为其所用。有几个客户敢在一年里把200多套生产库切到容灾中心里去运行？他们做到了。   是否去IOE,关键是客户得了解自己要什么，选择适合自己的才是正确的。想想为什么要去IOE,是因为成本、安全、技术瓶颈、商务和厂商合作、或别的原因？   IOE不是洪水猛兽，有机会去IOE,说明他们曾经是你们的选择，选择的理由应该还记忆犹新。如企业的技术成熟、稳定、高可用性、高服务性等。     先谈阿里巴巴，起初网站清一色SUN服务器，copy 美国.com的架构，淘宝的原型是在SARS封闭阶段几个工程师用PHP编的，在正式商用前决定使用J2EE架构和IOE，当初淘宝没有java技术储备而决定外购，我有幸代表Sun应得该项目，也是阿里第一次外购原厂服务，项目期间马云还常来项目组巡视，项目团队的高超技术和规范的方法论使得他们非常满意，不仅项目成功，后续我们帮助阿里建立其技术团队，从当初的上百人到如今的上万人，业务也复杂无比和阿里云等因素，决定去IOE,近5年的IOE历程，今天IE已去完，还在攻坚少数还活着的O.  O的替代是开源的mySQL（大部分）和自主开发的ocean base(小部分），从单个产品做比较，阿里认为没法和O比，主要是不稳定和单库能力，但是这些缺点有他们自主开发的架构所弥补，整体而言还是好的。另外开源的服务性由阿里的技术团队承担，他们掌握源代码，能开发补丁和新功能。       再谈谈移动，集团几年前不建议新项目新购Oracle,可以说去O想法和阿里差不多，但如今核心系统基本还是O. 在使用过程中受益颇多。浙江移动是我们的旗舰客户，他们勇于创新，跟踪O新技术，吃透了就敢用，他们在大规模地使用11g时已在计划使用12C. 也没觉得O那么贵。 对想去IOE的客户，得想想下面的问题？ 1，为什么要去IOE? 千万别盲目跟风 2,替代品的优缺点和适用性分析，是否能替代？ 3，是否有技术储备？ 4，谁来做服务，自己或厂商？ 自己没能力，就别用开源。IOE服务体系是可信赖的。有个客户用JBOSS开源软件，现遇到技术问题痛苦不堪，没有保障。       移动客户去IOE体会，：去ioe的主要驱动是打破传统架构在可扩展性和业务连续性等方面的瓶颈，加强自主技术掌控，实现业务需求，而不是成本。开源技术门槛很高，风险很大，购买成本低但是维持和发展成本极高，这一点很多人有意无意都在无视！个人以为移动需要创新可从去ie开始，去o需慎重，当然真要搞老子不怕！ 个人以为移动高层视o记为洪水猛兽的观念是值得商榷的。产品招标替换方式增强局方话语权的做法不是万能的，适合于各厂家产品品质差异不大的场合，而o记是一个怪胎，产品技术优势(开放性，生态环境，综合性能，综合功能)过于明显，应采用自主学习自主掌控方式来实现局方的目标，用的好并不贵，性价比远超其他产品。   记住，什么垄断，那只是由于“弱国无外交”。你自己实力不行才被o记垄断，自己掌握了不存在什么o记垄断！当然，如何在运营商这种环境下维持发展自主技术团队很难，是另外一个话题，但我认为事在人为！    

最近有个大型客户，Oracle DB和IBM DB2都经历了相似的故障，IBM DB2故障后不能重新打开，库中数据丢失，需要从别的来源倒入，历时很多天； Oracle则在原厂顶级高手的努力下，几个小时就把库打开，避免数据丢失。产品和服务缺一不可，很多高难度问题，尤其不公开的诀窍，只有原厂懂。 通过这个PK, 再次证明选择的重要性。尽管一些企业目前热衷于去IOE,  但请想仔细想想自己是否适合。 俗话说“好马配好鞍”，如果你的业务真那么关键和重要，费用也能承受的情况下，建议还是选择oracle及其原厂服务。关键时候绝对给力，为你成功保驾护航！ 感谢现场工程师的给力表现和客户的选择！致敬！！！

SQL优化课程:     了解 Oracle DB 体系结构 SQL 优化简介 优化程序简介 优化程序运算符 解释执行计划 案例分析：星形转换 优化程序统计信息 使用绑定变量 使用优化程序提示 HINT 应用程序跟踪 自动 SQL 优化   AWR性能报告分析课程：   AWR体系介绍 AWR必要技巧 AWR案例精讲1，等待事件、DB TIME、AAS指标分析 AWR案例精讲2，RAC特定的AWR环节 AWR主要指标解析   10g/11g优化课程：   优化体系介绍 基础调优诊断步骤 使用AWR性能报告 如何定义问题 度量和警告 使用SQL基线 使用基于AWR的工具 监控应用程序 找出问题TOP SQL 分析优化器影响 如何减少成本 使用SQL Performance Analyzer SQL性能管理 使用Database Replay 调优共享池 调优buffer cache 调优PGA和临时空间…

看到一位客户老总关于服务的感悟。深有同感，有些服务是活的，解决同样的问题，不同水平的工程师处理效率是有差异的。客户追求的应该是适合自己的服务，而不是最便宜的服务。个人看病也一样，普通门诊、专家门诊、急诊、特色门诊、VIP门诊等都有不同的适用群体。   昨天一客户进行“服务招标”，一些没和客户做过生意的代理商为了抢单，都纷纷勇敢地跳价，想赢单后再降低成本而盈利。只有原服务商很艰难地没跳，他知道客户对服务的要求和原厂服务的成本，他降价的前提是偷梁换柱，原厂服务由他代做，这个客户和厂家也不允许的情况下，所以尽管他知道跳价后他能赢，但他不想亏本做，做生意要有利润是公司经营的底线，结果价格最高，排名靠后。而排在第一、跳价最多的代理在客户前说公司愿投入亏钱做，而在厂家面前一厢情愿要折扣，说不能亏本做，如是诚信的商家，应该履行承诺，否则损人不利己。   希望圈中做决策的老总们，购买服务时多考虑买服务的目标（如保障安全生产，系统稳定等，或上线一个项目，支持业务发展等），在预算范围内尽量买最好的服务，相信一分钱一分货。   发生故障时谁都想最有本事的人帮你，购买时也要记住这点。   客户老总的原帖：   “又到预算时间，转给财务部和采购部的同志看一看！控制成本也要讲策略。   如果一件东西值一块钱，砍到九毛九，东西不会变，得到的还是那东西，要砍；如果一个人的服务值一块钱，砍到九毛九，虽成交了，得到的服务却可能变了，降低了，不能砍，要主动给他一快一，就能得到超值回报。人们常说的“对人一块一，对物九毛九”，所以工资奖金有关的成本千万不能砍!砍了以后真正吃亏的是我们移动自己！”

12c中提出了In-Memory Option，虽然在12.1.0.1中还未引入该特性，12c in-memory database cache的灵魂是 in memory in compressed columnar 简称IMCC ，在数据库中所有启用了IMCC 的表 将被加载在 in-memory snapshot store. 中。这个 in-memory snapshot store要通过 transaction journal 来更新。   该In-Memory Option特性致力于使用内存中的列存处理来实现以下4个主要目标： 显著增快SQL的全表扫描处理速度， 全表扫描将增快10~100倍，基于CPU的最大数据处理速度，对于简单扫描可以每秒扫描10亿行数据；  对于简单的连接过滤谓词最终选出少量数据行的达到每秒1亿条每秒。 与今日ORACLE数据库中对于内存在的大表访问最多处理2000万行每秒对比，将有巨大的进步。对于长向量CPU处理和压缩 积极使用有效内存 显著增快复杂SQL的处理，在绝大多数场景中连接处理将变快10倍或者更多。聚集，排序，分组也将随之变快。 积极使用内存、物化的连接键合以及压缩将使用in-memory算法大大得益，比之将临时数据溢出到磁盘的效益多出不可以道里计。 显著增快事务处理，DML操作-单行DML和批量DML都将运行地更快； 单行的处理收益主要来源于降低10倍的索引维护。 100%的应用程序透明。类似于OLTP压缩，主要的优势在于对于应用而言完全透明。所有的其他ORACLE特性均将可以与in-memory option一起工作，包括partitioning, indexes, text indexes，而没有明确的数据类型或者存储类型限制。   in-memory columnar & compression简称 (IMCC)项目， 会在ORACLE数据库内核中修改指定的层面来提供增强的性能，并保持数据库组件的接口不变； ORACLE在开发这一重量级特性的时候，反复强调该特性要与其他每一个数据库特性互通，类似于当初设计Exadata Hybrid Columnar Compression混合列压缩项目时的原则， 虽然IMCC的影响会更深，它会深植于SQL处理的关键区域。   IMCC项目包含了一个新的 数据引擎(就像MYSQL那样 ，ORACLE开始给自己添加引擎了) ，即IN-MEMORY…