最新文章

采集自各技术站点的近期文章。

IT 数据库/ 2009-10-11 22:32:05 / 累计浏览 4,123

Shared pool和library cache latch

这篇技术文章聚焦于Oracle数据库中一个关键却常被忽略的底层机制：Shared pool latch。作者从其核心作用切入——它主要负责保护共享池的内部结构，在内存分配、释放乃至老化处理时都需要被获取，是维护共享池稳定性的关键“门锁”。文章清晰地梳理了一个重要的技术演进。在Oracle 9i版本之前，整个共享池由单一的Shared pool latch统一保护。而自9i开始，Oracle引入了多子池（sub pool）设计：当服务器CPU核心数超过4个，且`shared_pool_size`设置大于250MB时，共享池会被动态划分为多个子池（最多7个），每个子池拥有独立的内存结构、LRU列表以及自己的latch。这意味着对共享池的操作竞争，从单一的“瓶颈”被分散到了多个子池的latch上，从而提升了在高并发环境下的性能。此外，文章也指出了人工干预的可能性，管理员可以通过`_kghdsidx_count`参数来手动设定子池的数量，为性能调优提供了一个更精细的调控点。对于理解Oracle内存管理机制和进行性能诊断的DBA来说，厘清这一 latch 的作用与演变历史，是诊断共享池竞争问题的重要基础。

本机暂存

IT 数据库/ 2009-10-11 22:31:21 / 累计浏览 6,776

如何建立合适的索引？

这篇文章从一个典型的运维场景出发：当你在 statspack 报表中发现逻辑读、物理读极高的 SQL，分析过表统计信息且执行计划已走索引时，该如何进一步判断其是否真正优化？作者没有停留在表面指标，而是深入探讨了在“看似合理”的表象下，如何验证索引选择的效能与 SQL 语句执行质量之间的深层关联。文章的核心在于提供一种系统性的诊断思路，而不仅仅是工具使用教程。它引导读者超越“是否走了索引”这个二元判断，去追问索引类型（比如是否是覆盖索引）、访问路径（如回表次数）、以及索引效率与数据分布的实际匹配度。通过对这些细节的剖析，文章旨在帮助读者建立一套从性能现象反推至设计根源的完整优化逻辑。读完能感受到，真正的优化工作往往从那些“看起来已经优化过了”的地方开始。它教会我们如何拆解一个“标准答案”，并在实际业务场景中做出更精准、更有效的判断，这对于任何需要与数据库性能打交道的工程师来说，都是一次扎实的思维训练。

本机暂存

IT 数据库/ 2009-10-11 22:30:14 / 累计浏览 4,475

我这几年

作者从大学时代对联想、方正这些“洋气”大公司的憧憬谈起，回忆了自己毕业后意外加入方正春元的幸运经历——没有复杂面试，因为公司急需人手而直接入职。这篇小文的核心，并非讲述一个逆袭的职场故事，而是借由这段初期经历，剖析了“第一份工作”的潜在价值。大公司带来的系统性训练让他印象深刻：从做人做事的规范，到学习方法、客户沟通技巧，甚至每日工作日志的要求，这些看似刻板的流程，实则为他搭建了职业世界的底层框架。作者认为，正是这段经历让他“明白了以后要做什么”，其重要性甚至超越了技能本身。这段平实的回顾提醒我们，职业生涯的起点或许不在于岗位的光鲜，而在于能否获得一次完整的、结构化的职业启蒙。它帮助新手从“学生思维”切换到“职业思维”，看清自己未来的方向——这可能是比起薪更宝贵的初始馈赠。

本机暂存

IT 数据库/ 2009-10-11 22:29:05 / 累计浏览 3,559

如何使用dbms_stats分析统计信息？

这篇讲的是Oracle数据库中一个非常实用的程序包——dbms_stats的入门使用。作者从Oracle 8i版本引入dbms_stats这一背景切入，提到它如今已广泛推荐用来替代传统的analyze命令，主要优势在于让统计信息的生成与处理变得更加便捷高效。文章简明地梳理了dbms_stats的基本定位：它不仅仅是一个工具，更是现代Oracle优化器赖以准确评估SQL执行计划的数据基石。作者分享了自己的学习笔记视角，没有停留在概念堆砌，而是隐含地指向了一个关键对比——与analyze命令相比，dbms_stats在并行处理、分区统计以及历史信息管理等方面都更为强大和灵活，这也解释了为何它能逐渐成为行业标准。对于希望理解优化器工作原理或进行SQL调优的DBA与开发者而言，掌握dbms_stats是必不可少的一环。这篇文章提供了一个清晰的起点，帮助读者从“知道有这么个工具”迈向“理解为何要用它以及如何用好它”，为后续更深入的统计信息管理实践打下基础。

