标签：RAC

共 11 篇相关文章

IT 累计浏览 3,388

在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 累计浏览 3,046

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

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

IT 累计浏览 5,431

ORACEL RAC 字符集

这篇讲的是在Oracle RAC环境下修改数据库字符集，一个容易“踩坑”的实操过程。作者从一个ZHS16GBK字符集的10g RAC环境出发，目标是将其变更为UTF8。文章核心记录的并非一帆风顺的步骤，而是在执行过程中遇到的典型问题：当尝试直接执行 `alter database character set` 命令时，数据库报出了 `ORA-12720` 错误，提示需要独占模式。这正是RAC环境下修改字符集的关键陷阱。为解决此问题，作者展示了完整的排查与操作流程：首先需要停止一个节点实例，然后修改 `cluster_database` 参数将集群模式临时改为 `false`，并以独占（`EXCLUSIVE`）模式启动数据库。在确保单节点独占访问后，方才成功执行了字符集变更命令。文章还提到了一个细节操作：手动更新 `props$` 表以同步国家字符集信息，这对于保持数据字典一致性至关重要。最后，再将参数改回集群模式并重启集群。整个操作对生产环境风险极高，文章通过真实报错和步骤复现，清晰地揭示了RAC架构下字符集变更的特殊限制与必备前提。对于需要执行此操作的DBA来说，这份记录提示了务必在维护窗口内进行、并提前备份的要点。

IT 累计浏览 5,820

仅仅只备份是不够的

作者从一个常见的技术误区切入：是不是只要部署了数据库、搭配成熟的备份软件（比如NBU、DP、TSM等），再购置大容量磁带库，就能高枕无忧了？文章通过一个真实案例，揭示了单纯备份策略的局限性——即使硬件和软件齐全，若忽略备份后的验证与恢复流程，在实际灾难场景中仍可能面临数据丢失风险。案例中详细描述了企业虽然拥有完整的备份基础设施，却在恢复阶段遭遇挑战：备份数据无法顺利还原、恢复时间远超预期，导致业务中断。作者指出，根因往往在于备份后缺乏定期测试、未制定清晰的灾难恢复计划，以及对恢复点目标（RPO）和恢复时间目标（RTO）的考量不足。这篇文章强调，备份只是数据保护链条中的一环，完整的策略还需涵盖数据验证、恢复演练和自动化监控。通过这个案例，作者启发读者重新审视自身的数据保护体系：技术投入固然重要，但流程和制度的完善才是确保数据安全的关键。文章结尾自然引导读者思考如何构建从备份到恢复的闭环方案，避免让备份沦为“摆设”。

IT 累计浏览 3,129

如何在Oracle 10g和11g上收集crs日志

Oracle RAC环境的故障诊断常常令人头疼——CRS日志散落在多个节点、多个目录下，手动收集既繁琐又容易遗漏关键信息。这篇讲的正是如何系统化地解决这个痛点。文章聚焦Oracle 10g和11g版本，直接切入CRS日志收集的实际操作。作者指出，虽然日志分布复杂，但Oracle官方其实提供了一个简洁高效的脚本，堪称“居家旅行必备”。通过调用这个脚本，管理员可以一次性抓取所有相关日志，避免了逐目录翻找的低效和风险。文章的核心价值在于将这个实用工具从文档深处提取出来，并明确了其在两个主流版本中的适用性。它没有泛泛而谈理论，而是给出了一条可立即执行的路径，让面对RAC诊断难题的DBA能快速定位问题根源。对于需要维护Oracle集群的工程师来说，这相当于在工具箱里常备了一个顺手的诊断利器。

IT 累计浏览 2,335

DRM引起的问题解决一例

这篇讲的是Oracle RAC环境中一类隐蔽的性能故障。客户系统平时运行平稳，但会周期性地“闹脾气”：前台操作明显变卡，后台监控显示CPU使用率和系统负载突然飙升，几分钟后又自行恢复，像是系统在短暂“发烧”后自动退烧。问题根源指向了Oracle RAC的分布式资源管理组件（DRM）。当RAC集群进行实例间资源协调时，DRM的相关操作（如数据块主节点的重新映射）在特定条件下会引发额外的、不必要的内部开销，从而导致可感知的性能波动。文章详细记录了从现象观察、日志分析到最终定位DRM为“元凶”的全过程。作者不仅解释了问题的技术机理，更分享了实际的解决方案——如何通过调整相关参数来规避DRM的激进行为，在保障集群功能的同时，平息这种间歇性的性能起伏。对于管理Oracle RAC、尤其是遭遇类似“阵发性”性能问题的DBA和系统工程师来说，这次故障排查的思路与处置措施，提供了一次很有价值的实战参考。

