Oracle scn介绍
SCN是当Oracle数据库更新后,由DBMS自动维护去累积递增的一个数字。当一笔交易commit 时,LGWR会将log buffer写入redo log file,
上次做了下基于scn恢复delete掉的数据后,觉得应该好好理解下scn的知识,今天在网上找了下相关的介绍,参考了某些文章,,在此我通过实验总结一下。
SCN是当Oracle数据库更新后,由DBMS自动维护去累积递增的一个数字。当一笔交易commit 时,LGWR会将log buffer写入redo log file,同时也会将该笔交易的SCN同步写入到redo log file内(wait-until-completed)。因此当你commit transaction时,在交易成功的讯息返回之前,LGWR必须先完整的完成上述行为之后,否则你是看不到提交成功的回应讯息。
那系统是如何产生一个最新的
select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback
2 .get_system_change_number) from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)
---------------------------------------------------------------------------
117947354
24-MAR-11 11.32.22.000000000 AM
也可以用函数
SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
control中有三种SCN分别为,system SCN、datafile SCN、last SCN,数据文件头中有一种SCN start SCN
system scn从视图v$database中获得,对应checkpoint_change#字段,datafile scn、last scn分别对应视图v$datafile中的checkpoint_change#,last_change#,而 start scn则从v$datafile_header中checkpoint_change#得到。
数据库在正常启动后下,system scn,datafile scn,start scn会相等,而last scn会被置于无穷大,这里为null。
正常关闭后(immediate,noraml,translate),上面四个scn会应执行full checkpoint 而相等。
当系统在非正常关闭后,如shutdown abort,这个时候last scn依然为无穷大,那么当重新启动实例时,系统首先会比较start scn与system scn,如果一致,那么再比较start scn 与last scan是否一样大,因为是非正常关闭,这里会不一样大,那么就需要例程恢复。
如果打开数据库时发现system scn>datafile scn,那么以为着使用旧的备份数据文件,也就是需要介质恢复
如果是system scn
SQL> SELECT checkpoint_change# FROM v$database;
CHECKPOINT_CHANGE#
------------------
117866282
SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 117866282
2 117866282
3 117866282
4 117866282
5 117866282
6 117866282
7 117866282
8 117866282
9 117866282
10 117866282
11 117866282
FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 117866282
13 117866282
14 117866282
14 rows selected.
SQL> SELECT file#, checkpoint_change#, last_change# FROM v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 117866282
2 117866282
3 117866282
4 117866282
5 117866282
6 117866282
7 117866282
8 117866282
9 117866282
10 117866282
11 117866282
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
12 117866282
13 117866282
14 117866282
14 rows selected.
2、正常关闭后,然后在startup mount;
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 835104768 bytes
Fixed Size 2217952 bytes
Variable Size 624953376 bytes
Database Buffers 201326592 bytes
Redo Buffers 6606848 bytes
Database mounted.
SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 117925094
2 117925094
3 117925094
4 117925094
5 117925094
6 117925094
7 117925094
8 117925094
9 117925094
10 117925094
11 117925094
FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 117925094
13 117925094
14 117925094
14 rows selected.
SQL> SELECT checkpoint_change# FROM v$database;
CHECKPOINT_CHANGE#
------------------
117925094
SQL> SELECT file#, checkpoint_change#, last_change# FROM v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 117925094 117925094
2 117925094 117925094
3 117925094 117925094
4 117925094 117925094
5 117925094 117925094
6 117925094 117925094
7 117925094 117925094
8 117925094 117925094
9 117925094 117925094
10 117925094 117925094
11 117925094 117925094
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
12 117925094 117925094
13 117925094 117925094
14 117925094 117925094
14 rows selected.
--发现start scn=last scn,证明系统是正常关闭
SQL> alter database open;
Database altered.
3、在正常打开状态下进行事务操作
SQL> CREATE TABLE w(a number);
Table created.
SQL> INSERT INTO w VALUES(1);
1 row created.
SQL> commit;
Commit complete.
SQL> INSERT INTO w VALUES(2);
1 row created.
4、非正常关闭
SQL> shutdown abort;
ORACLE instance shut down.
5、打开到mount状态下,观看scn
SQL> startup mount;
ORACLE instance started.
Total System Global Area 835104768 bytes
Fixed Size 2217952 bytes
Variable Size 624953376 bytes
Database Buffers 201326592 bytes
Redo Buffers 6606848 bytes
Database mounted.
SQL> SELECT file#,checkpoint_change#, last_change# FROM v$datafile;
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
1 117925097
2 117925097
3 117925097
4 117925097
5 117925097
6 117925097
7 117925097
8 117925097
9 117925097
10 117925097
11 117925097
FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
12 117925097
13 117925097
14 117925097
14 rows selected.
SQL> SELECT checkpoint_change# FROM v$database;
CHECKPOINT_CHANGE#
------------------
117925097
SQL> SELECT file#,checkpoint_chnge# FROM v$datafile_header;
SELECT file#,checkpoint_chnge# FROM v$datafile_header
*
ERROR at line 1:
ORA-00904: "CHECKPOINT_CHNGE#": invalid identifier
SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 117925097
2 117925097
3 117925097
4 117925097
5 117925097
6 117925097
7 117925097
8 117925097
9 117925097
10 117925097
11 117925097
FILE# CHECKPOINT_CHANGE#
---------- ------------------
12 117925097
13 117925097
14 117925097
14 rows selected.
--这时发现start scn 与last scn不等,last scn为无穷大,需要例程恢复
6、改变数据库状态为open,并查看该阶段运行日志
SQL> ALTER DATABASE open;
Database altered.
SQL> SELECT * FROM w;
A
----------
1
--发现没有提交的事务丢失。
查看日志如下:
Thu Mar 24 10:47:24 2011
ALTER DATABASE MOUNT
Successful mount of redo thread 1, with mount id 1274403260
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
Thu Mar 24 10:50:12 2011
ALTER DATABASE open
Beginning crash recovery of 1 threads --会自动判断是否需要恢复,这里开始例程恢复
parallel recovery started with 2 processes
Started redo scan
Completed redo scan
read 162 KB redo, 112 data blocks need recovery
Started redo application at
Thread 1: logseq 2635, block 491121
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2635 Reading mem 0 --恢复用的在线重做日志
Mem# 0: /u01/oradata/orcl/redo01a.log
Mem# 1: /u01/oradata/orcl/redo01b.log
Completed redo application of 0.13MB
Completed crash recovery at --恢复完成
Thread 1: logseq 2635, block 491446, scn 117945330
112 data blocks read, 112 data blocks written, 162 redo k-bytes read
Thu Mar 24 10:50:13 2011
LGWR: STARTING ARCH PROCESSES
Thu Mar 24 10:50:13 2011
ARC0 started with pid=22, OS id=31059
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Mar 24 10:50:14 2011
ARC1 started with pid=23, OS id=31061
Thread 1 advanced to log sequence 2636 (thread open)
Thu Mar 24 10:50:15 2011
ARC2 started with pid=24, OS id=31063
Thread 1 opened at log sequence 2636
Current log# 2 seq# 2636 mem# 0: /u01/oradata/orcl/redo02a.log

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

