Monthly Archives: June 2024
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
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