IT 累计浏览 3,492

RAC环境下Memory System Deconfigured

这篇讲的是一个经典的“节点越多，跑得越慢”的反例。作者从一个真实的Oracle 9i RAC环境出发，记录了一次令人困惑的性能衰退：当一台故障主机维修完毕重新加入集群后，整个系统的性能不升反降，前端业务甚至比单节点运行时还要缓慢。文章的核心直指这种违背直觉的现象。它描述了具体环境（IBM小型机，Oracle 9.2.0.8）和性能恶化的确切表现——收费系统响应迟滞。虽然给出的信息片段没有直接点明最终的“病根”，但标题“Memory System Deconfigured”已经强烈暗示，问题与集群恢复后内存子系统的配置或状态有关。这很可能涉及RAC架构中一个关键但容易被忽视的环节：集群节点间的共享内存管理或SGA配置在故障切换与恢复过程中出现了不一致或未被正确重置。对于维护高可用数据库系统的工程师来说，这篇文章的价值在于它提供了一个完整的排查案例框架。它提醒我们，硬件或网络故障的恢复并不意味着一切自动回归正常，集群内部资源的重新协商与分配可能引入新的、更隐蔽的瓶颈。作者对故障前后对比的详细记录，为诊断类似“集群反而累赘”的问题提供了宝贵的参考路径。

IT 累计浏览 2,310

ORACLE数据仓库备份方案分析

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

IT 累计浏览 3,063

Oracle高可用架构

这篇讲的是Oracle MAA（最大可用性架构）的全景式解读。作者从一个核心问题出发：如何设计数据库系统，才能在硬件故障、数据中心灾难等各种场景下，依然保持服务可用甚至不中断？文章没有堆砌枯燥的理论，而是将MAA架构拆解为几个关键维度来剖析——从本地高可用的RAC，到数据保护的Data Guard，再到云环境下的综合方案。它把Oracle多年来围绕高可用、容灾和性能优化推出的一系列“武器”清晰地串联了起来，点明了每个组件适合解决什么问题，以及它们如何协同工作形成完整的防护网。对于正在规划数据库架构或评估容灾方案的工程师来说，这种结构化的梳理非常实用。它帮你快速建立起从单机到集群、从本地到异地的完整认知框架，理解各种技术选择背后的权衡与定位。

IT 累计浏览 3,753

RAC的负载均衡

这篇讲的是Oracle RAC数据库环境下，负载均衡机制如何工作。文章直接点明核心问题：当一个新会话连接到RAC集群时，系统如何判断该由哪个节点来处理它。作者没有停留在概念，而是清晰地拆解了两种主流的实现路径。一种是客户端负载均衡，它依赖客户端的驱动程序或网络配置（如Oracle的TNS配置）来分发连接请求，这种方式更灵活，对客户端的配置有一定要求。另一种是服务器端负载均衡，它由集群件（如Oracle Grid Infrastructure）基于各节点的实际负载（如CPU、内存使用率）来智能地将新连接路由到合适的节点，这种方式更动态，对客户端透明。理解这两种模式的关键差异很重要：客户端方式将决策权部分下放，适合对连接控制有定制化需求的场景；服务器端方式则更集中、智能，能实时响应集群状态变化。选择哪一种，往往取决于应用架构的特点和运维管理的侧重。搞清楚它们的工作原理，是配置和优化RAC环境以实现高可用与高性能的基础。

IT 累计浏览 3,850

DBA最缺的不是技术

作者从自己离开上海的经历出发，探讨了一个好DBA真正欠缺的究竟是什么。他发现，在长期反思中，那些拖住自己前进脚步的，并非某项具体的技术短板，而是一系列长期被忽视的非技术能力。文章没有罗列技术清单，而是直指DBA职业成长中的隐形天花板：比如与业务对齐的思维、沟通协作的软技能、以及对自身价值的清晰认知。作者将自己定位为“技术人”，但恰恰是这些非技术因素，决定了DBA能否真正驱动业务并创造超出工具本身的价值。对于许多埋头于SQL优化与故障处理的技术人员来说，这篇文章提供了一个重要的审视视角——技术是立身之本，但视野与思维模式才是决定职业上限的关键。它提醒DBA群体，有时候需要抬头看路，而不仅仅是埋头苦干。