Category Archives: DB
MongoDB安装、基础操作和聚合实例详解
虽然MongoDB这些年很流行，但笔者之前没研究过，现在有需求研究这类NoSQL的数据库，是为了验证其是否可被替换。 MongoDB是很轻量的文档数据库，简单测试也懒得专门准备虚拟机环境了，直接在macOS上安装测试下其基础功能。 1.使用 Homebrew 安装 MongoDB 2.启动/停止 MongoDB 服务 3.启动 MongoDB Shell 4.体验 MongoDB 基本操作 5.体验 MongoDB 聚合操作 1. 使用 Homebrew 安装 MongoDB # 添加 MongoDB 存储库 brew tap mongodb/brew # 安装 MongoDB 社区版 brew install mongodb-community 2. 启动/停止 MongoDB … Continue reading
Operational Property Graphs到底是个啥？
Operational Property Graphs，中文通常译为“操作属性图”。 作为23ai中被官方highlight出的新特性之一，我们先看下官方的原文描述： Operational Property Graphs in SQL Developers can now build real-time graph analysis applications against operational data directly in the Oracle Database, utilizing its industry leading security, high availability and performance capabilities. 简单说，开发者可以直接在Oracle 23ai中进行实时图分析，而不需要额外的图数据库。 为了不纯扯概念，更好的直观体验，下面我们直接按照官方文档给出的一个简单示例来动手练习体验下： 本次测试环境： Oracle … Continue reading
实现并发新高度：23ai的无锁列值保留
Oracle Database 23ai支持Lock-Free Reservation，中文通常译为“无锁列值保留”。 本文将通过3个部分来阐述Lock-Free Reservation的这个特性： 1.应用场景 2.实现原理 3.使用限制 1.应用场景 Lock-Free Reservation这项特性可用于实现更细粒度的并发控制。 它的本质是相对于传统的行锁，能以更细的粒度（即列值级别）进行锁定，从而减少锁争用，提高并发性能。 例如，当库存充足时，数据仅在提交时锁定，并有可能改善最终用户体验以及事务的吞吐量。 为了避免重复造轮子，本文演示的测试用例部分，直接参考了官方博客中给出的测试用例，原文链接为： – https://blogs.oracle.com/coretec/post/lock-free-reservation-in-23c 下面我们就依据此测试用例来测试并理解下Lock-Free Reservation的具体功效吧。 1.1 创建测试表 首先，创建测试表inventory： create table inventory ( item_id NUMBER CONSTRAINT inv_pk PRIMARY KEY, item_display_name VARCHAR2(100) NOT NULL, item_desc VARCHAR2(2000), qty_on_hand NUMBER … Continue reading
Oracle优化神技之临时表
Oracle临时表在处理临时数据、会话数据隔离和复杂查询优化方面非常有用。 其底层逻辑是通过Oracle特殊的临时表来减少I/O操作和日志开销，提高了数据库性能和查询效率。开发者可以根据具体需求和场景，合理使用临时表来简化数据处理逻辑和提高系统性能。 早期开发人员在使用Oracle数据库时，经常因为不熟悉或不了解全局临时表（Global Temporary Table，下文简称GTT）的特性，因而自行定义了所谓的“临时表”，不但增加了开发复杂度，比如需要自行做数据清理和会话隔离等问题，还因高频操作这类表产生了大量重做日志（redo logs），进而增加了I/O负载和系统开销，主要代价这么多，最终的应用性能还不够好。 所幸这类问题随着用户量的提升，大家口口相传这个最佳实践，后续开发已经很少会犯这类低级问题。 那是不是用了Oracle的临时表就可以高枕无忧了呢？ 最近笔者在某客户遇到一个临时表的问题，在分析这个客户问题的过程，也和大家一起来回顾下有关Oracle临时表的知识。 1.创建临时表 2.临时表统计信息 3.临时表索引 4.临时表是否cache 5.临时表相关问题 1.创建临时表 本次遇到问题的临时表，是使用的Oracle的GTT，且定义表中数据是基于session-specific的类型，脱敏后的创建语句为： CREATE GLOBAL TEMPORARY TABLE “JINGYU”.”G_T_T1″ (“ID” NUMBER(10,0) NOT NULL ENABLE, “NAME” VARCHAR2(30) NOT NULL ENABLE) ON COMMIT PRESERVE ROWS; 下面是官方文档截图，比较了GTT和PTT的差异： 除了上面提到的命名规则等差异之外，还要补充一点： GTT是8i后就已经支持的技术，而PTT要在18c及以后版本才支持。 关于GTT的两种类型，文档说明如下： 根据你的应用需求选择，简单说就是如果想在事务结束就清空表，选择DELETE … Continue reading
23ai中的True Cache到底能做啥？
最近，Oracle的产品管理总监在Oracle数据库内幕中介绍了True Cache。 原文链接如下： – https://blogs.oracle.com/database/post/introducing-oracle-true-cache 由于这篇文章比较火爆，我们国内已经有很多的数据库爱好者完整的翻译这篇文章，所以笔者也不需要重复翻译，本文旨在提炼文中关键信息，并使用大白话和大家一起探讨下23ai中的True Cache功能： 1.为什么需要True Cache？ 2.True Cache工作原理 3.应用程序使用True Cache 4.True Cache的好处和应用场景 1.为什么需要True Cache？ 通常这个问题会是IT部门的领导层最关心的问题，现有架构下，为什么需要引入True Cache？ 回答这个问题，需要先了解下目前的发展趋势，当下随着数字化环境的不断发展，各类应用要求提供实时响应成为当务之急，而大家都知道数据库的资源很宝贵，大部分高并发应用其实都是读多写入的场景，所以业界常用的方案就是在数据库的前面加一个缓存层，且将它设计在内存中缓存（Caching），这个底层逻辑其实也非常简单，就是内存的速度一定是远远高于存储速度的，这是介质本身存在的数量级的性能差异。 当然，能接受用缓存的共识是这个缓存中无需最新的数据，说白了，无论你用什么样的缓存技术，读的数据无论多少，一定都是有延迟的，可应用需求一定会要求这个延迟越小越好，这里原文中立马就提到Oracle提供的True Cache是一个突破性的缓存解决方案，那这个突破性具体体现在哪里呢？ 性能的进一步优化 缓解数据陈旧问题 有效管理缓存数据 这些方面的优势是因为True Cache相当于是一个主库的全功能的只读副本，类似ADG，但又比ADG轻量，它不需要数据文件的存储，别小看这一点，对于当下一个动辄几十T数据量的数据库来说，将会是非常大的成本节约。 2.True Cache工作原理 这里，提炼文中关键的几点： 应用程序通过Oracle JDBC Driver连接对应实例（主库和True Cache实例） 当发生Cache miss（缓存未命中）时，True Cache会从主库获取块 当True Cache实例首次启动，除了获取Cache miss的块，还会以large … Continue reading
23ai免费版本环境快速就绪
笔者感受就是搞一套Oracle 23ai的学习测试环境，从未如此的简单高效。 因为近期Oracle 23ai这个话题很火，很多人也在找实验环境想亲自体验测试一番。 其实搞这样的环境没有任何的门槛，甚至无需注册任何账号，直接安装免费的Oracle VM VirtualBox，下载现成的23ai环境，双击导入，就可以开始一系列有关23ai的测试工作了。 1.下载最新的Oracle VM VirtualBox 直接搜索下载即可，免费。 这里唯一需要注意的是，不要用过低的版本，实测过低版本无法正常运行，下面的这个版本我实测是运行正常的，不会有任何报错。 2.下载并双击导入 下载.ova后缀的这个文件 – Oracle_Database_23ai_Free_Developer.ova 下载地址：Oracle Database 23ai Free： – https://www.oracle.com/database/free/get-started/ 选择这个： 下载后直接双击导入到VirtualBox中： 3.启动运行导入的虚拟机环境 在VirtualBox中启动这个虚拟机环境： 4.所有环境已就绪 虚拟机启动成功之后，进入会发现所有常规测试所需的环境已经就绪，想测试啥就直接测试吧： 比如随手试下在23ai中是否内置支持创建带有vector数据类型字段的表： 此外，连APEX、SQL Developer等环境都是配置好的，测试非常方便： 还在等什么呢？耳听为虚，眼见为实，快来搭建属于你自己的23ai测试环境吧～
你真会判断DataGuard的延迟吗？
这是一个比较细节的知识点，但必须要理解这个才能准确判断Oracle ADG的延迟情况。 以前做运维工作时，记得是要同时重点关注v$dataguard_stats视图中的几个字段的值，分别是：NAME、VALUE、TIME_COMPUTED、DATUM_TIME。 本文先不考虑v$dataguard_stats视图没有数值显示的特殊情况，只针对当v$dataguard_stats视图正常显示的情况，如何准确判断Oracle ADG的延迟情况。 其实绝大部分管理过ADG的同学都知道，要重点关注NAME列中的transport lag和apply lag，看这两项在VALUE列中的取值，如果都是0，那基本没问题。 经验多些的同学还会在此基础上多关注TIME_COMPUTED、DATUM_TIME这两列的时间，是否近乎相同，和系统时间有无差异。 曾经遇到有用户在巡检ADG延迟时，只简单关注了前者，看都是0就判断没问题，可实际情况已经有很大的gap，这就是没有同时关注TIME_COMPUTED、DATUM_TIME的结果。 而若只关注TIME_COMPUTED、DATUM_TIME，却忽略掉NAME列中的transport lag和apply lag取值，这样也同样会可能造成误判。 如果说给建议就是要都关注，当然，有经验的DBA还会各种查其他信息加以证明，但这也不在本文讨论范围。如果只谈v$dataguard_stats视图，很多用户心里是没底的，因为不清楚细节，为什么会有各种表现情况呢？ 通过查阅官方文档，其实在这些字段的描述上也不够精确，容易造成误解。 所以，本文就构建这样的动手实验环境，来帮助大家通过上手实践来具体观察典型场景，加深理解。 场景1: TIME_COMPUTED、DATUM_TIME二者时间近似，且都随系统时间变化 这种情况，无法判定ADG是否延迟。 ADG的传输链路正常，但是ADG备库的MRP进程很可能出现问题，或者不是实时应用导致ADG延迟。 下面开始动手实践构造这类场景的测试用例： MRP进程异常crash，这里使用kill进程的命令来模拟，一段时间后再去查看ADG延迟的情况： PHYSICAL STANDBY @DB0913_DG -> SYS @CDB$ROOT> set time on 03:04:32 PHYSICAL STANDBY @DB0913_DG -> SYS @CDB$ROOT> @dg SOURCE_DBID … Continue reading
Posted in Oracle故障处理, Oracle日常运维
Comments Off on 你真会判断DataGuard的延迟吗？
超简单：必须要掌握的运维小妙招
常言道：生产运维无小事！尤其针对黑屏操作，相信不少客户都有自己的血泪史。 比如操作系统rm命令误删掉了关键系统数据… 比如执行关库操作后才发现连错了数据库… 除了对生产要有敬畏之心，做关键操作之前反复多确认，多人复核，其实还可以借助一些小妙招来减少紧张和焦虑情绪。 我们给客户做hands-on实验演示时，也可以通过这些小妙招来加快演示速度，同时能让观众更清楚Demo环境。 Oracle的小妙招 MySQL的小妙招 Oracle的小妙招 sqlplus界面优化 默认情况下，sqlplus连接到数据库，并不会清楚显示必要信息，只有默认的SQL> 有经验的运维人员做关键操作时，比如关闭数据库，会习惯性的确认当前连接的数据库是否正确。 同时，建议设置glogin.sql文件，示例如下： cd $ORACLE_HOME/sqlplus/admin/ vi glogin.sql 添加新内容如下： define gname=idle column global_name new_value gname set heading off set termout off col global_name noprint select upper (sys_context (‘userenv’, ‘DATABASE_ROLE’) || ‘ @’ … Continue reading
数据库有故障怎么了？
数据库故障是不可避免的，任何软件，无论是开源类还是商业类，只要是人创造的，就一定会存在产品缺陷（bug），软件越复杂，承载任务越繁多，触发bug的概率就越大，这是IT人的基本常识。 快速定位能力的关键性 真正重要的是，在出现故障时，如何迅速而有效地应对故障，定位故障根因并给出有效的解决方案，这才是确保业务连续性和稳定性的关键。也是决定一款数据库是否成熟的一项关键指标。 可是，也不知道当下风气是怎么了，好多人吧，不踏下心来好好研究自家产品，反而喜好打听别家谁出了啥故障，打听到后就跟中了彩票一样兴奋，之后就开始大作文章，跟客户直接说这产品不行。不晓得这些人是纯粹的天真，不知道这个道理，还只是为了各自利益，揣着明白装糊涂呢？ 聊到数据库的故障，这里先抛开其他除数据库本身之外进而引发数据库故障的复杂情况不说，也暂不去讨论因用户操作使用不当这类导致的故障，就只是单纯的聊下所谓很严重的产品本身bug导致的故障。 为了客观，避免有些人又喜欢去对号入座，我们就以业界公认领先的，各方面指标均很优秀的商业数据库产品Oracle来举例，因为它本身承载着当今世界众多重要客户的核心系统，这些人总不能去喷Oracle这款数据库产品也不行吧。 Oracle产品本身bug多么？ Oracle产品本身bug多么？ 其实真的很多。 但凡你有在生产环境部署过Oracle数据库，应用过PSU/RU补丁集，就会发现光是建议应用的这些补丁集列表中的bug就非常多，opatch lsinventory 列出的bug号码都能铺满好几页屏幕。 可是，因这些产品bug导致的故障多么？ 如果单拎出来某一个客户来讲，其实是不多的，甚至还存在许多自使用以来从未遇到任何软件bug导致故障的幸运客户，尤其一些IT建设比较薄弱的客户，虽然购买了Oracle，但也没打啥补丁，甚至一直连MOS都没登录过，压根儿就没遇到任何产品bug引发的问题。 但是每个bug其实都直接或间接的对应了某个场景下的故障，那这么多隐秘的bug在测试时都没发现，最终又都是咋发现的呢？ 反而是因为Oracle太流行，用户太多太广了，开头也提到了，bug这东西本身触发概率并不高，再举个量化的例子，比如说某个bug只有万分之一的概率被用户触发，也就是说1万个用户里面估计也只有一个人能有幸遇到，于是他遇到过提交给官方，出补丁，其他客户定期更新补丁集，就不会再遇到这个bug。 另外，如此庞大复杂的软件其实bug有很多的，但因为你这个场景遇到了A bug，我这个场景遇到了B bug，他那个场景遇到了C bug… 不断完善，你要是想成为全球第一个遇到某个bug的用户，其实都不太容易呢，所以产品稳定性得到了保障。 如果你的IT管理很有章程，按照官方的建议，定期更新推荐的补丁集，实际上就很难遇到bug带来的影响；即使有的客户因各种原因没有及时应用推荐的补丁集，某一天好巧不巧的触发了某个bug，基本MOS一查现象，也大概率会是已知bug，别人早就遇到了，补丁都是现成的，你只需要及时应用这个补丁即可解决。 小概率事件就可以忽略吗？ 既然这样，那用户真的就可以无为而治，万无一失了吗？ 也不是，小概率事件不等价于不可能发生事件，为了万无一失，还是要确保你所使用的版本在支持周期之内。这也是为什么有的用户讲我不用你新版本的new feature，为啥也要跟着升级版本的原因之一。 很多人会抱着侥幸心理觉得无所谓，自己不会那么倒霉，但一旦真的不幸遇到就会痛苦不堪。 这里再举个实际的例子吧，比如最近就遇到了一个case，简单说的确是因为产品本身bug导致的故障，现象是ADG的Redo Apply缓慢，这个bug其实也非常隐蔽，因为正常平时延迟都是0，根本发现不了，可运气不好的是，恰好在某个重要保障节点，因为OOM类的原因导致ADG同步被意外终止，且也没有被及时监控到，等用户感知到时，已经有了数小时的延迟，正常情况下，这问题也不大，重新启动同步进程Redo Apply也是很快会追平，可此时不幸的发现追日志的效率异常缓慢，基本相当于延迟多久就追了多久，虽然MOS能查到这个问题，也是一个已知的bug，但更不幸的是，目前在MOS上针对这个bug只有Linux平台的现成补丁，而客户的系统是AIX，并没有找到对应补丁，同时与后台SR进一步确认，确认是真没有，且研发也不会再出这个补丁了。 为什么呢？ 因为这是一个老的数据库版本，已经不在支持周期内，研发不会为此提供新的补丁。 好在这个bug不算硬伤，追上这次意外的gap之后就可以保持同步，可风险其实依然存在，在升级之前，我们也只能加强监控，避免类似问题发生影响，并强烈建议尽快把版本升级提上日程。 可能有人会讲，一个已知bug，别的平台都出了补丁，为啥就不能也给出个其它平台的补丁呢？要知道打个one-off的patch是很轻松的事情，但大版本升级可是一个大动作，还要协调应用测试配合，干嘛搞这么复杂呢？ 其实这样的策略才是真正的对客户负责，也是很合理的，首先Oracle一直都建议用户要使用当前有效期内的LTS长期支持的版本，这样才能集中更多人来更好的保证你的稳定性，Oracle的LTS其实已经是支持周期非常久的了。 而且，不升级的话，就算研发帮你修复了这个bug，但是后续的风险其实会更大，这种已不在支持周期内的版本，万一下次遇到的bug是非常严重的呢？ 数据库有故障怎么了？ 最后，回到正题，数据库有故障怎么了？ 还是那句话，数据库是一个软件，而且是一款非常复杂的软件，遇到故障是再正常不过的，如何迅速而有效地应对故障，定位故障根因并给出有效的解决方案，这才是确保业务连续性和稳定性的关键。 如果说谁家的数据库产品至今为止，都没有任何产品bug导致的故障案例，那并不代表这个数据库产品有多稳定，反而大概率是这个产品的用户量不够，没有积累到足够量的用户去踩到坑而已。 … Continue reading
Posted in Oracle故障处理
Comments Off on 数据库有故障怎么了？
同样的SQL，怎么突然就慢了？
本篇文章素材来源于某银行系统的一次性能问题分析。 许久没写这种troubleshooting类型的技术文章了，因为曾在服务公司呆过多年，工作原因，这方面之前做的多，听的更多，导致已经达到在自己认知维度下的一个小瓶颈，纯技术型的问题，稍微常见的基本都遇到过，非常少见的也基本是bug类（软件缺陷只能通过补丁或一些workaround的方式绕过去），感觉实在是没啥可写的。 另外注意，我这里说的“常见”指的是所有客户群中相对常见，而对单个具体客户而言，就非常可能从没有见过，这也是纯甲方技术人员（这里的纯甲方是指毕业就在一个甲方呆着，只能看到自己公司系统运行情况）的局限性，在早些年时，一些行业前辈们还会建议新的技术从业者即使想去甲方，也要先在乙方吃几年苦，能多见一些场景，再去甲方，这样会有比较准确的判断力，不至于轻易被乙方忽悠，也不会瞎挑毛病挑不到点子上让人鄙视。 前些日子有客户遇到问题，申请出差过去现场帮客户分析解决了，这个分析过程还是有些意思的，但最终结论简单来说就是DPR（直接路径读）问题，定位那一刻就觉得没啥可写的了，相关文章也太多了，今天突然想换个思路，看能否以故事线的方式来呈现这个问题，并解释所有技术细节，试图能够让所有人（包括技术小白）都能看得懂，所有用户相关信息均已做遮蔽处理。 首先你要忘掉这是个DPR的问题，让我们一起体会下这个分析问题的历程。 起初是被同事叫来帮忙一起分析客户问题，搞了一个微信群，客户先发了一些所谓异常时间的AWR、ASH、ADDM报告。 说明环境是普通X86服务器上的一套Oracle RAC数据库，版本是11.2.0.4，有应用补丁，触发BUG风险相对较低。嗯，还是要强调下，这里说的低只是说主观感觉上，因为11g已经摸爬滚打了那么多年，无数客户曾趟出的bug也都做了修复，遇到新bug的概率相对小而已，但并不是遇不到，一旦运气不好遇到就麻烦了，所以我们现在会强烈建议你升级到现有的LTS（长期支持版本）19c，可不要再用11g了。 这里提到非常有用的报告： AWR（Automatic Workload Repository） ASH（Active Session History） ADDM（Automatic Database Diagnostic Monitor） 其中ADDM相对用的少，它可以自动分析 AWR 中的性能数据，识别潜在的性能问题，并生成相应的建议报告。对于复杂问题可能不够准确，但至少也能给我们提供一个思路。 AWR可以记录某个时段下的真实负载情况，ASH可以在某个时段下看到是哪些会话在运行，非常好用，对等待事件的细致划分程度，也是其他数据库梦寐以求的东西。 和应用配合明确这个业务感知慢的SQL是否是AWR中显示的Top SQL，同时明确对应的具体sql_id，开始深入分析。 起初明确的sql_id，有一个对应的是一个存储过程，但此时没有进一步去查。 因为另外一个sql_id被认为更值得关注，这是一条简单的SQL，查询一个分区表，谓词条件只有一个定位到某一天的日期，该表是按月分区的。该SQL奇怪是正常的时候1分钟以内完成，异常的时候要接近10分钟完成，前者客户认为正常可接受，后者认为无法接受。 同样的SQL，查询不同日期，效率差距如此明显，另外客户反馈每天数据量基本相当，并没有数量级的差异。 此时最先想要排查的是是否有不同的执行计划？ 可结果并不是，执行计划虽然是全表扫，但是前后并没有任何变化。 当时给的AWR中，我也看了IO部分，但只有3.3G的量级，感觉影响并不大，就忽略掉了。 后来去现场，实际动手分析发现，其实故障时刻远没有之前的AWR报告那样轻描淡写，重新收集后续故障时刻的AWR（1小时间隔）可以看到此时的DPR非常显著，达到了314G+，要是之前做紧急救援服务，看到这就已经结束了，直接凭借经验断定，DPR禁用掉再看效果。因为再慢的话，会影响其他客户问题的处理进度。 其实那种凭借历史经验直接判断问题虽然有很快很厉害的感觉，但却是不严谨的，现在我们要进一步确认细节，确认是否是这个问题。既然是DPR，再看TOP SQL中通过Reads的排序，发现Top 2都值得关注，因为物理读几千万，和后面SQL存在数量级上的差异： Top 1是一个存储过程，Top 2是一个SQL，经确认这个SQL也是存储过程之内的一条SQL，但是并不是之前我们分析的那条SQL，说明之前提供的方向有一定错误。这也说明这个Top 2才是问题根本。 同时配合ASH也可以看到的确就是这SQL引发的DPR，导致性能严重下降。 … Continue reading
