Author Archives: Alfred Zhao
YUM退役了？DNF本地源配置
客户遇到在OEL8安装Oracle缺包问题，使用dnf安装也没有，甚至连oracle-database-preinstall-21c都装不上。本质是DNF配置问题。 早期为了解决这类问题，专门写过很多yum配置的文章，后来汇总一篇《Linux的yum源配置总结》，包含当时的各种版本各种配置，只要有人求助遇到此类问题就甩给他，十有八九都能自行解决。 https://www.cnblogs.com/jyzhao/p/12757735.html 现如今，很多年没搞这玩意儿了，恍然发现新版的Linux，yum都退出历史舞台了，改成了dnf… 残留的yum命令也都链接指向dnf。 起初以为是多么大的改变呢，因为自己的确没配过dnf本地源，所以为了给客户更好的指导，现下载了客户用到的OEL8.7介质，然后测试发现这东西没太大改变，最起码对于使用者，是换汤不换药，本质还是此类问题，不会很复杂。 过程中顺便熟悉基本的OEL8的一些命令吧。 1.虚机装OEL8.7 2.配置dnf本地源 3.安装Oracle所需包 1.虚机装OEL8.7 如今是真的没办法才会临时使用虚机，因为云时代真的是太方便了。 使用Virtual Box安装，发现现在虚机的安装也比以前省事太多，输入一些必要信息，虚拟机直接自己就能安装好了。 唯一动手的，就是配置改了下网络，修改使用Host-Only网络，为了模拟不连接外网的客户环境。 IP地址为：192.168.56.4 这里用到OEL8中，重启指定网卡enp0s3的命令： nmcli connection down enp0s3 nmcli connection up enp0s3 之前熟悉的ifdown、ifup啥的，默认的安装下都没有。。 查看IP配置信息： ip addr 2.配置dnf本地源 起初以为多麻烦，实际完全一样。没啥技术含量直接贴出我的配置，供大家参考： 我是新建的一个文件oel.repo。 [root@OEL8 yum.repos.d]# cat oel.repo [OEL8.7-APP] name=oel8.7 baseurl=file:///media/AppStream/ enabled=1 … 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测试环境吧～
免费考AI OCP认证，附通关秘籍！
这是一个能让你快速熟悉AI相关技能的考试，由Oracle官方提供，而且限时免费。 它就是OCI Generative AI Professional。 可以看到，目前免费政策正在执行，到今年的7月31号截止，有想法的小伙伴们要抓紧学习了。 具体信息可参考OU官方的介绍：全新推出OCI Generative AI免费认证 最近刚考完这个认证，下面具体来分享实际考这个认证的经验，可作为通关秘籍，帮助大家建立信心。 整个通关过程涉及到4个部分： 其中第一部分OCI Generative AI Professional是这个认证配套的培训课程，一共6h+，非常经典，认真听讲一定会受益匪浅的。 即便你没有需求一定要通过这个考试，了解课程中讲到的一些概念，对加深AI LLM基础原理的理解也是非常有帮助，课程中举的例子都是那种相当简单易懂的类型。 在第一个部分中的重点章节会穿插有本节小测试，给出的5道题答对4道就OK，基本认真听讲都没问题，如果这里正确率没有达标，说明在课程的某些地方走神了，需要回过头来认真听再重新测试就可以。 还有个小技巧，遇到当时不能理解的，先记下来，完整听一遍后回头再看，比如T-Few这些的概念之类。 估计有很多人会习惯性的以为看完这个课程就可以直接约考试了，但实际上后面的才是秘籍所在，可以说都是实打实的帮你提升通过考试的概率。具体来说： 第二部分Prepare for OCI Generative AI Professional Certification，就是在告诉你如何答题，这个部分给出的9道示例题，很多都是在你实际考试中会出现的原题或是母题。而且讲师会手把手的带你分析如何选出正确答案。 第三部分Practice Exam: OCI Generative AI Professional Certification，更是直接给你25道题做练习测试，不过这里的设计是，你答对了会有解析，答错了就只会告诉你答错了，不会告诉你正确答案也没有解析，但这也相当于帮助你排除了一个错误答案。这些题感觉上也有不少原题或是母题，非常利于提升考试成绩。 总之，第二第三部分同样非常重要!!! 如果轻视了第二第三部分，比如只看了第一部分的课程去考试，是擦边通过的水平（40道题答对26道是65分），但若能在这个基础上，好好利用第二第三部分的内容，就会大幅提升你的考试成绩，感觉会到90分左右，这就是最关键的通关秘籍喽～ 当前面三个部分都认真完成之后，恭喜你，离成功就差一次真正的考试了，第四部分就是指导你预约一个合适的时间，准备好自己的身份证件，找一个安静的地方，按要求check in，考官提示你OK，给你一个码输入后，就可以正常开始考试了，考试通过后会收到类似这样的OCP证书，和传统DB类证书没有有效期不同，这个证书的有效期是2年： 最后祝大家都能顺利通过这个考试，同时对AI的理解更上一层楼。 Good … Continue reading
MAC批量删除文件名中某一段的内容
有时候从网络下载的资源，文件名会带有一些广告，比如网址之类。 因为文件通常很多，一个个改名工作量太大且乏味。 所以，测试写命名替换更高效，比如下面就是查找当前目录下，文件名包含【www.alfredzhao.cn】的部分直接删除掉，但保留文件名的其他部分。 find ./ -type f -name ‘*【www.alfredzhao.cn】*’ -exec bash -c ‘f=”{}”; mv — “$f” “${f//【www.alfredzhao.cn】/}”‘ \;
你真会判断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的延迟吗？
难道AI不知道tnsnames.ora的instance_name配置吗？
事情是这样，给某客户培训构建hands-on实验环境时，因测试环境有限，在同一环境做了一套ADG环境； 数据库是单实例，版本19.21，使用了多租户选件； 其中一个测试的PDB，名为demo1，其中建好测试用户jingyu，遇到的问题是： 使用sqlplus连接时，会随机连接到主库或者备库。 排查定位也很简单，因为这样的环境，监听lsnrctl status可以看到对应的服务下，是存在两个实例的，一个是主库，一个是ADG备库，但是，修改配置tnsnames.ora时，指定具体实例的语法怎么写，AI误导我走了弯路。 监听服务如下： Service “demo1.sub00000000000.xxvcn.xxxxxxvcn.com” has 2 instance(s). Instance “DB0913”, status READY, has 1 handler(s) for this service… Instance “DB0913_DG”, status READY, has 1 handler(s) for this service… tnsnames.ora配置如下： DEMO1 = (DESCRIPTION = (ADDRESS = (PROTOCOL … Continue reading
超简单：必须要掌握的运维小妙招
常言道：生产运维无小事！尤其针对黑屏操作，相信不少客户都有自己的血泪史。 比如操作系统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