Apple의 최신 iOS18, iPadOS18 및 macOS Sequoia 시스템 릴리스에는 사진 애플리케이션에 중요한 기능이 추가되었습니다. 이 기능은 사용자가 다양한 이유로 손실되거나 손상된 사진과 비디오를 쉽게 복구할 수 있도록 설계되었습니다. 새로운 기능에는 사진 앱의 도구 섹션에 '복구됨'이라는 앨범이 도입되었습니다. 이 앨범은 사용자가 기기에 사진 라이브러리에 포함되지 않은 사진이나 비디오를 가지고 있을 때 자동으로 나타납니다. "복구된" 앨범의 출현은 데이터베이스 손상으로 인해 손실된 사진과 비디오, 사진 라이브러리에 올바르게 저장되지 않은 카메라 응용 프로그램 또는 사진 라이브러리를 관리하는 타사 응용 프로그램에 대한 솔루션을 제공합니다. 사용자는 몇 가지 간단한 단계만 거치면 됩니다.

Hibernate 다형성 매핑은 상속된 클래스를 데이터베이스에 매핑할 수 있으며 다음 매핑 유형을 제공합니다. Join-subclass: 상위 클래스의 모든 열을 포함하여 하위 클래스에 대한 별도의 테이블을 생성합니다. 클래스별 테이블: 하위 클래스별 열만 포함하는 하위 클래스에 대한 별도의 테이블을 만듭니다. Union-subclass: Joined-subclass와 유사하지만 상위 클래스 테이블이 모든 하위 클래스 열을 통합합니다.

