标签：Oracle

共 211 篇相关文章

IT 累计浏览 3,390

在ORACLE 12C RAC中使用in memory特性请注意parallel_degree_policy和parallel_force_local参数

这是一篇典型的故障排查文章。作者在对Oracle 12C RAC的In-Memory特性进行测试时，遇到了一个棘手的问题：在清空缓冲区缓存后，测试总是意外触发大量并行操作，导致结果不准确。经过与Oracle官方协作排查，最终定位到问题的根源在于两个关键参数的默认设置不匹配In-Memory的最佳实践。具体来说，参数`parallel_degree_policy`被设为了`AUTO`，而`parallel_force_local`则是默认的`false`。在RAC环境下，这种组合会导致并行执行计划不符合预期。文章通过具体的SQL操作和执行计划对比，清晰地展示了问题表现：从执行计划中可以看到“automatic DOP: Computed Degree of Parallelism is 2”的提示，并且明确标注了“parallel scans affinitized for inmemory”，这证实了In-Memory特性已被触发。解决方法就是根据RAC环境的需要，正确调整这两个参数的值。对于计划在RAC集群中使用In-Memory功能的DBA来说，这篇文章提供了一个非常实用的避坑指南。它提醒我们，在启用强大的新特性时，往往需要仔细检查并调整相关的并行处理参数，才能确保其发挥出应有的性能优势。

IT 累计浏览 2,587

给你的rman备份集加上密码锁

备份是数据保护的最后一道防线，但如果备份集本身没有防护，泄露的风险同样存在。这篇文章从这个角度出发，讲解了如何为Oracle RMAN备份集加上密码锁，实现加密存储。作者从数据安全的现实威胁切入，指出RMAN备份集若被窃取，其数据风险等同于生产库被入侵。解决方案是利用RMAN在10.2及以上企业版中提供的`set encryption`命令，在备份过程中直接设置加密密码。文章详细演示了从配置加密算法（支持AES128/AES256等）到执行加密备份的完整步骤，并特别提醒：加密仅对`backupset`有效，`copy`方式不支持；若需备份到带库，则必须使用Oracle Secure Backup。最具说服力的部分是实操验证。作者创建了测试表空间和数据，进行了加密备份，随后模拟数据文件丢失并尝试恢复。结果显示，在不知道密码的情况下恢复会报错；即使设置错误密码也无法成功。只有使用正确的密码才能顺利完成恢复，这直观地证明了加密机制的有效性。整篇文章实操性强，不仅提供了命令行的具体操作，更通过正反验证让读者清晰看到加密带来的保护效果，对于关注数据库备份安全性的DBA来说，是一个直接可落地的加固方案。

IT 累计浏览 2,912

怎么查看oracle ebs的系统版本号以及各模块的版本号

这篇讲的是如何快速定位Oracle EBS的版本信息，这是系统管理和升级时的一个基础但关键的步骤。作者没有绕弯子，直接切入核心需求：如何查看系统整体版本号，以及如何深入查看每个应用模块的具体版本、安装状态和补丁级别。文章提供了两个现成的SQL查询，分别用于获取系统级版本（从`fnd_product_groups`表）和模块级详情（关联`fnd_product_installations`与`fnd_application`表）。作者特意点明，这类信息查询的关键线索通常在于以`fnd_`为前缀的系统表。对于需要进行版本核对、补丁安装前检查或环境排查的EBS顾问与DBA来说，这几行查询能直接给出准确答案，避免了在界面上层层点击的繁琐。

IT 累计浏览 2,455

修改oracle当前会话的语言环境，解决oracle显示中文乱码的问题

