ITPub博客

[20250511]记录truncate table相关数据段号的变化.txt--//恢复truncate table后恢复遇到的问题，记录分析看看truncate table后相关数据段号的变化.1.环境：SCOTT@book01p> @ ver2==============================PORT_STRING     &

[20250506]不使用bbed扫描确定数据段号.txt--//前段时间恢复truncate的数据，通过bbed确定数据段号，许多情况下并没有安装bbed，测试是否可以通过别的命令行工具完成相似的--//工作。1.环境：SCOTT@book01p> @ ver2==============================PORT_STRING    

[20250506]truncate table，drop table恢复使用脚本.txt--//扫描行号根据具体的情况修改，一般8k不会大于736.没有必要设置太大，不然执行很慢的。$ cat txt/truncT.txtDECLARE   v_fno          NUMBER;&

[20250506]drop table的恢复2.txt--//尝试drop table的恢复，前提没有备份的情况不得已为之的方法，前面测试提到drop table时清除段头里面的Extent Map以及--//Auxillary Map的信息。这样通过建立新表的方式也只能像truncate table的方式通过rowid扫描数据块来恢复，做一个完整的测试说--//明问题：1.环境：SCOTT@b

[20250505]建表指定特定的数据文件是否可行.txt--//测试需要，是否可以实现建表指定特定的数据文件，建立表只能指定表空间，无法指定数据文件，测试看看。1.环境：SCOTT@book01p> @ ver2==============================PORT_STRING        &

[20250505]drop table的恢复.txt--//尝试drop table的恢复，前提没有备份的情况不得已为之的方法，前面测试提到drop table时清除段头里面的Extent Map以及--//Auxillary Map的信息。这样通过建立新表的方式也只能像truncate table的方式通过rowid扫描数据块来恢复，做一个完整的测试说--//明问题：1.环境：SCOTT@bo

[20250504]drop table的恢复思路.txt--//节前做了一次truncate table的恢复，理论也可以应用到drop table的情况，只要建立与原来数据结构一样的表，修改段号等于以前--//drop table的段号，再扫描对应数据文件就可以恢复drop table的信息。--//我看了一些的一些恢复操作笔记，当时思路很乱，好像drop table清除段头的信息，还只能通过

[20250501]truncate table恢复实战.txt--//别人数据库不小心truncate table，需要恢复，本以为3-4个小时可以完成，结果几乎使用1倍的工作时间。--//往往是节前最容易出错的时候。--//这类事情虽然以前做过练习，实战的情况几乎没有，在测试环境重新模拟整个的恢复过程。1.环境：SCOTT@book01p> @ ver2=================

[20250421]in list相关问题.txt--//前几天测试in list相关绑定变量太多的问题，有点吃惊的是，大量执行相同sql语句，执行很慢，而且看不到相关等待事件，问题已--//经确定主要集中在客户端。--//我也测试了通过函数str2varlist，str2numlist，这样仅仅将数字或者字符拼接成一个通过英文逗号分割的字符串作为函数的参数来--//实现绑定变量的情况，测试1个参

[20250421]绑定变量太多的分析(21c补充).txt--//前几天写了"绑定变量太多的分析(21c)"，发现自己的分析存在一些错误，做一些必要的补充。--//我当时通过执行oradebug setospid <spid>,不断调用oradebug short_stack，收集stack信息。$ sort ostackprof_4088.txt| uniq -

[20250420]使用toad的关于绑定变量问题.txt--//以前遇到的情况是sql语句出现中文逗号有时候给绑定变量赋值时，出现输入变量的提示框，但是无法输入的情况，今天再次遇到。--//toad版本是12.7.select * from str2varlist(:v_str);--//按<F9>执行出现输入变量的提示框，但是无法输入。修改如下ok。select * from ta

[20250419]str2varlist函数的一个小错误.txt--//晚上想验证设置vartabletype类型TABLE OF VARCHAR2 (4000)可能不合理，因为这样每个绑定变量相当于占用4000字节，传入参数也--//是占用4000字节,这样可能导致父游标堆0占用空间增加，其它情况自己也不是很清楚，想通过测试验证。--//无意间发现原始代码的一个错误，我上网检索发现，其实许多人

[20250418]绑定变量太多的限制.txt--//看看最多1条sql语句能有多少绑定变量。1.环境：SCOTT@book01p> @ ver2==============================PORT_STRING             &nbsp

[20250418]绑定变量太多的分析(21c).txt--//前几天测试，执行绑定变量很多的sql语句，发现无法看出在绑定变量替换时，执行"缓慢"的原因，没有相关等待事件。--//再次尝试分析这种情况：1.环境：SCOTT@book01p> @ ver2==============================PORT_STRING   

[20250415]21c下测试软软解析与大量绑定变量的情况.txt--//测试大量用户同时执行相同sql语句存在大量绑定变量的情况，看看会出现什么等待事件。--//前几天测试单个用户的执行情况，至少我认为问题不是很大，今天测试大量执行的情况，结果有点出乎我的意料，再次说明思考问题--//不能太想当然,通过例子说明问题。1.环境：SCOTT@book01p> @ ver2==========

[20250409]执行计划出现OPT_PARAM('_optim_peek_user_binds' 'false')的相关问题--//生产系统一些sql执行计划outline出现OPT_PARAM('_optim_peek_user_binds' 'false')，导致选择不合理的执行计划。1.环境：> @ ver1PORT_

[20250410]GUID转换GUID_BASE64(补充4).txt--//昨天重新写bash shell脚本，总感觉遗漏了什么，oracle内部应该有对应函数转换GUID_BASE64。--//看了相关文档，发现使用UTL_ENCODE.BASE64_ENCODE函数，测试看看。1.环境：SCOTT@book01p> @ver2=============================

[20250409]GUID转换GUID_BASE64(补充3).txt--//前面写的bash shell脚本没有追加结尾的=，尝试完善该脚本。$ cat o64basex.sh#! /bin/bash# convert guid to guid_base64odebug=${ODEBUG:-0}v2=${1}v3=${2:-4}BASE64=($( echo {A..Z} {a..z} {0.

[20250407]GUID转换GUID_BASE64(补充2).txt--//以前写过一篇GUID转换GUID_BASE64的文章，链接：[20200103]GUID转换GUID_BASE64.txt--//实际上linux直接有一个命令base64直接实现转换.先要转换raw类型再计算，结果完全正确。--//只不过21c做了小小改动，结尾补充00在做运算。--//测试我以前写的bash she

[20250403]GUID转换GUID_BASE64(补充).txt--//以前写过一篇GUID转换GUID_BASE64的文章，链接：[20200103]GUID转换GUID_BASE64.txt--//实际上linux直接有一个命令base64直接实现转换，实际上当时我也做了测试，忽略一些编码问题，先要转换raw类型再计算，导致当--//时计算老是不对，自己当时也不明白问题在那里。在21c下