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
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











Apple の最新リリースの iOS18、iPadOS18、および macOS Sequoia システムでは、さまざまな理由で紛失または破損した写真やビデオをユーザーが簡単に回復できるように設計された重要な機能が写真アプリケーションに追加されました。この新機能では、写真アプリのツール セクションに「Recovered」というアルバムが導入され、ユーザーがデバイス上に写真ライブラリに含まれていない写真やビデオがある場合に自動的に表示されます。 「Recovered」アルバムの登場により、データベースの破損、カメラ アプリケーションが写真ライブラリに正しく保存されない、または写真ライブラリを管理するサードパーティ アプリケーションによって失われた写真やビデオに対する解決策が提供されます。ユーザーはいくつかの簡単な手順を実行するだけで済みます

Hibernate ポリモーフィック マッピングは、継承されたクラスをデータベースにマップでき、次のマッピング タイプを提供します。 join-subclass: 親クラスのすべての列を含む、サブクラス用の別個のテーブルを作成します。 table-per-class: サブクラス固有の列のみを含む、サブクラス用の別個のテーブルを作成します。 Union-subclass: join-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 拡張機能をインストールし、接続 (サーバー名、ユーザー名、パスワード、データベース名) を作成します。 PostgreSQL: PgSQL 拡張機能をインストールし、接続 (ホスト、データベース名、ユーザー、パスワード) を作成します。 Oracle: OracleOCI8 拡張機能をインストールし、接続 (サーバー名、ユーザー名、パスワード) を作成します。実際のケース: MySQL データ、PostgreSQL クエリ、OracleOCI8 更新レコードを取得します。