这篇讲的是如何快速解决Oracle数据库在操作时出现中文提示显示为一串问号的常见问题。作者从实际操作中的困扰出发，明确指出这种乱码的根源在于当前会话的语言环境设置不匹配。文章提供了具体、可操作的解决方案：首先通过 `SELECT userenv('language') FROM dual;` 命令来查看当前的语言环境配置，确认问题。接着，给出了两种修改方法：一是通过 `ALTER SESSION SET NLS_LANGUAGE='SIMPLIFIED CHINESE';` 命令临时修改当前会话，使其立即生效；二是通过修改环境变量等方式进行永久性设置，从根源上避免问题再次出现。整个排查思路清晰，步骤直接，对于遇到类似字符集显示问题的数据库管理员或开发人员来说，是一份实用且能快速解决问题的参考。简单几条命令就能让提示信息恢复可读性，提升了工作效率。

IT 累计浏览 2,980

oracle跟踪事件（dump）总结

这篇讲的是Oracle数据库中用于故障诊断的跟踪事件（dump）机制。文章系统梳理了跟踪文件的三种类型——后台报警日志、后台进程跟踪文件和用户跟踪文件，并详细说明了如何通过初始化参数或会话命令来触发dump操作。核心内容聚焦于各种跟踪事件的具体用法。例如，通过`buffers`事件可导出SGA缓冲区信息，`blockdump`事件能定位特定数据块，`errorstack`事件则用于捕获难以获取的错误栈。文章还列举了诸如`10046`（SQL语句跟踪）、`10231`（全表扫描时跳过损坏块）等实用的内部事件号，并解释了其参数级别含义。最后，文章提供了查看当前跟踪文件的简单示例。整体上，它像一份面向DBA和开发者的速查手册，将分散的Oracle诊断工具整理成可操作的条目，便于在性能调优或故障排查时快速定位并转储关键内存结构或日志信息。

IT 累计浏览 2,193

Oracle数据库升级迁移、SPA及统计信息

作者从一次真实的升级迁移讲起：某省级电信运营商将核心CRM系统的Oracle数据库，从IBM小型机上的10g RAC迁移至x86+VMware平台的11g RAC，成本降至十分之一。这引出了一个关键的后续问题：新系统上线后，应采用何种统计信息收集策略？文章对比了两种方案：迁移旧库统计信息或在新库自动收集。作者团队最终选择了后者，原因是11gR2的自动收集机制已相对完善，且能为后续运维降低风险。但如何确保这一策略在上线时就安全可用？答案在于利用SPA（SQL性能分析器）。团队使用了生产库三个时段及一个月AWR中的全部SQL，在新库上跑SPA测试。在测试前，先用`dbms_stats.gather_database_stats(options=>'gather auto')`执行一次增量收集。然而，直接这样做会导致新库的直方图信息严重缺失，因为自动收集依赖`col_usage$`表，而新库此表为空。解决方法是在SPA测试过程中，通过执行足够多的SQL来“喂饱”`col_usage$`，让系统“记住”哪些列需要被关注。最终，基于SPA的测试结果，用数十个SQL Profile固化了风险计划，保障了系统平稳上线。这篇分享的价值在于，它清晰地展示了在大型跨版本迁移中，如何通过组合使用SPA和自动统计信息收集策略，来系统性规避性能风险，而不仅仅是凭经验手工调优。

IT 累计浏览 1,427

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复杂的存储管理提供了清晰的视角。

IT 累计浏览 2,434

Oracle JDBC中的语句缓存

这篇讲的是如何在Java应用中，利用Oracle JDBC驱动提供的语句缓存机制，来优化数据库访问性能，核心目标是实现“一次解析，多次执行”的高效模式。文章首先清晰梳理了Oracle数据库中硬解析、软解析等不同SQL解析方式的特点与潜在性能瓶颈，指出过多解析会导致latch争用等问题。随后，作者通过一个对比实验，直观展示了开启JDBC语句缓存前后的巨大差异：未缓存时，一条SQL语句执行200次就产生了200次解析；而开启缓存后，同样执行200次，解析次数仅为1次，显著降低了数据库负载。实现的关键在于通过OracleConnection对象设置`setStatementCacheSize`和`setImplicitCachingEnabled`，这能为每个连接自动缓存使用过的PreparedStatement。文章还深入一层，介绍了如何通过`setExplicitCachingEnabled`及手工指定Key的方式，进行更精细的缓存控制，以避免缓存不常用语句造成的内存浪费。通过具体的代码示例与数据库监控结果验证，文章为Java开发者提供了一个实用且效果明确的Oracle性能优化方案。

