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

TograntpermissionstonewMySQLusers,followthesesteps:1)AccessMySQLasauserwithsufficientprivileges,2)CreateanewuserwiththeCREATEUSERcommand,3)UsetheGRANTcommandtospecifypermissionslikeSELECT,INSERT,UPDATE,orALLPRIVILEGESonspecificdatabasesortables,and4)

ToaddusersinMySQLeffectivelyandsecurely,followthesesteps:1)UsetheCREATEUSERstatementtoaddanewuser,specifyingthehostandastrongpassword.2)GrantnecessaryprivilegesusingtheGRANTstatement,adheringtotheprincipleofleastprivilege.3)Implementsecuritymeasuresl

ToaddanewuserwithcomplexpermissionsinMySQL,followthesesteps:1)CreatetheuserwithCREATEUSER'newuser'@'localhost'IDENTIFIEDBY'password';.2)Grantreadaccesstoalltablesin'mydatabase'withGRANTSELECTONmydatabase.TO'newuser'@'localhost';.3)Grantwriteaccessto'

The string data types in MySQL include CHAR, VARCHAR, BINARY, VARBINARY, BLOB, and TEXT. The collations determine the comparison and sorting of strings. 1.CHAR is suitable for fixed-length strings, VARCHAR is suitable for variable-length strings. 2.BINARY and VARBINARY are used for binary data, and BLOB and TEXT are used for large object data. 3. Sorting rules such as utf8mb4_unicode_ci ignores upper and lower case and is suitable for user names; utf8mb4_bin is case sensitive and is suitable for fields that require precise comparison.

The best MySQLVARCHAR column length selection should be based on data analysis, consider future growth, evaluate performance impacts, and character set requirements. 1) Analyze the data to determine typical lengths; 2) Reserve future expansion space; 3) Pay attention to the impact of large lengths on performance; 4) Consider the impact of character sets on storage. Through these steps, the efficiency and scalability of the database can be optimized.

MySQLBLOBshavelimits:TINYBLOB(255bytes),BLOB(65,535bytes),MEDIUMBLOB(16,777,215bytes),andLONGBLOB(4,294,967,295bytes).TouseBLOBseffectively:1)ConsiderperformanceimpactsandstorelargeBLOBsexternally;2)Managebackupsandreplicationcarefully;3)Usepathsinst

The best tools and technologies for automating the creation of users in MySQL include: 1. MySQLWorkbench, suitable for small to medium-sized environments, easy to use but high resource consumption; 2. Ansible, suitable for multi-server environments, simple but steep learning curve; 3. Custom Python scripts, flexible but need to ensure script security; 4. Puppet and Chef, suitable for large-scale environments, complex but scalable. Scale, learning curve and integration needs should be considered when choosing.

Yes,youcansearchinsideaBLOBinMySQLusingspecifictechniques.1)ConverttheBLOBtoaUTF-8stringwithCONVERTfunctionandsearchusingLIKE.2)ForcompressedBLOBs,useUNCOMPRESSbeforeconversion.3)Considerperformanceimpactsanddataencoding.4)Forcomplexdata,externalproc


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

SecLists
SecLists is the ultimate security tester's companion. It is a collection of various types of lists that are frequently used during security assessments, all in one place. SecLists helps make security testing more efficient and productive by conveniently providing all the lists a security tester might need. List types include usernames, passwords, URLs, fuzzing payloads, sensitive data patterns, web shells, and more. The tester can simply pull this repository onto a new test machine and he will have access to every type of list he needs.

DVWA
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is very vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, to help web developers better understand the process of securing web applications, and to help teachers/students teach/learn in a classroom environment Web application security. The goal of DVWA is to practice some of the most common web vulnerabilities through a simple and straightforward interface, with varying degrees of difficulty. Please note that this software

SublimeText3 Mac version
God-level code editing software (SublimeText3)

SublimeText3 English version
Recommended: Win version, supports code prompts!

SublimeText3 Linux new version
SublimeText3 Linux latest version
