oracle fast split partition

当拆分一个(partition)分区为两个分区时,其中一个分区为空,另一个非空分区保持了与原来分区相同的存储属性时,因为未产生数据移动,只通过内部切换data_object_id的内部调用,同时保证原来的Global 和 partition 索引一直处于USABLE(可用)状态,该特性叫做fast split partition. 这是9.2开始的老特性,IOT类型是从10.2 开始支持。

How to diag redo/archive log generation growth?(降低redo生成量)

redo中记录所有数据库的变化,包括所有数据文件上的变化,但不包含控制文件和参数文件的变化。redo最初记录在online redo logfile中,如果是归档模式会在填充满后生成离线的归档日志文件,有时会发现归档量突然某一天突增了需要查询原因, 更有甚者把降低redo生产量做为优化的目标。这里记录一些分析归档生成和分析变化的思路。

library cache lock或row cache lock, Failed Logon Delay 因为错误的密码尝试

数据库为了防止频繁的错误密码登录或暴力破解,如果user profile中配置了无限次失败而不lock用户,或当修改了应用用户的数据库密码,有遗漏的应用程序配置未及时更新,就会因密码错误而导致性能问题,Oracle 11g引入了密码延迟验证的新特性, 想法虽好但也成了问题特性。 错误的密码尝试在不同的版本中,对数据库带来的性能问题等待事件可能不同, Oracle 10g R2, 11g R1 等待事件的是row cache lock, 11g R2等待事件library cache lock, 12C是的等待事件Failed Logon Delay。

Oracle 19c RAC 频繁重启 OS log show “avahi-daemon : Withdrawing address record”

总会有一些创新型的客户走在技术的最前端,但有些问题无参考这是最担忧的问题,最近就一个非常新的环境ORACLE 19C 2-nodes RAC on IBM LinuxONE大机,同一大机部分节点上oracle实例频繁重启,重启前OS日志中有输出“avahi-daemon[4537]: Withdrawing address record for 28.83.70.4 on bond0.3112”…

细说“Error: cannot fetch last explain plan from PLAN_TABLE”

前几日有位小兄弟问为什么有时使用explain plan for ….., 然后用dbms_xplan.display查看执行计划, 有时会提示“Error: cannot fetch last explain plan from PLAN_TABLE” 错误? 其实这个问题在Oracle 12c 以后应该基本不存在,因为这是explain plan一种悄悄的行为变化

DUL 支持Oracle 19c , 如何手动处理延迟段创建的表

oracle dul是oracle的恢复利器, 它的传奇功能不再解释,但是dul和其它工具一样也是需要段块信息恢复数据,但是从oracle 11g开始支持了延迟段创建,那么使用dul unload table, unload user默认是不会导出未生成段的表对象, 这样恢复的数据理论也会因为表不存在而丢失部分空表。但是表结构是在数据字典中可以手动生成建表语句。

Oracle Dataguard New Features 历程 10g-19c

Oracle DataGuard已从最初只是做为一种容灾功能,到后期分担Primary SITE的负载,实现读写分离,在实时性,可用性,灵活性,分析诊断、功能种类引入了大量的特性,逐渐已成本了一个oracle生产环境标配, 这篇简单记录从10.1 到19c dataguard的主要新特性。

Troubleshooting ORA-00979: not a GROUP BY expression after upgrade Oracle 12C

数据库版本升级都会强烈建议功能和性能测试,但有时还是不具备这样的条件或未测试全面, 对于版本上线后的问题再见招拆招。最近遇到了一个11.2.0.3 升级 12.2 后有个存储过程无法执行,提示“ORA-00979: not a GROUP BY expression” 错误…

2019数据嘉年华,我和我经历的《真实世界Oracle故障诊断之一千零一夜》

主会场的爱好者们,座无虚席。 我的分享 我一共参加过2届嘉年华,上次是观众,这次是观众+分享者。 每次我都是以学习的心态参于, 收获满满,看看别人在做什么?这个行业在做什么?未来的方向在哪里?  这时代背景下分享Oracle多少有悲凉,“未能绽放就要枯萎吗?”。 但是看到Oracle专场还是不缺观众,很欣慰, 因为你不学oracle 确实什么错过很多其它库远远追不上的技术。 下面开始我的分享,没有经验时间,准备太多,时间太短。 今天很高兴来到这里, 我是张维照,“运维”的“维”,(~o_o~)。从事Oracle DBA一线工作十年有余, Oracle ACE-A,工作之余会在我的Blog(anbob.com)分享一些日常维护工作中遇到的有意思的案例和学习成果。开始为了督促自己进步,利用google搜索自己文档方便,后来就这么坚持至今, 可能世界上所有的坚持都是因为热爱。 身处在知识大爆炸的时代,获取知识的途径更加廉价和丰富, 数据库类型更是“百花齐放”,“万象更新”,开源、国产、云数据库开始崛起。首先,开源不是免费午餐,更不能只关注开源本身,重要的是开放的生态不能选择进入技术堡垒。再者,正如本次大会主会场行业大咖们所说, 如果国产库总是“慢一步”,那是不会有未来的。也希望国产数据库的崛起, 性能不是数据库的全部,稳定与安全同样应该放在首位。 最后,我想提一点,不能上了某云就无法换云,选择国产也不应该是重走长征路。于我个人而言,我也关注学习其它几个数据库,我喜欢所有数据库,但是发现Oracle依旧是我“初恋“。   ”一千零一夜“系列故事集可能是家中有小孩子床头必备书,刚开始接到分享任务时,我不确认要分享什么。我突然想到,几年前做好的电子书整理,但一直没有分享, 这次我希望把我分析故障的案例中一部分经验分享出来, 望大家在做相同操作起到一点预防或运维规范参考作用。非一线城市的客户在最佳实践、规范化方面还是相对较弱,我希望今天的分享能让他们多一些预防,少一些救火。Oracle技术是个知识的海洋,我只能分享点滴,诊断故障是一种能力,避免故障同样也是能力。 … 2019DTC ,我分享的《真实世界: ORACLE故障诊断一千零一夜》PPT 下载链接 : 链接:https://pan.baidu.com/s/1nf6mk74s1CeYTAae4lin5A 提取码:fo5o

多存储设备时Oracle RAC voting disk(表决盘)的最大可用

前几天银行客户问了一个问题,如果他们目前有两套存储,如何规划ASM diskgroup冗余度防止单存储坏时影响RAC的可用性, 常见于Extend RAC, 实现数据中心、电、网络、存储、服务器等等全部冗余。但是对于ASM DISKGROUP 可以使用redundancy normal(2-ways mirroring)允许坏1个failgroup. 甚至high redundancy(3-ways mirroring),允许坏2个failgroup. 都有可能存在坏1个存储而RAC不可用。对于Voteing disk有些特殊,redundancy normal 3个voting disk. high redundancy 5个voting disk。

Troubleshooting Slower IO Performance on Veritas for 11.2.0.4 compared 10gR2 on RAW device after RMAN migrate

一个数据库相同的存储从原来的oracle 10.2.0.4 使用RAW device,升级到oracle 11.2.0.4 同时使用Veritas 卷Vxfs 文件系统的RAC ,因为也使用了ODM(Oracle Disk Manager), 理论上也是一种变象的RAW device, 支持异常IO,避免双重buffer. 用户最直观的感受是在RMAN 备份集做的迁移后,数据库性能比之前慢的很多倍,