ITPub博客

[20210225]控制文件序列号满的恢复.txt--//继续昨天的测试,今天主要是测试恢复.--//我想给自己增加一点点难度,就是使用noresetlogs打开,因为这样重建的控制文件要读取redo,数据文件重新--//回填一些信息,实际上resetlogs也类似,但是noresetlogs回填的控制文件seq很大,一样打不开数据库.--//也就是必须提到我前面要修改的数据文件以及redo文件的

[20210224]控制文件序列号满的分析.txt--//上午看了链接:https://blog.csdn.net/enmotech/article/details/113855641,出现控制文件序列号满的情况,我从来没有遇到.--//下午没事,看看是否能在测试环境演示出来重复故障.--//注意不能在生产系统做这样的测试!!!很久没有做这类恢复工作,写的有点乱.1.环境:SCOTT@book&g

[20210224]fetch r=0算逻辑读吗.txt--//我一直以为fetch r=0时依旧算1次逻辑读.测试发现我理解错了.通过测试说明问题.1.环境:SCOTT@book> @ ver1PORT_STRING         VERSION     &n

[20210223]bbed itl ktbitflg 2.txt--//简单探究bbed查看ITL槽的ktbitflg含义.它包含2部分信息占32位,前4位表示提交状态,后12位表示dml的记录数.1.环境:SCOTT@book> @ ver1PORT_STRING          &nb

[20210223]sys与Extended Data Types.txt--//12c开始支持大于4000字符的字符串,但是缺省并不支持必须经过一些步骤升级完成.参考链接--//如下:http://blog.itpub.net/267265/viewspace-772855/=>[20130915]12c新特性 varchar2支持32K长度.txt --//实际上sys不受这个限制,可以

[20210222]gdb ptrace Operation not permitted.txt--//尝试使用gdb调试,发现如下错误.$ gdb -p 59148GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-119.0.1.el7Copyright (C) 2013 Free Software Foundation, Inc.License GPLv

[20210220]gdb跟踪逻辑读2.txt--//有了昨天的测试,链接如下:--//http://blog.itpub.net/267265/viewspace-2757857/ =>[20210219]全表扫描逻辑读问题.txt --//http://blog.itpub.net/267265/viewspace-2757859/ => [20210220]全索引扫描快速索引扫描

[20210220]全索引扫描快速索引扫描的逻辑读.txt--//昨天测试了表扫描逻辑读问题,今天测试看看全索引扫描快速索引扫描的逻辑读.1.环境:SYS@book> @ver1PORT_STRING                &

[20210219]全表扫描逻辑读问题.txt--//一般探究逻辑读设置_trace_pin_time,或者设置10200事件.--//设置_trace_pin_time有一个明显的缺点就是在系统级设置,而且要重启,这样每个进程产生大量跟踪信息.--//还有的一个因素就是对于唯一索引的执行计划,一些pin会捕捉到.自己没什么事情测试看看,--//主要出现一些小问题,自己无法理解.1.环境:SYS@

[20210218]shared latch spin count 6.txt--//测试遇到的情况,颠覆我对一些问题的理解:--//链接:[20210218]shared latch spin count 5.txt ->http://blog.itpub.net/267265/viewspace-2757533/1.环境:SYS@book> @ ver1PORT_STRING&nb

[20210218]shared latch spin count 5.txt--//节前的测试，链接http://blog.itpub.net/267265/viewspace-2756963/=>[20200426]查看shared latch gets的变化.txt，--//我发现如果大量shared latch出现，也会出现少量进入spin状态。--//按照文中链接介绍，spin_c

[20210218]bash echo 建立顺序号.txt--//昨天看了一下bash shell书籍,发现echo也可以实现顺序号.测试看它的效率.$ time echo {1..100000} >/dev/nullreal    0m0.200suser    0m0.198ssys   &nbsp

[20210218]Select vs Assign – How To Assign PLSQL Variables.txt--//链接https://blog.pythian.com/select-vs-assign-how-to-assign-pl-sql-variables/，我测试看看：1.环境：SCOTT@test01p> @ ver1PORT_STRING  

[20210218]xargs 与here doc测试.txt--//工作需要测试xargs与here doc(EOF)是否可以正常工作。1.环境：SCOTT@test01p> @ ver1PORT_STRING               &

[20210209]修改CPU_COUNT参数2.txt--//补充更正上午的测试.1.环境:SCOTT@book> @ ver1PORT_STRING                    VERSIO

[20210209]修改CPU_COUNT参数.txt--//昨天的测试:http://blog.itpub.net/267265/viewspace-2756963/=>[20210208][20200426]查看shared latch gets的变化.txt 表4-3------------------------------------------------------------

[20210208][20200426]查看shared latch gets的变化.txt--//前年的测试,链接:http://blog.itpub.net/267265/viewspace-2641549/--//我发现一些细节问题以前没有注意,我重复做一次,当时做的确实有点乱.这次看看整理一下.1.环境:SYS@book> @ ver1PORT_STRING  &

[20210208]lob字段与查询的问题.txt--//链接:http://www.itpub.net/thread-2140819-1-1.html,查询很慢.里面包含lob字段.--//不知道对方在什么环境或者工具下测试得到的,不过toad,PLSQLDev存在一定欺骗性.它并没有取出lob字段的全部,--//至少在toad下如此.通过测试说明问题.1.环境:SCOTT@book> @

[20210207]bash history小技巧.txt--//我经常在tmux下工作,在重新调用history命令缓存存在一些问题,做一个记录.--//通过例子演示:--//窗口1:$ qqqqqqqqqqqqq--//窗口2:$ wwwwwwwwwwwww--//窗口1:$ eeeeeeeeeeeee--//窗口2:$ rrrrrrrrrrrrr--//这个时候如果在窗口1调用窗口2执行的命

[20210207]使用gdb查看等待事件11g.txthttps://nenadnoveljic.com/blog/wait-events-dtrace/Before jumping to the DTrace script, I'd like summarize (and partially paraphrase) the most relevant information inSte