IT 累计浏览 2,682

如何提高Oracle进程的优先级 - 实现进程实时调度

这篇讲的是在繁忙的Oracle系统中，如何为关键后台进程争取更多的CPU资源。作者从Oracle 10gR2引入的一个隐含参数 **_high_priority_processes** 出发，介绍了实现进程实时调度的具体方法。文章核心是讲解这个参数的使用：通过在数据库中设置它（例如 `_high_priority_processes="LMS*|LGWR|PMON"`），可以提升指定进程的优先级。作者通过Linux下的实际测试展示了效果：设置前PMON进程为普通分时调度（TS），重启数据库后即转变为实时调度（RR），从而能优先获取CPU。文章还对比了不同操作系统下的差异，例如Solaris上会使用RT实时模式。最后，作者也提醒了实际应用中的细节，比如在RAC环境中，提升所有LMS进程的优先级可能并非必要，反而会抢占资源，需要根据业务负载审慎配置。整篇文章从原理、设置方法到实际效果和注意事项，提供了一套完整的技术思路。

IT 累计浏览 4,396

Oracle Database 12c架构图

这篇讲的是Oracle Database 12c的架构全景图。作者提供了两张高清图表，一张完整勾勒了12c的整体架构，清晰地展示了所有关键组件以及它们之间的关系，特别是那些在新版本中引入或调整的后台进程，并简要说明了它们的工作原理。另一张则专门聚焦于12c最引人注目的特性——多租户（Pluggable Database）架构。这张大图详细描绘了容器数据库（CDB）与可插拔数据库（PDB）之间的交互逻辑，将这种能大幅提升资源利用率和管理效率的新模式，以可视化的方式呈现得一目了然。对于需要快速理解Oracle 12c技术演进方向、或正在规划数据库升级的团队来说，这两张图提供了非常直接的架构参考。图文结合的方式，让抽象的数据库内核设计变得直观可感。

IT 累计浏览 3,028

PL/SQL的那些事儿

这篇讲的是PL/SQL在Oracle数据库中的正确使用姿势，作者通过对比两种常见场景，点明了优化的核心。文章清晰地划分了PL/SQL的两类使用场景：一类是作为“胶水”，串联一系列SQL分析语句，性能瓶颈主要在SQL引擎；另一类是用游标逐行处理数据，进行过程化计算。作者指出一个关键现象：即便优化后者，性能提升也有限；但若将其重写为前者纯SQL驱动的模式，性能常能获得成百上千倍的提升。这揭示的根本原则是：务必优先利用数据库核心的SQL引擎能力，而非用过程化代码（无论是Java还是PL/SQL）去替代它。当然，PL/SQL并非一无是处。文章也强调了其不可替代的价值，例如实现数据库内部监控工具。作者用了一个形象的类比：将监控代码部署在数据库内部，就像把监控脚本直接放在被监控主机上，避免了网络开销，能获取更精确的数据。文中推荐的工具Session Snapper，就是一个典型的、高效运行在数据库内部的PL/SQL诊断范例。因此，PL/SQL是一把宝剑，用于数据库管理与扩展时锋利无比；但若当作处理数据的“菜刀”来过度使用，则可能事倍功半。

IT 累计浏览 3,111

深入理解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）的思路，并附上了统计信息表示例，为实际的性能诊断提供了具体指引。

IT 累计浏览 4,749

Oracle数据恢复专题

