Oracle 各种删除操作对空间返还的说明
DBA们常常遇到这样的困惑：对Oracle表执行DELETE、DROP还是TRUNCATE？这些操作对空间到底有何影响？这篇技术说明正是为厘清这些差异而写。 文章将三种常见删除操作（DELETE SQL、DROP TABLE、TRUNCATE TABLE）放在一起对比，从多个维度拆解其不同。关键差异点包括：DELETE操作不会将空间归还给表空间或文件系统，空间仅能被原表重用，但可能产生“高水位”；而DROP和TRUNCATE默认都会释放表空间，但依然不会自动收缩数据文件。此外，在本地管理表空间下，这些操作基本不会造成表空间碎片，但在老旧的字典管理表空间中，DROP和TRUNCATE则可能导致碎片。 对于追求“干净”释放空间的场景，文章也给出了务实建议：例如使用`shrink space`整理表，或对索引执行`coalesce`。最终目的是帮助DBA们根据实际需求（是彻底删除、快速清空还是谨慎释放）选择合适的操作，并管理好预期——Oracle默认不会自动将空间返还给操作系统。
按照重要程度划分数据库级别
这篇讲的是一个为数据库重要性分级的实用框架。作者没有空谈理论，而是直接给出了从S级到D级的清晰划分，并为每个级别匹配了具体的业务场景、潜在影响范围以及相应的灾难恢复成本。 比如，一个仅影响几十人的测试系统（D级）与像12306这样的大型公共应用（S级），在业务类型、灾难救援价格（从几千元到50万元以上）以及需要的备份与灾备设施（从“几乎无任何有效备份”到“全冗余部署”）上，有着天壤之别。 这套体系的价值在于，它让技术团队能清晰地评估和沟通数据库资产的业务价值，并据此决定投入多少资源来保障其数据安全与业务连续性。文章用一个简洁的表格呈现了这种对应关系，对于需要制定数据保护策略的团队来说，这是一个非常直观的决策参考。
Oracle 11g大对象数据新技术
这篇内容专门针对 Oracle 数据库中令人头疼的 ORA-00600 内部错误，提供了一套从定位到解决的系统化诊断手册。它首先点明，这类错误本质上是 Oracle 软件遇到了不一致的低级异常，成因可能涉及 Bug、操作系统或硬件。 文章的核心价值在于其清晰的排查路径：第一步永远是检查 alert.log 和 trace 文件；第二步是利用 Metalink 提供的专用诊断工具，通过输入错误的第一个参数和数据库版本号快速检索知识库；第三步则是整理必要信息，向 Oracle Support 提交 SR。 作者特别强调了 trace 文件的完整性和参数信息的关键作用，并用“ORA-00600 [729]”空间泄漏的实例，演示了如何通过设置特定事件参数来规避这类可忽略的内存泄漏告警。整体而言，文章将复杂的内部错误排查流程，拆解成了可操作的步骤，对 DBA 构建故障处理预案很有参考价值。
那些常见的Oracle错误
这篇讲的是Oracle数据库运维中那些高频出现的“拦路虎”。作者从DBA经常面临的实际故障现场出发，梳理了ORA-00600、内存耗尽、空间不足等几类典型问题。文章不止于罗列现象，而是深入到了问题的“肌理”——比如ORA-00600这类内部错误，其第一个参数和数据库版本就是定位根因的钥匙；ORA-04030则往往与PGA内存分配和操作系统限制有关。 更实用的部分在于诊断思路。文章引导读者从检查alert.log和trace文件入手，还指出了Oracle官方在Metalink上提供的600/7445诊断工具这个利器。针对具体案例，如ORA-00600[729]“UGA空间泄露”，给出了设置事件参数“10262”来屏蔽小泄露的明确解决方案。这种“故障现象-诊断方法-官方工具-具体参数”的完整链条，为运维人员构建了一套可复用的排查预案，能有效降低面对突发故障时的手足无措感。
Oracle中的Low HWM与 High HWM 高水位
这篇讲的是Oracle数据库在ASSM存储管理下，如何通过引入Low HWM和High HWM两个高水位标记来优化存储空间利用与并发性能。作者从传统MSSM模式下单一高水位标记的局限性切入，指出了其可能引发的锁竞争与IO性能问题。 文章核心聚焦于ASSM的解决方案：通过两个高水位将数据块区域划分为已格式化（Low HWM以下）、未格式化但可能被重用（Low HWM与High HWM之间）以及完全未格式化（High HWM以上）三个区域。这种设计精妙之处在于，它允许在HWM以下存在未格式化的“空洞”，从而在直接路径加载数据时，能更灵活地复用空间，避免因频繁提升高水位而导致的锁等待和不必要的格式化IO开销。 作者进一步解释了这一机制的关键细节：只有当当前extent及之前extent中的所有块均被格式化后，Low HWM才会上升；而High HWM的提升则与一级位图块管理的范围相关。在顺序读取时，系统以High HWM为终点，同时忽略其间未格式化的块，保证了查询效率。整篇内容深入到底层实现原理，为理解Oracle复杂的存储管理提供了清晰的视角。
Oracle Database 12c架构图
这篇讲的是Oracle Database 12c的架构全景图。作者提供了两张高清图表，一张完整勾勒了12c的整体架构，清晰地展示了所有关键组件以及它们之间的关系，特别是那些在新版本中引入或调整的后台进程，并简要说明了它们的工作原理。另一张则专门聚焦于12c最引人注目的特性——多租户（Pluggable Database）架构。这张大图详细描绘了容器数据库（CDB）与可插拔数据库（PDB）之间的交互逻辑，将这种能大幅提升资源利用率和管理效率的新模式，以可视化的方式呈现得一目了然。对于需要快速理解Oracle 12c技术演进方向、或正在规划数据库升级的团队来说，这两张图提供了非常直接的架构参考。图文结合的方式，让抽象的数据库内核设计变得直观可感。
深入理解Oracle中的Mutex
这篇讲的是Oracle数据库中两种底层串行机制——Mutex与Latch的深度对比分析。作者从内部机制出发，清晰阐述了Mutex为何以及如何在多个场景下成为更优的选择。 关键差异首先体现在效率上：Mutex获取仅需约30~35个CPU指令，而Latch需要150~200个；其内存结构也仅16字节，远小于Latch的112字节。更重要的是，Mutex的设计能大幅减少伪争用——不同于一个Latch保护多个热点对象，一个Mutex可以专门服务于单个数据结构（如每一个父游标或子游标），使得串行控制点更精准。 文章详细剖析了Mutex如何兼具传统Latch和Pin的双重职责。其内嵌的引用计数（ref count）机制，使其能像Pin一样防止对象被释放，同时自身又提供了必要的串行保护。在10.2版本后，这直接替代了游标执行时频繁创建/销毁library cache pin的昂贵操作，后续进程只需轻量级地增减引用计数即可。作者以KKS游标共享为例，列举了在父游标检查、统计信息访问等操作中，Mutex如何带来更低的解析成本和更好的并发性能。 最后，文章也提供了从AWR报告解读Mutex等待事件（如cursor:mutex S/X, cursor:pin S）的思路，并附上了统计信息表示例，为实际的性能诊断提供了具体指引。
Oracle数据恢复专题
这篇专题文章直击一个国内DBA常面临的痛点：如何在缺少规范备份的严苛条件下，执行Oracle数据库的恢复操作。作者从东西方DBA工作重心的差异切入，坦言“无备份恢复”在国内技术环境中，有时会成为一种被迫练就的“屠龙之技”。 文章并非泛泛而谈，而是系统整理了一系列极具实战价值的案例与脚本。从利用DUL、BBED等底层工具直接抢救数据文件，到通过构造ROWID巧妙绕过ORA-1578等坏块错误；从处理ASM磁盘头丢失这类存储层灾难，到解决PL/SQL对象被覆盖、数据文件名乱码等逻辑故障。每一个链接背后，都是一个需要深入理解数据块结构与数据字典的硬核场景。 对于需要直面数据库“心跳停止”时刻的工程师来说，这份专题更像是一本应急手册。它提供的不只是方法，更是对Oracle内部机制的理解深度——在备份失灵时，这份理解往往是找回数据的最后一道防线。
老托的Oracle 数据库Patch概念性小常识
这篇讲的是Oracle数据库补丁体系中那些容易混淆的概念。文章清晰地梳理了从标准版本Release，到累积型的Patch Set (PSR)、季度发布的Patch Set Update (PSU) 和 Critical Patch Update (CPU) 等各类补丁的定义与区别。 特别实用的部分在于，它点明了不同补丁的发布逻辑和应用场景：例如，PSU和PSR虽是累积型，但PSU不改变主版本号；在Windows平台上则使用Bundle Patch (BP) 作为替代。文章还澄清了小补丁 (One-Off Patch)、合并补丁 (Merged Patch) 以及诊断补丁 (Diagnostic Patch) 的具体用途和注意事项。 对于希望理解补丁策略的DBA来说，文中的安装建议很有价值，比如推荐安装最新的PSR，以及在应用小补丁前务必进行测试。文章最后引入了Composite Patch的概念，解释了这种新格式如何通过增量安装减少时间开销，并与之前的PSU版本构成了清晰的包含关系，为管理补丁提供了新的视角。
了解Database Replay Capture内部原理
这篇讲的是 Oracle 11g 中 Database Replay 特性的工作负载捕获机制，作者从实际演示出发，剖析了其内部原理。它揭示了捕获并非被动记录，而是由服务进程主动完成：进程在 PGA（特别是 WCR Capture PGA）中累积会话的登录、登出及 SQL 执行信息，待历史记录达到一定数量后，再主动将数据写入到磁盘上的 WCR 文件中。这个过程中，进程会经历“WCR: capture file IO write”等待事件。 文章也量化了捕获带来的开销：磁盘上生成的是不可直读的二进制文件，在大并发 OLTP 场景下，10 分钟捕获可能占用约 1GB 空间；性能损耗约为 4.5%，且每个会话会额外消耗约 64KB 内存。对于 RAC 集群，共享目录是必须的。 此外，文中还梳理了相关的性能视图与等待事件，例如从 `v$event_name` 中查询所有 WCR 相关事件，以及查看 `v$latch` 中新增的 WCR 闩锁。这些细节展示了该功能在数据库内核中留下的足迹，为深入理解和监控这一特性提供了实用线索。
如何验证SQL PROFILE的性能？
这篇讲的是在Oracle数据库生产环境中，如何安全且有效地验证SQL PROFILE的实际性能收益。 文章开篇点明了背景：10g以后的SQL Tuning Advisor会给出多种调优建议，其中启用SQL PROFILE是常见选项。但在生产环境直接应用存在风险，因为优化建议未必适合真实负载，一旦出错可能加剧性能问题。尤其当缺乏测试环境，而SQL PROFILE又可能是“救命稻草”时，就需要一种可靠的局部测试方法。 作者随即演示了具体操作：在12c环境中创建测试表与索引，通过全表扫描执行SQL并记录基线成本。随后运行SQL Tuning Advisor生成任务，并展示了工具内置的“验证”步骤——它对比了原始执行计划与推荐SQL PROFILE计划的关键指标。测试结果极具说服力：使用SQL PROFILE后，缓冲区获取（Buffer Gets）从1470锐减至3，提升达99.79%，同时CPU时间与耗时也几乎归零，证明索引扫描方案远优于全表扫描。 这篇文章的实用价值在于，它提供了一个无需全面部署即可在session级别评估SQL PROFILE效果的清晰范式，帮助DBA在追求性能与保障稳定性之间找到平衡点。
那些在11gR2中可能惹祸的新特性，一张列表帮助你摆脱升级11gR2带来的烦恼
这篇讲的是从Oracle 10g/9i升级到11gR2时，可能因新特性默认启用而“惹祸”的那些事儿。作者指出，像自适应游标共享（Adaptive Cursor Sharing）、自动串行直接路径读（Automatic Serial Direct Path Read）、延迟段创建（Deferred Segment Creation）以及GC相关的新特性等，在实际中可能并不适合许多国产应用，会给原本稳定的系统带来执行计划波动等不确定风险。 文章的核心是一份可直接操作的“排雷清单”。作者汇总了一系列优化器和其他相关特性的隐藏参数，提供了一套通过设置参数来选择性禁用这些新特性的方法。其背后的逻辑很务实：如果你的应用没有条件或时间对这些新特性进行充分测试，不如主动禁用它们，让数据库在11gR2的架构上退回到类似于10gR2（10.2.0.4）的稳定行为模式。 作者也解释了“禁用新特性是否还有升级必要”的疑问。他强调，这并非全盘否定，而是给出了一份可选的选项列表。熟悉且已验证的特性可以保留，不熟悉的则可以选择关闭，从而在享受新版本其他益处的同时，规避因未经测试的优化器行为变更带来的潜在故障。对于那些需要手动开启才会生效的特性（如Flashback Archive），则不受此列表影响。
大于2GB的Listener.log和运行超过198天的主机上的Oracle实例
这篇讲的是Oracle DBA圈里流传已久的两个“传说”及其在当代的真相。 一个是关于Listener.log日志文件不能超过2GB的限制。作者追溯其根源，指出这在早年32位操作系统与文件系统（如Solaris 2.6、早期Linux）时代确实是铁律，但对如今主流的64位系统已成过去式。他通过实际演示，在64位Linux上让Listener.log增长至3GB以上，并依然成功建立新连接，直接证伪了这一“信仰”。同时，他从系统调用层面解释了监听器进程使用O_APPEND标志位追加写入，性能并不会因文件过大而下降。 另一个则是主机运行超过198天会导致Oracle实例故障的传闻。作者澄清，这特指Oracle 10.2.0.1版本的一个已知BUG，会导致OCI客户端CPU空转。该问题在后续的10.2.0.2补丁集中早已修复。他提到，这个因特定版本与超长运行时间偶合的BUG因其戏剧性而令人印象深刻，以至于多年后在部分运维场景中仍被当作经验传播。 文章的核心结论是，这两个基于特定历史条件产生的“最佳实践”，在硬件与软件都已迭代的今天应当被更新认知，尽管定期清理日志等习惯依然值得推荐。作者通过技术细节与版本历史，为读者梳理了从“真理”到“传说”的演变脉络。