Oracle scn介绍-Mysql Tutorial-php.cn

Home

Database

Mysql Tutorial

Oracle scn介绍

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 05:19 PM

ordatabase

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 scn1、正常启动时
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.

     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

linux

Statement

The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn

深入理解MySQL索引优化器工作原理Nov 09, 2022 pm 02:05 PM

本篇文章给大家带来了关于mysql的相关知识，其中主要介绍了关于索引优化器工作原理的相关内容，其中包括了MySQL Server的组成，MySQL优化器选择索引额原理以及SQL成本分析，最后通过 select 查询总结整个查询过程，下面一起来看一下，希望对大家有帮助。

sybase是什么数据库Sep 22, 2021 am 11:39 AM

sybase是基于客户/服务器体系结构的数据库，是一个开放的、高性能的、可编程的数据库，可使用事件驱动的触发器、多线索化等来提高性能。

visual foxpro数据库文件是什么Jul 23, 2021 pm 04:53 PM

visual foxpro数据库文件是管理数据库对象的系统文件。在VFP中，用户数据是存放在“.DBF”表文件中；VFP的数据库文件（“.DBC”）中不存放用户数据，它只起将属于某一数据库的数据库表与视图、连接、存储过程等关联起来的作用。

数据库系统的构成包括哪些Jul 15, 2022 am 11:58 AM

数据库系统由4个部分构成：1、数据库，是指长期存储在计算机内的，有组织，可共享的数据的集合；2、硬件，是指构成计算机系统的各种物理设备，包括存储所需的外部设备；3、软件，包括操作系统、数据库管理系统及应用程序；4、人员，包括系统分析员和数据库设计人员、应用程序员（负责编写使用数据库的应用程序）、最终用户（利用接口或查询语言访问数据库）、数据库管理员（负责数据库的总体信息控制）。

microsoft sql server是什么软件Feb 28, 2023 pm 03:00 PM

microsoft sql server是Microsoft公司推出的关系型数据库管理系统，是一个全面的数据库平台，使用集成的商业智能（BI）工具提供了企业级的数据管理，具有使用方便可伸缩性好与相关软件集成程度高等优点。SQL Server数据库引擎为关系型数据和结构化数据提供了更安全可靠的存储功能，使用户可以构建和管理用于业务的高可用和高性能的数据应用程序。

数据库的什么是指数据的正确性和相容性Jul 04, 2022 pm 04:59 PM

数据库的“完整性”是指数据的正确性和相容性。完整性是指数据库中数据在逻辑上的一致性、正确性、有效性和相容性。完整性对于数据库系统的重要性：1、数据库完整性约束能够防止合法用户使用数据库时向数据库中添加不合语义的数据；2、合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能；3、完善的数据库完整性有助于尽早发现应用软件的错误。