SCN /resetlogs question

I need some reference to get a simple minded understaning of SCN and the relationship to resetlogs.
This is the sequence of events as far as I can tell.
Database files were tar'ed and hardware was reconfigured.
The files were then un - tar'ed back into an area smaller than the original.  After the files were untarred, I attempted to start the database.  Some error messages came out that indicated I could recover until cancel which I did for one of the three databases and everything was fine.  Apparently noticing the space situation and the other two data bases giving error messages someone started trying to make space and deleted some files.  When I tried starting the database i had recovered, i got error messages.  I had my own backup of the data files  and replaced them.   At this point I resetlogs,
immediately made a backup.  Again files were deleted, this time all the datafiles plus the backup I had made immediately after the resetlogs.  Now SCN questions.  How does SCN relate to datafiles and /or controlfiles?
Who is Participating?
anand_2000vConnect With a Mentor Commented:
SCN is one of the different parts used in Oracle for syncronization. You might have noticed that the logfile sequence was reset to 1 after resetlogs. However SCN continued in the same manner. Resetting the SCN is not possible.  After you have given resetlogs you cannot use the previous backup datafiles for recovery unless you use the earlier controlfile also.
schwertnerConnect With a Mentor Commented:
System Change Number
Whenever a transaction commits, the Oracle server assigns a commit system change
number (SCN) to the transaction. The SCN is monotonically incremented and is
unique within the database. It is used by the Oracle server as an internal time stamp to
synchronize data and to provide read consistency when data is retrieved from the data
files. Using the SCN enables the Oracle server to perform consistency checks without
depending on the date and time of the operating system.

Steps in Processing COMMITs
When a COMMIT is issued, the following steps are performed:
1 The server process places a commit record, along with the SCN, in the redo log
2 LGWR performs a contiguous write of all the redo log buffer entries up to and
including the commit record to the redo log files. After this point, the Oracle server
can guarantee that the changes will not be lost even if there is an instance failure.
3 The user is informed that the COMMIT is complete.
4 The server process records information to indicate that the transaction is complete
and that resource locks can be released.
Flushing of the dirty buffers to the data file is performed independently by DBW0 and
can occur either before or after the commit.
xoxomosAuthor Commented:
I thing that was part of the problem
..."unless you use the earlier controlfile also. "
But I included the controlfile in the backup
When I did the restore, it restored the controlfile.
From console
Starting restore at 04-NOV-03

using target database controlfile instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=10 devtype=DISK
channel ORA_DISK_1: restoring controlfile
channel ORA_DISK_1: restore complete
replicating controlfile
input filename=/u01/app/oracle/oradata/haypsdmd/control01.ctl
output filename=/u01/app/oracle/oradata/haypsdmd/control02.ctl
output filename=/u01/app/oracle/oradata/haypsdmd/control03.ctl
Finished restore at 04-NOV-03

xoxomosAuthor Commented:
Sonds like Kong is saying i could have used any datafile 1 older than scn 162043.

What happened was you were able to recover the controlfile, what you had to do next was recover the datafiles then roll the database forward. If you only recovered the controlfile then it would have had an SCN < the datafiles that's why you got: RMAN-06556: datafile 1 must be restored from backup older than scn 162043

All Courses

From novice to tech pro — start learning today.