CHECKPOINTS, SCN, LSN

Greeting to Everyone !
I want to know more about relationship between CHECKPOINTS, SCN, LSN. (to maintain data consistency )
I read some articles many things are confusing me.
Ex:
Every redo log file has both a log sequence number and low and high SCN. The low SCN records
the lowest SCN recorded in the log file, while the high SCN records the highest SCN in the log file.
Thanks in advance ..

Hi Hemanth ; Thanks for your reply.
Anyhow i dont understnd your last line points. If possible , please rewrite with simple explanation.
and my direct question   1) IS LSN really required to maintain data consistency during hot backup ?
                                                   2) Some links say check point occurs every 3 seconds in my case , i never seen .. number never changed unless forcing
12:40:21 SQL> select checkpoint_change#,current_scn from v$database ;
CHECKPOINT_CHANGE# CURRENT_SCN
           1439794     1441646
12:40:44 SQL> select checkpoint_change#,current_scn from v$database ;
CHECKPOINT_CHANGE# CURRENT_SCN
           1439794     1441654
12:41:02 SQL> ALTER SYSTEM CHECKPOINT;
System altered.
12:42:54 SQL> select checkpoint_change#,current_scn from v$database ;
CHECKPOINT_CHANGE# CURRENT_SCN
           1441700     1441703
Thanks

Similar Messages

ORA-19648: datafile 132: incremental-start SCN equals checkpoint SCN

I re-ran full backup but still cumulative backups failing with this error, looking for quick commands to fix this
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on T1 channel at 04/12/2010 20:55:16
ORA-00604: error occurred at recursive SQL level 1
ORA-01427: single-row subquery returns more than one row
ORA-19648: datafile 132: incremental-start SCN equals checkpoint SCN
ORA-19640: datafile checkpoint is SCN 4361058556501 time 02/08/2008 20:32:22

19645, 00000, "datafile %s: incremental-start SCN is prior to creation SCN %s"
// *Cause: The incremental-start SCN which was specified when starting an
// incremental datafile backup is less than the datafile's
// creation SCN.
// *Action: Specify a larger incremental-start SCN.

Checkpoint scn in redolog and controlfile

Hi
The checkpoint scn in datafile headers are updated after checkpoint.
How about redologs and controlfile?
As far I read from the docs
scn's are written to redo logs continuously (every commit), it should also stored in controlfile continuesly(every commit) so that controlfile will know where redochain ends ..
Is that right?

Pascal Nouma wrote:
Yes Aman, I read it.
As I said,
I learned that scn is incremented in controlfile and datafile after checkpoint.
However still have doubts about redologs..No, that's what my doubt is. If you have read the thread thoroughly, it explains that in the redo logs, there is open/close SCN. And I have shown its behavior too there. SCN is nothing but a time stamp(see Hans's reply also for the explanation, in the thread too , I have posted one) and as redologs contain nothing but transactions, each one would be having its starting and ending SCN(the article posted by Hans goes into great length to show it) . The files would have the high and low scn. I would suggest that you reread the thread one more time and come back with a more detailed question. I am not still sure that what is your doubt regarging the scn in the redologs. Control file's mechanism or data files's mechanism are different as the writes happen at certain events while redo logs are constantly being fliushed with the minimum frequency of 3seconds. So things are not really alike and its not good to compare bit by bit all the aspects in every file IMHO.
HTH
Aman....

Checkpoint & SCN

Hi,
I have 1 small doubt related to checkpoint and SCN,
I have scheduled a hot backup at 4AM in the morning & ends at 7 AM in morning,
before and after there are 10 log switches,
But when i checked the at 3 pm , the view v$datafile shows the checkpoint time at 2:31 AM
why is it so? if a checkpoint occurs at the redo log file switch.
It means that there will be last checkpoint after 7AM or latest redo log switch..
Please correct me if Im wrong
Edited by: user10745179 on Sep 28, 2010 3:33 AM

Hi Aman,
thanks for ur reply ,
but then what happens at the begin tablespace backup mode, at that time checkpoint occurs then why it is not updated
Please tell if im wrong?
Please tell me wht exactly happens?
When the checkpoint will occur for other tahn clean shutdown?
Edited by: user10745179 on Sep 28, 2010 4:43 AM
Edited by: user10745179 on Sep 28, 2010 4:44 AM

