标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,763)
- DB2 (22)
- MySQL (76)
- Oracle (1,605)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
月归档:五月 2012
ksh翻上/下条和自动补全功能
AIX默认安装ksh,对于习惯了bash的人来说,不能tab自动补全,不能翻上/下,感觉使用起来很不方便,在ksh中不能直接实现这些功能,可以使用另外的方法来完成
一.安装bash程序,使用起来就和bash一样
二.ksh中通过其他方法完成
翻上/下条功能
1、在主目录中 vi .profile
2、添加一行:export EDITOR=vi
3、保存.profile,重新登陆;或者source ~/.profile
现在如果要使用翻上/下条功能,只需要按下esc键,然后使用j/k翻上/下即可;如果要退回到输入功能,直接输入i,然后输入即可.其实所有操作就是和vi中的操作一样.
自动补全功能
使用esc+\
发表在 AIX
评论关闭
记录一次比较棘手数据库恢复要点
在最近的一次数据库异常恢复过程中遇到不少问题,把重点记录下
ORA-00704/ORA-01555错误
Fri May 4 21:04:21 2012 select ctime, mtime, stime from obj$ where obj# = :1 Fri May 4 21:04:21 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1286288.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 40 with name "_SYSSMU40$" too small Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Instance terminated by USER, pid = 1286288 ORA-1092 signalled during: alter database open resetlogs... 这里的提示可以看出obj$基表中有事务存在,查询这个表的时候,要去找40号回滚段中相关数据;通过非常规方法, 查找到40号回滚段的状态是offliine了(这个查询出来的信息和是否使用隐含参数无关). 问题原因,为什么40号回滚段变得offline? Fri May 4 17:36:26 2012 alter tablespace undotbs offline Fri May 4 17:36:26 2012 ORA-1109 signalled during: alter tablespace undotbs offline... Fri May 4 17:37:29 2012 alter database datafile '/dev/rundodbs01' offline drop Fri May 4 17:37:29 2012 Completed: alter database datafile '/dev/rundodbs01' offline drop 因为强制offline 了file# 2文件导致(一个undo表空间文件) 解决方法: 1.bbed提交事务 因为现在生产的trace文件中未有关于obj$ 未提交事务的记录,做10046也为发现该记录,如果要使用bbed修改该事务, 那需要dump obj$相关的数据块(在mount状态下dump),然后找到相关事务,再修改 2.强制让file# 2 online 因为在resetlogs前file#2 已经offline掉了,所以要使得该文件能够成功online,需要先推进scn
ORA-00600[krhpfh_03-1209]
SQL> recover database until cancel; ORA-00283: recovery session canceled due to errors ORA-00600: internal error code, arguments: [krhpfh_03-1209], [2], [782415504], [782428968], [3987078030], [2379], [0], [0] ORA-01110: data file 2: '/dev/rundodbs01' 问题原因: 数据库处于非归档模式下,连续三次resetlogs,引起该bug 解决办法: 重建控制文件 但是这里问题出现了,因为file# 2的resetlogs scn和其他数据文件不一致,导致在file# 2 online的前提下,无法重建. 这样就处在了一个循环中(需要online file# 2 又要重建控制文件),这样的问题,可以通过bbed修改file# 2的resetlogs scn完成 或者先让file# 2 offline(没有加drop)掉,重建控制文件(除掉file# 2的文件记录)
ORA-00600[25025]
SMON: enabling cache recovery Fri May 4 22:36:36 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Errors in file /oracle/admin/standdb/udump/perfdb_ora_1167402.trc: ORA-00600: internal error code, arguments: [25025], [2], [], [], [], [], [], [] Fri May 4 22:36:38 2012 Error 600 happened during db open, shutting down database USER: terminating instance due to error 600 Instance terminated by USER, pid = 1167402 错误原因: 因为有undo文件不在undo对应的表空间中,而我们的file# 2文件确实是undo文件,而且重建控制文件时候未加入进来 解决办法: undo_management = AUTO undo_tablespace = UNDODBS(file# 2属于该表空间) 修改为 undo_management = MANUAL undo_tablespace = SYSTEM 或者bbed修改file# 2的header,然后重建控制文件
ORA-00600[4137]
Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:20:52 2012 create undo tablespace undotbs3 datafile '/dev/rundodbs21' size 20400M Fri May 4 23:23:47 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_smon_1290564.trc: ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], [] Fri May 4 23:23:48 2012 Errors in file /oracle/admin/standdb/bdump/perfdb_pmon_1520126.trc: ORA-00474: SMON process terminated with error Fri May 4 23:23:48 2012 PMON: terminating instance due to error 474 Instance terminated by PMON, pid = 1520126 错误原因: _smon_internal_errlimit(limit of SMON internal errors) SMON遇到了内部错误,最大允许100次, 不断计数增长,达到100的时候,数据库smon进程自动down掉,从而导致数据库down 解决办法: 1.临时解决办法:设置_smon_internal_errlimit一个较大值 3.根本解决办法:使用undo隐含参数,删除有问题undo 回滚段和undo表空间或者使用10513 事件
Bind Variable Peeking 测试
相关参数
SQL> select * from v$version; BANNER --------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production PL/SQL Release 11.2.0.3.0 - Production CORE 11.2.0.3.0 Production TNS for Linux: Version 11.2.0.3.0 - Production NLSRTL Version 11.2.0.3.0 - Production SQL> show parameter optimizer_mode; NAME TYPE VALUE ------------------------------------ ---------------------- ---------------- optimizer_mode string ALL_ROWS SQL> show parameter cursor_sharing; NAME TYPE VALUE ------------------------------------ ---------------------- ---------------- cursor_sharing string EXACT SQL> select a.ksppinm name,b.ksppstvl value,a.ksppdesc description 2 from x$ksppi a,x$ksppcv b 3 where a.inst_id = USERENV ('Instance') 4 and b.inst_id = USERENV ('Instance') 5 and a.indx = b.indx 6 and upper(a.ksppinm) LIKE upper('%¶m%') 7 order by name 8 / Enter value for param: _optim_peek_user_binds old 6: and upper(a.ksppinm) LIKE upper('%¶m%') new 6: and upper(a.ksppinm) LIKE upper('%_optim_peek_user_binds%') NAME VALUE DESCRIPTION -------------------------------- ------------------------ ---------------------------------- _optim_peek_user_binds TRUE enable peeking of user binds
创建模拟表
SQL> create table t_xifenfei(id number,name varchar2(30)); Table created. SQL> begin 2 for i in 1..100000 loop 3 insert into t_xifenfei values(i,'xifenfei'); 4 end loop; 5 commit; 6 end; 7 / PL/SQL procedure successfully completed. SQL> update t_xifenfei SET name='www.xifenfei.com' where mod(id,20000)=0; 5 row updated. SQL> commit; Commit complete. SQL> create index i_xifenfei on t_xifenfei(name); Index created.
默认收集统计信息,查看执行计划
SQL> exec DBMS_STATS.gather_table_stats(user,'T_XIFENFEI',CASCADE=>TRUE); PL/SQL procedure successfully completed. SQL> set autot trace exp SQL> select id from t_xifenfei where name='xifenfei'; Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50000 | 683K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 50000 | 683K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='xifenfei') SQL> select id from t_xifenfei where name='www.xifenfei.com'; Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50000 | 683K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 50000 | 683K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='www.xifenfei.com') --这里可以发现,对于这样少量的列的情况,没有选择一个合适的执行计划
准确收集统计信息
SQL> exec DBMS_STATS.gather_table_stats(user,'T_XIFENFEI',CASCADE=>TRUE, 2 method_opt => 'FOR ALL COLUMNS SIZE 254',estimate_percent => 100); PL/SQL procedure successfully completed.
再次查看执行计划
SQL> select id from t_xifenfei where name='www.xifenfei.com'; Execution Plan ---------------------------------------------------------- Plan hash value: 1926396081 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 14 | 2 (0)| 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 1 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("NAME"='www.xifenfei.com') Statistics ---------------------------------------------------------- 0 recursive calls 1 db block gets 320 consistent gets 0 physical reads 0 redo size 418 bytes sent via SQL*Net to client 419 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 5 rows processed SQL> select id from t_xifenfei where name='xifenfei'; 99995 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 99999 | 1367K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 99999 | 1367K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"='xifenfei') Statistics ---------------------------------------------------------- 0 recursive calls 1 db block gets 6970 consistent gets 0 physical reads 0 redo size 1455968 bytes sent via SQL*Net to client 73745 bytes received via SQL*Net from client 6668 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 99995 rows processed --通过这里可以看出在完整的收集表和index包括直方图信息后,数据库执行计划正常 --也说明一点:在数据列分布不均匀的时候,依靠数据库自动收集直方图还是不怎么拷贝.
使用AUTOTRACE测试
SQL> set autot trace exp SQL> var a varchar2(30); SQL> exec :a := 'www.xifenfei.com'; PL/SQL procedure successfully completed. SQL> select id from t_xifenfei where name=:a; Execution Plan ---------------------------------------------------------- Plan hash value: 548923532 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 50000 | 683K| 103 (1)| 00:00:02 | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 50000 | 683K| 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("NAME"=:A) --这里可以发现11g的Bind Variable Peeking 没有使用正确的执行计划,其实这个是AUTOTRACE本身的bug导致
收集下面sql执行计划(peeking测试需要)get_plan.sql脚本
SQL> select * from t_xifenfei where name='wwww.xifenfei.com' and id=100; no rows selected SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 2708637417 select * from t_xifenfei where name='wwww.xifenfei.com' and id=100 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 2 (100)| | |* 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 3 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("ID"=100) 2 - access("NAME"='wwww.xifenfei.com') SQL> select * from t_xifenfei where name='xifenfei' and id=100; ID NAME ---------- ------------------------------------------------------------ 100 xifenfei 1 row selected. SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 1355242984 select * from t_xifenfei where name='xifenfei' and id=100 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 103 (100)| | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 1 | 14 | 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(("ID"=100 AND "NAME"='xifenfei')) --这里可以看到,两个执行计划都我们希望的
测试peeking功能
SQL> alter system flush shared_pool; System altered. SQL> select * from t_xifenfei where name='xifenfei' and id=100; ID NAME ---------- ------------------------------------------------------------ 100 xifenfei 1 row selected. SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 2860562673 select * from t_xifenfei where name='xifenfei' and id=100 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 103 (100)| | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 1 | 14 | 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(("ID"=100 AND "NAME"='xifenfei')) SQL> var b varchar2(30); SQL> exec :b := 'www.xifenfei.com'; PL/SQL procedure successfully completed. SQL> select * from t_xifenfei where name=:b and id=100; no rows selected SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 4157424768 select * from t_xifenfei where name=:b and id=100 -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 103 (100)| | |* 1 | TABLE ACCESS FULL| T_XIFENFEI | 1 | 14 | 103 (1)| 00:00:02 | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter(("ID"=100 AND "NAME"=:B)) --重新硬解析 SQL> alter system flush shared_pool; System altered. SQL> var b varchar2(30); SQL> exec :b := 'www.xifenfei.com'; PL/SQL procedure successfully completed. SQL> select * from t_xifenfei where name=:b and id=100; no rows selected SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 4157424768 select * from t_xifenfei where name=:b and id=100 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 2 (100)| | |* 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 6 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("ID"=100) 2 - access("NAME"=:B) SQL> var b varchar2(30); SQL> exec :b := 'xifenfei'; PL/SQL procedure successfully completed. SQL> select * from t_xifenfei where name=:b and id=100; ID NAME ---------- ------------------------------------------------------------ 100 xifenfei 1 row selected. SQL> @get_plan.sql Rollback complete. Enter value for hash_value: 4157424768 select * from t_xifenfei where name=:b and id=100 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | | | 2 (100)| | |* 1 | TABLE ACCESS BY INDEX ROWID| T_XIFENFEI | 1 | 14 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_XIFENFEI | 6 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("ID"=100) 2 - access("NAME"=:B) --虽然oracle 11g宣称在在Bind Variable Peeking上增强了很多, --但是这里的实验,依然证明他存在问题,导致执行计划不正确
通过整体实验过程,证明几个问题:
1.默认的的DBMS_STATS收集统计信息不一定使得所有执行计划均正确,特别在数据很不均匀分布时.
2.AUTOTRACE不能跟踪Bind Variable Peeking
3.Bind Variable Peeking是在硬解析时候生效,虽然11g进行了改善,但是有些时候效果还是不明显,如果数据很不均匀,在发现sql语句很多不合适的时候,建议先删除该sql的执行计划,让其再次硬解析,碰碰运气,如果一直效果不好,建议不适用绑定参数形式(正确的执行计划,更多的硬解析)
4._optim_peek_user_binds参数可以关闭Bind Variable Peeking功能,很不推荐.
发表在 Oracle性能优化
评论关闭