标签：oracle

共 201 篇相关文章

IT 累计浏览 2,462

DBA手记:共享池的改进与ORA-04031的变化

这篇讲的是DBA在维护中遇到的ORA-04031错误，并由此切入Oracle共享池机制的演进。作者从一次线上数据库反复报出ORA-04031（共享池内存不足）的排查经历出发，记录了从依赖老经验（如调整`shared_pool_size`或使用绑定变量）到发现Oracle新版本中根本原因已变化的过程。通过对比传统解读与实际诊断，文章揭示了从10g到12c版本中，共享池管理机制（如“子池”和“请求队列”）的改进，如何改变了内存竞争的表现形式。核心发现是，许多过去针对10g的通用解决方案，在12c+环境中可能不再有效，甚至需要反向操作。作者用具体的AWR报告片段和事件跟踪，展示了新版本中“cursor: mutex S”等新等待事件如何取代了经典的“library cache lock”成为主要瓶颈。文章最终指向一个实用结论：DBA不能仅凭历史经验处理共享池问题，而需理解版本间的实现差异，并结合新的诊断视图（如`v$shared_pool_advice`）进行精准调优。这种从具体故障入手，层层剥离出技术演进逻辑的写法，为面临相似问题的DBA提供了一份清晰的升级参考。

IT 累计浏览 2,905

DBA诊断利器 - Event 10046和 10053

这篇讲的是 Oracle DBA 最常备的两个诊断事件：10046 与 10053。作者 eygle 从实际经验出发，指出在面对慢 SQL 或性能调优时，这两个事件就像 DBA 工具箱里的“透视镜”和“内窥镜”，各有其不可替代的作用。简单来说，10046 事件主要用来捕获 SQL 的详细执行过程信息，比如执行计划、绑定变量值、等待事件等。它回答的是“这条 SQL 实际是怎么跑的”，常用于定位已知的性能问题。而 10053 事件则更为深入，它记录了 Oracle 优化器（CBO）的内部决策过程，解释了为什么优化器选择了某个执行计划而不是其他。它回答的是“优化器为什么这么想”，对于理解复杂的执行计划选择、进行深度调优至关重要。文章的核心价值在于清晰地对比了这两者的适用场景。当你需要诊断一条 SQL 的运行时行为时，用 10046；而当你需要弄明白优化器为何做出一个“令人费解”的计划时，就必须请出 10053。作者强调，理解它们的差异并按需使用，能极大地提升诊断效率。掌握了这两个事件的使用，DBA 在分析性能瓶颈时就能从“现象观察”深入到“决策还原”，使调优工作更有针对性。

IT 累计浏览 2,883

Oracle数据库恢复：归档日志损坏案例一则

这篇讲的是一个相当棘手的Oracle归档日志损坏案例。作者在协助用户恢复数据库时遇到了这个罕见问题，直接影响了数据库的正常恢复流程。文章详细剖析了故障的现场表象：在尝试应用归档日志进行介质恢复时，RMAN报告日志校验失败，常规的重放操作无法继续。通过逐层排查，作者最终锁定了问题的根源——并非存储介质损坏，而是特定版本的Oracle在某种并发操作下，可能导致归档日志内部结构出现逻辑损坏，这在官方文档中鲜有记载。解决的关键在于绕过损坏的日志块，利用基于时间点的不完全恢复结合日志序列分析，巧妙地构建了恢复路径，最终成功保住了大部分数据。这个案例的价值在于，它揭示了一个隐蔽的软件缺陷风险点，并为DBA在面对类似“日志损坏”报错时，提供了超越常规手册的诊断思路和应急恢复策略。

IT 累计浏览 2,647

入门基础:浅析Oracle监听器安装与配置

这篇讲的是如何从零开始理解和配置Oracle监听器。作者从监听器拦截并转接连接请求的核心作用出发，深入解析了其配置文件`listener.ora`的结构与关键参数，例如主机名、端口号和服务列表的设定。文章没有停留在理论层面，而是手把手演示了监听器的安装过程，并点出了安装后需要检查服务状态和配置监听注册。特别对动态注册与静态注册的区别做了说明，解释了为什么在某些场景下需要明确配置静态服务信息。整体上，这篇文章把监听器这个数据库网络连接的“门卫”讲得清晰透彻，既覆盖了核心机制，也给出了可操作的配置步骤，对于刚接触Oracle或需要夯实基础的读者来说，是一份不错的实践指南。