Checkpoint SCN in backupset belongs to different incarnation

Reallly stuck with this one :( We are on Oracle 10.2.0.4, Solaris 5.3). Took full backup + archivelogs on Server A. Copied backup to server B, where trying to restore via the following method:
1. Restore controlfile:
Rman target /
Startup nomount;
Restore controlfile from ‘/directory_name/c-control_file’2. Catalog backuppieces:
RMAN> alter database mount;
RMAN> catalog backuppiece ‘/new_directory/backup_piece';3.Crosschecking backup:
RMAN> crosscheck backup;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=656 devtype=DISK
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/datafiles.rman recid=74 stamp=745857935
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/arch_KDEV_g8m78jfk_1544_20110315 recid=71 stamp=745857003
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/arch_KDEV_g9m78jfs_1545_20110315 recid=72 stamp=745857053
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/data/scratch/KRONOS/backup/anya/arch_KDEV_gam78jg5_1546_20110315 recid=73 stamp=745857069
Crosschecked 4 objects4. Backup is AVAILABLE
RMAN> list backup of database;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size       Device Type Elapsed Time Completion Time
61      Full    21.00G     DISK        00:05:43     15-MAR-11
        BP Key: 74   Status: AVAILABLE Compressed: NO Tag: TAG20110315T040105
        Piece Name: /data/scratch/KRONOS/backup/anya/datafiles.rman
List of Datafiles in backup set 61
File LV Type Ckp SCN    Ckp Time Name
1       Full 29951409518 15-MAR-11 /data/dbf/kdev/system01.dbf
2       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs1.dbf
3       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs2.dbf
4       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs3.dbf
5       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs4.dbf
6       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs5.dbf
7       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs6.dbf
8       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs7.dbf
9       Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs9.dbf
10      Full 29951409518 15-MAR-11 /data/dbf/kdev/tkcs8.dbf
72      Full 29951409518 15-MAR-11 /data/dbf/kdev/sysaux01.dbf
81      Full 29951409518 15-MAR-11 /data/dbf/kdev/undo01.dbf
82      Full 29951409518 15-MAR-11 /data/dbf/kdev/undo02.dbf
83      Full 29951409518 15-MAR-11 /data/dbf/kdev/undo03.dbf
84      Full 29951409518 15-MAR-11 /data/dbf/kdev/undo04.dbf
85      Full 29951409518 15-MAR-11 /data/dbf/kdev/undo05.dbfWe can see that backup SCN is *29951409518*
4. Listing incarnation of database:
RMAN> list incarnation of database;
List of Database Incarnations
DB Key Inc Key DB Name DB ID            STATUS Reset SCN Reset Time
1       1       KDEV     763526018        PARENT 29215810456 15-DEC-10
2       2       KDEV     763526018        CURRENT 29215838581 15-DEC-10Notice how this incarnation is different *29215838581* from backup SCN of *29951409518*. So when I run restore/recover, it fails:
set until sequence 3289;
set newname for datafile 2 to '/data/scratch/KRONOS/backup/anya/tkcs1.dbf';
set newname for datafile 3 to '/data/scratch/KRONOS/backup/anya/tkcs2.dbf';
set newname for datafile 4 to '/data/scratch/KRONOS/backup/anya/tkcs3.dbf';
set newname for datafile 5 to '/data/scratch/KRONOS/backup/anya/tkcs4.dbf';
set newname for datafile 6 to '/data/scratch/KRONOS/backup/anya/tkcs5.dbf';
set newname for datafile 7 to '/data/scratch/KRONOS/backup/anya/tkcs6.2> dbf';
set newname for datafile 8 to '/data/scratch/KRONOS/backup/anya/tkcs7.dbf';
set newname for datafile 9 to '/data/scratch/KRONOS/backup/anya/tkcs9.dbf';
set newname for datafile 10 to '/data/scratch/KRONOS/backup/anya/tkcs8.dbf';
set newname for datafile 1 to '/data/scratch/KRONOS/backup/anya/system01.dbf';
set newname for datafile 1 to '/data/scratch/KRONOS/backup/anya/undo01.dbf';
set newname for datafile 82 to '/data/scratch/KRONOS/backup/anya/undo02.dbf';
set newname for datafile 83 to '/data/scrat3> ch/KRONOS/backup/anya/undo03';
set newname for datafile 84 to '/data/scratch/KRONOS/backup/anya/undo04';
set newname for datafile 85 to '/data/scratch/KRONOS/backup/anya/undo05.dbf';
set newname for datafile 72 to '/data/scratch/KRONOS/backup/anya/sysaux01.dbf';
restore database;
switch datafile all;
recover database;
alter database open resetlogs;
release channel c1;
}Error:
Starting restore at 15-MAR-11
released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/15/2011 15:27:02
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 85 found to restore
RMAN-06023: no backup or copy of datafile 84 found to restore
RMAN-06023: no backup or copy of datafile 83 found to restore
RMAN-06023: no backup or copy of datafile 82 found to restore
RMAN-06023: no backup or copy of datafile 81 found to restore
RMAN-06023: no backup or copy of datafile 72 found to restore
RMAN-06023: no backup or copy of datafile 10 found to restore
RMAN-06023: no backup or copy of datafile 9 found to restore
RMAN-06023: no backup or copy of datafile 8 found to restore
RMAN-06023: no backup or copy of datafile 7 found to restore
RMAN-06023: no backup or copy of datafile 6 found to restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restoreHow do I fix this? Thank you!!!!

