eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 在北京Oracle 11g发布会作主题演讲 | Blog首页 | 开始一段假期 广州成都还有北京 »

控制文件的SECTION 11是什么?

有朋友遇到了控制文件不能扩展的问题,主要的错误提示信息如下:
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 |

4 Comments

谢谢,受教了。
请问这个报错的原因是什么,又没有方法避免ARCHIVED LOG在controlfile中达到最大值呢?65535是不是已经是oracle的极限了呢?重建controlfile可以清零这些纪录,如果不重建,如何清除这些纪录呢?

总不能定期重建controlfile吧?

有时跟人家说"我帮你Google一下". 其实还是自已去查比较好, 以不是急的事.

这个不能算错误.

第一个可以将keep time设得小一些
第二个估计你可以增加日志组的大小.

参考

metalink Note:47322.1, note 217718.1, Note:134234.1, Note:1060139.6,

没错,多动脑筋,事半功倍。


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com