How many types of SCN, well the better question would be how many places the SCN is stored.
Well, there are not MANY types of SCN which are there actually but stored many places with different names and different purposes.
The SCN will be only one number, a incremented value of every 3?(5 seconds 10g?). The SCN number at a specific moment is recorded in a lot of different places to help identify the state of the database. For each different place it is recorded, and for each different purpose it is recorded, it is commonly given a different name.
How many kinds of SCN are there? or how many places SCN store.
There are a few places in each database block, a few in the data file headers, a couple in the control files, some in the redo log files, some in the UNDO/ROLLBACK segments, and a number on the system dictionary (as well as some other plaves not mentioned). Each location basically provides a target ‘time’ at which an important change (relative to data) occurred, allowing the database software to rebuild that object to that time.
There are checkpoint SCNs(end of checkpoint),Commit SCNs(end of transaction),Snapshot SCNs(beginning of the query) ,system SCN etc..They are basically sequence of integers Oracle uses internally to keep track of various events and block versions to ensure statement level read consistency,multiversioning,transaction rollback,instance recovery etc etc. They(system SCNs) DO GET incremented as and when you make changes to data blocks irrespective of the state of the transaction. Oracle differentiates between these SCNs depending on its purpose(for example you are concerned about Snapshot SCN when you begin your statement. You are concerned about COMMIT SCN when you commit or rollback.You are concerned about CHECKPOINT SCN when performing recovery and so on )
What is SCN? (From Riyaz post)
SCN (System Change Number) is a primary mechanism to maintain data consistency in Oracle database. SCN is used primarily in the following areas, of course, this is not a complete list:
- Every redo record has an SCN version of the redo record in the redo header (and redo records can have non-unique SCN). Given redo records from two threads (as in the case of RAC), Recovery will order them in SCN order, essentially maintaining a strict sequential order. every redo record has multiple change vectors too.
- Every data block also has block SCN (aka block version). In addition to that, a change vector in a redo record also has expected block SCN. This means that a change vector can be applied to one and only version of the block. Code checks if the target SCN in a change vector is matching with the block SCN before applying the redo record. If there is a mismatch, corruption errors are thrown.
- Read consistency also uses SCN. Every query has query environment which includes an SCN at the start of the query. A session can see the transactional changes only if that transaction commit SCN is lower then the query environment SCN.
- Commit. Every commit will generate SCN, aka commit SCN, that marks a transaction boundary. Group commits are possible too.
What happens when a transaction commits? from the documentation.
When a transaction commits, the following actions occur:
- A system change number (SCN) is generated for the COMMIT.
- The internal transaction table for the associated undo tablespace records that the transaction has committed. The corresponding unique SCN of the transaction is assigned and recorded in the transaction table. See "Serializable Isolation Level".
- The log writer (LGWR) process writes remaining redo log entries in the redo log buffers to the online redo log and writes the transaction SCN to the online redo log. This atomic event constitutes the commit of the transaction.
- Oracle Database releases locks held on rows and tables.
- Users who were enqueued waiting on locks held by the uncommitted transaction are allowed to proceed with their work.
- Oracle Database deletes savepoints.
- Oracle Database performs a commit cleanout.
- If modified blocks containing data from the committed transaction are still in the SGA, and if no other session is modifying them, then the database removes lock-related transaction information from the blocks. Ideally, the COMMIT cleans out the blocks so that a subsequent SELECT does not have to perform this task.
Side note:- So cleanout (full with redo) will be performed during commit if the blocks are still in the SGA. In active systems, it is common for blocks with uncommited transactions to be written to disk and flushed from the SGA. In this case, the block is left as is and the next query that touches the block will perform delayed block cleanout (your point 5 doesn’t happen in all cases).
Each type of SCN and their location and what they have been called and its purpose
|Placestored||Called as||Visible as column||Related View||Purpose|
|V$database||For recover database using backup control file|
|ControlFile||individual datafile SCN||checkpoint
|v$datafile||We need this individual SCN for each datafile since there are some datafiles which need recovery due to offline status, this is different from the System SCN above|
|ControlFile||Stop SCN||last_change#||v$datafile||For Instance Recovery|
|v$datafile_header||The start of the SCn when the instance started|
|Redofile||HighSCN||Next_change#||V$log_history||The last scn recorded in the redo log files.|
||The oldest recorded SCN from where the next redo log file starts.|
|Block||BlockSCN||Ex: scn: 0×0000.
|Dump the block
||Every data block also has block SCN (aka block version). to match up the redo records before applying it|
|Every commit will generate SCN, aka commit SCN, that marks a transaction boundary.|
|Redo? PGA? Not sure where it records||SnapshotSCN||When a transaction or query begins, the current SCN is recorded. That SCN serves as the snapshot SCN for the query or transaction||scn: kcmgss in v$sysstat?
Current SCN from v$database?
|When the query starts it has to note down the SCN that current database or block has so that it can report consistent block back|
Thanks to nice references or post below:-