这篇专题文章直击一个国内DBA常面临的痛点：如何在缺少规范备份的严苛条件下，执行Oracle数据库的恢复操作。作者从东西方DBA工作重心的差异切入，坦言“无备份恢复”在国内技术环境中，有时会成为一种被迫练就的“屠龙之技”。文章并非泛泛而谈，而是系统整理了一系列极具实战价值的案例与脚本。从利用DUL、BBED等底层工具直接抢救数据文件，到通过构造ROWID巧妙绕过ORA-1578等坏块错误；从处理ASM磁盘头丢失这类存储层灾难，到解决PL/SQL对象被覆盖、数据文件名乱码等逻辑故障。每一个链接背后，都是一个需要深入理解数据块结构与数据字典的硬核场景。对于需要直面数据库“心跳停止”时刻的工程师来说，这份专题更像是一本应急手册。它提供的不只是方法，更是对Oracle内部机制的理解深度——在备份失灵时，这份理解往往是找回数据的最后一道防线。

IT 累计浏览 5,546

老托的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版本构成了清晰的包含关系，为管理补丁提供了新的视角。

IT 累计浏览 5,600

Oracle DBA的学习进阶成长树-从初出茅庐到高瞻远瞩

这篇文章探讨的是 Oracle DBA 这条技术路径上的长期成长规划。作者根据自己多年的经验，将 DBA 从新手到专家的历程，清晰地划分为五个进阶阶段，并指出这大约需要十年的持续积累。文章的核心观点是，在任何一个技术领域，扎实的阶段性积累远比频繁跳槽更为重要。作者特别强调，对于一位有十年经验的 DBA，面试官最看重的是他是否曾在某个阶段，全心钻研过底层技术。如果没有这样深入的“磨练”，职业高度便会受限。这个视角点明了技术精进的关键。文中还引用了一位网友的精彩比喻，用“少年听雨”到“灯火阑珊”的五句宋词，来映射 DBA 从青涩到豁达的五重境界，为硬核的技术成长增添了一份人文的注解。如果你正在数据库管理的职业道路上探索，这篇文章提供的阶段模型和心态建议，或许能帮助你更好地校准自己的方向。

IT 累计浏览 3,048

关于blockrecover 解决坏块相关测试与总结

这篇文章讲的是，当线上数据库因硬件故障（如小机意外掉电）出现大量坏块，甚至坏块中包含未提交事务时，如何使用Oracle的blockrecover命令进行恢复。作者从一个真实的故障场景出发，客户在IBM p系列小机更换电源后，数据库（9.2.0.8 RAC）出现了大量坏块和smon回滚报错。为了在减少业务影响的前提下解决问题，团队决定采用blockrecover方案。为了验证该方案在复杂情况下的有效性，作者在10g环境下进行了完整的模拟测试。实验详细重现了从创建测试表、使用RMAN备份数据文件、切换归档日志，到人为模拟产生包含未提交事务的坏块的全过程。测试的关键在于，它不仅模拟了坏块，还通过后续的业务操作模拟，验证了blockrecover能否在不影响其他正常数据块的情况下，精准修复目标坏块并正确处理其中的事务。最终的测试结果证实，blockrecover命令能够有效处理这类棘手的坏块问题。整个复现过程步骤清晰，对于遇到类似“坏块+事务回滚”故障的DBA来说，提供了一个极具参考价值的实战解决方案。

IT 累计浏览 2,860

aix使用太多内存导致shared pool 相关latch异常

这篇讲的是AIX系统因内存耗尽引发Oracle数据库性能问题的真实案例。某客户服务器上出现shared pool相关latch的异常等待，系统响应变慢。作者通过nmon和topas工具抓取现场数据，发现物理内存使用率高达99.8%，空闲内存仅剩51MB，同时Paging Space使用了近35%，表明系统正在大量依赖交换空间，这正是导致数据库共享池锁竞争加剧的直接原因。进一步查看vmo内核参数配置，其值遵循了Oracle官方建议，但根本问题在于物理内存总量（21.5GB）已无法承载数据库SGA、PGA及操作系统进程的消耗。文章分析了特定Oracle进程的内存映射，显示单个进程的SGA占用就非常高。最终指出的解决路径非常清晰：要么为服务器扩容内存，要么在业务允许的前提下，主动调小数据库SGA等内存相关参数，从源头降低内存压力。整个排查过程结合了监控命令与参数分析，是AIX+Oracle环境下一个典型的内存型性能故障样本。