IT 累计浏览 2,645

Oracle 启动监听命令

这篇讲的是 Oracle 数据库中一个非常基础但至关重要的操作——启动监听程序。作者从实际运维场景切入，详细拆解了使用 `lsnrctl start` 命令来启动监听服务的完整流程。文章不仅明确了命令本身，更重点指出启动监听服务必须确保监听配置文件 `listener.ora` 中的相关参数（如监听地址和端口）已正确配置，这是命令能否成功执行的先决条件。文中还特别提醒了一个容易被忽视的细节：如果服务器上已存在一个同名的监听器，直接启动会导致失败，此时需要先停止旧的监听进程。为了让读者直观地验证操作结果，作者展示了如何使用 `lsnrctl status` 命令来检查监听器状态，以及通过查看日志文件来确认服务是否已成功注册到监听器中。对于经常与 Oracle 打交道的开发者和 DBA 来说，这些步骤和注意事项能帮助他们避免常见的启动失败问题，确保数据库连接通道的顺畅建立。

IT 累计浏览 1,681

Oracle中的pfile和spfile详解

这篇讲的是Oracle数据库里两种核心配置文件——pfile与spfile——的区别与实践。作者从Oracle 9i版本的演进切入，点明了spfile取代pfile成为官方推荐方案的背景：spfile作为二进制文件，支持通过ALTER SYSTEM命令动态修改多数参数且立即生效，无需重启实例，也更能避免手工编辑文本文件可能带来的误操作。文章用实操演示澄清了几个关键点。它解释了spfile由pfile创建的初始步骤，并指出一个有趣的细节：运行中的spfile并未被锁定，理论上可以重命名，但后续通过spfile修改参数时就会报错，这或许预示着Oracle未来会加强文件保护。文中详细梳理了Oracle启动时搜索参数文件的默认顺序（spfile${ORACLE_SID}.ora > spfile.ora > init${ORACLE_SID}.ora），并指导读者如何在特定情况下使用pfile启动数据库。尤其值得注意的是对修改参数时SCOPE参数的剖析：MEMORY（仅影响当前运行实例）、SPFILE（仅写入配置文件，重启后生效）、BOTH（同时生效，相当于默认行为）。通过对比实验，清晰展示了不同Scope下修改参数（如timed_statistics）在重启前后的生效情况，特别是修改静态参数时必须指定SCOPE=SPFILE才能避免报错。对于需要理解Oracle参数管理机制、或在实际运维中面临参数调整与备份恢复需求的DBA而言，这篇详解提供了从理论到实践的清晰指引。

IT 累计浏览 2,013

ORACLE系统搭建的一般拓扑

这篇讲的是Oracle系统搭建中一个常见的认知偏差：技术团队往往被“百分百高可用”的期望所困扰，但实际上，系统拓扑的复杂度与冗余设计，并不单纯由投资预算或口头承诺决定。作者从一个非常现实的管理矛盾出发：老板投入重金，自然期望系统坚不可摧；而工程师面临的却是资源有限、应用各异的技术约束。文章直指核心——系统究竟能达到何种可用性与性能水平，根本上取决于承载的业务应用特性。一个OLTP交易系统与一个OLAP分析报表系统，其理想的拓扑结构、数据流向与高可用方案必然大相径庭。因此，这篇文章并非泛泛介绍“如何搭建Oracle”，而是引导读者在动手之前先厘清思路：你的应用到底需要什么？是低延迟的高并发读写，还是大批量的数据处理？明确了应用画像，才能反向推导出合适的硬件选型、网络拓扑、数据复制与备份策略。最终，一个健康的系统，其架构是“长”在应用需求之上的，而非堆砌在老板的期望之中。

IT 累计浏览 2,270

ORACLE数据仓库备份方案分析

这篇讲的是在超大规模ORACLE数据仓库场景下的备份与恢复方案设计。作者面对一个典型挑战：100TB的RAC数据仓库，每日归档量高达5TB，即便已经对非关键数据采用了nologging策略以减少日志产生，备份压力依然巨大。文章的核心是围绕这个背景，探讨如何制定一套可行且高效的备份恢复策略。它很可能深入分析了多种备份方式（如全量、增量、块变更）的权衡，考虑了RAC环境下的一致性保障，以及在海量数据下如何控制备份窗口和恢复时间目标（RTO/RPO）。对于同样运维着大型数据仓库的技术人员来说，文章提供的思路和具体参数考量，直接针对了日常运维中最令人头疼的存储与时间瓶颈问题。通过分析这个真实案例，文章为处理类似“数据量大、日志多”的备份难题，提供了一份从问题定义到方案落地的实用参考。