MySQLi를 사용하여 PHP에서 데이터베이스 연결을 설정하는 방법: MySQLi 확장 포함(require_once) 연결 함수 생성(functionconnect_to_db) 연결 함수 호출($conn=connect_to_db()) 쿼리 실행($result=$conn->query()) 닫기 연결( $conn->close())

PHP에서 데이터베이스 연결 오류를 처리하려면 다음 단계를 사용할 수 있습니다. mysqli_connect_errno()를 사용하여 오류 코드를 얻습니다. 오류 메시지를 얻으려면 mysqli_connect_error()를 사용하십시오. 이러한 오류 메시지를 캡처하고 기록하면 데이터베이스 연결 문제를 쉽게 식별하고 해결할 수 있어 애플리케이션이 원활하게 실행될 수 있습니다.

Golang의 데이터베이스 콜백 기능을 사용하면 다음을 달성할 수 있습니다. 지정된 데이터베이스 작업이 완료된 후 사용자 정의 코드를 실행합니다. 추가 코드를 작성하지 않고도 별도의 함수를 통해 사용자 정의 동작을 추가할 수 있습니다. 삽입, 업데이트, 삭제, 쿼리 작업에 콜백 함수를 사용할 수 있습니다. 콜백 함수를 사용하려면 sql.Exec, sql.QueryRow, sql.Query 함수를 사용해야 합니다.

JSON 데이터는 gjson 라이브러리 또는 json.Unmarshal 함수를 사용하여 MySQL 데이터베이스에 저장할 수 있습니다. gjson 라이브러리는 JSON 필드를 구문 분석하는 편리한 방법을 제공하며, json.Unmarshal 함수에는 JSON 데이터를 비정렬화하기 위한 대상 유형 포인터가 필요합니다. 두 방법 모두 SQL 문을 준비하고 삽입 작업을 수행하여 데이터를 데이터베이스에 유지해야 합니다.

Go 표준 라이브러리 데이터베이스/sql 패키지를 통해 MySQL, PostgreSQL 또는 SQLite와 같은 원격 데이터베이스에 연결할 수 있습니다. 데이터베이스 연결 정보가 포함된 연결 문자열을 생성합니다. sql.Open() 함수를 사용하여 데이터베이스 연결을 엽니다. SQL 쿼리 및 삽입 작업과 같은 데이터베이스 작업을 수행합니다. 리소스를 해제하기 위해 defer를 사용하여 데이터베이스 연결을 닫습니다.

PHP 데이터베이스 연결 가이드: MySQL: MySQLi 확장을 설치하고 연결(서버 이름, 사용자 이름, 비밀번호, dbname)을 만듭니다. PostgreSQL: PgSQL 확장을 설치하고 연결(호스트, DB 이름, 사용자, 비밀번호)을 생성합니다. Oracle: OracleOCI8 확장을 설치하고 연결(서버 이름, 사용자 이름, 비밀번호)을 만듭니다. 실제 사례: MySQL 데이터, PostgreSQL 쿼리, OracleOCI8 업데이트 기록을 얻습니다.
