标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr kgegpa MySQL恢复 ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kdsgrp1 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)
- 操作系统 (110)
- 数据库 (1,823)
- DB2 (22)
- MySQL (80)
- Oracle (1,652)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- 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 监听 (29)
- Oracle备份恢复 (620)
- Oracle安装升级 (103)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (45)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (28)
-
最近发表
- 注意:PostgreSQL库出现readme_to_recover勒索
- Oracle 19c 202601补丁(RUs+OJVM)-19.30
- Patch_SCN快速解决ORA-600 2663故障
- 在生产环境错误执行dd命令破坏asm磁盘故障恢复
- obet实现对数据文件坏块检测功能
- oracle linux 8.10注意pmlogger导致空间被大量占用
- obet快速修改scn/resetlogs恢复数据库(缺少归档,ORA-00308)
- 使用DBMS_PDB.RECOVER抢救单个pdb
- aix环境写入大文件设置combehin提高效率
- 记录一次国产数据库被rm -rf /*删除的救援过程
- 数据库启动报 maximum number of processes () exceeded分析
- ORA-600 [ksunfy : too few sessions]
- 由于数据块scn大于数据库scn导致ORA-600 kcbzib_kcrsds_1错误
- ORA-600 ktbair2: illegal inheritance恢复
- 一键恢复ORA-00704 ORA-00702故障—202512
- PostgreSQL查询一个表相关的所有oid
- PostgreSQL oid文件替换实现数据访问
- 模拟sql server故障备份完成恢复实现数据0丢失
- sql server 事务日志备份异常恢复案例
- win平台挂起Oracle数据库启动进程
标签归档:修改bootstrap$
修改bootstrap$影响数据库执行计划
在以前的文章中,我写过通过ue修改oracle二进制文件实现数据库启动的sql执行计划,这里再次提供另外一种方法,通过修改bootstrap$表实现数据库启动sql执行计划。这里试验的是数据库不走i_undo1 index。[此方法危害性巨大仅供测试]
跟踪数据库正常启动过程
[oracle@localhost .oradata]$ ss SQL*Plus: Release 11.2.0.1.0 Production on Sat Feb 4 23:07:41 2017 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 2421825536 bytes Fixed Size 2215744 bytes Variable Size 1828716736 bytes Database Buffers 570425344 bytes Redo Buffers 20467712 bytes Database mounted. SQL> oradebug setmypid Statement processed. SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 Statement processed. SQL> oradebug TRACEFILE_NAME /opt/oracle/diag/rdbms/test/test/trace/test_ora_19003.trc SQL> alter database open; Database altered. SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
分析10046 trace文件
PARSING IN CURSOR #2 len=196 dep=1 uid=0 oct=9 lid=0 tim=1486220893978359 hv=24291558 ad='ef95ff70' sqlid='fqkyj700r5a76' CREATE UNIQUE INDEX I_UNDO1 ON UNDO$(US#) PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE ( INITIAL 64K NEXT 1024K MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 OBJNO 34 EXTENTS (FILE 1 BLOCK 320)) END OF STMT PARSE #2:c=0,e=565,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=241391319,tim=1486220893978358 EXEC #2:c=0,e=123,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=241391319,tim=1486220893978566 STAT #2 id=1 cnt=0 pid=0 pos=1 obj=0 op='INDEX BUILD UNIQUE I_UNDO1 (cr=0 pr=0 pw=0 time=0 us)' STAT #2 id=2 cnt=0 pid=1 pos=1 obj=0 op='SORT CREATE INDEX (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=0)' STAT #2 id=3 cnt=0 pid=2 pos=1 obj=15 op='TABLE ACCESS FULL UNDO$ (cr=0 pr=0 pw=0 time=0 us)' CLOSE #2:c=0,e=5,dep=1,type=0,tim=1486220893978690 ………… PARSING IN CURSOR #5 len=142 dep=1 uid=0 oct=3 lid=0 tim=1486220894169144 hv=361892850 ad='ef934cb0' sqlid='7bd391hat42zk' select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1 END OF STMT PARSE #5:c=0,e=474,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,plh=0,tim=1486220894169143 BINDS #5: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7f4f4556b0a8 bln=22 avl=02 flg=05 value=1 EXEC #5:c=1000,e=802,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,plh=906473769,tim=1486220894170055 WAIT #5: nam='db file sequential read' ela= 1018 file#=1 block#=321 blocks=1 obj#=34 tim=1486220894171138 WAIT #5: nam='db file sequential read' ela= 2620 file#=1 block#=225 blocks=1 obj#=15 tim=1486220894173817 FETCH #5:c=0,e=3770,p=2,cr=2,cu=0,mis=0,r=1,dep=1,og=3,plh=906473769,tim=1486220894173859 STAT #5 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS BY INDEX ROWID UNDO$ (cr=2 pr=2 pw=0 time=0 us)' STAT #5 id=2 cnt=1 pid=1 pos=1 obj=34 op='INDEX UNIQUE SCAN I_UNDO1 (cr=1 pr=1 pw=0 time=0 us)' CLOSE #5:c=0,e=9,dep=1,type=0,tim=1486220894173944
这些trace文件比较明显的展示了数据库在启动过程中,先是create index i_undo1,然后from undo$ where us#=:1走I_UNDO1 index访问。
删除i_undo1 在bootstrap$中信息
SQL> select line#,obj#,sql_text from bootstrap$ where sql_text like '%I_UNDO1%';
LINE# OBJ#
---------- ----------
SQL_TEXT
--------------------------------------------------------------------------------
34 34
CREATE UNIQUE INDEX I_UNDO1 ON UNDO$(US#) PCTFREE 10 INITRANS 2 MAXTRANS 255 STO
RAGE ( INITIAL 64K NEXT 1024K MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0
OBJNO 34 EXTENTS (FILE 1 BLOCK 320))
SQL> DELETE FROM BOOTSTRAP$ WHERE OBJ#=34;
1 row deleted.
SQL> COMMIT;
Commit complete.
SQL> SHUTDOWN IMMEDIATE;
Database closed.
Database dismounted.
ORACLE instance shut down.
再次跟踪数据库启动
SQL> STARTUP MOUNT; ORACLE instance started. Total System Global Area 2421825536 bytes Fixed Size 2215744 bytes Variable Size 1828716736 bytes Database Buffers 570425344 bytes Redo Buffers 20467712 bytes Database mounted. SQL> oradebug setmypid Statement processed. SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 Statement processed. SQL> oradebug TRACEFILE_NAME /opt/oracle/diag/rdbms/test/test/trace/test_ora_19205.trc SQL> alter database Open; Database altered.
再次分析10046 trace文件
PARSING IN CURSOR #5 len=142 dep=1 uid=0 oct=3 lid=0 tim=1486221250365628 hv=361892850 ad='ef935ce0' sqlid='7bd391hat42zk' select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1 END OF STMT PARSE #5:c=1000,e=536,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,plh=0,tim=1486221250365627 BINDS #5: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7f89004340a8 bln=22 avl=02 flg=05 value=1 EXEC #5:c=1000,e=727,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,plh=3995376916,tim=1486221250366467 WAIT #5: nam='db file sequential read' ela= 12 file#=1 block#=224 blocks=1 obj#=15 tim=1486221250366534 WAIT #5: nam='db file sequential read' ela= 10 file#=1 block#=225 blocks=1 obj#=15 tim=1486221250366606 FETCH #5:c=0,e=147,p=2,cr=3,cu=0,mis=0,r=1,dep=1,og=3,plh=3995376916,tim=1486221250366647 STAT #5 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS FULL UNDO$ (cr=3 pr=2 pw=0 time=0 us)' CLOSE #5:c=0,e=39,dep=1,type=0,tim=1486221250366717
这次的trace文件中已经没有了create index i_undo1,而且对于undo$ where us#=:1的访问是通过全表扫描undo$来实现的。通过这里已经清晰证明通过修改bootstrap$表内容,可以影响数据库启动的sql执行计划。

加我微信(17813235971)
加我QQ(107644445)