IT 累计浏览 2,485

几个连接数据库用的python模块

在日常开发中，Python与数据库打交道是家常便饭，无论是从Oracle读取配置，还是向MySQL写入结果，选对驱动模块至关重要。这篇内容梳理了几个主流的数据库连接模块，为不同场景下的选择提供了清晰的参考。文章的核心在于对比这些模块的差异与适用场景。例如，作者提到了像`psycopg2`（用于PostgreSQL）、`pymysql`（纯Python实现的MySQL驱动）以及`cx_Oracle`（Oracle官方驱动）等常见选择。关键差异往往体现在性能、依赖和易用性上：部分模块依赖特定数据库客户端库（性能好但部署复杂），而纯Python实现则更易于安装和迁移，但性能可能略有损耗。文章帮助读者理解，选择时需要权衡项目的具体需求——是追求极致性能，还是需要快速开发和跨平台兼容性。总之，这篇文章并非简单罗列库名，而是将几个实用模块放在了一起进行比较，点明了各自的核心特点。对于需要快速选定数据库连接方案的开发者来说，这份梳理能提供切实的决策依据。

IT 累计浏览 3,026

Oracle中审计删除（DELETE）操作的触发器

这篇讲的是如何用Oracle触发器实现对DELETE操作的轻量级审计。作者从实际的运维需求出发，帮朋友编写了一个简单但实用的解决方案。核心实现思路很清晰：先创建一张审计表来存储删除记录的元数据，再编写一个行级触发器在DELETE操作发生时自动插入审计数据。触发器被设计为在每次删除操作触发一次（FOR EACH ROW），从而能逐条记录。记录的内容不仅包括了被删除数据的关键业务字段，还贴心地捕获了执行删除操作的数据库用户（USER）和精确到秒的系统时间（SYSDATE），为事后追溯提供了完整的信息链。这个方案的巧妙之处在于其“四两拨千斤”的直接性——没有复杂的配置或依赖，仅用数据库原生的对象组合就实现了核心审计功能。它特别适合那些需要快速部署、对审计粒度要求明确（仅追踪删除操作），且追求维护简便性的场景。对于许多中小型项目或特定模块的数据保护来说，这种实现方式往往比启用全面审计或部署第三方工具来得更加轻便、高效。

IT 累计浏览 2,366

cursor_sharing参数对于expdp的性能影响

这篇讲的是一个关于Oracle数据库性能的实际问题。作者从客户的生产环境出发，发现当数据库设置了`cursor_sharing=similar`参数后，执行数据泵（expdp）导出操作的速度出现了显著下降。文章通过测试验证了这一关联，并剖析了其中的技术原因：在该参数模式下，Oracle会过度合并相似SQL，导致为expdp生成大量非最优的执行计划，从而严重拖累了整个导出作业的效率。核心发现是，这个旨在优化共享游标的参数，反而在特定的大批量数据导出场景下成为了性能瓶颈。文章给出的解决方案直接而有效——在需要进行expdp操作时，临时将参数调整为`cursor_sharing=exact`，以此绕过不必要的SQL合并，让数据泵工作在最佳状态。这个案例为DBA们提供了一个明确的踩坑记录和应对策略，在规划数据库参数与ETL任务时，需要特别留意这类潜在的相互影响。

IT 累计浏览 2,026

天道酬勤 - 从头细数来时路（Eygle的职业生涯）

这篇是Eygle对自己Oracle DBA职业生涯的一次深度回顾。文章从大学时代初次接触Oracle讲起，细致梳理了他如何从一个爱好者，一步步成长为国内知名的数据库专家。作者回顾了几个关键节点：早期在ITPUB社区的活跃与学习积累，对Oracle底层原理的执着钻研，以及将实践经验系统化输出的过程。文中没有回避遇到的技术瓶颈与职业困惑，而是坦诚地分享了自己如何通过持续学习和实战，将“天道酬勤”这一信念落到实处。 Eygle特别提到了他与技术社区的深厚渊源，从早期的分享者到后来的推动者，他的成长轨迹也折射出中国第一代Oracle技术社区的发展风貌。文章结尾，他将这段旅程归结为对技术热爱与坚持的回报，传递出一种踏实、专注的技术人精神。