IT 累计浏览 4,152

陈吉平的Oracle职业生涯：兴趣与思考成败之所系

这篇文章记录的是资深技术专家陈吉平从大学沉迷游戏到成长为Oracle领域专家的完整职业历程。作者以第一人称回忆了从非科班出身，到初入职场作为混沌的VB程序员，再到因兴趣选择数据库方向，最终在Oracle领域扎根的全过程。文章并非讲解具体技术，而是通过大量真实细节——比如为逃避本专业而打游戏逃课、因800元月薪接下第一个项目、在论坛解答问题养成学习习惯、考取OCP证书——生动刻画了一个技术人员的成长轨迹。其中，如何确立方向、从迷茫转向系统学习、借助社区力量（如CSDN与ITPUB）提升自我等思考，构成了文章的主线。其核心观点在于，技术的成败与持续的“兴趣”和“思考”紧密相关。从最初对计算机的着迷，到后来面对Oracle学习瓶颈时主动寻找方法、总结经验，这份内驱力和对成长路径的反思，远比起点或背景更重要。这对许多正处于技术学习或转型期的读者，提供了真实而鼓舞人心的参考。

IT 累计浏览 4,761

ORACLE 12C可以通过expdp导出view数据

这篇讲的是Oracle 12c中一个相当实用的新功能：通过数据泵工具expdp，直接将视图数据导出为类似表的数据文件。以往，我们想迁移某个视图的数据，通常需要先创建一张临时表来存储查询结果，过程稍显繁琐。而从12c开始，expdp引入了`VIEWS_AS_TABLES`参数。作者在文中用一个完整的实例做了验证：在测试库中创建了一个关联查询的视图`v_xifenfei`，随后使用`expdp`配合该参数，直接将其数据导出为转储文件。接着，使用`impdp`导入时，通过`remap_table`参数，成功地将视图数据作为一张名为`v_xff`的新表导入到了目标库，且查询结果完全一致。这个功能打通了视图与表在数据迁移工具链上的壁垒，特别适合在数据迁移、环境搭建或数据分发时，需要快速提取某个特定视图“快照”结果的场景，省去了中间建表的步骤，让基于视图的数据迁移变得像操作普通表一样直接和简单。

IT 累计浏览 4,142

EXADATA与非EXADATA搭建DATAGURAD关于EHCC特性测试

这篇讲的是一个常见的异构容灾场景：很多企业只有一台昂贵的Exadata机器，但为了数据安全，会用一台普通的非Exadata服务器通过Data Guard来搭建备库。官方宣传的EHCC高级压缩特性是否还能正常使用？作者通过实测给出了答案。测试环境是Oracle 11g，作者在Exadata主库上分别创建了使用BASIC、OLTP以及各种EHCC（Query Low/High， Archive Low/High）压缩的表。关键发现在于，当Data Guard备库是非Exadata环境时，主库的EHCC压缩效率会显著下降。测试数据显示，此时所有EHCC压缩表的数据块大小都膨胀到了接近无压缩的水平，其压缩效果甚至不如简单的OLTP压缩。作者分析，这很可能是Exadata的一种智能降级机制：当检测到备库不支持EHCC时，主库会牺牲自身的存储性能（高压缩效率）来确保数据在备库的可读性与安全性。因此，在这种异构DG架构下，使用Oracle自带的OLTP压缩或许是更优选择，既能保证容灾，也能获得更好的整体效率。