Category Archives: Oracle
Exadata系列之配置利器OECA
Oracle Exadata Configuration Assistant (OECA) 是一款简便的配置工具，用于快速生成Exadata系统的推荐配置方案。它根据用户的需求和负载特点，自动推荐合适的硬件和存储配置，简化配置过程，并确保性能和可扩展性最佳。 1.OECA工具下载并准备就绪 2.使用OECA配置Exadata X7-2 HC 八分之一配置 3.使用OECA配置给上述配置增加HC存储节点 4.使用OECA配置Exadata X10M-2 HC 八分之一配置 5.使用OECA配置Exadata X10M-2 HC 四分之一配置 1.OECA工具下载并准备就绪 OECA工具官方下载地址： – https://www.oracle.com/database/technologies/oeca-download.html 需要登录Oracle账号，然后勾选同意标准条款并点击下载： 首先下载到的是一个下载工具，比如我MAC的环境就是这个包： – Oracle_SSN_DLM_11120313.dmg 选择下载路径： 成功下载OECA的压缩包： – V1045466-01.zip 解压之后，可在web文件夹下找到index.html，双击在浏览器中打开： 在浏览器中的打开的初始效果如下： 因为此时还没有输入任何有效配置信息，所以Rack Validity Status显示红色的Rack Config is NOT … Continue reading
Oracle的用户如何优雅地达成软件合规目标
企业一旦发展到了一定规模，就会衍生软件100%合规正版化的需求。 而对于使用到Oracle的用户，当然，具体核定的购买数量和off等商务问题，需要客户管理层直接和对应的Oracle销售代表进行商务谈判。 理想情况下，一旦用户面临这个场景，就需要安排自己的技术负责人提前梳理清楚公司目前到底都用了哪些付费选件和管理包，并清楚Oracle计算价格的规则。 因为Oracle是Paper license，很多中小客户早期很可能都没这个意识，所以一旦在某个重要节点被提出来合规要求，都显得有些手足无措，尤其对Oracle一系列复杂的细分产品选件细节定义顿感头痛。 有些客户也会选择邀请我们专门给他们培训解释这些规则。为了让更多有需求的客户能在未来正式的商务谈判中不至于太被动，优雅地达成合规正版化。 这里介绍下如何下功夫先自行梳理一番，做到自己心中有数。 好在这些产品定义信息并不是秘密，规则也都是公开透明的，甚至连列表价都是公网可查的： Oracle Technology Global Price List 目前能查到的最新版本，发布时间是June 13, 2024，在公网也能直接搜索到。这里贴出最普遍的Oracle数据库部分来举例说明： 细节在官方文档有非常清晰的描述，比如Oracle数据库的所有license细节都可以在这篇文档中找到依据： Database Licensing Information User Manual https://docs.oracle.com/en/database/oracle/oracle-database/23/dblic/Licensing-Information.html 本文挑重点部分聊下，通常有哪些困惑和常见的误解。 1.Partitioning是指分区？分区还收费？ 2.RAT是指啥？咋小老鼠还收费呐？ 3.ADG中链路压缩还需要高级压缩选件？ 4.高级安全都有啥？ 5.In-Memory的免费使用条件？ 6.Diagnostic Pack是必选项？ 7.Tuning Pack能不用吗？ 彩蛋1：Oracle产品是都按照Core收费吗？ 彩蛋2：警惕那些看起来人畜无害的小参数！ 1.Partitioning是指分区？分区还收费？ 是的，就是针对表或索引的各种分区，都是算Partitioning这个选件中的。 很多用户会很容易认同RAC、ADG这种看着就很大的功能，作为Option还很好理解，而误以为分区是数据库内部很基础的功能，应该归属于DBEE的功能中，但实际上，它也是在DBEE之外，作为一个独立的付费Option。 参考官方文档内容： These … Continue reading
使用触发器来审计表的DML、DDL操作
最近帮客户排查某问题时，因为怀疑应用对某张配置表有变更，所以需要对这张表的所有操作进行审计。 原本Oracle对某张表的审计是非常方便的，一条命令就可以实现，也不需要费心自定义审计表。 — 启用对表DEPT的插入、更新和删除操作的审计 AUDIT INSERT, UPDATE, DELETE ON DEPT BY ACCESS; — 查看对DEPT表的所有审计记录 SELECT * FROM DBA_AUDIT_TRAIL WHERE OBJ_NAME = ‘DEPT’; — 停用对表DEPT的审计 NOAUDIT INSERT, UPDATE, DELETE ON DEPT; 但不幸的是，因为客户当前环境已经把默认开启的audit_trail给关闭了。（默认开启，默认值是DB，关闭就是NONE） 笔者已经在实验环境验证过： – 1.audit_trail必须开的情况下，对表进行审计才会有记录； – 2.audit_trail是静态参数，如果修改，需要重启数据库才可以生效。 尤其注意要检查这个参数的设置情况，因为这里比较坑的一点是，上述审计命令，即便你关了这个参数，开启表审计的命令执行也并不会报错，只是实际上无法记录。 相信大家都知道，生产环境的重启申请流程非常麻烦，因此只能用手工的方式，比如自定义触发器的方式来监控这张表的DML操作。 还好因为这个配置表正常情况下，并不会被频繁修改，所以使用触发器也不会带来什么性能问题。 下面就进入到hands-on环节，我们模拟下这个客户的需求，假设dept这张表: … 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