IT 累计浏览 3,202

几个连接数据库用的python模块

这篇针对Python开发者在日常工作中频繁的数据库访问需求，梳理了几个主流连接模块的对比。作者从实际场景出发，比如从Oracle读取配置或向MySQL写入数据，详细介绍了MySQLdb、psycopg2、cx_Oracle和PyMySQL等选项。关键差异在于：MySQLdb以高性能和稳定性著称，适合高并发生产环境；PyMySQL作为纯Python实现，安装简便且跨平台友好，更适合快速开发和轻量级应用；psycopg2针对PostgreSQL深度优化，提供了丰富的事务管理和高级特性；cx_Oracle则与Oracle数据库紧密集成，确保了官方支持的最佳性能。文章还分析了各模块的维护状态和社区活跃度，指出MySQLdb虽然成熟但更新较慢，PyMySQL则更活跃于Python 3生态。通过这些具体对比，帮助读者根据项目数据库类型、性能要求和团队技术栈做出选择，避免在初期架构中选错工具。

IT 累计浏览 2,746

EXPDP:使用ESTIMATE_ONLY参数评估ESTIMATE性能

这篇讲的是Oracle Expdp导出时一个容易被忽略却至关重要的参数：ESTIMATE_ONLY。作者从导出数据前“容量估算”这一环节切入，点明Oracle提供了两种估算路径——按数据块数量和按统计信息。文章的核心价值在于，它明确指出这两种方式在不同版本中性能差异巨大，尤其是在Oracle 10g早期，一些Bug会让估算变得异常缓慢。这其实是很多DBA遇到的“Expdp导出卡在估算阶段”问题的潜在根源。作者通过剖析这个具体的性能陷阱，最终给出了一个清晰的结论：在特定版本下，应优先选择更可靠、性能更可控的估算方法。这篇文章没有空谈理论，而是精准地击中了运维中一个实际的性能痛点。对于需要处理大规模数据导出、追求稳定性的数据库从业者来说，它提供的排查思路和实用建议，能帮你有效规避一个可能导致任务失败或耗时激增的坑。

IT 累计浏览 2,962

Oracle数据库恢复:存储故障导致的数据损坏

这篇讲的是一个真实的大型数据库灾难恢复案例。面对一个4TB的、运行在浪潮存储设备上的Oracle数据库，整个系统因为存储控制器突然损坏而陷入崩溃，导致了数据损坏。文章详细记录了从故障发生后的应急判断，到深入分析存储层面的控制器失效如何波及上层数据库文件，再到执行恢复操作的全过程。核心的挑战在于，这种由底层硬件引发的损坏往往复杂且影响深远。作者没有停留在表面症状，而是剖析了故障链条：控制器故障不仅导致了I/O错误，更关键的是破坏了数据库文件写入的完整性和一致性。这解释了为什么简单的重启或文件拷贝无法解决问题。最终，通过专业的数据库恢复工具和一套严谨的操作流程，成功挽救了数据。整个案例的价值在于它揭示了存储与数据库之间紧密的依存关系，对于负责运维或架构的技术人员来说，这是一次宝贵的实战经验复盘，清晰地展示了如何从硬件故障的迷雾中定位问题并实施有效恢复。

IT 累计浏览 4,188

Oracle hash join

这篇讲的是Oracle中hash join的运作原理，它被作者称为一个“非常强悍的功能”。文章没有停留在理论，而是直白地剖析了其核心流程：Oracle首先会选择一个表作为驱动表，根据过滤条件进行筛选，然后将结果集构建成一个哈希表存放在进程的PGA内存（hash area）中。接着，它再去扫描第二张表，对每一行的键值进行哈希运算，并到内存的哈希表中去“探测”，命中则返回数据，否则丢弃。但文章的重点不止于此。作者紧接着点出了关键现实约束：考虑到单个进程PGA内存的大小，Oracle并不会允许无限制地消耗系统内存。因此，这个看似直接的过程在Oracle内部实际上被细化为三种不同的执行模式。这恰恰解释了在不同数据规模或内存条件下，查询计划为什么会发生差异。文章从原理讲到内存限制的现实考量，为读者勾勒出一个更立体的hash join图景，其细节对于理解数据库性能和配置背后的逻辑很有启发。

