 | "kccrsz: expanded controlfile" message | 28 July 1999 |
|
I found a bunch of these in the alert.log file during a period where batch loads were causing rapid redo log rolling.
kccrsz: expanded controlfile section 11 from 755 to 769 records Did the control file actually grow in size or was it just starting to use previously unused space? | ||
 | Controlfiles can grow under version 8. Section 11 is the log history. The slots in this section are cyclically reusable, but will not be reused within control_file_record_keep_time, which defaults to 7 days. The controlfile will grow instead. If you want a statically sized controlfile, then you must set this parameter to 0. |
|
| Datafile size | 13 November 1999 |
| Do the data dictionary views like DBA_DATA_FILES and V$DATAFILE go out to the control file for the size of the datafiles? | ||
| DBA_DATA_FILES reflects what is in SYS.FILE$, whereas V$DATAFILE reads directly from the controlfile (every time it is referenced). |
|
| Timestamps | 9 December 1999 |
| Does Oracle record timestamps inside the datafile or datablock headers? | ||
| Yes, Oracle does record a timestamp with each of the various SCNs in the datafile and log file headers, and in the corresponding places in the controlfile, but not in data block headers. |
|
| control file parallel write | 3 March 2000 |
| I've had 227,750 waits for control file parallel write. V$SESSION_EVENT shows 15 waits by ARCH, 3 by DBW0 and 277,702 by LGWR. What is LGWR doing, or is there an I/O bottleneck? Also, where did the other 30 waits go? | ||
| I suspect that it is in fact the CKPT process, rather than the LGWR process that is waiting here. In 8.0.5 a heartbeat mechanism was included in CKPT's timeout action (every 3 seconds) to update the checkpoint progress record for the thread in the controlfile. Join V$SESSION_EVENT.SID to V$SESSION.SID and V$SESSION.PADDR to V$BGPROCESS.PADDR to confirm. The other 30 waits would be from controlfile transactions by foreground sessions that have since disconnected. |
|
| Mount lock and lock file | 16 March 2000 |
|
I changed $ORACLE_HOME for a database and could not start it up again (ORA-9968).
Oracle said that the problem was that the $ORACLE_HOME/dbs/lkDBNAME file was still open
even though the database had been shutdown.
The solution was to recreate the controlfile using a CREATE CONTROLFILE script.
I am confused. I have dumped the controlfile and I don't see any reference to $ORACLE_HOME. How can this happen? | ||
| It is the mount lock (or more correctly, the mount id and related information) that is in the controlfile, not the location of $ORACLE_HOME. There should be an equivalence between the mount lock and the lock file under $ORACLE_HOME. The problem was that the database appeared to be mounted (in the controlfile) but the lock file was not there, because $ORACLE_HOME had changed when the database was not down cleanly. |
| Copyright © Ixora Pty Ltd |
|