Presentation on theme: "ITEC474 Control File Maintenance. Objectives These notes explain how: – a control file is used. – to examine control file content. – to multiplex control."— Presentation transcript:
ITEC474 Control File Maintenance
Objectives These notes explain how: – a control file is used. – to examine control file content. – to multiplex control files. – to manage control files with an Oracle Managed Files (OMF) approach.
Control File Control File is a small binary file that stores information needed to startup an Oracle database and to operate the database.
Control File (cont.) A control file belongs to only one database. A control file(s) is created at the same time the database is created based on the CONTROL_FILES parameter in the PFILE. If all copies of the control files for a database are lost/destroyed, then database recovery must be accomplished before the database can be opened. An Oracle database reads only the first control file listed in the PFILE; however, it writes continuously to all of the control files (where more than one exists). You must never attempt to modify a control file as only the Oracle Server should modify this file. While control files are small, the size of the file is affected by the following CREATE DATABASE or CREATE CONTROLFILE command parameters if they have large values. – MAXLOGFILES – MAXLOGMEMBERS – MAXLOGHISTORY – MAXDATAFILES – MAXINSTANCES
Contents of a Control File Control files record the following information: – Database name – recorded as specified by the initialization parameter DB_NAME or the name used in the CREATE DATABASE statement. – Database identifier – recorded when the database is created. – Time stamp of database creation. – Names and locations of datafiles and online redo log files. This information is updated if a datafile or redo log is added to, renamed in, or dropped from the database. – Tablespace information. This information is updated as tablespaces are added or dropped. – Redo log history – recorded during log switches. – Location and status of archived logs – recorded when archiving occurs. – Location and status of backups – recorded by the Recovery Manager utility. – Current log sequence number –recorded when log switches occur. – Checkpoint information – recorded as checkpoints are made.
Multiplexing Control Files Control files should be multiplexed – this means that more than one identical copy is kept and each copy is stored to a separate, physical disk drive – of course your Server must have multiple disk drives in order to do this. Even if only one disk drive is available, you should still multiplex the control files. – This eliminates the need to use database recovery if a copy of a control file is destroyed in a disk crash or through accidental deletion. – You can keep up to eight copies of control files – the Oracle Server will automatically update all control files specified in the initialization parameter file to a limit of eight. – More than one copy of a control file can be created by specifying the location and file name in the CONTROL_FILES parameter of the PFILE when the database is created. – During database operation, only the first control file listed in the CONTROL_FILES parameter is read, but all control files listed are written to in order to maintain consistency. – One approach to multiplexing control files is to store a copy to every disk drive used to multiplex redo log members of redo log groups.
Multiplexing Control Files (cont.) You can also add additional control files. When using a PFILE, this is accomplished by shutting down the database, copying an existing control file to a new file on a new disk drive, editing the CONTROL_FILES parameter of the PFILE, then restarting the database.
Multiplexing Control Files (cont.) If you are using an SPFILE, you can use the steps specified in the figure shown here. The difference is you name the control file in the first step and create the copy in step 3.
Create New Control Files Command A DBA will create new control files in these situations: – All control files for the database have been permanently damaged and you do not have a control file backup. – You want to change the database name. For example, you would change a database name if it conflicted with another database name in a distributed environment. Note: You can change the database name and DBID (internal database identifier) using the DBNEWID utility.
Example CREATE CONTROLFILE SET DATABASE USER350 LOGFILE GROUP 1 ('/u01/oradata/prod/redo01_01.log', '/u02/oracle/prod/redo01_02.log'), GROUP 2 ('/u01/oracle/prod/redo02_01.log', '/u02/oracle/prod/redo02_02.log'), GROUP 3 ('/u01/oracle/prod/redo03_01.log', '/u02/oracle/prod/redo03_02.log') RESETLOGS DATAFILE '/u01/.../system01.dbf' SIZE 350M, '/u01/.../sysaux01.dbf' SIZE 350M, '/u02/.../undo01.dbf' SIZE 64M, '/u02/.../users01.dbf' SIZE 5M '/u02/.../temp01.dbf' SIZE 64M MAXLOGFILES 50 MAXLOGMEMBERS 3 MAXLOGHISTORY 400 MAXDATAFILES 200 MAXINSTANCES 6 ARCHIVELOG;
Creating New Control Files The CREATE CONTROLFILE statement can potentially damage specified datafiles and redo log files. It is only issued as a command in NOMOUNT stage. Omitting a filename can cause loss of the data in that file, or loss of access to the entire database. Use caution when issuing this statement and be sure to follow the instructions in "Steps for Creating New Control Files" (Next Slide). If the database had forced logging enabled before creating the new control file, and you want it to continue to be enabled, then you must specify the FORCE LOGGING clause in the CREATE CONTROLFILE statement.
Steps for Creating New Control Files Steps to use when a control file must be recreated: 1. Make a list of all datafiles and redo log files of the database. SELECT MEMBER FROM V$LOGFILE; SELECT NAME FROM V$DATAFILE; SELECT VALUE FROM V$PARAMETER WHERE NAME = 'control_files'; If you have no such lists and your control file has been damaged so that the database cannot be opened, try to locate all of the datafiles and redo log files that constitute the database. Any files not specified in step 5 are not recoverable once a new control file has been created. Moreover, if you omit any of the files that comprise the SYSTEM tablespace, you might not be able to recover the database. 2. Shut down the database. If the database is open, shut down the database normally if possible. Use the IMMEDIATE or ABORT clauses only as a last resort.
Steps for Creating New Control Files (cont.) 3. Back up all datafiles and redo log files of the database. 4. Start up a new instance, but do not mount or open the database: STARTUP NOMOUNT 5. Create a new control file for the database using the CREATE CONTROLFILE statement. When creating a new control file, specify the RESETLOGS clause if you have lost any redo log groups in addition to control files. In this case, you will need to recover from the loss of the redo logs (step 8). You must specify the RESETLOGS clause if you have renamed the database. Otherwise, select the NORESETLOGS clause. 6. Store a backup of the new control file on an offline storage device. 7. Edit the CONTROL_FILES initialization parameter for the database to indicate all of the control files now part of your database as created in step 5 (not including the backup control file). If you are renaming the database, edit the DB_NAME parameter in your instance parameter file to specify the new name.
Steps for Creating New Control Files (cont.) 8. Recover the database if necessary. If you are not recovering the database, skip to step 9.9 If you are creating the control file as part of recovery, recover the database. If the new control file was created using the NORESETLOGS clause (step5), you can recover the database with complete, closed database recovery.5 If the new control file was created using the RESETLOGS clause, you must specify USING BACKUP CONTROL FILE. If you have lost online or archived redo logs or datafiles, use the procedures for recovering those files. 9. Open the database using one of the following methods: If you did not perform recovery, or you performed complete, closed database recovery in step 8, open the database normally.8 ALTER DATABASE OPEN; If you specified RESETLOGS when creating the control file, use the ALTER DATABASE statement, indicating RESETLOGS. ALTER DATABASE OPEN RESETLOGS;
What if a Disk Drive Fails? Recovering a Control File Use the following steps to recover from a disk drive failure that has one of the database’s control files located on the drive. – Shut down the instance. – Replace the failed drive. – Copy a control file from one of the other disk drives to the new disk drive – Restart the instance. If the new disk drive does not have the same disk drive name as the damaged disk drive or if you are creating a new copy while awaiting a replacement disk drive, then alter the CONTROL_FILES parameter in the PFILE prior to restarting the database. – No media recovery is required. – If you are awaiting a new disk drive, you can alter the CONTROL_FILES parameter to remove the name of the control file on the damaged disk drive – this enables you to restart the database.
Backup Control Files and Create Additional Control Files Oracle recommends backup of control files every time the physical database structure changes including: – Adding, dropping, or renaming datafiles. – Adding or dropping a tablespace, or altering the read/write state of a tablespace. – Adding or dropping redo log files or groups. Use the ALTER DATABASE BACKUP CONTROLFILE statement to backup control files. ALTER DATABASE BACKUP CONTROLFILE TO ‘...oradata/backup/control.bkp’ ; Now use an SQL statement to produce a trace file (write a SQL script to the trace file) that can be edited and used to reproduce the control file. ALTER DATABASE BACKUP CONTROLFILE TO TRACE; To create additional control files follow the steps specified earlier for multiplexing control files.
Dropping a Control File Control files are dropped when a location is no longer appropriate, e.g., a disk drive has been eliminated from use for a database. 1. Shut down the database. 2. Edit the init.ora file CONTROL_FILES parameter by removing the old control file name. 3. Restart the database.
Oracle Managed Files Approach Control files are automatically created with the Oracle Managed Files (OMF) approach during database creation even if you do not specify file locations/names with the CONTROL_FILES parameter— it is preferable to specify file locations/names. With OMF, if you wish to use the init.ora file to manage control files, you must use the filenames generated by OMF. – The locations are specified by the DB_CREATE_ONLINE_LOG_DEST_n parameter. – If the above parameter is not specified, then their location is defined by the DB_CREATE_FILE_DEST parameter. Control file names generated with OMF can be found within the alertSID.log that is automatically generated by the CREATE DATABASE command and maintained by the Oracle Server.
Control File Information Several dynamic performance views and SQL*Plus commands can be used to obtain information about control files. – V$CONTROLFILE – gives the names and status of control files for an Oracle Instance. – V$DATABASE – displays database information from a control file. – V$PARAMETER – lists the status and location of all parameters. – V$CONTROLFILE_RECORD_SECTION – lists information about the control file record sections. SHOW PARAMETER CONTROL_FILES command – lists the name, status, and location of control files. CONNECT / AS SYSDBA SELECT name FROM v$controlfile;
Control File Information (cont.) SELECT name, value FROM v$parameter WHERE name='control_files'; DESC v$controlfile_record_section; SELECT type, record_size, records_total, records_used FROM v$controlfile_record_section WHERE type='DATAFILE'; The RECORDS_TOTAL shows the number of records allocated for the section that stores information on data files. Several dynamic performance views display information from control files including: – V$BACKUP – V$DATAFILE, – V$TEMPFILE – V$TABLESPACE – V$ARCHIVE – V$LOG – V$LOGFILE