IT 累计浏览 2,266

数据库不能正常关闭的问题

这篇讲的是Oracle 10.2.0.3版本中一个棘手的关闭问题：尝试使用`shutdown immediate`命令关闭数据库，但命令无法正常完成，数据库始终卡在关闭过程中。这显然是一个典型的线上故障排查场景。作者从这个问题出发，深入剖析了可能导致该现象的几条关键排查路径。比如，是否存在未提交的长事务、有无被阻塞的会话，或者某些特定的后台进程是否处于异常状态。文章没有停留在理论，而是结合具体版本号（10.2.0.3）和命令（`shutdown immediate`）的实际执行表现，引导读者一步步定位问题根源。最终，作者给出了具体的解决方法，很可能涉及识别并终止问题会话，或是处理特定进程的状态。整个过程清晰地展示了一个从发现问题到分析，再到动手解决的完整技术排障思路，对于同样使用该版本Oracle数据库的DBA或开发人员来说，是一个非常直接的参考案例。

IT 累计浏览 2,943

Latch free竞争 - 最近的SAP测试项目小记

这篇讲的是作者在一个SAP测试项目中，围绕Oracle后端数据库进行性能优化时，与“Latch free”竞争打了一场硬仗。问题表现为特定负载下系统性能出现瓶颈，通过监控发现Oracle的“latch free”等待事件异常飙升。这不是典型的锁等待，而是Oracle内部内存结构（如缓冲池、共享池）的热块争用问题，处理起来更为棘手。作者没有停留在表面等待事件，而是深入ASH和AWR报告，像侦探一样抽丝剥茧，最终将矛头指向了数条高频执行、涉及大量索引读取的SQL语句。这些语句造成了对特定内存区域（如“cache buffers chains” latch）的激烈竞争。优化的核心并非调整复杂的数据库参数，而是回归到SQL本身——通过重写低效SQL、调整执行计划和优化索引结构，从源头减少对关键内存区的并发访问压力。经过一轮反复的测试与验证，系统的响应时间和吞吐量得到了显著改善，那个高企的等待事件曲线也回落到了正常水平。这个案例生动地说明，数据库性能问题有时深藏在应用逻辑与底层内存机制的交互中，解决它需要一份对内部原理的好奇心和一套从应用到内核的完整排查思路。

IT 累计浏览 3,704

oracle数据库的CPU/IO信息采集

这篇讲的是如何在Oracle数据库中系统化地采集CPU与IO性能指标。作者从实际运维需求出发，详细拆解了通过V$SYSSTAT、V$SYSTEM_EVENT等动态性能视图获取关键数据的方法，并给出了具体的SQL查询示例。文章不仅说明了如何抓取CPUTime、User IO Wait Time等核心时间统计，还深入解析了逻辑读、物理读等IO指标的采集逻辑。特别值得注意的是，作者将操作系统级监控与数据库内部视图相结合，形成了完整的监控闭环，为性能瓶颈定位提供了清晰的量化依据。整篇内容扎实，可操作性强，对于需要构建Oracle监控体系的DBA而言，是一份能直接落地参考的技术指南。

IT 累计浏览 14,319

Oracle MTS模式下进程地址与会话信息

这篇讲的是Oracle数据库在MTS（多线程服务器）模式下一个容易忽略的监控现象。作者从客户现场的实际问题出发：在操作系统层面，明明找不到对应的数据库连接进程，但在数据库内部，会话信息却清晰可见。这种“OS无踪，DB有迹”的反差，正是理解MTS架构的关键。 MTS模式改变了传统的“一个会话一个专用进程”模式。它通过调度器（Dispatcher）将大量用户会话复用到少量的共享服务进程上，这极大提升了高并发场景下的资源利用效率。因此，当检查OS时，你看到的是共享进程的进程ID（PID），而不是每个独立会话的PID。而数据库内部的会话视图（如V$SESSION）依然忠实记录着每一个逻辑连接。作者通过这个案例，揭示了在MTS模式下进行性能监控或问题排查时，必须调整传统的思路。单纯依赖操作系统工具查看网络连接或进程树可能无法定位真实的会话活动，需要结合数据库内部的动态性能视图进行交叉比对。这种架构选择带来了效率，也要求管理员掌握更深入的视图知识来洞悉数据库的真实运行状态。