关于数据库open阶段时何时需要recovery： 1. oracle通过系统checkpoint scn，datafile checkpoint scn,start scn三者之间的比较来判断数据文件是否需要进行介质恢复. 2. 在redo 线程打开的情况下，即数据库open的情况下，stop scn会被设置为无穷大，当正常关
关于数据库open阶段时何时需要recovery：<br>
1. oracle通过系统checkpoint scn，datafile checkpoint scn,start scn三者之间的比较来判断数据文件是否需要进行介质恢复.<br>
2. 在redo 线程打开的情况下，即数据库open的情况下，stop scn会被设置为无穷大，当正常关闭时，stop scn等于datafile scn.<br>
这里需要注意的是，stop scn是存放在controlfile中的，网上部分资料说是存在datafile header中，这个说法是错误的 。<br>
3. oracle在open之前是先判断是否进行介质恢复，然后再是判断是否进行instance recovery。<br>
4. 关于4种scn的关系如下：<br>
system checkpoint scn — 存放在controlfile中<br>
datafile checkpoint scn –存放在controlfile中<br>
start scn —存放在datafile header中<br>
stop scn —存放在controlfile中
system scn，datafile checkpoint scn，start scn，这3种scn用于判断数据文件是否需要进行介质恢复。这3个相等这不需要介质恢复。
如何这4个都相等，那么就不需要进行实例恢复。stop scn是用于判断是否进行实例恢复的。
5. 如果stop scn比其他的几个scn要大，那么就需要进行instance recover，需要进行扫描redo，实例恢复的起点是low cache rba，终点
是redo log的最末端。
自己的理解：
关于上述几点小鱼测试过程中并不如此，oracle恢复是分介质恢复和实例恢复，介质恢复是需要利用备份集和归档来恢复的，而实例恢复则是自动的利用在线日志进行的。
但是试想一种情况，shutdown abort数据库，然后删除掉所有的在线日志，而此时你重启这个数据库到mount状态，可以清晰的看见如下过程：
SQL> select checkpoint_change#,name from v$datafile;
CHECKPOINT_CHANGE# NAME
------------------ --------------------------------------------------
1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SYSTEM01.DBF
1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\UNDOTBS01.DB
F
1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SYSAUX01.DBF
1303384 G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\USERS01.DBF
SQL> select name,checkpoint_change#,checkpoint_count from v$datafile_header;
NAME CHECKPOINT_CHANGE# CHECKPOINT_COUNT
---------------------------------------- ------------------ ----------------
G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SY 1303384 112
STEM01.DBF
G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\UN 1303384 75
DOTBS01.DBF
G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SY 1303384 112
SAUX01.DBF
G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\US 1303384 111
ERS01.DBF
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
1303384
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: 'G:\ORACLE\PRODUCT\10.2.0\ORADATA\UTF8\SYSTEM01.DBF'
看出system的checkpoint scn、控制文件中记录的数据文件的checkpoint scn和数据文件头记录的start scn是一致,
但是由于这里删除了所有的redo,open resetlogs过程中会重置所有redo序号，然后重新生成redo，但是由于缺少之前的在线redo，导致实例恢复失败，也就提示需要进一步恢复file 1
那么来说：
这里小鱼想提出并不是所谓的实例恢复就不会报出所谓的错误的，数据库在open阶段能自动实现的就是实例恢复，介质恢复是需要dba去手动执行的，
但是如果实例恢复失败了，比如缺少在线redo，那么一样会出现无法打开数据库，并不意味着实例恢复好像不影响数据库的能否正常打开，这点需要特别明确。
这里小鱼看了好几个版本的数据库何时需要恢复，整理下想法：（eygle也曾经这么说过）
1 控制文件记录的checkpoint cnt也就是检查点计数和数据文件头记录的checkpoint cnt是否一致，并不是说数据文件头的启动scn和控制文件中记录的scn一致
控制文件记录的checkpoint cnt和数据文件头的checkpoint cnt这个可以用来区分数据文件和控制文件是否来自同一版本，而不是从备份中得来。
checkpoint scn检查点计数这个主要是用于区分数据文件和控制文件是否来自同一版本，这个非常重要。
有网友做过测试即使数据文件的启动scn和控制文件中记录的数据文件的checkpint scn不一致，同样可以打开数据库。（注意控制文件中也记录了数据文件的checkpoint scn）
2 数据文件头的启动scn和控制文件的结束scn是否一致，不一致则需要进行实例恢复，实例恢复是自动的，但是并不意味不重要，如果由于缺少日志恢复失败一样无法打开数据库。
puber上面的一个网友的测试说明：
SQL> startup mount
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 2bc309 2bc309
2 2bc309 2bc309
3 2bc309 2bc309
4 2bc309 2bc309
5 2bc309 2bc309
SQL>
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
2bc309
2bc309
2bc309
2bc309
2bc309
SQL>
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2bc309
SQL> host
RMAN> restore datafile 3
2> ;
........
RMAN> recover datafile 3;
........
RMAN> exit
恢复管理器完成。
Cocuments and SettingsRequieM>exit
SQL> select file#,checkpoint_change#,last_change# from v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 2bc309 2bc309
2 2bc309 2bc309
3 2bc309 2bc308
4 2bc309 2bc309
5 2bc309 2bc309
SQL>
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
2bc309
2bc309
2bc308
2bc309
2bc309
SQL> alter database open;
在作上述步骤同时选取几个时间点，对控制文件和数据文件头作dump。过程太长，只贴一下结果。
1、shutdown以后；
2、restore以后；
3、recover以后；
4、open db以后。
结果如下：
时间点 控制文件 数据文件头
chk cnt chk scn chk cnt chk scn
1 302 2bc309 302 2bc309
2 302 2bc309 264 233c60 --看出这里restore时数据文件头的启动cnt和控制文件记录cnt不一致
3 303 2bc309 303 2bc308 --recover后利用归档和在线日志已经达到了cnt一致，但是checkpoint scn并不一致
4 304 2bc30a 304 2bc30a
结论：当恢复结束时，文件头内的chk scn比控制文件中的chk scn小1，但是chk cnt是完全相同的。
因此，数据库打开时比较的是检查点计数和数据文件头的启动scn和控制文件的数据文件的结束scn，而不是比较数据文件头启动scn和控制文件的checkpoint scn。
自己做了一个测试：
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
SQL> startup mount;
rman>restore datafile 4;
alter session set events 'immediate trace name controlf level 12';
controlfile trace：
DUMP OF CONTROL FILES, Seq # 1497 = 0x5d9
V10 STYLE FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=4166494968=0xf857aaf8, Db Name='ORA10G'
Activation ID=0=0x0
Control Seq=1497=0x5d9, File size=432=0x1b0
File Number=0, Blksiz=16384, File Type=1 CONTROL
Logical block number 1 (header block)
DATA FILE #4:
(name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:316 scn: 0x0000.001818e7 05/28/2014 17:21:16 --这个checkpoint cnt 316就是控制文件记录的检查点计数，scn: 0x0000.001818e7是控制文件记录的数据文件的checkpoint scn
Stop scn: 0x0000.001818e7 05/28/2014 17:21:16 -- 这个Stop scn: 0x0000.001818e7就是所谓的数据文件的stop scn，注意的是这个stop scn并不是在数据文件中，而是记录在控制文件中
Creation Checkpointed at scn: 0x0000.00002997 08/26/2008 12:33:50
thread:0 rba:(0x0.0.0)
alter session set events 'immediate trace name file_hdrs level 10';
file_hdrs trace:
DATA FILE #4:
(name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:316 scn: 0x0000.001818e7 05/28/2014 17:21:16 这一段并不是数据文件头的信息，而只是控制文件中关于这个数据文件的信息，这个一定要特别注意，曾几何时这个困扰了小鱼好长时间
Stop scn: 0x0000.001818e7 05/28/2014 17:21:16
Creation Checkpointed at scn: 0x0000.00002997 08/26/2008 12:33:50
thread:0 rba:(0x0.0.0)
这段file header才是数据文件头的信息
V10 STYLE FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=4166494968=0xf857aaf8, Db Name='ORA10G'
Activation ID=0=0x0
Control Seq=1474=0x5c2, File size=12000=0x2ee0
File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - USERS rel_fn:4
Creation at scn: 0x0000.00002997 08/26/2008 12:33:50
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x3285b2bc scn: 0x0000.00093009 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
prev reset logs count:0x2790538b scn: 0x0000.00000001 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
recovered at 05/28/2014 17:25:05
status:0x0 root dba:0x00000000 chkpt cnt: 314 ctl cnt:313 --首先这个chkpt cnt: 314就是数据文件头的检查点计数checkpoint cnt
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.001817ee 05/28/2014 17:20:29 --而这个checkpointed at scn: 0x0000.001817ee就是数据文件头的scn，也就是我们所谓的数据文件头的启动scn
SQL> select checkpoint_change#,last_change# from v$datafile;
CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
1579239 1579239
1579239 1579239
1579239 1579239
1579239 1579239
V$datafile中Last_change#就是控制文件记录的数据文件的stop scn，v$datafile的checkpoint_change#是控制文件中记录的数据文件的checkpoint scn
SQL> select checkpoint_change#,checkpoint_count from v$datafile_header;
CHECKPOINT_CHANGE# CHECKPOINT_COUNT
------------------ ----------------
1579239 318
1579239 108
1579239 318
1578990 314
V$datafile_header中的checkpoint_change#就是数据文件头的checkpoint scn（也叫做start scn），v$datafile_header中的checkpoint_count就是数据文件头的checkpoint count
而我们查询v$datafile和v$datafile_header视图发现查询结果确实和我们上面dump controlfile和datafile header结果一致
比如这里的v$datafile_header中的checkpoint_change#是1578990正好对应于dump datafile header trace文件中的Checkpointed at scn: 0x0000.001817ee，而v$datafile_headers的checkpoint_count 314也正好对应于chkpt cnt: 314
SQL> recover datafile 4
SQL> select checkpoint_change#,last_change# from v$datafile;
CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
1579239 1579239
1579239 1579239
1579239 1579239
1579239 1579238
SQL> select checkpoint_change#,checkpoint_count from v$datafile_header;
CHECKPOINT_CHANGE# CHECKPOINT_COUNT
------------------ ----------------
1579239 318
1579239 108
1579239 318
1579238 317
controlfile trace:
DATA FILE #4:
(name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:317 scn: 0x0000.001818e7 05/28/2014 17:21:16 --这里控制文件中记录checkpoint cnt变为了317，之前控制文件中记录的是316，这个checkpoint scn没有变化
Stop scn: 0x0000.001818e6 05/28/2014 17:21:16 --Stop scn: 0x0000.001818e7变为了Stop scn: 0x0000.001818e6，这里stop scn减少了1
Creation Checkpointed at scn: 0x0000.00002997 08/26/2008 12:33:50
thread:0 rba:(0x0.0.0)
datafile header trace:
DATA FILE #4:
(name #4) G:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\USERS01.DBF
creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1
tablespace 4, index=4 krfil=4 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:317 scn: 0x0000.001818e7 05/28/2014 17:21:16
Stop scn: 0x0000.001818e6 05/28/2014 17:21:16
Creation Checkpointed at scn: 0x0000.00002997 08/26/2008 12:33:50
thread:0 rba:(0x0.0.0)
aux_file is NOT DEFINED
V10 STYLE FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=4166494968=0xf857aaf8, Db Name='ORA10G'
Activation ID=0=0x0
Control Seq=1499=0x5db, File size=12000=0x2ee0
File Number=4, Blksiz=8192, File Type=3 DATA
Tablespace #4 - USERS rel_fn:4
Creation at scn: 0x0000.00002997 08/26/2008 12:33:50
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
reset logs count:0x3285b2bc scn: 0x0000.00093009 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
prev reset logs count:0x2790538b scn: 0x0000.00000001 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
recovered at 05/28/2014 17:47:28
status:0x0 root dba:0x00000000 chkpt cnt: 317 ctl cnt:316 -- checkpoint cnt从314变为了317，此时datafile header中记录的checkpoint cnt已经和controlfile中记录的checkpoint cnt一致了
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.001818e6 05/28/2014 17:21:16 --datafile header的checkpoint scn（start scn）也变为了 0x0000.001818e6和控制文件中记录的stop scn也已经一致了
此时这个数据库已经完成了检测：controlfile中记录的checkpoint cnt和datafile header中记录的checkpoint cnt一致；controlfile中记录的stop scn和datafile header中记录的checkpoint scn(也叫start scn）一致。
但是正如这个过程还有很多需要注意的地方，比如这个controlfile中记录的scn是什么，和启动数据库有什么关系，对于recovery还是要等后面借助bbed对block、recovery有深刻的认知后才能慢慢解开面纱。
其实探索这些东西短期内可能并不会为我们带来什么收益，但是正如小鱼个人认为，如果想突破所谓的瓶颈（一般人都会遇见，至少小鱼现在算是遇见了），比如在某些方面比如优化、sql tuning、troubleshooting、recovery等方面的有深入学习的探索的毅力和行为，坚持下去可能瓶颈就慢慢突破了！
原文地址：数据库open阶段关于检查点的校验, 感谢原作者分享。
MySQL에서 느린 쿼리를 식별하고 최적화하는 방법은 무엇입니까? (느린 쿼리 로그, Performance_schema)Apr 10, 2025 am 09:36 AMMySQL 느린 쿼리를 최적화하려면 SlowQueryLog 및 Performance_Schema를 사용해야합니다. 1. SlowQueryLog 및 Set Stresholds를 사용하여 느린 쿼리를 기록합니다. 2. Performance_schema를 사용하여 쿼리 실행 세부 정보를 분석하고 성능 병목 현상을 찾고 최적화하십시오.
MySQL 및 SQL : 개발자를위한 필수 기술Apr 10, 2025 am 09:30 AMMySQL 및 SQL은 개발자에게 필수적인 기술입니다. 1.MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템이며 SQL은 데이터베이스를 관리하고 작동하는 데 사용되는 표준 언어입니다. 2.MYSQL은 효율적인 데이터 저장 및 검색 기능을 통해 여러 스토리지 엔진을 지원하며 SQL은 간단한 문을 통해 복잡한 데이터 작업을 완료합니다. 3. 사용의 예에는 기본 쿼리 및 조건 별 필터링 및 정렬과 같은 고급 쿼리가 포함됩니다. 4. 일반적인 오류에는 구문 오류 및 성능 문제가 포함되며 SQL 문을 확인하고 설명 명령을 사용하여 최적화 할 수 있습니다. 5. 성능 최적화 기술에는 인덱스 사용, 전체 테이블 스캔 피하기, 조인 작업 최적화 및 코드 가독성 향상이 포함됩니다.
MySQL 비동기 마스터 슬레이브 복제 프로세스를 설명하십시오.Apr 10, 2025 am 09:30 AMMySQL 비동기 마스터 슬레이브 복제는 Binlog를 통한 데이터 동기화를 가능하게하여 읽기 성능 및 고 가용성을 향상시킵니다. 1) 마스터 서버 레코드는 Binlog로 변경됩니다. 2) 슬레이브 서버는 I/O 스레드를 통해 Binlog를 읽습니다. 3) 서버 SQL 스레드는 데이터를 동기화하기 위해 Binlog를 적용합니다.
MySQL : 쉽게 학습하기위한 간단한 개념Apr 10, 2025 am 09:29 AMMySQL은 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1) 데이터베이스 및 테이블 작성 : CreateAbase 및 CreateTable 명령을 사용하십시오. 2) 기본 작업 : 삽입, 업데이트, 삭제 및 선택. 3) 고급 운영 : 가입, 하위 쿼리 및 거래 처리. 4) 디버깅 기술 : 확인, 데이터 유형 및 권한을 확인하십시오. 5) 최적화 제안 : 인덱스 사용, 선택을 피하고 거래를 사용하십시오.
MySQL : 데이터베이스에 대한 사용자 친화적 인 소개Apr 10, 2025 am 09:27 AMMySQL의 설치 및 기본 작업에는 다음이 포함됩니다. 1. MySQL 다운로드 및 설치, 루트 사용자 비밀번호를 설정하십시오. 2. SQL 명령을 사용하여 CreateAbase 및 CreateTable과 같은 데이터베이스 및 테이블을 만듭니다. 3. CRUD 작업을 실행하고 삽입, 선택, 업데이트, 명령을 삭제합니다. 4. 성능을 최적화하고 복잡한 논리를 구현하기 위해 인덱스 및 저장 절차를 생성합니다. 이 단계를 사용하면 MySQL 데이터베이스를 처음부터 구축하고 관리 할 수 있습니다.
InnoDB 버퍼 풀은 어떻게 작동하며 성능에 중요한 이유는 무엇입니까?Apr 09, 2025 am 12:12 AMinnodbbufferpool은 데이터와 색인 페이지를 메모리에로드하여 MySQL 데이터베이스의 성능을 향상시킵니다. 1) 데이터 페이지가 버퍼 풀에로드되어 디스크 I/O를 줄입니다. 2) 더러운 페이지는 정기적으로 디스크로 표시되고 새로 고침됩니다. 3) LRU 알고리즘 관리 데이터 페이지 제거. 4) 읽기 메커니즘은 가능한 데이터 페이지를 미리로드합니다.
MySQL : 초보자를위한 데이터 관리의 용이성Apr 09, 2025 am 12:07 AMMySQL은 설치가 간단하고 강력하며 데이터를 쉽게 관리하기 쉽기 때문에 초보자에게 적합합니다. 1. 다양한 운영 체제에 적합한 간단한 설치 및 구성. 2. 데이터베이스 및 테이블 작성, 삽입, 쿼리, 업데이트 및 삭제와 같은 기본 작업을 지원합니다. 3. 조인 작업 및 하위 쿼리와 같은 고급 기능을 제공합니다. 4. 인덱싱, 쿼리 최적화 및 테이블 파티셔닝을 통해 성능을 향상시킬 수 있습니다. 5. 데이터 보안 및 일관성을 보장하기위한 지원 백업, 복구 및 보안 조치.
MySQL에서 인덱스를 사용하는 것보다 전체 테이블 스캔이 더 빠를 수 있습니까?Apr 09, 2025 am 12:05 AM전체 테이블 스캔은 MySQL에서 인덱스를 사용하는 것보다 빠를 수 있습니다. 특정 사례는 다음과 같습니다. 1) 데이터 볼륨은 작습니다. 2) 쿼리가 많은 양의 데이터를 반환 할 때; 3) 인덱스 열이 매우 선택적이지 않은 경우; 4) 복잡한 쿼리시. 쿼리 계획을 분석하고 인덱스 최적화, 과도한 인덱스를 피하고 정기적으로 테이블을 유지 관리하면 실제 응용 프로그램에서 최상의 선택을 할 수 있습니다.
핫 AI 도구
Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱
AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.
Undress AI Tool
무료로 이미지를 벗다
Clothoff.io
AI 옷 제거제
AI Hentai Generator
AI Hentai를 무료로 생성하십시오.
인기 기사
뜨거운 도구
mPDF
mPDF는 UTF-8로 인코딩된 HTML에서 PDF 파일을 생성할 수 있는 PHP 라이브러리입니다. 원저자인 Ian Back은 자신의 웹 사이트에서 "즉시" PDF 파일을 출력하고 다양한 언어를 처리하기 위해 mPDF를 작성했습니다. HTML2FPDF와 같은 원본 스크립트보다 유니코드 글꼴을 사용할 때 속도가 느리고 더 큰 파일을 생성하지만 CSS 스타일 등을 지원하고 많은 개선 사항이 있습니다. RTL(아랍어, 히브리어), CJK(중국어, 일본어, 한국어)를 포함한 거의 모든 언어를 지원합니다. 중첩된 블록 수준 요소(예: P, DIV)를 지원합니다.
SublimeText3 Linux 새 버전
SublimeText3 Linux 최신 버전
맨티스BT
Mantis는 제품 결함 추적을 돕기 위해 설계된 배포하기 쉬운 웹 기반 결함 추적 도구입니다. PHP, MySQL 및 웹 서버가 필요합니다. 데모 및 호스팅 서비스를 확인해 보세요.
SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.
안전한 시험 브라우저
안전한 시험 브라우저는 온라인 시험을 안전하게 치르기 위한 보안 브라우저 환경입니다. 이 소프트웨어는 모든 컴퓨터를 안전한 워크스테이션으로 바꿔줍니다. 이는 모든 유틸리티에 대한 액세스를 제어하고 학생들이 승인되지 않은 리소스를 사용하는 것을 방지합니다.
뜨거운 주제
1374
524019