Author: mac

  本文永久地址： https://www.askmac.cn/archives/实践oracle-性能调优-从诊断到解决.html 前言 本资料中，包含oracle数据库的系统中产生性能问题时，将对调查原因到完成调优为止，进行指导。 本资料面向对数据库具有基相关知识的人士。 因此，发生性能问题时的对策，仅仅讲解确认数据库是否有性能问题的方法，最多讲解处理性能问题的1个方法，但这也不是绝对的 请作为系统发生性能问题时的参考资料来灵活使用 发生了系统性能问题   解决的顺序 为了解决问题，需要处理与考虑方法 指定出现性能问题的地方 执行调优 确认DB的性能问题 获得DB内部的统计信息，确认其是否发生了性能问题 DB内部的统计信息是指 性能统计信息（ex. 资源使用情况以及发生待机的信息） 执行各SQL时的详细信息 ＜方法＞ Statspack（8i~） AWR报告（10g~） ※Enterprise Edition中需要Diagnostic Pack选项 SQL 追踪（主要在测试环境中使用）   ＜参考＞其他的推荐事先获得的信息 OS统计信息 　　－CPU统计信息 －磁盘统计信息 －内存统计信息 －网络统计信息 －运行进程统计信息 OS中的统计信息因为含有包含oracle以外的部分的服务器整体的资源信息 所以即使原因可能出在DB中，也可以获得 在分析之前需要了解Statspack是什么 在使用DB内部的统计信息进行分析之前，先需要获得统计信息 理解各个方法的概要 ＜方法＞ Statspack（8i~） AWR报告（10g~） ※Enterprise Edition中需要Diagnostic Pack选项 SQL追踪（主要在测试环境中使用）   Statspack（Statistics Package） Statspack 的意思是 从Oracle 8i 安装的oracle标准的性能分析工具…

利用OGG GoldenGate迅速同步系统之间的数据  

 了解 Oracle Mutex   虽然Mutex中文翻译为互斥锁，但为了和OS mutex充分的区别，所以我们在本文里称Oracle Mutex为Mutex。   Oracle中的mutex，类似于Latch，是一种低级的串行机制，用以控制对SGA中部分共享数据结构的访问控制。  Oracle中的串行机制有不少，引入它们的目的是避免一个对象出现下述现象： 当某些进程在访问该对象时，该资源被重新分配 当某些进程在修改它时，被其他进程读取 当某些进程在修改它时，被其他进程修改 当某些进程在读取它时，被其他进程修改   不同于Latch，Mutex的使用更灵活，用途更多，例如: 哪些需要被mutex保护的共享数据结构可以有自己独立的mutex，即一个对象拥有自己独立的mutex，不像Latch往往一个需要保护大量对象，举例来说，每一个父游标有其对应的mutex， 而每一个子游标也有其对应的mutex 每一个数据结构可能有一个或多个mutex保护，每一个mutex负责保护其结构的不同部分 当然一个mutex也可以用来保护多于一个的数据结构   理论上mutex即可以存放在其保护的结构本身中(其实是嵌入在结构里)，也可以存放在其他地方。 一般情况下Mutex是在数据结构需要被保护时动态创建出来的。 如是嵌在需要保护结构体内的mutex，则当 所依附的数据结构被清理时 该mutex也将被摧毁。     Mutex带来的好处 虽然mutex和latch都是Oracle中的串行机制，但是mutex具有一些latch没有的好处   更轻量级且更快 Mutex作为Latch的替代品，具有更快速获得，更小等优势。 获取一个mutex进需要大约30~35个指令， 而Latch则需要150~200个指令。一个mutex结构的大小大约为16 bytes，而在10.2版本中一个latch需要112个bytes，在更早的版本中是200个bytes。 从200个bytes 精简到112个是通过减少不必要的统计指标 SLEEP1~SLEEP11、WAITERS_WOKEN, WAITS_HOLDING_LATCH等从而实现的。今后我们将看到更多关于Latch的代码优化。   减少伪争用 典型情况下一个Latch保护多个对象。 当一个Latch保护多个热对象时，并行地对这些对象的频繁访问让latch本身变成性能的串行点。 这也就是我们此处说的伪争用点， 因为争用是发生在这个串行保护的机制上，而不是进程去访问的对象本身。与latch不同， 使用mutex的情况下Oracle开发人员可以为每一个要保护的数据结构创建一个独立的mutex。 这意味着Latch的那种伪争用将大大减少，因为每一个对象均被自己独立拥有的mutex保护      Mutex在一些地方替代了latch和PIN   一个Mutex可供多个Oracle进程并行地参考，反过来说进程们可以以S(Shared 共享) mode模式参考一个Mutex。以S mode一起共享参考这个mutex的进程的总数成为参考总数reference…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     适用于： Oracle Database – Enterprise Edition – 版本 8.1.5.0到 12.1.0.2 [Release 8.1.5 到 12.1] 本文信息适用于任何平台。 ***于24-Aug-2015检查相关性*** 目的 本文叙述了如何使用RMAN从DROP/TRUNCATE/DELETE或需要恢复的其他类型的数据操作失误恢复。 在Oracle10g 及以上版本，如果回收站未被显式禁用，你可以用它来恢复 DROP 表。参见： Note 265254.1 Flashback Table feature in Oracle Database 10g 如果回收站被禁用或数据库在运行Oracle9i，还有一些可选的操作： 使用RMAN duplicate创建一个数据库的子集，作为drop之前时间点的克隆。辅助数据库可以是一个表空间的子集，所以只有必要的表空间被还原并恢复。一旦RMAN创建了克隆并打开了数据库，可以从辅助数据库导出表并再导入生产。这是恢复表（或数据）建议的方法，因为这对数据库中其他对象的影响很小。 2. 还原并恢复主数据库到drop之前的时间点。这种方法对于一个表来说较极端，因为整个数据库的数据都回到该时点。 3. 还原并恢复表空间到drop之前的时间点。这是较好的选择，但同样会将要整个表空间的数据恢复到过去。这是标准的表空间时间点恢复（TSPITR），将需要一个辅助数据库，但会使表空间的所有数据在目标数据库中回到该时间点。 参见 Note 109979.1了解详情。 如果出于某种原因，你无法使用RMAN duplicate，还有第四个选项： 4. Restore and recover…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     ORA-01171 oerr ora 1171 01171, 00000, “datafile %s going offline due to error advancing checkpoint” // *Cause: The checkpoint in the file header could not be advanced. See // accompanying errors for the reason. The datafile will be taken // offline the same as for a…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     ORA-01180 oerr ora 1180 01180, 00000, “can not create datafile 1” // *Cause: Attempting to create datafile 1 using ALTER DATABASE CREATE // DATAFILE. // *Action: Recover file from a backup or recreate database. oerr rman 3002 3002, 1, “failure of %s command at %s” //…

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] ORA-01180 oerr ora 1180 01180, 00000, “can not create datafile 1” // *Cause: Attempting to create datafile 1 using ALTER DATABASE CREATE // DATAFILE. // *Action: Recover file from a backup or recreate database. 适用于： Oracle Database – Enterprise Edition – 版本9.2.0.1 及以上 本文信息适用于任何平台。 ***于16-Apr-2014检查相关性*** 症状 RMAN…

