ITPub博客

[20260806]测试11g cursor_sharing=force下的library cache lock pin的情况.txt--//补充测试11g下cursor_sharing=force下的library cache lock/library cache pin的情况.1.环境：SCOTT@book> @ ver2==============================POR

[20260802]测试遇到的问题.txt--//我的测试很喜欢写一个脚本，打开一定数量并发，执行特定循环次数，看看遇到什么相关等待事件。前段时间测试带dblink的sql语--//句密集执行的情况，以及select sid from v$mystat where rownum=1的pdb与cdb情况，实际上测试应该选择类似sql语句执行格式：select /*+ &3 */sid fro

[20260725]centos 9安装dstat rpm包.txt--//今天检查发现安装的centos 9没有安装dstat,查询iso文件,发现竟然没有dstat rpm包,有点意外.--//而且记忆里安装后我使用过,什么会现在不能使用了,也许删除软件包时附带删除了.--//查询发现: 原始dstat在CentOS 9/RHEL 9 中已被官方移除，因为它基于 Python 2 且已停止维护

[20260724]putty配置tunnel远程连接.txt--//以前测试过，参考链接：[20210929]putty配置tunnel远程连接.txt--//理论讲配置ssh tunnel并且勾上 Local ports accept connections from other hosts,remote ports do the same(SSh-2 only).--//配置好的端口无论是l

[20260721]测试带dblink的sql语句密集执行的情况(整理版本).txt--//前面测试带dblink的sql语句，每次都会存在对dblink对象的library cache lock，测试密集执行这类sql语句会出现什么情况。1.环境：SCOTT@book01p> @ ver2==============================PORT_STRING &nbs

[20260718]跟踪带dblink的sql语句的library cache lock/library cache pin的使用情况.txt--//还从来没有使用自己写的gdb或者其他脚本跟踪带dblink的sql语句，看看相应sql语句使用library cache lock/library cache pin的情况.--//为了测试比较符合实际情况，使用2个数据库，版本都是21c。1.环境：

[20260717]ORA-02011 duplicate database link name.txt--//在centos 9，IP=192.168.56.103上建立dblink，报ORA-02011 duplicate database link name错误,做一个记录：1.环境：SCOTT@book01p> @ ver2==============================

[20260715]对象RECO.ORACLE.COM的FULL_HASH_VALUE.txt--//后记:链接 https://www.anbob.com/archives/9706.html =》High 'latch: shared pool' and 'library cache: mutex X' in--//Oracle 19c(19.13),我没遇到这

[20260715]sqlplus定义绑定变量名长度.txt--//测试需要了解定义绑定变量名长度，通过例子说明问题：1.环境：SCOTT@book01p> @ ver2==============================PORT_STRING           &nbsp

[20260709]centos 9登录提示信息.txt--//安装centos 9，使用kitty(putty变体)从windows登录linux服务器，总是出现如下内容：Using username "root".root@192.168.56.103's password:Send automatic passwordActivate the web consol

[20260708]vim字符集以及寄存器问题.txt--//最近几天总是莫名其妙的vim里面的寄存器保存内容存在问题，我自己有一个习惯把一些长的复杂按键以宏的形式记录在寄存器中，--//里面包含一些非ascii字符,只要执行@寄存器就是可以执行,前面加数字可以重复次数。--//仔细检查才发现问题在于最近打开一些utf-8的文本，设置:set encoding=utf-8，导致寄存器的内容发生变化

[20260707]验证跟踪library cache lock library cache pin使用bpftrace的脚本是否执行正确.txt--//跟踪[library cache lock library cache pin使用bpftrace的脚本增加获得library cache lock address以及library cache pin--//address，不知道是否正确，通过

[20260703]完善跟踪library cache lock library cache pin使用bpftrace.txt#!/usr/bin/env bpftraceuprobe:/u01/app/oracle/product/21.0.0/dbhome_1/bin/oracle:kgllkal/ $1 == 0 || pid == $1 /{    @lk+

[20260703]跟踪library cache lock library cache pin的bpftrace脚本转换为bcc脚本--//首先说明bcc的脚本不是我写的，是使用kimi生成，仅仅提供bpftrace脚本。$ cat lkpn21c.bt#!/usr/bin/env bpftraceuprobe:/u01/app/oracle/product/21.0.0/dbhome_1/bi

[20260629]跟踪ora_cjq0_<sid>进程.txt--//上午使用bpftrace脚本跟踪library cache lock /library cache pin.在测试环境跟踪全部进程时出现如下情况:$ cat lkpn21c.bt#!/usr/bin/env bpftraceuprobe:/u01/app/oracle/product/21.0.0/dbhome_1

[20260629]使用bpftrace跟踪library cache lock/library cache pin的疑问.txt--//写了使用bpftrace跟踪library cache lock/library cache pin的脚本,想看看跟踪全部进程的情况，注：我的测试环境仅仅自己在--//使用，如果如果生产系统，不知道会发生什么情况。# cat  /home/oracle

[20260629]跟踪library cache lock library cache pin使用bpftrace.txt--//以前写过一个跟踪library cache lock library cache pin使用gdb的脚本，尝试使用bpftrace在写一个类似脚本。$ cat lkpn.gdbset pagination offset logging file /tmp/lkpn.l

[20260628]测试不同字符集使用dblink的情况.txt--//测试不同字符集使用dblink的情况,数据库oracle 21c。--//网络地址       主机名   数据库字符集        国家字符集--//192.168.56.1

[20260628]centos 9下安装bpftrace软件包.txt1.检查发现没有安装bpftrace。# rpm -qa | grep bpftrace# locate-cdrom bpftrace/mnt/cdrom/AppStream/Packages/bpftrace-0.24.2-1.el9.x86_64.rpm/mnt/cdrom/AppStream/Packages/pcp-p

[20260626]等待事件external table read.txt--//很久以前就知道21c启动，要执行$ORACLE_HOME/QOpatch/qopiprep.bat的脚本，特别是第1次启动数据库，执行非常缓慢，需要13秒--//完成,主要出现的external table read等待事件，以前做过探究，启动实例后由后台进程mmon完成。--//尝试启动服务器centos 9，使用