本机暂存

IT 数据库/ 2009-10-11 22:27:37 / 累计浏览 3,427

library cache pin和lock的区别

这篇讲的是Oracle数据库中library cache pin与library cache lock这两个常被混淆的概念。作者从一个经典的面试问题出发，坦言自己曾被难住，并在与同事的深入讨论和查阅官方文档后，终于理清了二者的本质区别。文章的核心在于细致对比。简单说，lock保护的是对象在共享池中的存在性（如一个游标的打开状态），而pin则保护的是对象本身的内容（如SQL语句的执行计划）不被修改或刷出。关键差异体现在阻塞场景上：lock通常阻塞DDL或依赖管理操作，而pin则直接阻塞那些需要执行SQL的会话。它们就像数据库门卫和内容保镖的不同分工。作者没有停留在概念，还结合了V$SESSION_WAIT视图的观测，剖析了它们在争用时的不同等待事件。这种从实际讨论到理论梳理，再回归实践验证的路径，为理解Oracle共享池的底层保护机制提供了清晰的逻辑线索。

本机暂存

IT 数据库/ 2009-10-11 22:24:35 / 累计浏览 2,830

Index Full Scans和Fast Full Index Scans的区别

这篇对比了Oracle数据库中两种常见的索引扫描方法：Index Full Scans和Fast Full Index Scans。作者从查询优化的实际需求出发，详细解释了它们的核心差异——Index Full Scans通常通过顺序读取索引块来执行，依赖单块I/O，虽然操作直接，但在处理大量数据时可能效率不高；而Fast Full Index Scans则利用多块读取和并行机制，能显著加快全索引扫描的速度，更适合性能要求高的场景。文章还结合具体例子，比如当SQL查询需要快速获取索引列数据时，Fast Full Index Scans可以减少I/O开销，提升整体响应时间。通过分析各自的实现特点和适用场合，读者可以更灵活地选择合适的方法，避免不必要的性能损耗，从而在数据库调优中做出更精准的决策。

本机暂存

IT 数据库/ 2009-10-11 22:22:55 / 累计浏览 3,578

Oracle9i中如何恢复误删除数据？

这篇讲的是一个让很多DBA或开发人员心头一紧的场景：在Oracle9i环境中，不小心执行了删除操作，导致重要数据丢失。文章聚焦于这个紧急问题，没有泛泛而谈数据库原理，而是直接针对Oracle9i这个特定版本，给出了具体的恢复路径。核心方法是利用Oracle的闪回查询（Flashback Query）特性，通过查询指定时间点或SCN（系统变更号）的数据状态，来还原误删的记录。文章会详细说明如何精确地构建查询语句，找到数据被删除前的那个“时间切片”，并将其重新插入表中。这对于尚未升级到拥有更完善闪回功能的较新版本的系统来说，是一套非常实用的应急方案。作者不仅列出了步骤，也提示了该方案生效的几个前提条件，比如Undo表空间需要足够大且保留时间设置得当。这对于实际操作至关重要，避免了用户按照步骤操作却发现数据早已被覆盖的窘境。整体来看，这是一份针对特定版本、解决具体痛点的操作手册。

本机暂存

IT 数据库/ 2009-10-11 22:22:30 / 累计浏览 2,333

pl/sql developer编译存储过程中遇到了ORA-07445错误...