Got 3289 from disk, registered via RMAN as follows:
RMAN> catalog start with '/data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1';
searching for all files that match the pattern /data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1
List of Files Unknown to the Database
=====================================
File Name: /data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1/o1_mf_1_3289_6qyhlwx0_.arc
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /data/scratch/KRONOS/backup/anya/arch/KRNTSTORA1/o1_mf_1_3289_6qyhlwx0_.arcRan restore/recovery script:
RMAN> run {
2> allocate channel c1 type disk;
3> set until sequence 3290;
4> set newname for datafile 00002 to '/data/scratch/KRONOS/backup/anya/tkcs1.dbf';
set newname for datafile 00003 to '/data/scratch/KRONOS/backup/anya/tkcs2.dbf';
set newname for datafile 00004 to '/data/scratch/KRONOS/backup/anya/tkcs3.dbf';
set newname for datafile 00005 to '/data/scratch/KRONOS/backup/anya/tkcs4.dbf';
set newname for datafile 00006 to '/data/scratch/KRONOS/backup/anya/tkcs5.dbf';
set newname for datafile 00007 to '/data/scratch/KRONOS/backup/anya/tkcs6.dbf';
set newname for datafile 00008 to '/data/scratch/KRONOS/backup/anya/tkcs7.dbf';
set newname for datafile 00009 to '/data/scratch/KRONOS/backup/anya/tkcs9.dbf';
set newname for datafile 00010 to '/data/scratch/KRONOS/backup/anya/tkcs8.dbf';
set newname for datafile 00001 to '/data/scratch/KRONOS/backup/anya/system.dbf';
set newname for datafile 00081 to '/data/scratch/KRONOS/backup/anya/undo01.dbf';
set newname for datafile 00082 to '/data/scratch/KRONOS/backup/anya/undo02.dbf';
set newname for datafile 00083 to '/data/scratch/KRONOS/backu5> p/anya/undo03';
set newname for datafile 00084 to '/data/scratch/KRONOS/backup/anya/undo04';
set newname for datafile 00085 to '/data/scratch/KRONOS/backup/anya/undo05.dbf';
set newname for datafile 00072 to '/data/scratch/KRONOS/backup/anya/sysaux01.dbf
6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21>
22> restore database;
23> switch datafile all;
24> recover database;
25> alter database open resetlogs;
26> release channel c1;
27> }
using target database control file instead of recovery catalog
allocated channel: c1
channel c1: sid=656 devtype=DISK
executing command: SET until clause
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 16-MAR-11
channel c1: starting datafile backupset restore
channel c1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /data/scratch/KRONOS/backup/anya/system.dbf
restoring datafile 00002 to /data/scratch/KRONOS/backup/anya/tkcs1.dbf
restoring datafile 00003 to /data/scratch/KRONOS/backup/anya/tkcs2.dbf
restoring datafile 00004 to /data/scratch/KRONOS/backup/anya/tkcs3.dbf
restoring datafile 00005 to /data/scratch/KRONOS/backup/anya/tkcs4.dbf
restoring datafile 00006 to /data/scratch/KRONOS/backup/anya/tkcs5.dbf
restoring datafile 00007 to /data/scratch/KRONOS/backup/anya/tkcs6.dbf
restoring datafile 00008 to /data/scratch/KRONOS/backup/anya/tkcs7.dbf
restoring datafile 00009 to /data/scratch/KRONOS/backup/anya/tkcs9.dbf
restoring datafile 00010 to /data/scratch/KRONOS/backup/anya/tkcs8.dbf
restoring datafile 00072 to /data/scratch/KRONOS/backup/anya/sysaux01.dbf
restoring datafile 00081 to /data/scratch/KRONOS/backup/anya/undo01.dbf
restoring datafile 00082 to /data/scratch/KRONOS/backup/anya/undo02.dbf
restoring datafile 00083 to /data/scratch/KRONOS/backup/anya/undo03
restoring datafile 00084 to /data/scratch/KRONOS/backup/anya/undo04
restoring datafile 00085 to /data/scratch/KRONOS/backup/anya/undo05.dbf
channel c1: reading from backup piece /data/scratch/KRONOS/backup/anya/datafiles.rmanOracle restored/recovered without errors :) Thank you! However, I dont understand why 3289 was not included in the backup when it is needed for recovery. Database and archvielog backup takes place in the same script as follows:
run
allocate channel c1 type disk;
crosscheck archivelog like '/data/flash_recovery_area/KRNTSTORA1%';
sql 'alter system archive log current';
backup database format '${BACKUP_DIR}/datafiles__${BACKUP_TYPE}_${TIMESTAMP}%p_%s.rman';
backup archivelog like '/data/flash_recovery_area/KRNTSTORA1%' format '${BACKUP_DIR}/arch_%d_%u_%s_%T';
backup current controlfile format '${BACKUP_DIR}/${ORACLE_SID}_${TIMESTAMP}_CTL';
delete noprompt archivelog like '/data/flash_recovery_area/KRNTSTORA1%' completed before 'sysdate-4' backed up 1 times to device type disk
}confusing :(

Scn in recovery

Hi
1-)
If I restored a datafile which has higher scn then controlfile and datafiles.
I think The only way to open the db is to recreate a controlfile or copy the old controlfile.
Correct me if I am wrong.
2-)
If I recreate the controlfile how does oracle determine checkpoint scn of the datafiles?
3-)
Even I`ve just recreated a new controlfile and copy a datafile which has high scn then other datafiles.
When I check;
select CHECKPOINT_CHANGE# from v$datafile, all numbers are equal.
What is the reason for that?

Situation 1) would arise when you have backups of datafiles from different points in time and you restore almost all the datafiles from a set prior to the last backup but one datafile from the last backup. (you can't be restoring a datafile from the future ! so you can't have restore a datafile with a higher SCN than the current SCN, ergo, the other datafiles have also been restored from a backup older than this one !)
In this case,
a) if you restore the controlfile, you use the "USING BACKUP CONTROLFILE" clause.
b) if you recreate the controlfile, you use the "USING BACKUP CONTROLFILE" clause.
(ie, the RECOVERY command is the same !)
2) : Oracle reads the datafile headers. It uses this information to determine the lowest SCN in the datafiles and identify which Log Sequence Numbers are required for recovery. Don't think of whether "oracle uses datafile headers to create the controlfile" {although it DOES do so}. Think of "oracle uses the datafile headers to determine SCNs and LSNs for Recovery !".
3) : Checkpoint Change# is as of the last Checkpoint. A Checkpoint could be a system checkpoint ("ALTER SYSTEM CHECKPOINT") or a Checkpoint initiated by a Log Switch or an Incremental Checkpoint (because of FAST_START_MTTR_TARGET) or a Tablespace Checkpoint (ALTER TABLESPACE command) or a Datafile checkpointed (ALTER DATABASE DATAFILE command). (Note : You will not see Incremental Checkpoints in the V$DATAFILE_HEADER)
Here's one example below. Notice one datafile having a different CHECKPOINT_CHANGE# with the ALTER TABLESPACE command.
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
           1183007
           1183007
           1183007
           1183007
           1183007
           1183007
6 rows selected.
SQL> alter tablespace users begin backup;
Tablespace altered.
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
           1183007
           1183007
           1183007
           1204726
           1183007
           1183007
6 rows selected.
SQL> alter tablespace users end backup;
Tablespace altered.
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
           1183007
           1183007
           1183007
           1204726
           1183007
           1183007
6 rows selected.
SQL> Hemant K Chitale
http://hemantoracledba.blogspot.com
Edited by: Hemant K Chitale on May 31, 2009 11:41 PM

Best Practice For Database Parameter ARCH_LAG_TARGET and DBWR CHECKPOINT

Hi,
For best practice - i need to know - what is the recommended or guideline concerning these 2 Databases Parameter.
I found for ARCH_LAG_TARGET, Oracle recommend to setup it to 1800 sec (30min)
Maybe some one can guide me with these 2 parameters...
Cheers

Dear unsolaris,
First of all if you want to track the full and incremental checkpoints, make the LOG_CHECKPOINT_TO_ALERT parameter TRUE. You will see the checkpoint SCN and the completion periods.
Full checkpoint is being triggered when a log switch happens and checkpoint position in the controlfile is written in the datafile headers. For just a really tiny amount of time the database could be consistent eventhough it is open and in read/write mode.
ARCH_LAG_TARGET parameter is disabled and set to 0 by default. Here is the definition for that parameter;
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams009.htm
If you want to set this parameter up the Oracle recommends it to be 1800 as you have said. This can subject to change from database to database and it is better for you to check it by experiencing it.
Regards.
Ogan

Scn in redologs and controlfile

Hi
The checkpoint scn in datafile headers are updated after checkpoint.
How about redologs and controlfile?
As far I read from the docs
scn's are written to redo logs continuously, it should also stored in controlfile continuesly(every commit) so that controlfile will know where redochain ends ..
Is that right?

Hi,
The checkpoint scn in datafile headers are updated after checkpoint.
Yes. By CKPT process.
scn's are written to redo logs continuously
Yes, by LGWR every COMMIT IMMEDIATE.
+ it should also stored in controlfile continuesly(every commit) so that controlfile will know where redochain ends ..+
Even if it is in controlfile then it is NOT updated every commit.
Bartek

ORA-26667 during checkpoint retention check

HI Guys
I have an environment which is being replicated in 2 ways (DML,DDL ) RDBMS 10.2.0.4 , each RDBMS is running in RAC (3 nodes one RDBMS) and another running (2 nodes RAC) everything was running without problems for the last 3 months however last weekend I got
Sat Feb 14 23:18:41 2009
STREAMS Warning: ORA-26667 during checkpoint retention check <= this message is the first kind of message that we got
Sun Feb 15 05:18:43 2009
STREAMS Capture C 1: first scn changed.
scn: 0x0009.79468518
However I took a look that day and I dint find any issue I looked for that problem in metalink but I didn't find any problem , this message came out when the checkpoint retention time moved
the checkpoint retention time in streams is a number of days that the capture process retains checkpoints before purging them automatically . A capture process periodically computes the age of a checkpoint by subtracting the next_time of the archived redo log that corresponds to the checkpoint from dba_capture.first_time of the archived redo log file containing the required checkpoint scn
if the resulting value is grater than the checkpoint retention time then the capture process automatically purges the checkpoint by advancing the dba_capture.first_scn value all the archived retained by the dba_caprure process can be seen using dba_registered_archived_log view
the default retention time is 60 days
i didnt find any error in the RDBMS therefore I didnt do anything but on Monday morning I got a lot of replication errors caused by
ORA-01403 , after fixing all those errors I changes of the database that I got that error were not replicated across the other database , it could explain why many tables got out of sync , seems the reason was the propagation process was hanging , I stopped and restarted no changes were received in the other database , as a workaround I recreate it and the problem was fixed . Have you had a problem like this before ?
Rgds

browsing on Metalink seems the way to trace the root cause of this kind of problem is running the Oracle Streams Healtcheck right away after we got this kind of problem , seems the error that I got was just a coincidence because there is nothing related

First SCN

10.2.0.5 4 Node RAC cluster with Stream -
We have few XA transactions on the source database and the commit/rollback/failure of the transaction is not understood by streams. The first SCN position is set to the start_scn of that transaction - It never advances. In certain scenario When we re-start streams it goes back to the first_scn -
I have few questions -
1) How can we monitor the first_scn of the capture process- Is there any dba views we can refer to
2)once we encounter a First SCN which is void we need to manually advance it. - We need to get the min(scn) from gv$transaction and compare it to the checkpoint scn.
First_scn will be set to the scn whichever is lower . Is there any procedure we can use for altering the capture process first scn.
Thanks in advance

You can query dba_capture:
SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;
You can reset the start SCN using the alter capture subprogram:
BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name => 'your_capture_name',
start_scn => your_new_start_SCN_as_a_number_not_string);
END;
/

Checkpointing - control file contents question

Some clarification is needed if possible...
When you commit a transaction:
- commit scn is recorded in the itl of the data block and undo segment header
- lgwr records the committed scn (for all data blocks involved) to the redo log
Checkpoint Event
- (3 seconds or possibly less passes by) CKPT wakes up and signals DBWn to write dirty (modified and committed)
blocks to disk
- CKPT records the scn of those blocks in the control file (data file and redo thread sections) and the data file
header (task of checkpoint when a log switch occurs)
- Checkpoint position in the Redo Log is forwarded
Control file contents question:
When LGWR writes the commit scn to the redo log, who writes the scn to the control file? LGWR or CKPT?
Also, when is the redo thread scn written?
Matt

Matt,
This is my understanding of the stuff. Feel free to correct me.
Checkpoint SCN , as I mentioned in my last reply is the marker of the point till which the data is "chekpointed" to the datafiles. This marker tells the controlfile that in the case of the crash, where to start recovery of the datafile and have to go which extent in the redo stream? This is only available in the datafile header and in the controlfile. This doesn't get recorded in the redo log file/stream.
I mentioned checkpoint queue in my reply too. Though I couldn't find any reference directly mentioned between this and in the checkpoint SCN but I believe my theory , if not totall, partially is correct. The incremental checkpoint is the stuff which makes the decision that how many redo blocks needs to be applied to the datafile if its closed without a proper checkpoint. So this part is maintained in the Datafile header itself in the form of the checkpoint SCN. When not matched with the conrolfile checkpoint SCN, which is always higher than this, a recovery is reported.
I hope its somewhat correct. Do let me know your views too.
Cheers
Aman....

11.2.0.3 Database shutdown after a checkpoint

Hi ,
I am just doing a backup and recovery scanrio in 11.2.0.3.
I am running in archivelog mode
i just crash the users.dbf file
and type the alter system checkpoint command
then database shuts down abnormally
usually in archive log mode just because a normal .dbf file crashes it won't shutdown .
but this is unusual . Can some body explain why ?

909592 wrote:
This is because at checkpoint oracle will update controlfile checkpoint scn and all datafiles header scns... So now while scaning user.dbf, it found that its missing and cannot update its header..so ckpt process cannot be processed and will shutdown abnormally. Please check what errors you have found in alert.log and in background process dump area(for errors related to abnormal shutdown of background process) to confirm this
Hope this helpsI don't think that the explanation is correct since teh user01.dbf is just another datafile, losing which would cause the checkpoint not to complete only on this datafile. So crashing the whole db for one file's loss would be a little too much.
@OP,
I have 11203 and I shall be testing the same by tomorrow. In the meanwhile, do check for any other information that's there for the time when the node got rebooted.
Aman....

Header datafile and SCN

Hi every body,
The controlfile contains the current SCN and the checkpoint SCN. that is right ?
In my search, I found that every datafile online and in read write mode, contain in his header the scn checkpoint.
But, I think that it contains only the last scn applied to this datafile. that is right?
Without this last scn in the datafile, how oracle know when he is stopped writing to the datafile in case of failure, to recover it ?
Thank in advance for your answers.

user622061 wrote:
Thank you a lot for the links.
I did a test :
BEFORE TEST
v$database :
CHECKPOINT_CHANGE# CURRENT_SCN
13114719 13117108
v$datafile :
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
C:\ORACLE\ORADATA\BDD10G\TBS1_01.DBF 13117132
v$datafile_header :
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
C:\ORACLE\ORADATA\BDD10G\TBS1_01.DBF 13117132
v$logfile and v$log :
MEMBER STATUS
C:\ORACLE\ORADATA\BDD10G\REDO01.LOG INACTIVE
C:\ORACLE\ORADATA\BDD10G\REDO02.LOG CURRENT
C:\ORACLE\ORADATA\BDD10G\REDO05.LOG UNUSED
TEST
create table toto ( a varchar2(30)) tablespace tbs1 ;
insert into table toto values ('SEBASTIAN');
commit;
AFTER TEST
v$datafile :
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
C:\ORACLE\ORADATA\BDD10G\TBS1_01.DBF 13117132
v$datafile_header :
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
C:\ORACLE\ORADATA\BDD10G\TBS1_01.DBF 13117132
the checkpoint_change# for this datafile is the same, before and after insert and commit a data in this tablespace.That's correct! The reason for this is that Oracle won't go and ask DBWR to write into the datafile with each and every commit of yours. You have ended a transaction, that's all! Now, the results of that transaction is updated already by LGWR into the redo log file. The checkpoint number(not SCN) is not updated by DBWR since this would happen in the case it would do a full Checkpoint.
To inspect the contents of this datafile, I use some OS commands : I search the word "SEBASTIEN" !
The first time, I didn't find it.
few minutes later, I found the word "SEBASTIEN" --> So my datafile is updated by the insert I did.Correct again! DBWR would write when it would think it's good to write. So not at the time of commit but after some time, DBWR updated the contents into the datafile.
But, the problem is that his checkpoint_change# still the same = 13117132As I have explained , it won't change, not so quickly.
>
>
You can reproduce the test !
My problem is to understand how Oracle ( DBWR) can update a datafile with data related to the SCN newer than the SCN registered in the header of datafile ?DBWR would have the list of the dirty buffer's list with it which it would periodically. If there is a commit and the data is updated in the logfile, the contents logged into the redo log file would be checkpointed in thedatafile after some time. This commit event, stored in the log file, is also recorded inthe control file. That's how Oracle knows, in the event of a crash, that to what extent they have to do the recovery since the stop checkpoint is already noted in the controlfile.
If Oracle did it, how can he know the last SCN on every datafile.It doesn't need to. Control file has it.
HTH
Aman....

How SCN sync after the tablespace is put back to END Backup mode

When we put the tablespace in begin backup mode, the scn get forzen and it will not be further updated, until it is put back to end backup.
Question is : If at the time of being backup , say the snc forzed at 45. Before we put back the tablespace to end back up , we had genrerated 10 SCN. Then the current scn is 55. If we put the tablespace in end backup , does the datafile will start with scn 56 ( by maintaint it previous scn at 45)
Or after we put back the tsp in end back up , does the datafile will be updated from 46 to 55 , before it is updated with scn 56.
In the above example i am considering by db has one datafile only.
Thanks
Naveen

Are you implying that the "Checkpoint number" is a different series of numbers --
seperate from SCNs ?
Are you implying that when a checkpoint occurs it is this "Checkpoint number"
that is incremented and written to the datafile headers ?
There really is no such thing as a "Checkpoint number".
If you look at the definitions of V$DATABASE , V$DATAFILE and V$DATAFILE_HEADER, you would see that a Checkpoint increments the SCN.
A header can have multiple entries -- a Checkpoint SCN (called CHECKPOINT_CHANGE#) , ArchiveLog SCN (called ARCHIVELOG_CHANGE#),
the Current SCN (called CURRENT_SCN), SCN of last Unrecoverable (Nologging)
(called UNRECOVERABLE_CHANGE#) etc etc. They are all derived from SCNs
only.
The SCN is used as the single point of reference. Thus, we can compare
CHECKPOINT_CHANGE# with CURRENT_SCN with UNRECOVERABLE_CHANGE# etc.

Difference between switch logfile and checkpoint

Hi All,
what is the difference between
Forcing log file switches:
ALTER SYSTEM switch logfile;
and
ALTER SYSTEM checkpoint;
when i should use one and not use the other
Thanks very much

I don't know that checkpoint will increase the scn. In a way it can be called correct but there are multitudes of SCN floating around. For example, for the matching of the datafiles and controlfles, there are two scn's which are used, stop scn and checkpoint scn. Than for the block, there can be , commit scn , transaction scn , High scn and low scn. There is one counter that is there for both checkpoint and SCN and checkpoint number is generated from SCN itself. I am sure that there is a missing link here some where but still, to some extent this is correct.
Checkpointing is an event which happens at certain conditions and SCN is always there, just like in a clock, there is always a time.
HTH
Aman....

CHECKPOINTS, SCN, LSN

Similar Messages

Maybe you are looking for