ITPub博客

[20220216]为什么出现这样的情况.txt--//春节放假期间,看来以前一个帖子,很奇怪的发现以前写的链接:--//[20191213]共享池绑定变量的值在哪里.txt=>http://blog.itpub.net/267265/viewspace-2668705/ --//里面查询子光标堆0时,发现多了一个chunk,按照以前测试这里仅仅显示一个chunk,为什么呢?--//我重复测

[20220129]完善tpt ash ash_index_helperx脚本.txt--//tpt scripts包的ash目录下有两个脚本ash_index_helperx.sql，ash_index_helper.sql脚本用来定位表来提供索引建立帮助。--//不过我下载执行包如下错误。SYS@127.0.0.1:9105/dbcn> @ash/ash_index_helper % p

[20220128]Check the datapump file header information in Oracle.txt--//昨天看了链接:smarttechways.com/2022/01/17/check-the-datapump-file-header-information-in-oracle/,自己尝试看看.1.环境:SCOTT@book> @ver1PORT_STR

[20220125]生产系统怪异的查询语句.txt--//生产系统有一些编程工具会执行一些怪异的查询语句,检查生产系统时发现一些奇怪的语句.1.环境:> @ prxx==============================PORT_STRING            &

[20220124]index split level.txt--//https://jonathanlewis.wordpress.com/2022/01/09/oeri-6051/,重复测试:1.环境:SCOTT@book> @ ver1PORT_STRING          &nbsp

[20220124]验证oradebug dump heapdump 2050中chunk的第1字节表示chunk size+1.txt--//验证oradebug dump heapdump 2050中chunk的第1字节表示chunk size+1,顺便复习awk的使用.1.环境:SCOTT@book> @ver1PORT_STRING    &n

[20220124]开发不应该这样写sql3.txt--//在sql优化中,遇到sql语句出现这样的写法:select ...(case                 when basyxx.icu_start is not null t

[20220124]group by bug.txt--//https://jonathanlewis.wordpress.com/2022/01/01/happy-new-year/,重复测试:1.环境:SCOTT@book> @ ver1PORT_STRING          &nbsp

[20220120]超长sql语句补充4.txt--//昨天通过oradebug peek 查看超长sql语句父游标句柄的chunk如何将sql语句连接在一起的,--//我当时查看时有点吃惊,开始每个chunk的sql语句长度仅仅0x201=513字节,这样34140/513 = 66个chunk,需要不断地oradebug peek--//才能完成,我差点想放弃,当时就想写一个脚步完成测试,今天

[20220121]Hash Aggregation.txt--//https://jonathanlewis.wordpress.com/2022/01/17/hash-aggregation-1/,重复里面的测试:1.环境:SCOTT@book> @ver1PORT_STRING         &

[20220121]windows使用grep注意.txt--//昨天在windows下使用grep遇到一个问题.D:\notes>grep -l -r -i 'v_t' *2014/201401/[20140113]视图与修改操作.txtD:\notes>grep  -r -i 'v_t' *2014/201401/[20140113]视图与

[20220121]开发不应该这样写sql2.txt--//生产系统遇到的优化问题,原始语句很复杂,在测试环境做一个分析并记录.1.环境:SCOTT@book> @ver1PORT_STRING                &nbs

[20220119]超长sql语句补充3.txt--//前几天做了超长sql语句的探究,主要目的看看如何连接起来sql语句,写的有点乱,今天做一个例子验证自己的判断.1.环境:SCOTT@book> @ver1PORT_STRING             &nb

[20220117]超长sql语句.txt--//最近一直在做一个优化工作,发现一些sql语句超长.主要有两种情况:1.第一种不知道那个开发写sql代码都是一行,而且字段与字段之间还有很多空格,导致语句很长.导致我抽取后给格式化,然后在考虑优化问题.我甚至要设置set linesize 32767,不然会出现换行问题.导致抽取的语句无法执行.而且sqlplus语句有最长239字符.2.另外一个问题

[20220117]调用bccalc_win.vim插件失效.txt--//同事给我一个sql语句脚本看看,我当时在里面写一个算式调用我写bccalc_win.vim插件,发现计算失效.--//我手工执行开头出现乱码,感觉很奇怪,我顺便自己建立一个文本,测试没有任何问题,仔细检查发现,原来文本的格式是保存为utf-8.--//执行:set fileencoding,返回utf-8.我修改为set

[20220111]完善tpt ashash_index_helper脚本.txt--//定位索引问题很好,但是有时候开发执行不需要优化,主要原因可能他们的带入参数使用非绑定变量,有时候出现隐式转换,--//又时候仅仅执行此事很少,这类语句要排除在优化范围之外.修改ashash_index_helper脚本,加入一个查询字段lower(module).$ cat ash_index_helper.

[20220111]该语句的sql_id如何计算的.txt--//昨天定位一个数据库问题,我发现使用我的计算sql_idx.sh的脚本计算不对,做一个记录并分析.> select sql_id,prev_sql_id from v$session where sid=14382;SQL_ID        PREV_SQL

[20220109]开发不应该这样写SQL语句.txt--//最近一段时间优化sql语句,遇到一个语句我开始以为我能够优化它,结果仔细检查尝试后发现不行,在测试环境做一个例子演示出来看--//看.1.环境:SCOTT@book> @ ver1PORT_STRING          &nbsp

[20220106]ora-00600  kokasgi1.txt--//上午看了https://www.xifenfei.com/2022/01/2022-first-recovery-ora-600-kokasgi1.html的恢复,我前一阵子也帮别人做了1次恢--//复。作者通过特殊手段启动数据库,然后修改SYSXX为原来SYS用户。我仔细想想应该类似以前laoxiong的恢复。-

[20220105]sqlplus &1替换最大支持239个字符.txt--//昨天遇到的问题，使用&3之类替换时，如果替换的字符串超过一定长度，语句会报错，做一个记录。1.环境：SCOTT@book> @ ver1PORT_STRING           &nbs