这篇讲的是一个在Oracle 9205环境下，使用PL/SQL Developer或Toad等第三方工具编译存储过程时遇到的诡异故障。作者发现，用这些工具编译时，连接会莫名断开并失败，但切换回sqlplus执行同样的DDL语句却能顺利通过。检查数据库日志后，发现了大量的ORA-07445内存访问错误。经过排查，作者将问题根源定位为Oracle数据库与特定第三方客户端工具之间的兼容性缺陷，这很可能是Oracle该版本的一个小bug。一个关键的验证线索是：问题只发生在使用第三方工具时，而使用官方的sqlplus则完全正常。作者后续在Oracle的官方支持网站Metalink上检索到了相关案例，证实了这一判断。这篇文章的价值在于，它记录了一个典型的“工具链”兼容性问题排查思路。当遇到类似的不明确报错时，除了检查代码和权限，更换一个已知稳定可靠的客户端工具进行交叉验证，往往是定位问题的快捷路径。

本机暂存

IT 数据库/ 2009-10-11 22:21:46 / 累计浏览 2,232

利用DBMS_REDEFINITION在线重定义表

这篇讲的是如何在不停机、不中断业务的情况下给数据库表“动手术”。对于那些7×24小时运行的核心业务系统，对一张正在被频繁增删改查的表进行结构修改（比如加列、改数据类型）堪称噩梦，传统的做法往往需要停机维护，造成业务中断。作者从这个常见的痛点出发，介绍了Oracle从9i版本就提供的一个强大工具——`DBMS_REDEFINITION`包。它的核心思路是“暗度陈仓”：先在后台创建一个与原始表结构一致的“影子表”，在此期间允许业务正常读写原始表。等到“影子表”准备就绪，再通过该包快速将两者交换，并同步期间产生的差异数据。整个过程实现了在线重定义，业务几乎感知不到，巧妙地解决了结构变更与业务连续性之间的矛盾。对于需要高可用保障的DBA和开发来说，这是一个必须掌握的运维技巧。

本机暂存

IT 数据库/ 2009-10-11 22:17:15 / 累计浏览 4,719

oracle技术方面的路线

这篇讲的是作者近期与eBay资深技术专家诸超在上海的一次深度交流。他们探讨的核心话题，正是当前企业环境下Oracle技术路线的选择与演进。交流中，双方在多个关键看法上不谋而合，比如在何种业务场景下Oracle数据库的特性依然是无可替代的，又该如何规划其与开源数据库、云原生数据服务的共存路径。作为在全球顶尖电商技术体系中历练过的专家，诸超从实践角度分享的案例，为理论探讨增添了扎实的注脚。这类跨公司的同行对话，其价值往往不在于给出一个标准答案，而是揭示了技术决策背后的复杂权衡。文章将这次交流中迸发出的观点与思考片段呈现出来，为正在面临数据库技术选型的团队，提供了一个来自一线实践者的、更具象的观察视角。

本机暂存

IT 数据库/ 2009-10-11 22:14:32 / 累计浏览 2,062

你知道多少个存储容量单位？

这篇讲的是存储容量单位这个基础但容易被模糊化的概念。作者从最常见的KB、MB出发，一路梳理到PB、EB，甚至探讨了TB以上的冷门单位如ZB、YB，并解释了它们之间的千进制换算关系。文章的核心在于通过具体数字的直观对比，揭示了这些单位背后巨大的数量级差异。例如，从1GB到1TB相差一千倍，而从1TB到1PB则是百万倍的跨度。这种对比旨在帮助读者建立对海量数据的真实感知。作者也点出了这些单位在实际场景中的应用意义。比如，个人设备容量常用GB和TB衡量，而数据中心或互联网流量统计则会用到PB乃至EB级别的单位。文章通过厘清这些概念，解释了为什么有时会感觉“容量不够用”，其实是因为单位认知存在偏差。通过这篇文章，你能快速补上对现代数据存储规模的系统认知，下次再看到“1TB”或“100PB”时，脑海里能立刻构建起清晰的尺度概念。

本机暂存

IT 数据库/ 2009-10-11 22:13:17 / 累计浏览 4,289

我的担忧：dba如何在稳定环境中成长

