recreate controlfile (inside) [message #50390] |
Wed, 13 March 2002 19:02 |
forest_man
Messages: 1 Registered: March 2002
|
Junior Member |
|
|
I get a script using 'alter database backup controlfile to trace',then shutdown the database normal,recreate the controlfile in nomount state.I want to know what the checkpoint and log sequence number the new controlfile has in this time.I open the database using the new controlfile,how the database know it is consistent? Is it a complete recovery?
|
|
|
Re: recreate controlfile (inside) [message #50393 is a reply to message #50390] |
Wed, 13 March 2002 20:16 |
seng
Messages: 191 Registered: February 2002
|
Senior Member |
|
|
The checkpoint and log sequence number is sama as old database when new database is in nomount state. If the database is open resetlogs then log sequence number will set to 1.
Database has indicator to check the consistensi.
it shouldn't call complete recovery. it is more to change some structure setting in controlfile or duplicate database.
hope this is helping.
|
|
|
Re: recreate controlfile (inside) [message #50405 is a reply to message #50390] |
Thu, 14 March 2002 01:10 |
R.Muralidhar
Messages: 5 Registered: March 2002
|
Junior Member |
|
|
Hi forest man,
I think this space is not sufficient to give the answer to this query.I would suggest u read BACKUP AND RECOVERY principles by RAMA VELPURI.It will give u a very good explanation.
Regards
R.Muralidhar
|
|
|
Re: recreate controlfile (inside) [message #51288 is a reply to message #50390] |
Sun, 12 May 2002 22:26 |
kwalther
Messages: 9 Registered: April 2002
|
Junior Member |
|
|
There are three phases of startup:
Phase 1: The init.ora file is read and the memory structures are created.
Phase 2: The database is mounted which opens the controlfile, and the commands "recover database" and "alter database"...etc can be used to dump information into trace files for some interesting reading later.
Phase 3: All the datafiles and logfiles are verified as cool to use.
The controlfile is a metadata repository for the physical database.
It's binary and is updated with any physical changes whenever you add or rename a file.
Here's the deal with Checkpoint counters and system change numbers. Whenever there is a checkpoint, the system change number changes too.
Each datafile and controlfile has a file header that records checkpoints. They both have to match; checkpoints in datafiles have to match checkpoints in the controlfile. If they don’t match, data recover needs to be done. System Change Numbers are another issue.
Part of the checkpoint structure includes a system change number (SCN). The SCN defines a committed version of the database at a precise moment of time. When a transaction commits, it gets a unique SCN that identified that specific transaction.
Let's call the SCN in the datafile "START" SCN, and the one in the controlfile, we'll call "STOP" SCN.
Everytime there's a checkpoint, the datafile START is incremented by one. Meanwhile the controlfile STOP stays at infinity during normal operation.
When you shutdown the database normally, the STOP in the controlfile will change to match the START. Hence, the controlfile can record when the datafile changes stopped.
When you reopen the datafile, Oracle checks to make sure the two checkpoints match, then it moves to the issue of SCN’s. If the STOP in the controlfile matches the START in the datafile, no recovery needs to be made. Every START in every datafile has to match the STOP in the controlfile, or it’s considered hosed. When everything is cool, the STOP SCN in the controlfile is changed to infinity again as it waits for another shutdown. The cycle happens everytime you startup and shutdown the database.
"I want to know what the checkpoint and log sequence number the new controlfile has in this time"
Judging from the above, the controlfiles will synchronize with the Checkpoints of the datafiles. The system change numbers are another story but I've run out of time, and I have to crash. More later....
|
|
|