« 在北京Oracle 11g发布会作主题演讲 | Blog首页 | 开始一段假期 广州成都还有北京 »
控制文件的SECTION 11是什么?
作者：eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接：https://www.eygle.com/archives/2007/09/whats_controlfile_section_11.html
有朋友遇到了控制文件不能扩展的问题，主要的错误提示信息如下：链接：https://www.eygle.com/archives/2007/09/whats_controlfile_section_11.html
Fri Sep 21 09:29:49 2007
kccrsz: denied expansion of controlfile section 11 by 65535 record(s)
the number of records is already at maximum value (65535)
krcpwnc: following controlfile record written over:
查询v$controlfile_record_section可以得出控制文件的使用情况：
SQL> select * from v$controlfile_record_section;
TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID
-------------------- ----------- ------------- ------------ ----------- ---------- ----------
DATABASE 316 1 1 0 0 0
CKPT PROGRESS 4084 4 0 0 0 0
REDO THREAD 228 1 1 0 0 0
REDO LOG 72 5 4 0 0 10
DATAFILE 428 200 126 0 0 274
FILENAME 268 216 138 0 0 0
TABLESPACE 68 200 18 0 0 67
TEMPORARY FILENAME 56 200 4 0 0 14
RMAN CONFIGURATION 1108 50 13 0 0 53
LOG HISTORY 36 65535 65535 64300 64299 178639
OFFLINE RANGE 180 226 0 0 0 0
ARCHIVED LOG 328 65535 65535 65535 65534 123694
BACKUP SET 40 204 204 41 40 3304
BACKUP PIECE 480 408 408 151 150 10350
BACKUP DATAFILE 116 492 492 412 411 11871
BACKUP REDOLOG 76 3761 3761 2111 2110 122462
DATAFILE COPY 404 404 404 94 93 901
BACKUP CORRUPTION 44 371 0 0 0 0
COPY CORRUPTION 40 204 0 0 0 0
DELETED OBJECT 20 4084 4084 2259 2258 134988
PROXY COPY 596 411 0 0 0 0
BACKUP SPFILE 36 226 226 31 30 934
DATABASE INCARNATION 56 145 1 1 1 1
这位朋友提出的一个问题是，哪一个才是section 11?
到底是哪一个部分超出了限制。我们注意到，达到最大限制65535的有LOG HISTORY、ARCHIVED LOG信息。
那到底哪一个才是section 11的错误根源呢？
其实在遇到这类问题时，我们完全可以自己找到答案，运用一点已知的知识。
比如autotrace的功能：
SQL> set autotrace trace explain
SQL> select count(*) from v$controlfile_record_section;
Execution Plan
----------------------------------------------------------
Plan hash value: 1553993283
-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 26 | 0 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 26 | | |
|* 2 | FIXED TABLE FULL| X$KCCRS | 1 | 26 | 0 (0)| 00:00:01 |
-----------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("INDX"<>22 AND "INST_ID"=USERENV('INSTANCE'))
我们可以找到这个视图的底层表X$KCCRS，这个视图的INDX字段显然就是我们所寻找的section的来源。
对照v$controlfile_record_section可以知道section 11是ARCHIVED LOG部分:
SQL> select * from x$kccrs;
ADDR INDX INST_ID RSRSZ RSNUM RSNUS RSIOL RSILW RSRLW
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
B7112E3C 0 1 316 1 1 0 0 0
B7112E3C 1 1 8180 11 0 0 0 0
B7112E3C 2 1 256 8 1 0 0 0
B7112E3C 3 1 72 16 3 0 0 3
B7112E3C 4 1 428 100 24 0 0 33556
B7112E3C 5 1 524 2298 28 0 0 0
B7112E3C 6 1 68 100 7 0 0 11
B7112E3C 7 1 56 100 1 0 0 1
B7112E3C 8 1 1108 50 2 0 0 4
B7112E3C 9 1 56 1168 1168 36 35 24855
B7112E3C 10 1 200 163 0 0 0 0
ADDR INDX INST_ID RSRSZ RSNUM RSNUS RSIOL RSILW RSRLW
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
B7112E3C 11 1 584 1120 1120 242 241 24601
B7112E3C 12 1 40 409 409 62 61 1697
B7112E3C 13 1 736 200 200 98 97 1697
B7112E3C 14 1 116 282 282 256 255 2793
B7112E3C 15 1 76 2150 2150 930 929 24579
B7112E3C 16 1 660 223 0 0 0 0
B7112E3C 17 1 44 371 0 0 0 0
B7112E3C 18 1 40 409 0 0 0 0
B7112E3C 19 1 20 1636 1636 94 93 27905
B7112E3C 20 1 852 249 0 0 0 0
B7112E3C 21 1 36 454 413 1 413 413
ADDR INDX INST_ID RSRSZ RSNUM RSNUS RSIOL RSILW RSRLW
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
B7112E3C 22 1 276 1 1 0 0 0
B7112E3C 23 1 56 292 1 1 1 1
B7112E3C 24 1 84 2048 0 0 0 0
B7112E3C 25 1 180 1 0 0 0 0
B7112E3C 26 1 28 1055 1 0 0 0
B7112E3C 27 1 32 1000 0 0 0 0
B7112E3C 28 1 116 141 141 118 117 1668
B7112E3C 29 1 80 8 8 0 0 0
B7112E3C 30 1 100 8 1 0 0 0
B7112E3C 31 1 568 57 0 0 0 0
B7112E3C 32 1 400 10 10 0 0 0
ADDR INDX INST_ID RSRSZ RSNUM RSNUS RSIOL RSILW RSRLW
-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
B7112E3C 33 1 212 2048 0 0 0 0
B7112E3C 34 1 212 2083 0 0 0 0
35 rows selected.
如果我们曾经知道v$fixed_view_definition，那么我们可以更容易的找到答案：
SELECT inst_id,
DECODE (indx,
0, 'DATABASE',
1, 'CKPT PROGRESS',
2, 'REDO THREAD',
3, 'REDO LOG',
4, 'DATAFILE',
5, 'FILENAME',
6, 'TABLESPACE',
7, 'TEMPORARY FILENAME',
8, 'RMAN CONFIGURATION',
9, 'LOG HISTORY',
10, 'OFFLINE RANGE',
11, 'ARCHIVED LOG',
12, 'BACKUP SET',
13, 'BACKUP PIECE',
14, 'BACKUP DATAFILE',
15, 'BACKUP REDOLOG',
16, 'DATAFILE COPY',
17, 'BACKUP CORRUPTION',
18, 'COPY CORRUPTION',
19, 'DELETED OBJECT',
20, 'PROXY COPY',
21, 'BACKUP SPFILE',
23, 'DATABASE INCARNATION',
24, 'FLASHBACK LOG',
25, 'RECOVERY DESTINATION',
26, 'INSTANCE SPACE RESERVATION',
27, 'REMOVABLE RECOVERY FILES',
28, 'RMAN STATUS',
29, 'THREAD INSTANCE NAME MAPPING',
30, 'MTTR',
31, 'DATAFILE HISTORY',
32, 'STANDBY DATABASE MATRIX',
33, 'GUARANTEED RESTORE POINT',
34, 'RESTORE POINT',
'UNKNOWN'
),
rsrsz, rsnum, rsnus, rsiol, rsilw, rsrlw
FROM x$kccrs
WHERE indx NOT IN (22)
多动点脑筋，对学习实在是会有很多好处。
-The End-
历史上的今天...
>> 2013-09-21文章:
>> 2008-09-21文章:
>> 2006-09-21文章:
>> 2005-09-21文章:
By eygle on 2007-09-21 15:45 | Comments (4) | FAQ | 1624 |
谢谢，受教了。
请问这个报错的原因是什么，又没有方法避免ARCHIVED LOG在controlfile中达到最大值呢？65535是不是已经是oracle的极限了呢？重建controlfile可以清零这些纪录，如果不重建，如何清除这些纪录呢？
总不能定期重建controlfile吧？
有时跟人家说"我帮你Google一下". 其实还是自已去查比较好, 以不是急的事.
这个不能算错误.
第一个可以将keep time设得小一些
第二个估计你可以增加日志组的大小.
参考
metalink Note:47322.1, note 217718.1, Note:134234.1， Note:1060139.6，
没错，多动脑筋，事半功倍。