这篇讲的是一位资深DBA对自己职业状态的深刻反思。他身处一个极其稳定、几乎“风平浪静”的数据库环境中，却因此感到了成长的焦虑与停滞。作者指出，长期维护高稳定性系统，固然体现了运维的功力，但这也容易让DBA陷入“无事可做”的舒适区，技术敏感度和实战能力可能悄悄退化。他担忧的是，当未来真正的风暴来临时，自己会不会已经失去了驾驭的能力。为此，他分享了自己主动“破局”的方法：不再被动等待故障，而是主动去“创造”挑战。比如系统性地梳理和偿还那些潜伏的“技术债务”，或者定期进行高强度的“故障推演”模拟演练。这些行动的本质，是把平淡的日常转化为持续的学习和进化过程。文章最打动人的地方，是将这种个人的职业困境，延伸到了对整个行业稳定系统运维模式的思考——在“不出事”就是最大功劳的环境下，如何为技术团队注入必要的活力与成长压力？他给出的不是一个答案，而是一个所有技术人都值得思考的问题。

本机暂存

IT DevOps/ 2009-10-11 22:12:37 / 累计浏览 3,548

中国骨干网络结构图

这篇梳理了中国骨干网络的核心结构。作者从宏观的层级关系切入，清晰地展示了这张“网络高速公路”是如何分层运作的。文章没有停留在概念层面，而是具体拆解了骨干网的核心组件，比如国干网与省干网如何衔接、不同层级的传输带宽差异，以及主要的数据交换枢纽节点分布。它解释了像“163骨干网”和“CN2”这类常见名词背后的技术定位与服务场景区别——前者是覆盖面最广的基础承载网，后者则更侧重高质量业务。对于技术人员而言，这份梳理的价值在于提供了理解国内网络流量走向的基础地图。无论是排查跨地域访问延迟，还是在设计分布式系统时考虑网络拓扑，文中关于骨干层与接入层交互的细节，都能提供扎实的参考。它把庞大复杂的物理网络抽象成了一幅逻辑清晰的图谱，帮助读者建立起从本地网络到全国互联的完整认知框架。

本机暂存

IT 数据库/ 2009-10-11 22:10:54 / 累计浏览 4,073

我对学习oracle与成长的理解

这篇讲的是作者从自身Oracle技术栈的学习经验出发，如何通过深入理解数据库技术来获得个人成长。文章没有聚焦于某个具体的技术问题或版本特性，而是从一个更宏观的视角，探讨了掌握一门深厚技术（如Oracle）所能带来的长期价值。作者的核心观点在于，真正的技术精通不仅仅是会用，而是能洞悉其“过去、现在和未来”。这意味着理解技术演进的脉络、当下的市场定位，以及其在云时代可能面临的变化与转型。这种深度认知，将学习过程从单纯的功能记忆，提升到了架构思维和行业洞察的层面。对于技术人员而言，这篇文章提供了一种超越日常运维或开发的学习范式。它启示我们，将一门技术学深学透，并以此为支点建立体系化认知，或许比频繁追逐各种浅层的新工具更能构建扎实的职业护城河。文章将个人技术实践与职业成长路径结合了起来，引发了关于如何学习才能面向未来的思考。

本机暂存

IT 设计/ 2009-10-11 22:09:15 / 累计浏览 1,818

今天看了功夫熊猫，随便说说

作者看完《功夫熊猫》后，注意到电影中两个有趣的设定。一是熊猫老爹的祖传面汤秘笈竟然只是“不放佐料”，这看起来无厘头，却指向“相信自己”这一朴素道理；二是最终的神龙秘笈其实是一张白纸，需要主角用信念去理解。这两处情节看似简单，却层层递进地揭示了电影的核心观点：功夫的最高境界，或许并非掌握了多少复杂招式，而是回归本心、心中无招。作者从这个角度切入，将看似童话的情节解读为一种对“技术修行”的隐喻——有时最极致的解决方案，不在于堆砌复杂工具或框架，而在于对本质的理解与自信。这种跳出剧情本身的思考，为读者提供了一个有趣的视角：无论是学功夫还是解决技术问题，最终都可能需要一份“返璞归真”的勇气。

本机暂存

IT DevOps/ 2009-10-11 21:46:06 / 累计浏览 4,230

Linux下的NFS

