ITPub博客

[20260825]利用proc查看对应地址信息的方法.txt--//昨天测试 [20260823]数字字典对象hash的计算验证.txt时,遇到的问题:krqhsh Begin[15:57:23] kgghash #11 pid=3809 hash_text=m\x00\x00\x00\x04\x00DEPT\x00......x00\x00\x00\x00\x00\x01\.......\x0

[20260825]sqlplus输入nul字符问题.txt--//上午测试遇到的问题,单独拿出来做一个记录.1.环境:SYS@book> @ ver2==============================PORT_STRING             &n

[20260825]ora_hash与kgghash函数.txt--//昨天测试使用oracle的ora_hash函数计算数据字典对象的hash值,使用bpftrace跟踪发现调用oracle的内部函数kgghash,与我手工执--//行ora_hash计算结果一致.既然这样是否可以反向验证如果执行带有ora_hash的sql语句,使用内部调用kgghash函数.1.环境:SYS@book>

[20260824]数字字典对象hash的计算验证.txt--//前面的测试已经猜测数据字典对象hash的大致计算方法。拿来验证看看。1.环境：SYS@book> @ ver2==============================PORT_STRING           &n

[20260824]数字字典对象hash的计算.txt--//前几天探究row cache时，好奇对应的hash值如何计算，经过多次尝试，大致知道算法。1.环境：SYS@book> @ ver2==============================PORT_STRING         &nbsp

[20260824]gdb的使用问题.txt--//想写一个gdb脚本跟踪oracle kqrhsh函数的调用，实际上以前也遇到类似情况，做一个记录：1.环境：SYS@book> @ ver2==============================PORT_STRING          

[20260824]bpftrace的str和buf函数使用问题.txt--//使用bpftrace脚本使用str与buf函数遇到的问题,通过例子说明问题：1.环境：SYS@book> @ ver2==============================PORT_STRING         &nb

[20260819]关闭pdb CON_NAME=PDB$SEED.txt--//发现CON_NAME=PDB$SEED,缺省打开在READ ONLY模式，如果不通过它建立新的pdb根本不需要，也就是我的测试环境根本无需要每次启--//动都打开到read only,做一个记录关闭它、1.环境：SYS@book> @ ver2==============================PORT

[20260818]建立完善dc_objects.sql脚本.txt--//原先写的脚本有点问题user_id=1,dba_users以及cdb_users视图没有public用户，实际上public是特殊角色。--//使用CONTAINERS(sys.user$)代替user$.--//另外即使使用CONTAINERS(sys.user$)，查询也不包括CON_ID=2，CON_NAME=PDB

[20260818]21c X$表的分析与直方图信息2.txt--//偶然发现这个问题，在测试环境演示出来,这与我的个人维护习惯有关。1.环境：SYS@book> @ ver2==============================PORT_STRING           &n

[20260815]centos 9 sar安装.txt--//发现安装的centos 9，没有sar命令# sarbash: sar: command not found...Failed to search for file: /mnt/cdrom/BaseOS was not found# mount /dev/sr0 /mnt/cdrom/ -o ro# sarbash: sar: com

[20260813]简单探究row cache的相关问题2.txt--//继续昨天的探究:--//疑问:前面测试查询如下SYS@book> select rownum cache# from dual connect by level <=65 minus select cache# from v$rowcache where type='PARENT'; &

[20260812]简单探究row cache mutex的相关问题.txt--//继续昨天的探究.--//假设一个表scott.dept，对象类型dc_objects，oracle如何确定那些chunk上寻找row cache mutex以及row cache hash呢?  必须还--//有chunk记录这些信息.1.环境:SYS@book> @ ver2===========

[20260811]简单探究row cache mutex的定位问题.txt--//如果知道某个对象hash值，在row cache如何定位呢？--//首先说明这些分析讲的不好听就是瞎猜,对不对我自己都不是很清楚.1.环境：SYS@book> @ ver2==============================PORT_STRING    &nbs

[20260810]简单探究row cache mutex.txt--//昨天的测试使用mutexprofz.sql脚本输出有mutex_addr地址，不知道是否巧合2个hash相差1，对row cache mutex做一个简单探究。1.环境：SYS@book> @ ver2==============================PORT_STRING   

[20260810]测试遇到的问题(21c).txt--//昨天测试遇到的问题，单独拿出来测试验证看看。1.环境：SYS@book> @ ver2==============================PORT_STRING             &nbsp

[20260810]row cache的直方图信息.txt--//昨天探究row cache mutex等待事件关联的对象。oracle 缺省分析方法是auto，这样会在表的一些字典上建立大量的直方图信息。--//实际上许多字段根本不需要建立直方图，尝试建立表并且建立直方图，看看相关字段直方图占用共享内存的情况。1.环境：SCOTT@book01p> @ ver2==============

[20260809]Row Cache Mutex 定位具体对象的方法.txt--//利用sql语句select sid from v$mystat where rownum=1;密集执行时会出现row cache mutex等待事件，测试是否能定位具体对象。--//主要原因执行如下查询，没有返回记录。SYS@book> select * from v$rowcache_parent whe

[20260809]跟踪执行select sid from v$mystat where rownum=1;.txt--//前段时间测试cdb下密集执行select sid from v$mystat where rownum=1;很慢，发现调用kgllkal函数在实例对象上，大量的执行必--//然要在该对象上产生争用。出现library cache: bucket mutex X，library

[20260808]测试21c cursor_sharing=force下的library cache lock pin的情况.txt--//补充测试21c下cursor_sharing=force下的library cache lock/library cache pin的情况.1.环境：SCOTT@book01p> @ ver2==============================