2014年初本人正在南方出差，某天晚上从南京坐高铁到了杭州。刚过午夜12点，正准备关灯就寝之际，突然响起了急促的手机铃声。多年从事Oracle服务工作的我们都有“天不怕、地不怕，就怕半夜来电话”的共同感受，果不其然，南京某政府客户数据库出问题了：大规模数据文件损坏！ 客户的运维科长电话中心急火燎地希望我马上能回到南京，赶赴现场。但深更半夜的，高铁早没有了，怎么办？更重要的问题是，该客户还没有采购Oracle现场高级客户服务（ACS），按照Oracle公司政策，这种情况下，我们是不能赴客户现场做具体服务工作的。即便采购了ACS服务，作为解决方案售前顾问，我也不能随便去现场做这种实施工程师的事情。这就是大公司：条条框框很多。 但该客户正处于申请预算走流程，准备采购ACS服务的关键时期。于是，为安抚客户、保证客户满意度，我与销售同事商量决定采取折中方法：一方面我在远程提供电话技术支持，另一方面他去负责协调资源，看看能否特事特办，尽快申请到工程师资源赶到现场。 我这边马上通过科长手机与开发公司的DBA进行沟通，大致了解到问题原因和现象：原来他们在晚上欲对数据库表空间进行扩展，通过IBM HACMP软件对LV操作时出问题了，不仅损坏了LV，甚至第二个节点的VG都看不见了！我很快了解到以下Oracle的报错信息：ORA-00376和ORA-1110。其实这类错误比较普遍，处理过程并不复杂，本书“第十一章 那些常见的Oracle错误”就有相关错误的处理。我也很快在Metalink中找到了该类错误的若干篇官方处理文档。例如：《Resolving ORA-00376 Error Encountered in database (Doc ID 1339985.1)》，其中最主要的步骤就是两步： SQL>recover datafile <数据文件名>; SQL>Alter database datafile <数据文件名> online; 于是，DBA与我分析了错误现象和处理办法之后，DBA就准备对几十个数据文件进行恢复（recover）操作了。 将近2：00还没有客户反馈信息，我自己也因为一路旅途疲劳而睡过去了。是啊，毕竟是奔五的人了，精力远不如当年了。 临门一脚的遗憾 第二天早晨9：00醒来，放心不下的我急忙想给客户去电话，突然发现自己没有DBA的电话，也想到也许客户加班一通宵正在补觉呢。直至中午时分，我才拨通客户运维科长的电话，科长很高兴问题得到解决了！并感激说是某某第三方运维公司救了他们的命！怎么回事？待我要来DBA电话，才得知的确是第三方运维公司的人帮他们解决了问题。如何解决的呢？就是上述提到的两条关键命令！为什么DBA自己不做？原来他还是信心不足，也担心责任，希望有高手来操作。于是，他们通过多种管道，找到了一个第三方运维公司的人，并通过VPN连接到他们的系统，成功地在3：00实施了上述恢复操作。 唉，我和客户DBA从后场开始带球，运过中场，DBA带球至门前，结果关键时刻他犹豫了，要找个外援进场，外援按我们设计的角度和射门方式，轻松一脚，球就进了！于是，所有的镜头和光环都对准了这位外援。而DBA和我都被埋没了。呵呵。 更多的故事和反思 首先，我自己需要深刻反思：原以为已经有Oracle官方文档为依据，DBA该大胆操作了，可惜我当时在电话里没有把这个信心充分传递给DBA。另外，我怎么没有感觉到DBA信心不足，从而主动提VPN连接到他们系统，亲自进行操作呢？说明还是我自己主动性不够，导致现在上述局面。 其实，已经快知天命的人了，当然不会患得患失。更大的遗憾是通过此次故障的处理，客户对Oracle公司非常失望，其它公司都派人去现场了，唯独Oracle受限于公司政策，销售、技术一个人都没去现场。尽管我在远程提供了一定的支持，但客户领导并不充分知晓。 事后，更得知客户之所以找到第三方公司的人，是因为Oracle公司另一个服务部门一位已经离职的的销售牵线搭桥的结果。而由于Oracle内部竞争等因素，该销售并没有在客户面前对我们ACS团队美言，反而起到了负面的效果。唉。内部倾扎啊。 再者，尽管Oracle政策比较僵化，尽管国内客户不能从感情上理解Oracle这种一板一眼的行事风格，也幸亏当天的故障并不难解决，但假设当天的故障是某个很难解决的问题，例如Oracle Bug呢？还是说明针对重大的生产系统，客户应该采购Oracle高级运维服务包，有了这种服务包，Oracle完全可以按正常流程和渠道进行操作：我们会第一时间通过电话、远程登录等方式进行处理，同时也将第一时间派出工程师赶赴现场，而且会不计成本地帮助客户解决问题，恢复生产，甚至会找出问题根源，防止问题的再次爆发。—- 这就是Oracle高级服务包的价值。 这个案例也是典型的先有鸡，还是先有蛋的问题，呵呵。Oracle的心态是：出了这么重大的问题，赶紧采购Oracle高级服务包吧。客户的心态是：我出了这么重大的问题，你Oracle都不管不顾，以后买了你们Oracle高级服务包，能尽心尽力为我服务吗？服务也要讲感情的。 的确如此，服务是人去实施的，人与人交往是要讲感情的。为弥补此次故障处理的不足，我们已决意在遵循Oracle政策的前提下，去做进一步的工作了。例如，告诉客户ORA-00376故障的官方处理流程；帮助客户梳理未来故障处理流程；给客户建议一定要解决此次故障的真正原因：HACMP软件的Bug和Patch问题；加强数据库后台运维管理规范，避免在联机操作情况下进行数据库文件的扩容操作（这次故障的另一个诱因）… … 亡羊补牢，为时未晚。重树客户对Oracle原厂服务的信心！这种信心不仅是对Oracle技术实力，还有服务态度、服务深度和服务质量。 最后，还需要强调Oracle多种服务的综合效益。那天晚上针对这么重大的问题，客户其实应该通过Oracle标准服务（PS）在metalink上提出1级SR，这样，第一时间Oracle后台GCS团队就会积极响应，如果客户再采购了ACS现场服务，GCS与ACS配合，将起到更好的效果，问题处理时间也将大大降低。

SQL Translation Framework SQL 翻译框架是12cR1中跨RDBMS SQL标准的特性， 具体详见如下文档： [gview file=”https://www.askmac.cn/wp-content/uploads/2013/08/SQL-Translation-OBE.pdf”]

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   ORA-01177 oerr ora 1177 01177, 00000, “data file does not match dictionary – probably old incarnation” // *Cause: When comparing the control file with the data dictionary after // a CREATE CONTROLFILE or OPEN RESETLOGS, it was noted that this // datafile was inconsistent with the dictionary.…