Author Archives: Alfred Zhao
免费考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
Oracle与MySQL的差异和对比
Oracle与MySQL的差异和对比：配套hands-on参考脚本。 方便客户针对培训课件内容进行动手实践，加强理解。 ——————————— — 主题：Oracle与MySQL的差异和对比 — 一、MySQL的基础特性 — 二、重要特性差异对比 — 三、性能对比和优化技巧 ——————————– Hands-on场景环境准备@MySQL实例 ——————————– — Hands-on场景环境准备@MySQL实例 ——————————– –Create db & user CREATE DATABASE demodb; CREATE USER ‘alfred’@’localhost’ IDENTIFIED BY ‘alfred123’; GRANT ALL PRIVILEGES ON demodb.* TO ‘alfred’@’localhost’; GRANT SELECT ON … Continue reading
AI助力快速定位数据库难题
最近很多人都在讨论AI能否替代人类工作的话题，最近笔者正好遇到一个AI帮自己快速定位问题的实例，分享给大家，一起来切身感受下AI对于解决数据库问题的价值吧。 事情的经过是这样，有个朋友咨询我，说他最近遇到一个客户的数据库问题现象非常诡异。 就是有一套Oracle数据库实例不知何时变成了mount状态，但客户确认这套库之前是open成功的，而且也有数据库监测，数据库若有重启就会告警，可监控期间也没有发现数据库有任何重启行为。 而且，实例的启动时间，也是上次open数据库的时间。 看到这样的描述，首先要确认下，启动时间，是否open的动作成功了？ 另外，监控是否有问题，建议人工通过alert告警日志搜索是否有数据库状态改变的痕迹。 这个做法并不是不相信客户，是因为问题troubleshooting都讲究一个证据链，就好像律师一样，要收集现有证据然后基于这些证据来找到问题本质。 于是就开始收集证据： 1. alert告警日志，上次open的操作是成功的 Physical standby database opened for read only access. Completed: alter database open 2. 遍历搜索重启操作 在上次open动作之后的时间点，没有发生过重启。 3. 实例当前状态和启动时间 确认是mount状态，启动时间是上次open的时间没错。 嗯，以上这些基础验证朋友其实在之前排查时也都做过，也正因为各种搜索也没有找到有用的信息，所以问我有没有遇到过这个情况？ 我其实也没有遇到过，且当时正在外地出差，又约好了客户时间要马上出发去现场做交流，所以并没太多时间深入去帮忙排查这个问题。 基础理论和操作大家都很清楚： Oracle的启动流程，是经过nomount、mount、open三个阶段 已经open的数据库，如果想要切换成其他状态，正常操作是需要先shutdown关闭数据库，再启动到某个状态 可这个与现在的事实相违背，难道说某种情况下可以不重启直接从open状态到mount状态？ 带着这个疑问问了下基于LLM的AI，没指望没经过RAG专门训练的通用AI能直接定位问题，但从其回复的内容还是看到一句话引起了我的关注： 手动执行了ALTER DATABASE CLOSE的命令… Oracle有这个手工执行的命令吗？恐怕99%的人都不知道吧。 alter … Continue reading
Posted in AI
Comments Off on AI助力快速定位数据库难题
AI热点概念解读：一文搞懂这些热词
自 ChatGPT 问世以来，AI的风口就来了。 AI是一门研究如何使计算机具有类似人类智能的学科。 自从ChatGPT-3.5给大家带来了极大的震惊之后，全民都在谈论AI，在这个AI大时代背景之下，如果你想进一步了解AI相关热词含义，从而更好的理解当下AI的基础原理，本文就不容错过。 如今，当你找专业人士解释一些关于AI的基础概念，最大的问题就是，你也许只是想简单的了解一个热词的简单解释，回答者跟你解释时，却引入了更多你不熟悉的新概念。 当你不得不追问这些新概念的含义时，却发现又引入了一堆新词，此刻是不是感觉头都大了？其实这么多新词和概念也很难通过一次简短的询问来搞懂并厘清期间的关系。 如果你也有这样的困惑，无论是提问方还是解答方，都可以利用这篇文章来帮助自己理解或辅助回答。 下面我们就从最熟悉的ChatGPT切入提问，看看都有哪些AI相关高频词汇，又各自是什么意思。 ChatGPT 是什么？ ChatGPT是一种LLM（大语言模型），具体是由OpenAI开发的一种聊天型生成预训练模型。它基于GPT架构，专门设计用于处理自然语言对话和生成有意义的回应。 LLM（大语言模型）是什么？ LLM英文全称是：Large Language Model。 大语言模型通常是指参数规模庞大、在大规模语料库上进行训练的自然语言处理模型。 另外LLM也不止OpenAI的GPT一种，还有其他很多家，比如Meta的Llama 2，以及更专注于企业应用的Cohere等。 OpenAI 是什么？ OpenAI是一个人工智能研究实验室，致力于推动人工智能的发展。 OpenAI 是许多先进语言模型的背后力量，其中最著名的就是 GPT 系列。 GPT 是什么？ GPT 全称是 “Generative Pre-trained Transformer”，翻译成中文是”生成式预训练转换器”。 GPT 是 OpenAI 提出的一系列预训练语言模型，它采用了 Transformer 架构。这些模型在大规模文本数据上进行预训练，学习了丰富的语言知识，可以用于各种自然语言处理任务。 Transformer … 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 数据库有故障怎么了？
您好，2024！
首先，2023是非常充实的一年，虽然很难，但增强了抗压能力，心态也变乐观了。 2024主要计划是延续2023的大方向继续努力前行。 工作&学习篇： 1.博客园继续保持更新；（已成为习惯） 2.从用户视角重新认识全栈技术，重点项目用心做；（需要主动性） 3.重点产品XD深入学；（软硬件等） 4.典型国产DB代表多了解；（OB架构设计、版本迭代） 5.PPT功底继续提升；（软技能） 6.英语能力全面提升；（软技能） 生活篇： 7.锻炼身体逐步达成目标；（游泳健身） 8.自驾游探亲；（计划今年暑假时期） 9.出国旅游；（非今年） 工作&学习篇： 1.博客园继续保持更新；（已成为习惯） 2023依然坚持，且开始同步微信公众号，文章开始注重故事性叙述，降低阅读门槛，增强趣味性。 2024会继续保持。 2.从用户视角重新认识全栈技术，重点项目用心做；（需要主动性） 2023有重点项目在进行中； 2024会继续支持有价值的项目，实现双赢。 3.重点产品XD深入学；（软硬件等） 最新的X10M软硬件情况有过了解，后续关注更广的维度，将XD作为DBA了解硬件和扩展知识体系的方式。 2024会继续深入，包括但不限于独特特性，相关专利，关于白皮书中可量化的性能指标等。 4.典型国产DB代表多了解；（OB架构设计、版本迭代） 2023因为精力分配问题，了解不够多，只是粗浅的案例层面； 2024会加强这方面的学习，可以参考OBCP的课件做整体了解，并关注最新版本发展情况。 5.PPT功底继续提升；（软技能） 目前满足工作需求； 2024如果有时间会精进，但不作为重点关注点。 6.英语能力全面提升；（软技能） 目前提升ing，没有量化的指标，不给具体的压力。 口语带孩子互动练； idea：模拟情景剧，比如新概念题材，和孩子一起学习。 英语精读，贯穿全文，找到整个文章各个段落之间的关系； 之前极客时间有课程材料，可作为素材。 英语写作，结合精读的方法，加强写作训练。 先从工作邮件加强，再逐步扩展到其他方面。 生活篇： 7.锻炼身体逐步达成目标；（学习游泳） 2023已自学游泳； … Continue reading
