标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 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 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,879)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- 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 (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (659)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
分类目录归档:Oracle
DBMS_STATS比较复杂参数
method_opt
Accepts:
FOR ALL [INDEXED | HIDDEN] COLUMNS [size_clause]
FOR COLUMNS [size clause] column|attribute [size_clause] [,column|attribute [size_clause]…]
size_clause is defined as size_clause := SIZE {integer | REPEAT | AUTO | SKEWONLY}
- integer : Number of histogram buckets. Must be in the range [1,254].
- REPEAT : Collects histograms only on the columns that already have histograms.
- AUTO : Oracle determines the columns to collect histograms based on data distribution and the workload of the columns.
- SKEWONLY : Oracle determines the columns to collect histograms based on the data distribution of the columns.
举例说明:
method_opt => ‘FOR COLUMNS size 254 object_id’ 收集objct_id列直方图
method_opt => ‘FOR COLUMNS size 1 object_id’ 删除object_id列直方图
method_opt => ‘for all columns size repeat’ 重新分析现有直方图
method_opt => ‘for all columns size auto’ oracle决定收集哪些列的直方图(需要设置table monitoring)
method_opt => ‘for all columns size skewonly’ oracle分析所有列的分布情况,生成直方图
method_opt => ‘FOR COLUMNS object_id size SKEWONLY’ 收集object_id列分布情况,生成直方图
method_opt => ‘FOR all INDEXED COLUMNS size SKEWONLY’ 收集index列分布情况,并生成直方图
granularity
Granularity of statistics to collect (only pertinent if the table is partitioned).
‘ALL’ – gathers all (subpartition, partition, and global) statistics
‘AUTO’- determines the granularity based on the partitioning type. This is the default value.
‘DEFAULT’ – gathers global and partition-level statistics. This option is obsolete, and while currently supported, it is included in the documentation for legacy reasons only. You should use the ‘GLOBAL AND PARTITION’ for this functionality. Note that the default value is now ‘AUTO’.
‘GLOBAL’ – gathers global statistics
‘GLOBAL AND PARTITION’ – gathers the global and partition level statistics. No subpartition level statistics are gathered even if it is a composite partitioned object.
‘PARTITION ‘- gathers partition-level statistics
‘SUBPARTITION’ – gathers subpartition-level statistics.
options
Further specification of which objects to gather statistics for:
GATHER: Gathers statistics on all objects in the schema.
GATHER AUTO: Gathers all necessary statistics automatically. Oracle implicitly determines which objects need new statistics, and determines how to gather those statistics. When GATHER AUTO is specified, the only additional valid parameters are ownname, stattab, statid, objlist and statown; all other parameter settings are ignored. Returns a list of processed objects.
GATHER STALE: Gathers statistics on stale objects as determined by looking at the *_tab_modifications views. Also, return a list of objects found to be stale.
GATHER EMPTY: Gathers statistics on objects which currently have no statistics. also, return a list of objects found to have no statistics.
LIST AUTO: Returns a list of objects to be processed with GATHER AUTO.
LIST STALE: Returns list of stale objects as determined by looking at the *_tab_modifications views.
LIST EMPTY: Returns list of objects which currently have no statistics.
发表在 Oracle性能优化
一条评论
BITMAP CONVERSION FROM ROWIDS
在有些执行计划中,可以会看到 BITMAP CONVERSION FROM ROWIDS这样的东东,也许你会感觉奇怪,我没有使用位图索引怎么出现了bitmap。
我通过一个sql和大家分析下原因:
sql语句为:
SELECT *
FROM (SELECT a.*, ROWNUM rn
FROM ( SELECT module_no, MAX (id) AS id
FROM vasoa.tab_moa_historypage t
WHERE t.company_id = :1 AND t.user_id = :2 AND t.TYPE = :3
GROUP BY module_no
ORDER BY id DESC) a
WHERE ROWNUM <= :4) b
WHERE b.rn >= :5
执行计划为:

表结构为:

目前索引情况:

通过观察执行计划的图片可以发现,使用了 BITMAP CONVERSION FROM ROWIDS,其目的是:.oracle将btree索引中获得的rowid信息通过BITMAP CONVERSION FROM ROWIDS的步骤转换成bitmap进行匹配,然后匹配完成后通过BITMAP CONVERSION TO ROWIDS再转换出rowid获得数据或者回表获得数据。这种想象出现的原因为:oracle的cbo是根据cost来决定大小来选择合适的执行计划,当它计算获得通过bitmap的方式执行的时候cost会更小,它就会选择使用这样的执行计划。一般出现这样的情况,都是因为对表建立的不适当的index导致,特别是对表中的唯一度不高的列建立了index,然后oracle就有可能选择两个这样的列转为为bitmap来执行。根据oracle的执行计划,肯定是cost最小的,但是它很多时候忽略了一致性读等其他条件,导致这个执行计划并非像oracle想象的那样最优,因为把btree index转为为bitmap index执行,需要消耗更多的cpu,特别是在cpu比较紧张的系统中,所以这样的情况如果发生在oltp系统中,一般都需要解决。
本例的解决办法是删除唯一度低的index,建立组合index。分别删除COMPANY_ID与USER_ID上的index,建立COMPANY_ID和USER_ID的组合index,执行计划如下:

发表在 Oracle性能优化
3 条评论
bbed 修改datafile header
SQL> startup
ORACLE instance started.
Total System Global Area 236000356 bytes
Fixed Size 451684 bytes
Variable Size 201326592 bytes
Database Buffers 33554432 bytes
Redo Buffers 667648 bytes
Database mounted.
ORA-01113: file 2 needs media recovery
ORA-01110: data file 2: '/opt/oracle/oradata/xifenfei/xff01.dbf'
提示数据文件2需要恢复,首选是recover datafile 2;,如果失败,可以考虑bbed修改scn的办法
SQL> select file#,to_char(checkpoint_change#,'999999999999') from v$datafile;
FILE# TO_CHAR(CHECK
---------- -------------
1 107374278108
2 107374278108
3 107374278108
4 107374278108
5 107374278108
6 107374278108
7 107374278108
8 107374278108
9 107374278108
10 107374278108
11 107374278108
11 rows selected.
SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;
FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
2 ONLINE 107374277136
[oracle@localhost tmp]$ bbed parfile=/tmp/parfile.cnf
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Mon Aug 22 06:05:34 2011
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> info
File# Name Size(blks)
----- ---- ----------
1 /opt/oracle/oradata/xifenfei/system01.dbf 1280
2 /opt/oracle/oradata/xifenfei/xff01.dbf 1280
BBED> set dba 1,1
DBA 0x00400001 (4194305 1,1)
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @140
struct kcvcpscn, 8 bytes @140
* ub4 kscnbas @140 0x000175dc
ub2 kscnwrp @144 0x0019
* ub4 kcvcptim @148 0x2d49fbbb
ub2 kcvcpthr @152 0x0001
union u, 12 bytes @156
struct kcvcprba, 12 bytes @156
ub4 kcrbaseq @156 0x00000005
ub4 kcrbabno @160 0x00008e05
ub2 kcrbabof @164 0x0010
struct kcvcptr, 12 bytes @156
struct kcrtrscn, 8 bytes @156
ub4 kscnbas @156 0x00000005
ub2 kscnwrp @160 0x8e05
ub4 kcrtrtim @164 0x09110010
ub1 kcvcpetb[0] @168 0x02
ub1 kcvcpetb[1] @169 0x00
ub1 kcvcpetb[2] @170 0x00
ub1 kcvcpetb[3] @171 0x00
ub1 kcvcpetb[4] @172 0x00
ub1 kcvcpetb[5] @173 0x00
ub1 kcvcpetb[6] @174 0x00
ub1 kcvcpetb[7] @175 0x00
BBED> p kcvfhcpc
*ub4 kcvfhcpc @176 0x0000007a
BBED> p kcvfhccc
*ub4 kcvfhccc @184 0x00000079
星号表示使用bbed修改datafile header scn需要考虑的地方
SQL> select to_char(to_number('19000175dc','xxxxxxxxxxxx'),'999999999999') from dual;
TO_CHAR(TO_NU
-------------
107374278108
证实system01.dbf的scn为107374278108和v$datafile查询到的一致
BBED> set dba 2,1
DBA 0x00800001 (8388609 2,1)
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @140
struct kcvcpscn, 8 bytes @140
ub4 kscnbas @140 0x00017210
ub2 kscnwrp @144 0x0019
ub4 kcvcptim @148 0x2d49fa27
ub2 kcvcpthr @152 0x0001
union u, 12 bytes @156
struct kcvcprba, 12 bytes @156
ub4 kcrbaseq @156 0x00000005
ub4 kcrbabno @160 0x00006f18
ub2 kcrbabof @164 0x0010
struct kcvcptr, 12 bytes @156
struct kcrtrscn, 8 bytes @156
ub4 kscnbas @156 0x00000005
ub2 kscnwrp @160 0x6f18
ub4 kcrtrtim @164 0x09110010
ub1 kcvcpetb[0] @168 0x02
ub1 kcvcpetb[1] @169 0x00
ub1 kcvcpetb[2] @170 0x00
ub1 kcvcpetb[3] @171 0x00
ub1 kcvcpetb[4] @172 0x00
ub1 kcvcpetb[5] @173 0x00
ub1 kcvcpetb[6] @174 0x00
ub1 kcvcpetb[7] @175 0x00
BBED> p kcvfhcpc
ub4 kcvfhcpc @176 0x00000034
BBED> p kcvfhccc
ub4 kcvfhccc @184 0x00000033
SQL> select to_char(to_number('1900017210','xxxxxxxxxxxx'),'999999999999') from dual;
TO_CHAR(TO_NU
-------------
107374277136
和v$recover_file视图中查询出来一致
BBED> set dba 2,1 offset 140
DBA 0x00800001 (8388609 2,1)
OFFSET 140
BBED> show
FILE# 2
BLOCK# 1
OFFSET 140
DBA 0x00800001 (8388609 2,1)
FILENAME /opt/oracle/oradata/xifenfei/xff01.dbf
BIFILE bifile.bbd
LISTFILE /tmp/list
BLOCKSIZE 8192
MODE Edit
EDIT Unrecoverable
IBASE Dec
OBASE Dec
WIDTH 80
COUNT 32
LOGFILE log.bbd
SPOOL No
BBED> m /x dc750100
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 1 Offsets: 140 to 171 Dba:0x00800001
------------------------------------------------------------------------
dc750100 19000000 27fa492d 01000000 05000000 186f0000 10001109 02000000
<32 bytes per line>
BBED> m /x bbfb492d offset 158
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 1 Offsets: 158 to 189 Dba:0x00800001
------------------------------------------------------------------------
bbfb492d 00001000 11090200 00000000 00003400 00004cc0 492d3300 00000000
<32 bytes per line>
BBED> m /x 7a000000 offset 176
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 1 Offsets: 176 to 207 Dba:0x00800001
------------------------------------------------------------------------
7a000000 4cc0492d 33000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
BBED> m /x 79000000 offset 184
File: /opt/oracle/oradata/xifenfei/xff01.dbf (2)
Block: 1 Offsets: 184 to 215 Dba:0x00800001
------------------------------------------------------------------------
79000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<32 bytes per line>
注意:p打印出来的值和m修改的值可能不是完全一致(和cpu的计算类型有关,常用的intel cpu中是倒序存储),可以选择先dump正确的相关值,然后m修改
如:p打印出来的值为:80084d1f时,m修改时要为: 1f4d0880
BBED> sum apply dba 2,1
Check value for File 2, Block 1:
current = 0x7ece, required = 0x7ece
SQL> shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 236000356 bytes
Fixed Size 451684 bytes
Variable Size 201326592 bytes
Database Buffers 33554432 bytes
Redo Buffers 667648 bytes
Database mounted.
ORA-01122: database file 2 failed verification check
ORA-01110: data file 2: '/opt/oracle/oradata/xifenfei/xff01.dbf'
ORA-01207: file is more recent than controlfile - old controlfile
提示控制文件太老,需要重建控制文件
SQL> shutdown abort
ORACLE instance shut down.
SQL> STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "XIFENFEI" NORESETLOGS ARCHIVELOG
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/opt/oracle/oradata/xifenfei/redo01.log' SIZE 100M,
GROUP 2 '/opt/oracle/oradata/xifenfei/redo02.log' SIZE 100M,
GROUP 3 '/opt/oracle/oradata/xifenfei/redo03.log' SIZE 100M
DATAFILE
'/opt/oracle/oradata/xifenfei/system01.dbf',
'/opt/oracle/oradata/xifenfei/xff01.dbf',
'/opt/oracle/oradata/xifenfei/cwmlite01.dbf',
'/opt/oracle/oradata/xifenfei/drsys01.dbf',
'/opt/oracle/oradata/xifenfei/example01.dbf',
'/opt/oracle/oradata/xifenfei/indx01.dbf',
'/opt/oracle/oradata/xifenfei/odm01.dbf',
'/opt/oracle/oradata/xifenfei/tools01.dbf',
'/opt/oracle/oradata/xifenfei/users01.dbf',
'/opt/oracle/oradata/xifenfei/xdb01.dbf',
'/opt/oracle/oradata/xifenfei/UNDOTBS01.dbf'
CHARACTER SET ZHS16GBK
;
ORACLE instance started.
Total System Global Area 236000356 bytes
Fixed Size 451684 bytes
Variable Size 201326592 bytes
Database Buffers 33554432 bytes
Redo Buffers 667648 bytes
SQL> 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Control file created.
SQL> alter database open;
Database altered.
SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/opt/oracle/oradata/xifenfei/temp01.dbf'
2 SIZE 32505856 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;
重建控制文件后,需要添加临时文件
补充说明:
1、datafile 的file header 存储在第一个block里
2、Oracle considers four attributes of this data structure when determining if a datafile is sync with the other data files of the database:(不同oracle版本offset可能不同)
(1)kscnbas (at offset 140) – SCN of last change to the datafile.
(2)kcvcptim (at offset 148) -Time of the last change to the datafile.
(3)kcvfhcpc (at offset 176) – Checkpoint count.
(4)kcvfhccc (at offset 184) – Unknown, but is always 1 less than thecheckpoint point count.
Oracle有4个属性来判断datafile 是否和其他的datafile 一致,如果都一致,可以正常操作,如果不一致,那么会报ORA-01113错误
使用Oracle Recovery Tools一键式解决给问题

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