这篇讲的是 Linux 系统中广泛使用的网络文件系统——NFS。文章并非停留在概念介绍，而是深入剖析了其背后的核心机制。作者从 NFS 的基本工作原理讲起，清晰地勾勒出客户端与服务器如何通过 RPC 协议进行交互，将远程目录无缝挂载为本地文件。文章重点对比了 NFSv3 与 NFSv4 在架构与特性上的关键差异：V3 依赖外部的端口映射服务，配置相对灵活但也更复杂；而 V4 则进行了重大整合，引入了状态管理，安全性更高，更适合现代企业环境。对于实践部分，文章详细拆解了服务端与客户端的配置流程，不仅列出了关键参数的含义，还结合实际场景，说明了如何为开发、测试环境选择合适的导出选项，以及如何通过调整缓存策略来平衡性能与数据一致性。最后，文章探讨了 NFS 在性能优化上的几个实用技巧，比如调整传输块大小和利用异步写入。总的来说，它将一个略显古老但至关重要的技术点讲得既透彻又实用，无论是初次接触文件共享的新手，还是希望优化现有存储方案的运维人员，都能从中找到直接可用的配置思路与避坑指南。

本机暂存

IT 数据库/ 2009-10-11 12:32:39 / 累计浏览 2,032

如何关闭统计信息自动分析？

这篇讲的是Oracle 10g中一个常被提及却容易误解的功能——统计信息的自动分析。它默认会在每天晚上22点启动一个调度任务，但并非全盘扫描所有表，其设计智慧在于只关注那些行数据变动超过10%的表。这种基于变化率的选择性分析，旨在以较低的资源开销维持优化器的统计信息新鲜度。然而，任何自动化的机制都可能存在与特定业务场景不适配的情况。比如，对于更新频率极低或变更规律明确的表，定期的自动分析或许并非必需，甚至可能在特定时段引入不必要的负载。文章指出，是否关闭这个功能，没有一刀切的答案。它完全取决于你的数据库负载特征、维护窗口以及对性能波动的容忍度。因此，作者的建议是回归到自身的需求分析：评估自动分析带来的收益（优化器更准确的统计信息）与潜在的成本（资源消耗、对特定操作的干扰）之间的平衡。这篇内容的价值在于厘清了这个功能“在做什么”，并将最终的决策权交还给了需要结合实际场景判断的数据库管理员。

本机暂存

IT DevOps/ 2009-10-11 00:21:04 / 累计浏览 1,730

祸不单行

这篇讲的是作者在搞定虚拟带库备份配置、正感顺利时，又接连遭遇新状况的经历。他原本为成功配置好备份而高兴，但“祸不单行”的现实随即上演——文章记录了接下来遇到的技术难题及其排查过程。作者从一次成功的配置实践出发，但很快转向了对后续问题的描述。虽然提供的片段只揭示了开端，但从标题和“先说一下吧”的铺垫来看，这显然是一篇详实的踩坑记录。它很可能描述了一个问题如何引出另一个问题，或者新旧问题交织的复杂场景，体现了实际运维中常见的挑战连环。对于遇到类似困境或想学习故障排查思路的读者，这篇文章的价值在于其真实的“事故”现场复现。它没有回避曲折，而是将解决问题的过程娓娓道来，这种从顺利到意外再到解决的完整路径，往往比一帆风顺的教程更能带来启发。

本机暂存

IT 数据库/ 2009-10-11 00:14:33 / 累计浏览 2,588

Oracle 11g Linux单机STANDBY配置

这篇讲的是如何在Oracle 11g数据库的Linux单机环境中配置STANDBY，以实现高可用和数据保护。在企业应用中，数据库的持续运行至关重要，而STANDBY配置

本机暂存

IT 数据库/ 2009-10-11 00:13:45 / 累计浏览 3,424

ASM中如何配置多个控制文件

这篇讲的是，在使用了ASM自动存储管理的Oracle数据库环境中，如何避免因默认只创建一个控制文件而带来的潜在风险。对于使用ASM存储的数据库，如果初始仅创建了一个ASM磁盘组，控制文件会默认只有一个副本，这违背了多副本冗余保障数据库安全的最佳实践。作者从这一常见配置问题出发，指出了其中的安全隐患。文章的核心在于提供一套具体的配置方法，指导读者如何在ASM磁盘组中，将控制文件配置为多个独立的物理副本。这涉及到对ASM存储特性的理解和相应的管理操作。通过遵循文中所述的操作步骤，管理员能够轻松地在ASM环境下为控制文件建立多重保护。这确保了即使某个控制文件所在的磁盘组或文件发生损坏，数据库依然能够依靠其他副本保持稳定运行，有效提升了系统的可用性与容灾能力。

本机暂存